On Mon, 31 Oct 2005 18:51:50 +0100 (CET) Michael Schmitz <[EMAIL PROTECTED]> wrote:
> > > This is probably Bug #304734. Sorry, but as my PowerBook got stolen, I'm > > > currently unable to work on this. I just ordered a new one and will > > > hopefully find some time to work on mouseemu when it arrives. In the > > > meantime feel free to fix and NMU. The problem is to find a solution, > > > that does not break mouseemu (as does not reintroduce to passthrough of > > > the mouse button hotkeys). > > > > I think the main problem here is that mouseemu EVIOCGRAB all keyboard > > event devices and therefore block them for other programs like pbbuttonsd. > > Is it necessary that mouseemu block event devices? > > mouseemu grabs keyboard events, but passes them on to a virtual keyboard > device that other applications can use. You need enough input event > devices for this to work. Ok, I understand now. I'm running udev so I never got the problem with too less event devices. I agree that wouldn't have any problem if enough event devices were available. Because udev need some time to create newly created event devices, there might be a race condition if mouseemu and pbbuttonsd were lauched directly after another. The virtual keyboard device might not have been appeared in /dev/input/ when pbbuttonsd scans for it. This race won't occour if udev was not used or pbbuttonsd was set up to scan reguarly for new devices. I don't know how often this race will happen, just a thought. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
