[conspire] help: linux scancode/keycode problem on Dell E6500 ?

[Rick Moen]

Quoting =JeffH (Jeff.Hodges at KingsMountain.com):

> Well it turns out I probably shudda queried the xorg at freedesktop.org
> list long ago because some folks there were on top of this problem
> and apparently my googling skills are lacking.
> 
> Fn+F8 is now working on my E6500 and I've successfully migrated to
> it as my primary system (whew).

Wow, as you said, blow me down.  Who'd have thought that OEMs would
sabotage the Fn key's sending function just because Microsoft Corp.
asked them to please make it send Windows ('super') key, instead.  I
wonder what these idiots would say if you asked them 'Excuse me, but how
do I make my E6500 with current firmware do what Fn+F8 used to do?'

> So I applied this fix in /etc/default/grub:
> 
>    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=\\\"!Windows 2009\\\""
> 
> ..from..
> 
>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477/comments/47
> 
> and ran "sudo update-grub", and apparently it's all fixed (for now).

You know, you don't need to have 'quiet' and 'splash' in there unless
you actually want them.  They interfere somewhat with being able to
observe and debug the booting process.


> I'm curious though -- why can't this be solved by remapping keycodes,
> or down lower in the X stack ?

It probably could be solve by remapping key scancodes.

> Apparently the gnome folk have resorted to putting a fix into
> gnome-settings-daemon, which has the downside of breaking various
> users' keymappings for various applications. 

That's obviously a very wrong place in the software stack to fix key
mappings -- but then, the GNOME people have a history of assuming that
everybody runs GNOME and that nothing outside GNOME matters.

> Plus presumably KDE has had to do their own fix, and other desktop
> regimes may also need to (or already have)...

That's one of the many reasons why any desktop environment is a very
wrong place to fix the problem.  Patching the kernel keyboard support at
boot time via parametres to the bootloader is reasonable.  One might
hope eventually for the kernel's inline code to test ACPI for broken
behaviour and compensate for it automatically.