[PATCH xf86-input-evdev] Allow multitouch support to be disabled
Peter Hutterer
peter.hutterer at who-t.net
Thu Oct 18 15:44:00 PDT 2012
On Thu, Oct 18, 2012 at 12:54:35PM +0200, Thierry Reding wrote:
> On Thu, Oct 18, 2012 at 08:36:30PM +1000, Peter Hutterer wrote:
> > On 18/10/12 20:32 , Thierry Reding wrote:
> > >Instead of always automatically including multitouch support if the
> > >mtdev library is installed, the new --disable-multitouch option can
> > >be used to forcefully disable multitouch support in the driver.
> >
> > uhm. seems a bit like the proverbial sledgehammer. what's the reason
> > for this?
>
> It turns out that the stuck key issue that I've seen with the OSK is
> related to multitouch. If I apply this patch to the xf86-input-evdev
> driver and rebuild with --disable-multitouch the issue is gone.
well, yes. but the real question in this case is whether the bug is in the
driver (don't think so, given the previous logs), in the server, or in the
client.
> I know this is really not a bugfix and we have an upcoming project where
> we need multitouch support so I'll have to continue looking into the
> original issue anyway, but this is an acceptable workaround for the
> present deadline.
>
> Besides that I think it's nice to have these knobs to explicitly tell
> the package to enable support for some feature or not, independent of
> what the build environment has installed. It helps with reproducibility
> of a given software configuration.
I understand your point, but I do wonder how many distributions ship evdev
without mtdev support. I consider multitouch a rather important feature
these days, one reason I don't want it to be disabled (except on older
servers) is to make sure we get as much exposure to the code as possible and
fix the bugs that are there.
tbh, a more useful option regarding multitouch is to skip mtdev for devices
that don't need it - it would save us some memory that mtdev largely wastes
on protocol B devices.
but either way, I do want multitouch turned on at all times if possible
Cheers,
Peter
More information about the xorg-devel
mailing list