On Thu, Dec 10, 2009 at 10:28:44AM -0800, Dmitry Torokhov wrote:

On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:

quoted

Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :

quoted

Hi Stephane,

On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:

quoted

+
+	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.

are we talking about kernel drivers or userspace drivers here?

not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
not-yet-implemented feature) but if the kernel hands out both ABS_X and
ABS_MT_X that makes it difficult to determine which event is a valid one and
which one can be ignored.

quoted

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.

not only that, but it's now quite easy to create devices as-needed within
the X driver and control creation/deletion of these devices as required by
underlying physical device. If the driver does that, it has knowledge of the
other devices it created and thus better control of the features these
provide.

having multiple devices provided by the kernel removes this ability, you'd
have to manually link them together.

Cheers,
  Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html