Hi,
There is a bug in the processing of the Fn key on the first generation
of Dell XPS 13 laptops (at least models L321X and L322X have the problem).
It happens with the combinations for Home, End, Page Up and Page Down
keys, achieved with pressing Fn with respectively Left, Right, Up and
Down. If the Fn key is released before the other key, the release of
the other key is not passed through. In that case, an auto-repeat of
the key may activate itself until any other key is pressed.
This is confirmed by running evtest:
Event: time 1485332907.361701, type 4 (EV_MSC), code 4 (MSC_SCAN), value cf
Event: time 1485332907.361701, type 1 (EV_KEY), code 107 (KEY_END), value 1
Event: time 1485332907.659714, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
The second MSC_SCAN happens when the Fn key is released and after it,
until any key is pressed again, the End key is considered pressed and
auto-repeating eventually starts.
Another similar situation happens if for instance the Right key is
pressed, then the Fn key is pressed before the Right key is released.
The subsequent release of the Right key is not passed through:
Event: time 1485333101.589438, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
Event: time 1485333101.589438, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 1
Event: time 1485333101.959561, type 4 (EV_MSC), code 4 (MSC_SCAN), value cf
Interestingly, after such an event, if the not-released-key is pressed
again, the key press is not registered by whatever application has the
focus and evtest shows the following:
Event: time 1485333306.755393, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
Event: time 1485333306.755393, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 2
Event: time 1485333306.847098, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
Event: time 1485333306.847098, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 0
The same happens after the first sequence (first Fn press, then Right
press), the value with KEY_END is 2 on press and then 0 on release.
I tested this on kernel 4.8 (live Ubuntu 16.10) but I haven't tested
it with the latest vanilla kernel just yet. I searched through
linux-input archives and found some threads about repeating keys, but
this looks like a different problem altogether. Also note that on my
L321X I've upgraded the BIOS to the latest version (A08) long ago.
The problem doesn't appear either on the Linux console or in Windows.
Do you think this is something that could be fixed in the input
driver?
Regards,
Ignacy
--
Sex on TV doesn't hurt....unless you fall off.
On Wed, Jan 25, 2017 at 12:47 AM, Ignacy Gawędzki [off-list ref] wrote:
Hi,
There is a bug in the processing of the Fn key on the first generation
of Dell XPS 13 laptops (at least models L321X and L322X have the problem).
It happens with the combinations for Home, End, Page Up and Page Down
keys, achieved with pressing Fn with respectively Left, Right, Up and
Down. If the Fn key is released before the other key, the release of
the other key is not passed through. In that case, an auto-repeat of
the key may activate itself until any other key is pressed.
This is confirmed by running evtest:
Event: time 1485332907.361701, type 4 (EV_MSC), code 4 (MSC_SCAN), value cf
Event: time 1485332907.361701, type 1 (EV_KEY), code 107 (KEY_END), value 1
Event: time 1485332907.659714, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
The second MSC_SCAN happens when the Fn key is released and after it,
until any key is pressed again, the End key is considered pressed and
auto-repeating eventually starts.
Another similar situation happens if for instance the Right key is
pressed, then the Fn key is pressed before the Right key is released.
The subsequent release of the Right key is not passed through:
Event: time 1485333101.589438, type 4 (EV_MSC), code 4 (MSC_SCAN), value cd
Event: time 1485333101.589438, type 1 (EV_KEY), code 106 (KEY_RIGHT), value 1
Event: time 1485333101.959561, type 4 (EV_MSC), code 4 (MSC_SCAN), value cf
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very naive
as it emits "release" keycodes for the state FN is currently in, not
the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
Thanks.
--
Dmitry
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry Torokhov:
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very naive
as it emits "release" keycodes for the state FN is currently in, not
the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be fixed
or worked around in the input driver, since the bug obviously doesn't
show up in neither in the linux console nor in Windows.
What do you think?
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
On Thu, Feb 02, 2017 at 09:40:33AM +0100, Ignacy Gawędzki wrote:
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry Torokhov:
quoted
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very naive
as it emits "release" keycodes for the state FN is currently in, not
the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be fixed
or worked around in the input driver,
Well, obviously I'd rather fix the bug at its root rather than piling
workarounds in the driver.
since the bug obviously doesn't
show up in neither in the linux console nor in Windows.
So where does it not work in Linux? Because keyboard driver in console
and elsewhere is the same. Maybe it is not noticeable when in text
console?
In Windows the bug might be masked if they use hardware autorepeat for
PS/2 keyboards. I don't know if they do or not.
Thanks.
--
Dmitry
On Thu, Feb 02, 2017 at 08:47:48AM -0800, thus spake Dmitry Torokhov:
On Thu, Feb 02, 2017 at 09:40:33AM +0100, Ignacy Gawędzki wrote:
quoted
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry Torokhov:
quoted
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very naive
as it emits "release" keycodes for the state FN is currently in, not
the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be fixed
or worked around in the input driver,
Well, obviously I'd rather fix the bug at its root rather than piling
workarounds in the driver.
Sure, but supposing that the BIOS has to be fixed, I don't expect Dell
to release a fix for a model that's about five years old. Unless
there's a good soul out there reading this and able to do anything
about it.
quoted
since the bug obviously doesn't
show up in neither in the linux console nor in Windows.
So where does it not work in Linux? Because keyboard driver in console
and elsewhere is the same. Maybe it is not noticeable when in text
console?
The bug appears only in X11. Not in the console, although autorepeat
is active there too.
In Windows the bug might be masked if they use hardware autorepeat for
PS/2 keyboards. I don't know if they do or not.
I have no idea either.
--
To err is human, to purr feline.
-----Original Message-----
From: Ignacy Gawędzki [mailto:bugs@qult.net]
Sent: Thursday, February 2, 2017 11:08 AM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Limonciello, Mario <redacted>; linux-
input@vger.kernel.org
Subject: Re: Dell XPS 13 Fn key bug?
On Thu, Feb 02, 2017 at 08:47:48AM -0800, thus spake Dmitry Torokhov:
quoted
On Thu, Feb 02, 2017 at 09:40:33AM +0100, Ignacy Gawędzki wrote:
quoted
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry Torokhov:
quoted
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very
naive as it emits "release" keycodes for the state FN is currently
in, not the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be
fixed or worked around in the input driver,
Well, obviously I'd rather fix the bug at its root rather than piling
workarounds in the driver.
Sure, but supposing that the BIOS has to be fixed, I don't expect Dell to release
a fix for a model that's about five years old. Unless there's a good soul out
there reading this and able to do anything about it.
There hasn't been any maintenance BIOS releases for the L322X since around the
end of 2013.
I won't be able to get anyone to spin up resources on this unless it was a major
security vulnerability or proverbial kitten killer type of bug.
quoted
quoted
since the bug obviously doesn't
show up in neither in the linux console nor in Windows.
So where does it not work in Linux? Because keyboard driver in console
and elsewhere is the same. Maybe it is not noticeable when in text
console?
The bug appears only in X11. Not in the console, although autorepeat is active
there too.
quoted
In Windows the bug might be masked if they use hardware autorepeat for
PS/2 keyboards. I don't know if they do or not.
I have no idea either.
--
To err is human, to purr feline.
On Thu, Feb 02, 2017 at 05:15:02PM +0000, thus spake Mario.Limonciello@dell.com:
quoted
-----Original Message-----
From: Ignacy Gawędzki [mailto:bugs@qult.net]
Sent: Thursday, February 2, 2017 11:08 AM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Limonciello, Mario <redacted>; linux-
input@vger.kernel.org
Subject: Re: Dell XPS 13 Fn key bug?
On Thu, Feb 02, 2017 at 08:47:48AM -0800, thus spake Dmitry Torokhov:
quoted
On Thu, Feb 02, 2017 at 09:40:33AM +0100, Ignacy Gawędzki wrote:
quoted
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry Torokhov:
quoted
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is very
naive as it emits "release" keycodes for the state FN is currently
in, not the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be
fixed or worked around in the input driver,
Well, obviously I'd rather fix the bug at its root rather than piling
workarounds in the driver.
Sure, but supposing that the BIOS has to be fixed, I don't expect Dell to release
a fix for a model that's about five years old. Unless there's a good soul out
there reading this and able to do anything about it.
There hasn't been any maintenance BIOS releases for the L322X since around the
end of 2013.
I won't be able to get anyone to spin up resources on this unless it
was a major security vulnerability or proverbial kitten killer type
of bug.
Yeah well, obviously it's not the former. As for the latter, the
qualification is very subjective. It's very annoying when it happens,
but I must admit I can sort of live with it (I already have for all
these years). It's just a pity such a lame thing hasn't shown up
before production, supposing it is actually something that can be
fixed with a BIOS patch (a question which hasn't been answered yet).
Anyway, God certainly kills a kitten every time my auto-repeat gets
stuck. :/
--
To err is human, to purr feline.
-----Original Message-----
From: Ignacy Gawędzki [mailto:bugs@qult.net]
Sent: Thursday, February 2, 2017 11:50 AM
To: Limonciello, Mario <redacted>
Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
Subject: Re: Dell XPS 13 Fn key bug?
On Thu, Feb 02, 2017 at 05:15:02PM +0000, thus spake
Mario.Limonciello@dell.com:
quoted
quoted
-----Original Message-----
From: Ignacy Gawędzki [mailto:bugs@qult.net]
Sent: Thursday, February 2, 2017 11:08 AM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Limonciello, Mario <redacted>; linux-
input@vger.kernel.org
Subject: Re: Dell XPS 13 Fn key bug?
On Thu, Feb 02, 2017 at 08:47:48AM -0800, thus spake Dmitry Torokhov:
quoted
On Thu, Feb 02, 2017 at 09:40:33AM +0100, Ignacy Gawędzki wrote:
quoted
On Wed, Feb 01, 2017 at 04:16:13PM -0800, thus spake Dmitry
Torokhov:
quoted
quoted
quoted
quoted
quoted
OK, so 'cd' is scancode for KEY_RIGHT and 'cf' is scancode for
KEY_END, and it seems that implementation of FN handling is
very naive as it emits "release" keycodes for the state FN is
currently in, not the state it was when key was pressed.
Ideally Dell would fix that. Mario, any chance of that?
I'm just wondering whether this is still something that could be
fixed or worked around in the input driver,
Well, obviously I'd rather fix the bug at its root rather than
piling workarounds in the driver.
Sure, but supposing that the BIOS has to be fixed, I don't expect
Dell to release a fix for a model that's about five years old.
Unless there's a good soul out there reading this and able to do anything
about it.
quoted
quoted
There hasn't been any maintenance BIOS releases for the L322X since
around the end of 2013.
I won't be able to get anyone to spin up resources on this unless it
was a major security vulnerability or proverbial kitten killer type of
bug.
Yeah well, obviously it's not the former. As for the latter, the qualification is
very subjective. It's very annoying when it happens, but I must admit I can sort
of live with it (I already have for all these years). It's just a pity such a lame
thing hasn't shown up before production, supposing it is actually something
that can be fixed with a BIOS patch (a question which hasn't been answered
yet).
Anyway, God certainly kills a kitten every time my auto-repeat gets stuck. :/
As much as I hate to use the "you're using it wrong" card, these types of things
are usually linked to certain typing styles. Without having dug into this code,
I would suspect that this is related to how the state machine in the EC works.
I know from previous key stuck issue reports reworking it can be fragile and
when one mob of people says it's fixed a different mob says it's broken.
At this point I'd recommend to continue to look for an OS solution.
Thanks,