New approach to multitouch using DIDs and bitmasked events

[Rafi Rubin]

On 07/05/2010 02:06 PM, Chase Douglas wrote:
> On Mon, 2010-07-05 at 13:48 -0400, Rafi Rubin wrote:
>> On 07/05/2010 01:31 PM, Chase Douglas wrote:
>>> On Mon, 2010-07-05 at 13:20 -0400, Rafi Rubin wrote:
>>>> On 07/05/2010 12:54 PM, Chase Douglas wrote:
>>>>> The reason we can't pass DIDs as XI1 events is because an XI1 client
>>>>> also doesn't see "floating" input devices that aren't attached to master
>>>>> pointers. Only XI2 can see events from "floating" input devices.
>>>>
>>>> Would vestigial valuators enable us to support XI1?  Do we care about XI1?
>>>
>>> Heh, I feel like we're returning to the conversation I had with Peter
>>> about legacy client support. Essentially, you need XI2 for multitouch,
>>> and the toolkit layer should use XI2 and translate to toolkit events as
>>> required. XI1 just isn't extensible enough for multitouch.
>>
>> Yup, I was thinking of what you said before with something watching all the MT
>> contacts moving around and producing conventional pointer events where they are
>> needed.  It sounds like a great idea.
>
> Yeah, the problem is that the X architecture really just does not allow
> this to happen. The *aha* moment for me was when I was reading the
> wikipedia article about X :). It quoted some early principles of X, one
> of which was:
>
> Provide mechanism rather than policy. In particular, place user
> interface policy in the clients' hands.
>
> Thus, it makes sense why X is architected as it is, but it also means we
> have to solve issues like MT pointing above X itself.
>
>> However, it is yet another obstacle in the path of getting MT to the X desktop.
>>    When you say toolkit, I hope you mean just some separate piece of code, and
>> not requiring gtk/qt to get conventional pointer events.  I'd hate to loose
>> support for some real legacy apps (which I actually use for my work), where it
>> really is standard X events or nothing (programs written in straight xlib,
>> statically compiled, obscure toolkits, etc).
>
> I think the real solution is getting the MT to pointer translation in
> all the toolkits. If you build your programs right, they shouldn't be
> statically linked to toolkits. A toolkit upgrade should just magically
> make things work in older applications.
>
> Now, if you've really written stuff in xlib, then you'll have to fix it
> up manually. How many applications are really written in xlib though?

Enough.

I take it you aren't stuck with commercial tools.  My lab uses various FPGA CAD 
tools which are maintained conservatively, ie if they use a toolkit that does 
eventually support MT->conventional, then I'd still expect it to take a couple 
years (optimistically) to see the tk fixes percolate back to my desktop.

I also work with academic tools, which were started in the early/mid 90's that 
are written in xlib.  As yes its nice to examine route by tapping the wires to 
follow a path.  While I could rewrite that code, its a pretty simple user 
interface that's actually well written.  Switching to a tk would probably result 
in larger and more complex code.

Oh, and um, well, I do actually select text in xterms with my fingers (and for a 
while I also had paste working, but was convinced to remove 2 and 3 finger 
clicks in favor of the MT protocol).

Rafi