[RFC XI 2.1] current issues

[Denis Dzyubenko]

On 7 December 2010 20:07, Daniel Stone <daniel at fooishbar.org> wrote:

>> Chase, Daniel: would be nice to put packages with debugging symbols to the ppa.
>
> I have nothing to do with the PPA, sorry: I run Debian, and only test
> against master.  As for the crash, I don't have a Magic Trackpad either,
> but will try to get my hands on one.

I would like to be able to test latest versions of the XI2.1 changes
from time to time, and the easiest way (at least for me :P) is the
ubuntu ppa with binaries. The last time I tried to compile modular
xorg using the wiki and provided shell scripts I failed miserably.

>> - Who is going to "adjust" valuators values for different devices?
>>
>> For example the Touch Minor and Touch Major valuators give me totally
>> different values for N-Trig touch screen and for the Apple Magic
>> Trackpad.
>> On the N-Trig I usually get values around 400 for my finger pressing
>> gently while the range is from 0 to 9600; while with the magic
>> trackpad it is around 100 in the range 0 to 255.
>
> Hm, I'm not sure how much we can do here without a table of
> device-specific scalings.  Maybe we just need to get better data from
> the kernel.

I guess different kernel driver for different device _will_ give you
different data. Hence my question was in context of recent discussion
- getting events through slave devices vs. master devices - I would
expect the data to be "unified" so that clients won't need to have
device-specific workarounds. I wouldn't be surprised if some
parameters would need to be configurable - the only example that comes
to my mind right now is again width/height of the touch - right now I
do not know what the value means and just assume that value 255 (the
maximum for magic trackpad) means 50 pixels wide.

>> Another example is the MTAbsX valuator coming from the N-Trig - the
>> range announced to be from 0 to 9600, while the value is actually in
>> screen coordinates.
>
> Hm, the x/y/root_x/root_y co-ordinates are in screen co-ords, but the
> valuators themselves (appended to the event) should be in device
> co-ordinate space.  I'll check this out.

With N-Trig those valuators are in screen coords - at least touching
in the bottom-right corner gives me the value that matches exactly the
resolution of the screen.

>> Other than that it seems to be working fine and I am looking forward
>> to having grabs implemented :) Awesome job guys!
>
> Thanks. :) Please do keep testing it out and let us know about any more
> problems.  Right now, the main problem I'm tracking is related to grabs
> and short-lived touches: the touch may be finished before the grabbing
> client has a chance to process the data and release the grab to pass on
> ownership.

my understanding of grabs is pretty vague. I guess you are talking
about non-synchronous grabs? Sounds like synch-grabs should be used
all over the place instead of you want to handle short-lived touches.

How does it work for fast mouse clicks? I would expect the timing of a
short-lived touch be exactly the same as the timing of a mouse button
press and release.

> My current hunch is to hold TouchEnd events until any grabbing client
> has asserted ownership of the touch, or the last grabbing client has
> released it to be played to selecting clients.  This adds a little more
> scope for clients to get it wrong, but I don't see any other way to make
> it work, and this is how grabs work today too.




oh and one more question. I guess it will not be possible to get
additional information about the touch device unless the driver
exposes it? In my case I would like to know the physical size of the
device in metric units - the size of the magic track pad - I want to
be able to match metric distance between two fingers on the touch pad
to the distance of the feedback on the screen.

-- 
Best regards,
Denis.