Dell XPS 13 Fn key bug?

Dell XPS 13 Fn key bug?

[Ignacy Gawędzki]

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.

Re: Dell XPS 13 Fn key bug?

[Dmitry Torokhov]

On Wed, Jan 25, 2017 at 12:47 AM, Ignacy Gawędzki <bugs@qult.net> 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

Re: Dell XPS 13 Fn key bug?

[Ignacy Gawędzki]

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.

Re: Dell XPS 13 Fn key bug?

[Dmitry Torokhov]

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:
> > 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

Re: Dell XPS 13 Fn key bug?

[Ignacy Gawędzki]

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:
> > 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,
> 
> 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.

> > 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.

RE: Dell XPS 13 Fn key bug?

[Mario.Limonciello]

> -----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 <Mario_Limonciello@Dell.com>; 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:
> > 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:
> > > > 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.

> > > 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.

Re: Dell XPS 13 Fn key bug?

[Ignacy Gawędzki]

On Thu, Feb 02, 2017 at 05:15:02PM +0000, thus spake Mario.Limonciello@dell.com:
> > -----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 <Mario_Limonciello@Dell.com>; 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:
> > > 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:
> > > > > 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.

RE: Dell XPS 13 Fn key bug?

[Mario.Limonciello]

> -----Original Message-----
> From: Ignacy Gawędzki [mailto:bugs@qult.net]
> Sent: Thursday, February 2, 2017 11:50 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> 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:
> > > -----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 <Mario_Limonciello@Dell.com>; 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:
> > > > 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:
> > > > > > 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. :/
> 

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,