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