Enabling multitouch in input-evdev

[Benjamin Tissoires]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20100118/41785986/attachment.html