On 13 November 2010 18:16, Ben Armstrong <[email protected]> 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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
