← Back to team overview

multi-touch-dev team mailing list archive

Re: A new release of xi 2.1 + utouch stack in xorg-unstable ppa

 

On 02/07/2011 06:20 AM, Henrik Rydberg wrote:
> Hi Chase,
> 
>> The past few weeks have been challenging for xi 2.1 development on
>> Ubuntu. The new xserver 1.10 has been pushed to natty and, though this
>> really helps us overall, the transition has impacted installability of
>> packages from the xorg-unstable ppa.
> 
> I suspect this is actually the most unstable ubuntu cycle in a while,
> given the amount of exciting work that is currently taking
> place. Kudos for making it work so well in such a fluid environment.

Thanks :)

>> I come bearing good news! I have remade all the packages in the ppa as
>> patched versions of the natty X packages. This means we are close to
>> pushing things into Ubuntu proper! I would encourage everyone who is
>> interested to give the packages some testing. Here's an overview of how
>> to install the ppa:
>>
>> $ sudo add-apt-repository ppa:utouch-team/xorg-unstable
>>
>> Create and/or edit /etc/apt/preferences.d/utouch-team-xorg-unstable to
>> include:
>>
>> Package: *
>> Pin: release o=LP-PPA-utouch-team-xorg-unstable
>> Pin-Priority: 1001
> 
> It seems this is not even necessary anymore?

I'm now basing the work on the packages as they are pushed into Ubuntu.
That means that there are times when an Ubuntu package is higher
versioned than what's in the ppa. When that happens, you want to stick
with the packages in the ppa, or else you may break your system. For
example, if xorg-server alone is updated in Ubuntu, you may end up with
non-xi2.1 xorg-server installed with xi2.1 input modules. This would
prevent X from starting.

>> At this time I would like to receive any issues or bug reports on this
>> mailing list. We will transition to launchpad for bug reports once the
>> work is in Ubuntu proper, but due to things still being in flux I think
>> reports are better here for now.
> 
> There is an important difference in the handling of prolonged gestures
> in this environment, which seems to imply that not all basic
> application gesture needs can be met with this approach.
> 
> With the maverick X drivers (synaptics and multitouch), it is natural
> to position the cursor with one finger, and then add another finger to
> scroll a bit, life one finger to position the cursor again, and so
> on. The same goes for zooming, where one first positions the cursor,
> then zooms at that point.
> 
> With the new natty XI2.1 packages, the gesture engine releases control
> over a touch based on a timeout, passing it on to the application in
> such a way that the modus operandi described above no longer is
> possible. In practise, one might need to view the server-side
> recognition as dedicated to system gestures, and instead reimplement
> the current application behavior on the client side.

It's not confined to system gestures, but to gestures that are clear
from the start. For example, you can still have a two finger drag
gesture, but you must initiate it immediately. It can't morph into a two
finger drag from a one finger drag, for example.

You have been a proponent of trackpad position then scroll then position
based on the number of fingers. I believe this comes from how OS X does
things. I think there are a few reasons why OS X can handle this, and
why it doesn't fit in our system as it is:

1. We have been of the mindset that a touch stream from X must only end
when the touch has physically ended. Another way of stating this is that
any client using the touch stream events must either use the entire
physical stream or none of the stream.

2. OS X performs two finger scroll recognition on the server side. We
have been of the mind that all multitouch gestures should be handled
client side.

Because of 1, we cannot start moving the pointer with a touch stream,
and then end the touch stream when a second touch begins and we start
performing a scroll. I believe OS X skirts 1 by checking if the window
under the cursor wants touch events, and if not it will send scroll
events as appropriate. In essence, I believe OS X is special casing
scrolling.

Maybe we should be special casing scrolling too, but I'm not quite
convinced. I would rather have the window system be "dumb" and handle
things like scrolling on the client side. This would prevent lock-in to
a poor system only fully understood in the future (just like we have
with scroll buttons in X today). However, it may mean that we lose the
ability to have position then scroll then position based on the number
of fingers, as OS X does.

Thanks,

-- Chase



Follow ups

References