[Debian-eeepc-devel] Bug#598097: Make detect_x_display go away to solve this

[Ben Armstrong]

On 13/11/10 12:01 PM, Ben Armstrong wrote:
> I have found the elusive key mapping.  It's actually the kernel input
> subsystem handling it, so the place to look is in /usr/include/linux/input.h
> 
> #define KEY_DISPLAY_OFF 245 /* display device to off state */

Ah.  We needn't guess which keys will be sent, but only look at code
upstream:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/platform/x86/eeepc-laptop.c;h=b2edfdcdcb84fd09d6eee096c56ef146351393be;hb=HEAD

 134 static const struct key_entry eeepc_keymap[] = {
 135         { KE_KEY, 0x10, { KEY_WLAN } },
 136         { KE_KEY, 0x11, { KEY_WLAN } },
 137         { KE_KEY, 0x12, { KEY_PROG1 } },
 138         { KE_KEY, 0x13, { KEY_MUTE } },
 139         { KE_KEY, 0x14, { KEY_VOLUMEDOWN } },
 140         { KE_KEY, 0x15, { KEY_VOLUMEUP } },
 141         { KE_KEY, 0x16, { KEY_DISPLAY_OFF } },
 142         { KE_KEY, 0x1a, { KEY_COFFEE } },
 143         { KE_KEY, 0x1b, { KEY_ZOOM } },
 144         { KE_KEY, 0x1c, { KEY_PROG2 } },
 145         { KE_KEY, 0x1d, { KEY_PROG3 } },
 146         { KE_KEY, NOTIFY_BRN_MIN, { KEY_BRIGHTNESSDOWN } },
 147         { KE_KEY, NOTIFY_BRN_MAX, { KEY_BRIGHTNESSUP } },
 148         { KE_KEY, 0x30, { KEY_SWITCHVIDEOMODE } },
 149         { KE_KEY, 0x31, { KEY_SWITCHVIDEOMODE } },
 150         { KE_KEY, 0x32, { KEY_SWITCHVIDEOMODE } },
 151         { KE_KEY, 0x37, { KEY_F13 } }, /* Disable Touchpad */
 152         { KE_KEY, 0x38, { KEY_F14 } },
 153         { KE_END, 0 },
 154 };

and

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/platform/x86/eeepc-wmi.c;h=462ceab93f87b84d59796a58ac90703a2ffaddee;hb=HEAD

  64 static const struct key_entry eeepc_wmi_keymap[] = {
  65         /* Sleep already handled via generic ACPI code */
  66         { KE_KEY, 0x5d, { KEY_WLAN } },
  67         { KE_KEY, 0x32, { KEY_MUTE } },
  68         { KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
  69         { KE_KEY, 0x30, { KEY_VOLUMEUP } },
  70         { KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
  71         { KE_IGNORE, NOTIFY_BRNUP_MIN, { KEY_BRIGHTNESSUP } },
  72         { KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
  73         { KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
  74         { KE_KEY, 0xe1, { KEY_F14 } },
  75         { KE_KEY, 0xe9, { KEY_DISPLAY_OFF } },
  76         { KE_KEY, 0xe0, { KEY_PROG1 } },
  77         { KE_KEY, 0x5c, { KEY_F15 } },
  78         { KE_END, 0},
  79 };

So if we do synthesize any keys (and the X team advises they'd rather
see us synthesize no keys at all and push for kernel patches instead)
then it should be a subset of what is shown above.

So where do we go from here?  Use acpi_fakekey to generate the keys not
currently sent to the input subsystem in 2.6.32?  Backport eeepc_laptop
and eeepc_wmi?  Both?  Neither?  Something else?

Ben