On Thu, Dec 10, 2009 at 02:28:10PM -0500, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/10/09 13:28, Dmitry Torokhov wrote:
> > On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
> >>
> >> Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
> >>
> >>> Hi Stephane,
> >>>
> >>> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
> >>>> +
> >>>> + if (emulate_touchscreen) {
> >>>> + if (sd->first) {
> >>>> + if (!sd->activity) {
> >>>> + input_event(input, EV_KEY, BTN_TOUCH, 1);
> >>>> + sd->activity = 1;
> >>>> + }
> >>>> + input_event(input, EV_ABS, ABS_X, sd->x);
> >>>> + input_event(input, EV_ABS, ABS_Y, sd->y);
> >>>> + }
> >>>> + }
> >>>
> >>> Why are you doing the above conditionally? Just report it always -
> >>> less
> >>> setup required for the user.
> >>
> >> As regards setup, the emulate_touchscreen parameter is 1 by default so
> >> that users don't have to care about it. But I felt compelled to have this
> >> parameter because the ongoing work on X.org suggests that there might be
> >> a problem in upper layers with having duplicate information flows. For
> >> instant, if we associate a slave pointer (MPX terminology) to every
> >> ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow
> >> and we'll need to do something to ignore it. Benjamin, Peter, what do you
> >> think?
> >
> > I thought Henrik's idea was that driver should use either classic or
> > multitouch events from the data stream but not both. This way users
> > could either use old, non-multitouch-aware drivers or newer ones without
> > issues.
>
> How far are we from decent user-space support for multi-touch devices?
> If we can expect that to solidify in the near future, perhaps we'd be
> better off migrating away from conventional touchscreen/single point
> digitizer behavior.
I do not think would be wise. World is bigger than X.
>
> >>
> >> Also, some devices (especially the N-Trig) do not make it possible to
> >> implement a single touch emulation because they have no finger tracking
> >> (IDs change over time, you never know which finger to use and the cursor
> >> would jump from one to the other randomly). Therefore, I did not feel
> >> like creating a new "standard" behaviour that will be broken by such
> >> devices.
> >
> > If driver can't support something then it smply won't provide such
> > events at all and users that require certain capability will simply
> > ignore devices that don't provide it.
>
> In the case of the n-trig digitizer (with the latest firmware), single
> touch emulation can be reproduced by a relatively simple tracking
> mechanism. If we're talking about supporting dual mode drivers, would
> there be much objection to the cost of computation in the kernel
> driver?
>
It really depends on the cost, but I don't think there would be much
objection.
> >>
> >> Actually, Rafi Rubin and I have started to discuss the idea of splitting
> >> this into two input nodes: a pure multitouch device and a pure single
> >> touch emulation. I'd like to have feedback on this idea too, even if I
> >> have no time to work on it yet.
> >
> > If you create 2 devices basically supplying the same data then it will
> > be harder for consumers to select between them and drivers. I.e. if
> > single device transmits entire state then it is easy to write hotplug
> > policy for say X server (using udev/hal) such as:
> >
> > - this box always uses evdev for everything, or
> > - devices with nultitouch capabilities use new multitouch
> > X driver, the rest use evdev.
> >
> > This will be harder if there were 2 "copies" of multitouch devices
> > because we'd have to be able to recognize "siblings" and ignore one or
> > the other.
> >
> > Does this make sense?
>
> At the moment, the evdev and wacom drivers (the only two that I've
> used for a digitizer), require specifying which device to use. I also
> have the memory (and I might just be miss-remembering) that the
> synaptics driver finds an event dev on its own.
I think this is only true in non-hotplug case. I am running without
xorg.conf at the moment and X input hotplug seems to be working well
properly selecting the drivers and making sure that alps is driven by
Synaptics X driver while all the rest are driven by evdev.
> So as far as I see it
> a single driver should be smart enough to select the device that it
> prefers.
Right, but we are dealing with 2+ drivers. You need to somehow signal
evdev that it should not touch devices whose siblings are driven by
other drivers. But not always since sometimes siblings are to be driven
by different devices (ALPS touchpad is driven by Synaptics, sibling
representing trackpoint is driven legitimately by evdev).
>
> If we're worried about a discovery tool identifying both devs and
> assigning appropriate drivers to each, could we not just export names
> that indicate they are in fact the same device and let the tools
> select which to prefer? It should be trivial for such tools to select
> sanely.
>
Too fragile IMO.
>
> That being said, I did at some point have a touchpad that was
> configured such that I got events from both mice and an event dev, and
> it was really annoying.
>
Yep.
> > If there is a concern about too many unused events reaching userspace -
> > then we need to implement subscription model in evdev where consumer can
> > specify list of events it is interested in and have input core deliver
> > only those. I'll take patches ;)
>
> While that sounds tempting, it also could introduce a bit of a hazard.
> Programmer A masks out events he doesn't need, then programmer B
> starts coding up support for more features and is confounded by the
> lack of response, and yet a hexdump of the dev indicates the events
> are streaming.
>
I think you are stretching it a bit here. Yes, it is possible but people
should really be familiar with the codebase.
>
> On that note, how does one convince the input or hid core to emit an
> event when the state hasn't actually changed? I ran into that when I
> was trying to inject device swaps for interleaved streams of touch and
> pen events. Clearly I was attacking a symptom and ignoring the real
> problem, but I'm still curious.
>
There isn't. It is a feature - if state did not change there is no
reason to transmit it.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
