multi-touch-dev team mailing list archive

[Daniel Stone <daniel@xxxxxxxxxxxxx>]

Hi,

On Tue, Dec 07, 2010 at 10:36:36PM +0100, Denis Dzyubenko wrote:
> On 7 December 2010 20:07, Daniel Stone <daniel@xxxxxxxxxxxxx> 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.

If you could file bugs or mail the list about this, that'd be nice; it'd
be great if this just worked out of the box everywhere without having to
rely on PPAs.

> >> - 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.

Well, if the N-Trig kernel driver tells us that the range of values is
0-9600 and the maximum you get is 400, then it means that either your
finger is too small and pressing with a freakishly large finger will
give you a value of 9600, or that the kernel is giving us incorrect
scale information.

So at best, it's a driver fix, at worst it means that somewhere (be it
kernel or X server), we need a device-specific table to fix up these
values.

Make sense?

(Bear in mind that we make no attempt to correllate these values to
 pixels.)

> >> 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.

Yep, found the bug (which was only present for direct input), fixed in
my branch.  It would be nice if we could get the build script so you
could test this as well.

> >> 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.

The problem with synchronous grabs is that they introduce fairly
unacceptable latency, especially if you're expecting high-frequency data
to come in, which we require[0].

> 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.

Mice don't have the same concept of event streams which appear and
disappear: they just have the individual events, which can be held,
discarded, or replayed.

> > 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.

Yeah, the driver needs to provide it, as we can't really just make it
up.

Cheers,
Daniel

[0]: You can turn down the reporting frequency if you like, but then you
     get sky-is-falling-severity bugs because you can't draw a circle in
     your drawing app, only a series of stepped lines.

Attachment: signature.asc
Description: Digital signature