On 7 December 2010 20:07, Daniel Stone <dan...@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. _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
