[PATCH]: mtdev could be disabled at configuration

[Marc Chalain]

Hello
The detection of the library is automatically done during the
configuration. The option is not useful.

And the use #ifdef HAVE_MTDEV seems to be simpler, if in the future this
feature will disappear.

What I do ? I send again or I increase the complexity.
Marc.


2013/6/11 Benjamin Tissoires <benjamin.tissoires at gmail.com>

> On Tue, Jun 11, 2013 at 12:40 PM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > On Tue, 11 Jun 2013 12:10:05 +0200
> > Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote:
> >
> >> On Tue, Jun 11, 2013 at 9:41 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >> > On Tue, 11 Jun 2013 09:01:48 +0200
> >> > Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote:
> >> >
> >> >> On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >> >> > On Fri, 7 Jun 2013 12:11:14 +0200
> >> >> > Marc Chalain <marc.chalain at gmail.com> wrote:
> >> >> >
> >> >> >> mtdev is not necessary on some device (desktop or set-top-box).
> For
> >> >> >> embedded solution the minimum of dependencies is required.
> "configure"
> >> >> >> accepts the --disable-mtdev option.
> >> >> >
> >> >> > Hi Marc,
> >> >> >
> >> >> > with this patch, if weston is compiled with --disable-mtdev, it
> looks
> >> >> > like it will still happily open multitouch devices, expose them to
> >> >> > Wayland clients, and feed them garbage or fail or whatever. Right?
> >> >>
> >> >> Hi Pekka,
> >> >>
> >> >> no. mtdev is a compatibility layer for converting very rare
> >> >> touchscreen using the multitouch protocol A into the mostly used
> >> >> multitouch protocol B.
> >> >> To my mind, only legacy devices (ntrig 0001 and few others) use the
> protocol A.
> >> >> So without mtdev, wayland will open and handle most of the multitouch
> >> >> screen happily.
> >> >>
> >> >> >
> >> >> > I think the proper approach is to change the configure option into
> >> >> > --disable-multitouch or --disable-touchscreen, which would not only
> >> >> > drop the dependency to mtdev, but also make Weston ignore all
> >> >> > touchscreen devices since it will not be able to handle them.
> >> >>
> >> >> Without mtdev, wayland should only ignore multitouch screen not
> >> >> presenting the ABS_MT_SLOT axis.
> >> >> Those relying on SYN_MT_REPORT do not provide tracking (which is
> done by mtdev).
> >> >>
> >> >> So my guess is that if you detect multitouch screens by looking at
> >> >> ABS_MT_SLOT, then everything will be fine whether or not you have
> >> >> mtdev:
> >> >> - multitouch B screens will correctly be handled
> >> >> - multitouch A screens will be processed as a single touch screen,
> >> >> which is not a problem because the kernel provides single touch
> >> >> emulation since the early days of multitouch. And if mtdev is
> present,
> >> >> then it will show the ABS_MT_SLOT axis, leading to the previous case.
> >> >>
> >> >> Bonus point, mtdev has not been updated since a long time, and is
> >> >> missing the bits allowing you to retrieve the initial per-slot
> states.
> >> >> And you may find useful to retrieve the current states when weston
> >> >> launches.
> >> >
> >> > Thank you for clarifying that, Benjamin.
> >> >
> >> > Does this mean that we need explicit single-touch support in Weston?
> >>
> >> After giving a quick look at evdev.c, it appears that single touch
> >> devices are already treated in the same way tablets (with stylus) are.
> >> So, single touch devices are seen from weston in the same way they
> >> have been seen in Xorg since the beginning: as absolute input devices.
> >>
> >> Then, it's just a matter of deciding whether we want to inform the
> >> client if the source of the event is a finger or a pen.
> >
> > Right... except we do not support tablets at all at the moment. We miss
> > the whole protocol for tablets. Wayland (not just Weston) only has
> > support for touchscreens so far, in addition to keyboards and relative
> > pointing devices.
> >
> > evdev.c's device type recognition is just a handful of ad hoc
> > heuristics for now, written only for touschscreens, keyboards, and
> > mice/touchpads, and trying to ignore everything else.
>
> Right, the current recognition seems to be even worth than what udev
> does (in the sense that it is not a complete characterization, no
> offense).
> I followed the thread from David Herrman about libinputmapper and
> hopefully, we will get in the end a more robust detection of input
> devices.
>
> >
> >> > I don't think we have that yet. Everything touchy goes through mtdev,
> >> > which makes also real single-touch devices look like multitouch
> devices
> >> > except they never report more than one contact. Do I understand that
> >> > right?
> >>
> >> evdev.c detects "touch" devices by looking at ABS_MT_SLOT. But mtdev
> >> does not transform single touch device into pseudo-multitouch devices.
> >> So I would say that those single touch devices are not treated as
> >> "touch" today.
> >
> > Ok, so probably they would not work anyway atm.
> >
> > Which means that dropping mtdev loses only some rare multitouch
> > devices, which do not advertise ABS_MT_SLOT, and hence will get
> > properly ignored. Right?
>
> right :)
>
> >
> > I wonder if single-touch devices get detected as touchpads. Depends on
> > if they have any keys, it seems. :-)
>
> They should not:
> the udev mapping for touchpads rely on BTN_TOOL_FINGER, so normally,
> the kernel will not set this property for single touch screen (we try
> to not break existing in the kernel, and the existing detection
> mechanism rely on BTN_TOOL_FINGER...). But again, this is the theory
> :)
>
> Cheers,
> Benjamin
>
> >
> >> > Marc, in any case, I think you should check that Weston correctly
> >> > ignores touch devices it cannot support without mtdev, as per
> >> > Benjamin's instructions above.
> >> >
> >> > Retrieving current state is a matter for another time.
> >> >
> >>
> >> Oh yes. FYI, I still did not found the time to finalize the patches for
> Xorg :)
> >
> >
> > Thanks,
> > pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130611/b4b19104/attachment-0001.html>