New approach to multitouch using DIDs and bitmasked events
Rafi Rubin
rafi at seas.upenn.edu
Mon Jul 5 11:30:21 PDT 2010
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
More information about the xorg-devel
mailing list