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

[Luca Niccoli]

On 13 November 2010 18:16, Ben Armstrong <synrg at sanctuary.nslug.ns.ca> wrote:
> 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.

In particular, my 901 uses KEY_COFFEE for the "screen off" key; this
will generate a XF86ScreenSaver keysym in Xorg, that is usually
handled by the window manager (locking and possibly turning off the
screen).

Rant:
How braindead is it that some other models send KEY_DISPLAY_OFF? How
did they decide that keys that have the same function have different
semantics?
Or is there a model that has both the keys? (I doubt that)
In case there isn't, do you thin there's a chance to fix this in the
kernel, and have just one keysym generated (possibly KEY_COFFEE, since
it's the one better handled by X, even if it has a somewhat
inappropriate name)?

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

Synthesizing keysyms with acpi_fakekey is the standard stopgap
solution. It has proven error prone though, since when new kernel
start generating keysyms themselves these are reported twice.

Cheers,

Luca