<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Hutterer wrote:
<blockquote cite="mid:20100112110352.GB28371@barra" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:20100112110352.GB28371@barra" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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)
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:20100112110352.GB28371@barra" type="cite">
<pre wrap=""></pre>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:20100112110352.GB28371@barra" type="cite">
<blockquote type="cite">
<pre wrap="">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).