> -----Original Message----- > From: Ignacy Gawędzki [mailto:bugs@xxxxxxxx] > Sent: Thursday, February 2, 2017 11:50 AM > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: dmitry.torokhov@xxxxxxxxx; linux-input@xxxxxxxxxxxxxxx > Subject: Re: Dell XPS 13 Fn key bug? > > On Thu, Feb 02, 2017 at 05:15:02PM +0000, thus spake > Mario.Limonciello@xxxxxxxx: > > > -----Original Message----- > > > From: Ignacy Gawędzki [mailto:bugs@xxxxxxxx] > > > Sent: Thursday, February 2, 2017 11:08 AM > > > To: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > Cc: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; linux- > > > input@xxxxxxxxxxxxxxx > > > 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, -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
