Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev3)

[Henrik Rydberg <rydberg@euromail.se>]

Chase Douglas wrote:
> On Sat, 2010-05-22 at 19:47 +0200, Henrik Rydberg wrote:
>> Chase Douglas wrote:
>>> On Sat, 2010-05-22 at 12:38 +0200, Henrik Rydberg wrote:
>>>> Getting serious, it is anyone's guess what will happen next, but I was picturing
>>>> a table, with a large multitouch screen and buttons along the side of the table.
>>>> Sure, we can do "ABS_BTN_0", "ABS_BTN_1", etc, but with slots in place, it seems
>>>> more natural to use something like "ABS_MT_BTN_X". While at it, REL_MT event
>>>> makes sense for those touchscreen techniques which register changes, like
>>>> acoustic pulse recognition.
>> s/ABS/KEY/
>>
>>> Shouldn't this be handled in userspace? I don't think we want to be
>>> quirking drivers for instances where the same touchscreen is overlaid on
>>> buttons in some cases, but not in others. If we don't quirk, we'd need
>>> some mechanism to tell the driver about such buttons.
>> Perhaps you would like to clarify what "this" means here, and how you arrive at
>> quirking drivers.
> 
> I'm arriving rather late to the conversation, so this could be a matter
> of me not understanding everything. What I thought you were proposing is
> something like what I have on my Nexus One: an MT area encompassing a
> touchscreen and extending to an area of four "buttons" off the bottom of
> the screen. I was thinking that interactions with these buttons would
> trigger the KEY_MT_BTN events you mentioned. However, if thats the case
> then the driver needs to know of these buttons, so we've gone from a
> dumb touchscreen driver to a driver that must be aware of regions of the
> screen where there are buttons. This is where I think it would be better
> to have a userspace application (X?) understand the properties of the
> screen to know exactly what a touch means, instead of trying to
> interpret it inside the kernel.
> 
> If this isn't what you meant, then feel free to ignore me :).

I see -- I was not thinking anything that advanced at all, but rather imagining
that some future driver development might consider using slots to communicate
arrays of similar (physical) button data. And that imagination, in turn, was an
example of why userspace would want to know which events are treated on a
per-slot basis.

And as Dmitry just said, KEY_MT will not happen, anyways. ;-)

Cheers,
Henrik