Very strange problem with input events

[Cedric Sodhi]

For your information, it turns out you were absolutely right, Peter, and
the problem was in the kernel's input layer. It was fixed with

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=3ac36d15557d1bedfb1151d9911b9587b2d40759

mtview now gives the right feedback and the poblem in X is also
resolved.

best regards,
Cedric

On Fri, Jun 15, 2012 at 11:02:56AM +1000, Peter Hutterer wrote:
> 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