Re: pbbuttonsd vs. mouseemu
On Mon, 31 Oct 2005 18:51:50 +0100 (CET)
Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> 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
Reply to: