Very strange problem with input events

[Peter Hutterer]

On Thu, Jun 14, 2012 at 11:52:50AM +0200, Cedric Sodhi wrote:
> On Thu, Jun 14, 2012 at 07:19:22PM +1000, Peter Hutterer wrote:
> > On 14/06/12 17:35 , Cedric Sodhi wrote:
> > > On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote:
> > >> On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote:
> > >>> Unfortunally, I lack a better or just more precise description of my
> > >>> problem. I get strange behaviour all throughout X, everywhere clicks are
> > >>> involved.
> > >>>
> > >>> One thing I think I had already mentioned is that my touchscreen, which
> > >>> runs evdev does work properly everywhere, but there are no regular
> > >>> events generated - only XI events.
> > >>
> > >> this can only be a client issue. I can't tell you which client from here
> > >> though. The drivers and the server don't deal with core vs XI events until
> > >> very late. There' internal events and then based on the client selection
> > >> that internal event structure is converted to the wire event and sent.
> > >>
> > >> So if you don't see core events, the clients haven't registered for it, or
> > >> clients have otherwise registered for XI events and take precedence over
> > >> core..
> > >>
> > >>> Also, many applications strangely misbehave in a way that other people
> > >>> cannot possibly reproduce. Unrelated to the touchscreen, that is. Using
> > >>> an ordinary mouse with evdev.
> > >>>
> > >>> Two examples:
> > >>>
> > >>> Tint2 (the panel) had me "drag" window-icons ("tasks") on the taskbar,
> > >>> when I clicked them, as if I had held the mouse button down. I was able
> > >>> to "fix" that by a minor change in the code of tint2, but as no one else
> > >>> is getting any such behaviour I assume I did not really fix the bug but
> > >>> only found some solution to somewhich, which fails elsewhere. I was not
> > >>> able to track the logic which is supposed to run, though.
> > >>>
> > >>> Second example, Midori (the browser). When I right click a hyperlink and
> > >>> subsequently left click an entry in the context menu, the context menu
> > >>> disappears (as it should) and I'm suddenly "dragging" the link upon
> > >>> which I clicked.
> > >>>
> > >>> Similar things happen everywhere else, too.
> > >>>
> > >>> I'm not even sure where to start looking. I wish I could get a
> > >>> suggestion from you, what to do.
> > >>
> > >> options are trying an older X servers and bisecting from a good one if you
> > >> can find one.
> > >>
> > >> or look at the protocol with xscope to see the actual events sent on the
> > >> wire (you can also use systemtap/dtrace for that but it's less pretty).
> > >>
> > >> For the link issue, I'd check the evtest output of the touchscreen to see if
> > >> the actual device data makes sense.
> > >
> > > I take back what I said previously, that it was unrelated to the
> > > touchscreen. In fact, I narrowed down the source of the problem exactly
> > > to the touchscreen. It appears that if I do not touch the touchscreen at
> > > all, after the server has started, everything works.
> > >
> > > But as soon as I touched it at least once - thought there appears to be
> > > no sign of problems at first - these strange things (see the two
> > > examples above - I've got more examples, if you like) start happening,
> > > even if I just use the normal mouse. I had attached an evtest log of the
> > > device, do you see any indication of problems in that?
> > 
> > disable the device in X with xinput and run mtview against it, that 
> > should tell you if the device misbehaves. the log looks ok on a glance.
> > 
> > https://github.com/whot/mtview/
> 
> 
> Ok, I think I noticed a few irregularities. Here is what I did:
> 
> From the outer left and right towards the middle, I repeatedly:
> 
> Put down the first finger at the righter top, dragged it down a bit. Then put
> down the second finger on the lefter top, and dragged both fingers down
> a way. Then I first took the right finger off, kept dragging a bit more
> downwards with the left, and then also took that one off.
> 
> And did so repeatedly towards the middle of the screen.
> 
> If you look carefully, you can see not onle that a single line consist of
> two, but really three colors! The third colored blob at the very bottom
> appears the moment I start over with new lines towards the middle (as
> consistently represented by the color).
> 
> Also, on the first iteration the left finger does not appear until I
> raised the right finger.

that's a missing feature in evemu that'll be fixed with the new version. if
you're running against the current evemu release, you won't see touchpoints
until the MT_SLOT value changes.
 
> Can I do anything else?

fix your kernel driver :)
if mtview shows the events this way it means that the touch points aren't
tracked properly in the kernel - could be a device issue, could be the
kernel driver. but until mtview shows the touchpoints as they should be, the
issue isn't in X.

judging from the picture what happens is that when you start with a new
touchpoint, the device gets confused about which touch is which. look at the
yellow-green line. apparently when you put the right finger down, it assumed
that this was a continuation of the previous touch, while at the same time
it started a new touch where the left finger was still down.

I've seen similar behaviour once on a pre-production tablet that just didn't
keep track of the touchpoints properly in the hardware. the second
touchpoint got shifted to the first one in the data structures whenever the
first one ended. I suspect something similar happens here.

either way - kernel issue, if the hardware is really busted I suggest
switching it to protocol A instead and letting mtdev handle the tracking.

Cheers,
  Peter