[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pbbuttonsd and NoTapTyping option?



> > > does anybody use the NoTapTyping function of pbbuttonsd with success?
> > > How much would you pay to keep it? ;-)
> >
> > I don't use that function - at least not in pbbuttonsd. moussemu takes
> > care of that for me.
> >
>
> I have noticed notap no longer gets set properly in the latest version
> available through Ubuntu Breezy, and I filed a bug report about it. (It
> worked fine in Hoary.) I haven't learned enough about mouseemu to determine
> whether I want to mess with it, but I do like having it in pbbuttonsd
> (whether it logically belongs there or not) because I use the other
> powerbook features in it.
>
> Of course, if the feature wasn't in pbbuttonsd I would just make sure a
> process runs the "/sbin/trackpad notap" command sometime by the time I need
> to use Xwindows.

You may be confusing two different notap aspects here - setting the
trackpad to notap mode (which may be done pretty much anywhere you like,
and it doesn't hurt to do it in the rc scripts, pbbuttonsd and pmud all at
the same time), and the 'no tap while typing' function that Matthias
introduced in pbbuttonsd quite a while back.

This typing block of the trackpad currently requires a process to
exclusively grab all input from the trackpad, and only pass a trackpad tap
when no key has been pressed a short while before the tap. If that process
messes up, no more trackpad input for you. Only one process can grab a
device exclusively, so having multiple programs attempting the same
function may be problematic.

Some users have reported problems with this feature, that's why Matthias
asked if it makes sense to keep it. All I said is I use mouseemu for this
(because I got addicted to the kernel mouse button emulation, and mouseemu
nicely sanitizes this). As others reported trouble with mouseemu, I'd
advocate keeping the feature in pbbuttonsd for the time being. I don't
know if the problems are related to recent changes in the kernel or udev,
but I'm sure they will get resolved.

	Michael



Reply to: