On Mon, Jan 9, 2012 at 7:51 AM, Ping Cheng <pingli...@gmail.com> wrote: > On Sun, Jan 8, 2012 at 9:56 PM, Peter Hutterer <peter.hutte...@who-t.net> > wrote: >> >> On Sun, Jan 08, 2012 at 12:16:57AM -0800, Ping Cheng wrote: >> > On Saturday, January 7, 2012, Chris Bagwell <ch...@cnpbagwell.com> >> > wrote: >> > > What was the usecase for this again? >> > >> > The goal was to disable touch events when there are more than one touch >> > on >> > the tablet while wcmMT is off. That is, we only report touch events when >> > there is only one touch on the tablet. >> what's the use-case for that though? You're essentially saying you want to >> disable multitouch but still report one touch? At what point is this >> useful? > > > Yes, we want to report ST when there is only one finger on the tablet. We do > not want to report ST when more than one fingers are on the tablet. >> >> The server (1.12) only does pointer emulation for one touchpoint anyway >> and >> any client that actually handles touch events is rather expected to deal >> with multiple ones. Same with the in-driver touch support. > > > With your above comments, I know you are going to come back another > question: "why do you want to do that?". ;-）Well, it is becaue the kernel MT > driver doesn't do the job for us. The way that the kernel input-mt.c > emulates ST causes too much jumps while changing from ST to MT and vice > verse. Our customers, whose apps only support ST, can not accept those > jumps. They'd rather only receive reliable ST when there is only one finger > moving. >
I'd like to understand this better if ya don't mind. First up, is this usecase for absolute or relative mode? I'll phrase it like that instead of touchscreen/touchpad since some people put touchpad in absolute mode. Also, are gestures enabled or disabled? For relative mode, Alexey just submitted a nice bug fix that may fix what your really worried about. Previously, during gestures-with-no-movement we were not storing updated X/Y movement so when you released gesture you'd get a big jump. I believe this was seen mostly during transition from 2 fingers to 1 finger (the case your talking about). Maybe you should try today's git and see if the issue is reproducible any more. Now on the ST vs. MT part. xf86-input-wacom doesn't know ST vs. MT. Its always MT to it. Sometimes its a MT with a count of 1 but still MT. So if we are seeing unwanted jumps during touch transitions, I'd like to understand that better because I think there are real xf86-input-wacom bugs to fix beyond giving an optional disable. I'm actually a little surprised that ignoring MT events and looking at only ST events helps instead of hurts. At least in xf86-input-synatpics, there is special logic to detect transition of fingers and to account for an expected cursor jump in ST values. Probably, for wacom it depends on finger release order. If you release 1st finger before 2nd finger then you should see a nice cursor jump since finger tracking is forced to move to only remaining finger. Chris ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
