Message-ID: <20100524045855.GC16369@barra>
Date:	Mon, 24 May 2010 14:58:55 +1000
From:	Peter Hutterer <peter.hutterer@...-t.net>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Rafi Rubin <rafi@...s.upenn.edu>,
	Michael Poole <mdpoole@...ilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

On Thu, May 20, 2010 at 12:40:08PM +0200, Henrik Rydberg wrote:
> Peter Hutterer wrote:
> [...]
> >>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> >>> in advance if a device may use slots or not?
> >> Eventually, this might become true, but you are pointing at one of the weaker
> >> points of the current setup. There is no bit field for the EV_SYN events, so
> >> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
> >> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
> >> is to detect the first SYN_MT_SLOT and select parser based on that information.
> > 
> > I'd really prefer if there was some way to detect this. While I'm not quite
> > sure how the matching X drivers would look like it's likely that the setups
> > will be different for drivers that support slots and those that don't.
> > e.g. those that don't have slots simply send events as valuators, those that
> > do may split into multiple devices.
> > 
> > Doing this at runtime - after the device has been set up is...tricky.
> 
> Changing SYN_MT_SLOT to ABS_MT_SLOT will take care of this.
> 
> >> If you are thinking of a setup where one program is already hooked up to the
> >> device, and a new one comes in just as the message in question appears on the
> >> wire, it just means the new program will have to spend some time catching up. If
> >> this should ever become a problem, one could possibly add a send-full-state
> >> method to the input layer, to be issued when the new program opens the device. I
> >> doubt this will be needed in practice though, since contacts change all the time.
> > 
> > This was the case I was wondering about. While I agree with the last part
> > (contacts change all the time) the side-effect that you'll get from this is
> > that devices can seemingly be non-responsive for random periods of time.
> > 
> > If you have a finger down when the X server starts or after a VT switch (or
> > even a fast user switch), the driver will have to drop events. So you can
> > wriggle your finger around and nothing happens, but once you lift it goes
> > "well, now it works again". Since this happens only once in a while, it can
> > make the whole lot appear flaky.  Especially if one finger works and the
> > other one doesn't.
> >
> > So I guess it comes down to whether sending SYN_MT_SLOT with every event
> > costs too much compared to these admittedly rare use-cases. They're not much
> > different to the current button events either, if you weren't there when a
> > button was pressed you won't know. So I'm somewhat indifferent about this
> > bit.
> 
> Yes, it is a inherent property of the input protocol between the kernel and user
> space. A different problem, in other words.
> 
> > And yes, you could add it once we find it's an issue, but by then someone
> > has already spent time to work around this. And when you then start sending
> > slot events all the time, you admit that writing the workaround was just a
> > time waster :)
> 
> Work around what, exactly?

I was referring to having a protocol where processes has to ignore contacts
already down until they've been there when a contact was pressed (and your
comment that if this becomes an issue it could be added lateron). 
Now, the ignoring part needs to be written (this is the "workaround"
referred to above). if you're planning to add it later, we need to cater for
that part as well then, having two implementations depending on the kernel
versions.

but this is just for clarification, it's a moot point anyway given that
button events have the same behaviour. so, nevermind, I think we can just
ignore it and get on with life.

Cheers,
  Peter

> >> As a side note, the notion of a used slot depends on how the attributes of the
> >> slot are interpreted. The method described in the document treats an
> >> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
> >> unused slot.
> > 
> > It's easier for a latecomer to guess a tracking ID since you can just
> > assign any random value to it, provided the kernel guarantees to only send
> > updates on the tracking ID for changes. This doesn't quite work for slots.
> > 
> > But I'm not sure what your last sentence means. Does this mean the kernel
> > will open a new slot for out-of-range tracking IDs? I'm missing something
> > here.
> 
> I am referring to the notion of create-move-destroy from earlier discussions,
> and the question of how it is implemented using slots. The document is a bit
> unclear on this point, so I will add a note stating something like this:
> 
> * Every slot with a tracking id within the value range represents a contact.
> 
> * Tracking ids not previously present are considered new.
> 
> * Tracking ids no longer present are considered removed.
> 
> Cheers,
> Henrik
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists