From: <Mario.Limonciello@dell.com>
To: bugs@qult.net, dmitry.torokhov@gmail.com
Cc: linux-input@vger.kernel.org
Subject: RE: Dell XPS 13 Fn key bug?
Date: Thu, 2 Feb 2017 17:15:02 +0000 [thread overview]
Message-ID: <156e931c68344eccb7360df7c15f6577@ausx13mpc124.AMER.DELL.COM> (raw)
In-Reply-To: <20170202170825.r3ellulrx47kku35@zenon.in.qult.net>
> -----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.
next prev parent reply other threads:[~2017-02-02 17:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 8:47 Dell XPS 13 Fn key bug? Ignacy Gawędzki
2017-02-02 0:16 ` Dmitry Torokhov
2017-02-02 8:40 ` Ignacy Gawędzki
2017-02-02 16:47 ` Dmitry Torokhov
2017-02-02 17:08 ` Ignacy Gawędzki
2017-02-02 17:15 ` Mario.Limonciello [this message]
2017-02-02 17:50 ` Ignacy Gawędzki
2017-02-02 19:53 ` Mario.Limonciello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=156e931c68344eccb7360df7c15f6577@ausx13mpc124.AMER.DELL.COM \
--to=mario.limonciello@dell.com \
--cc=bugs@qult.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox