Thread (37 messages) 37 messages, 6 authors, 2015-04-13

Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2015-02-24 00:51:17
Also in: lkml

On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote:
On Friday 20 February 2015 22:21:43 Mario Limonciello wrote:
quoted
On 02/20/2015 02:41 PM, Pali Rohár wrote:
quoted
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:
I have BIOS version A05 on my E6440 machine. That version
does not have problems with "repeating keys" and my
workaround for ALPS touchpad (which is in mainline tree and
-stable trees now) works fine. If I do not see other
problems, I will not update BIOS (just because current
version working -- with workarounds).

But CCing Rob. He told me as first about existence of new
BIOS version for E6440 and he is already testing new
version of BIOS, so can share details.

Mario, can you share some details about that new BIOS
update? If it is not secret, how was problem with
"repeating keys" fixed? Why linux had more problems as
Windows? Cannot we implement some "workaround" in linux
kernel to prevent that (or similar) problems in future?
It's a bit ironic really.  The problem was introduced because
a timer was added to the EC last year to fix a key repeating
problem found on Windows.  In doing so the EC was blocking
"BREAK" from being sent to the OS.  Windows OS didn't mind
this, but Linux did. The fix doesn't block BREAK anymore.
Thank you for information!

Mario, do you know if it is possible to "switch" keyboard into 
mode under which Fn key will send scancode (like Ctrl or Alt) 
when presses, so it could be possible to use any Fn+key 
combination for keyboard shortcuts? Because now Fn+F* send one 
scancode (e.g. suspend key) and other combination of Fn+something 
does not work...

Dmitry, should not Linux follow this Windows input behaviour? For 
year we have seen people complaining about non working keyboard 
on Dell laptops under Linux (when user Windows it worked)...
I am not sure what exactly the issue is... We do need to have the break
code to know when the key is released. We can't go and say that we will
release old key when we detect another key press as that would mess up
key combination handling (like control, meta, etc).

What does Windows driver do? 

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help