Peter Hutterer wrote:
First of all, thanks for your efforts here. I really appreciate that you
pushed it that far and I'm sorry about the delay in my comments.
On Fri, Jan 08, 2010 at 12:55:21PM +0100, Benjamin Tissoires wrote:
First, I try to dynamically create/detroy such subdevices. However,
it infers very often freezes in the Xserver due to some mallocs. So
the idea to solve this problem is to staticaly allocate the
subdevices.
Do you have any logs or other data on where these freezes occured? they'd be
useful for others as well since chances are someone is going to run into
this deadlock.
Sorry, when this freezes occurs I only had backtracks from the driver (a
xmalloc) and not the other threads (I forgot to check them). I add this
to my todo list.
Finally, let's talk about the internal detection and behavior of multitouch.
The multitouch-enabled evdev driver (since kernel 2.6.30) has some
more events (SYN_MT_REPORT, ABS_MT_TOUCH_MAJOR, ABS_MT_TOUCH_MINOR,
ABS_MT_WIDTH_MAJOR, ABS_MT_WIDTH_MINOR, ABS_MT_ORIENTATION,
ABS_MT_POSITION_X, ABS_MT_POSITION_Y, ABS_MT_TOOL_TYPE,
ABS_MT_BLOB_ID and ABS_MT_TRACKING_ID). The only necessary event
given by a multitouch device (correct me if I'm wrong) is the
SYN_MT_REPORT. So I activate multitouch only when I received this
event.
Do you activate it when you receive the event or based on this bit? It seems
checking for the bit set is the better approach. (I haven't yet looked at
your patch)
I detect the multitouch capability in the init basing on this bit.
However, I pack the multitouch event when I receive the SYN_MT_REPORT.
Sorry for not being clear.
The evdev driver is first and foremost a generic mouse driver. Which means
that devices that provide x and y are the most important to work, regardless
of relative or absolute. The need for x/y is also implied by the core
protocol. However, there's no reason that you couldn't fake up x/y
and simply leave it as a mute axis. IMO the kernel should not report axes
that don't exist.
The axis mapping evdev is a convention not a rule, so you could just
reshuffle the axis checking to cater for the multitouch situation.
That goes for the rest of the driver too, if something seems wrong to cater
for a new situation then the driver can be rewritten to suit this.
As I had to rewrite the patch to keep all the events in one device, I
will have to play with axes... and tackle this issue.
The second problem was concerning trackpads:
How can we handle modern-multitouch trackpads (Broadcom 5974,
DiamondTouch). We excluded synaptics trackpads as they don't send
ABS_MT events but special tools events (325, 330, 333, 334 for
ToolFinger, Touch, Tool Doubletap, Tool Tripletap).
From Stéphane's point of view, they should be transparent of my
patched version of input-evdev as they are giving quite the same
events than multitouch screens.
Finally, I was wondering what is your position concerning the use of
XI-properties to notify the client of the starting/ending of touch
events.
Property events are neither designed nor particularly well suited for this.
Their data delivery is partially out-of-band with the input events and
frequent property changes reduce the load on both the server and the client
significantly. As with the multitouch data, this should ideally be included
in a new type of event.
Cheers,
Peter
As I send in the previous mail I send, maybe we should use valuators to
send such events ?
One last question I forgot to ask:
Do we need to dynamically change the number of touch that can be detected ?
I.e. do we need to have only 10 touches (as in Windows I think) or do we
let the choice to the user (the toolkit) if the device can handle more ?
Cheers,
Benjamin
_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel
