New approach to multitouch using DIDs and bitmasked events

[Henrik Rydberg]

Peter Hutterer wrote:
> On Sat, Jul 03, 2010 at 01:10:24AM -0400, Rafi Rubin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07/02/10 05:59, Henrik Rydberg wrote:
>>> Peter Hutterer wrote:
>>> [...]
>>>> It'd be interesting to see how much work it is to have this API
>>>> _replace_ the current API. Gives us more exposure and better testing.
>>>> Note that I have some more API changes planned (not coded) that simplify
>>>> the init process, they should all go in in one go.
>>>> Another change that goes with that is the ability to easily split up
>>>> devices into multiple X devices. This would make it easier to handle
>>>> devices that have both MT events and normal events - they would simply
>>>> end up being two devices, one normal one, one DID.
>>>>
>>>> Henrik, Rafi - do you think this would work for the MT devices we've
>>>> seen so far?
>>> From a device perspective, absolutely. In the kernel, a single device can have
>>> any combinations of BTN, ABS, and MT events. Keys are getting there as well, but
>>> are still normally separated by force. In other words, trusting the kernel to
>>> make a logical split of events which fits the X framework is not very fruitful.
>>>
>>> Going forward, I wonder why we split input into separate devices at all. We have
>>> different types, and different behavior based on capabilities, but input is
>>> becoming so intermixed that the notion of separated devices looses its meaning.
>>> Why not just put all input events into the same bucket, and let clients specify
>>> what event types to listen to?
>> I agree, I don't see the need to artificially separate keyboards and pointers.
> 
> say hello to my friend the core protocol. approximately 100% of all
> applications rely on it (rounded to the nearest percent) :)
> who needs enemies if you got friends like this.
> 
> fwiw, about a year ago I had a private branch that gets rid of the
> pointer/keyboard distinction and provide a unified master device that's both
> pointer and keyboard. that didn't turn out well, grab synchronization is a
> nightmare.

I will take your word for it, but it does sound like there is not much of a
resistance against the idea. :-)

Cheers,
Henrik