> >> Well, no luck, it's not that easy. Neither the fact that mouseemu is
> >> running in parallel, nor the order in which thez are started seems to
> >> matter.
>
> Correction: it does seem that running mouseemu blocks the special keys,
> as well as blocking pbbuttonsd's keyboard activity detection.
>
>
> > And there's been problems with the number of event devices being
> > checked by either mouseemu or pbbuttonsd (forgot which). And there may
> > be input devices that are fake (no real device attached, I have two
> > such). Check
> > /sys/class/input/input*/name to see what is what, and if the virtual
> > devices mouseemu created are really there.
>
> All 32 event devices are there (udev disabled). mouseemu does create
> it's event device corresponding to /dev/input/uinput. If mouseemu
> wouldn't relay keyboard events, the keyboard wouldn't work at all.
Unless mouseemu fails to accept the new keyboard as keyboard ... a simple
thing to try: change the register_inputhandler call for the keyboard
handler to pass 0 (zero) as last argument. That keeps it from grabbing the
keyboard for exclusive use. May result in each key being sent twice, so
don't do this unless you can ssh into the machine :-)
> It seems to be more a problem of mouseemu filtering out _some_ events?
OK, that's something to hunt for. mouseemu does in fact set up the virtual
keyboard for passthrough of all events except the button emulation events,
so it would seem the special keys never make it to mouseemu. The event
mask for the virtual keyboard is set up to KEY_UNKNOWN - maybe that
constant got changed by the new special key patch? Try building mouseemu
using your own kernel headers in that case.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
