Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT
On Mon, Jan 9, 2012 at 5:20 PM, Chris Bagwell wrote: > On Mon, Jan 9, 2012 at 3:02 PM, Ping Cheng wrote: > > On Mon, Jan 9, 2012 at 7:22 AM, Chris Bagwell > wrote: > >> > >> > >> I'd like to understand this better if ya don't mind. > >> > >> First up, is this usecase for absolute or relative mode? > > > > > > Very good question ;-). To be honest, I didn't think about that when I > > worked on it. It was for touchscreen devices. So, I assumed absolute > mode. > > But, from the code, it is clear that I have not taken care of that... > > > >> > >> I'll phrase it like that instead of touchscreen/touchpad since some > people > >> put > >> touchpad in absolute mode. Also, are gestures enabled or disabled? > > > > > > I would suggest that wcmMT only applies to absolute mode unless you see > if > > differently. Under this assumption, gestures will have no meaning. > > > > I still don't quite see the issue so hard to say. I assume if its > useful to absolute then it could be useful to relative. > > >> > >> 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). > > > > > > The issue is not with gestures. > > There was one part that is not exactly gesture related. Its correctly > setting the oldX/Y values at the right times. If you don't get this > right for MT then you'll see jumps. > > > It is the "raw" ST value we get from the > > kernel that is jumpy. > > When you say ST here, what do you mean? Do you mean ABS_X/Y by ST? > xf86-input-wacom ignores those when device supports MT. Do you mean > "raw" values of MT_SLOT==0? > > I think you've been working on a touchscreen where Slot 0 is not as > reliable first touch any more so probably thats what you mean. I do > not have have much experience with these type and how they would > behave with xf86-input-wacom. > > For this, we probably need small updates to our channel selection > logic to pick Slot with oldest ID and put it in channel 0 instead of > always Slot 0. > > > >> > >> Maybe you should try today's git and see if the issue is reproducible > any > >> more. > > > > > > Will try, but not for this issue I think. > > > >> > >> 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. > > > > > > As mentioned above, the jump was "raw", we can not use the ST events > > reported from the kernel as is when there are more than one finger on the > > tablet. > > > >> > >> 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. > > > > > > How did that work? > > They keep it quite simple. When current_num_touch != > previous_num_touch then they empty their filter history and require > filling the history back up (something like 5 packets) before movement > is allowed. All brands of touchpads seem to have some amount of > unstable X/Y right at finger transitions. > > We used to have something in xf86-input-wacom that waited 4 samples > before allowing movement when coming into proximity but I can't find > that logic any more. > > We can add history reset in easy enough during touch count transitions > and it wouldn't be to hard to go back to requiring wcmRawSample's > worth of packets before movement. We also need to be updating oldX/Y > when resetting filter window. > > Without this and in absolute mode, I could envision in Gimp that > lifting 1 finger away during 2 finger case could cause a line to be > drawn towards the remaining finger as the filter window clears out the > old touches. This could be the jump? > > > > >> > >> 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. > > > > > > You are right. I think that is the root cause of the jump, which I do not > > have a way to correct, and ST app users do not like. > > I'm thinking something like above could help out a lot. I have some > ideas how to do it but will be the weekend before I can play with it > to much. > Guess what? I pulled today's xf86-input-wacom from git. The new driver only reacts to one finger on my 0xE5 unit. So, it works as I would like it to be, at least for now. I do not think I need to add this new op
Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT
On Mon, Jan 9, 2012 at 3:02 PM, Ping Cheng wrote: > On Mon, Jan 9, 2012 at 7:22 AM, Chris Bagwell wrote: >> >> >> I'd like to understand this better if ya don't mind. >> >> First up, is this usecase for absolute or relative mode? > > > Very good question ;-). To be honest, I didn't think about that when I > worked on it. It was for touchscreen devices. So, I assumed absolute mode. > But, from the code, it is clear that I have not taken care of that... > >> >> I'll phrase it like that instead of touchscreen/touchpad since some people >> put >> touchpad in absolute mode. Also, are gestures enabled or disabled? > > > I would suggest that wcmMT only applies to absolute mode unless you see if > differently. Under this assumption, gestures will have no meaning. > I still don't quite see the issue so hard to say. I assume if its useful to absolute then it could be useful to relative. >> >> 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). > > > The issue is not with gestures. There was one part that is not exactly gesture related. Its correctly setting the oldX/Y values at the right times. If you don't get this right for MT then you'll see jumps. > It is the "raw" ST value we get from the > kernel that is jumpy. When you say ST here, what do you mean? Do you mean ABS_X/Y by ST? xf86-input-wacom ignores those when device supports MT. Do you mean "raw" values of MT_SLOT==0? I think you've been working on a touchscreen where Slot 0 is not as reliable first touch any more so probably thats what you mean. I do not have have much experience with these type and how they would behave with xf86-input-wacom. For this, we probably need small updates to our channel selection logic to pick Slot with oldest ID and put it in channel 0 instead of always Slot 0. > >> >> Maybe you should try today's git and see if the issue is reproducible any >> more. > > > Will try, but not for this issue I think. > >> >> 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. > > > As mentioned above, the jump was "raw", we can not use the ST events > reported from the kernel as is when there are more than one finger on the > tablet. > >> >> 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. > > > How did that work? They keep it quite simple. When current_num_touch != previous_num_touch then they empty their filter history and require filling the history back up (something like 5 packets) before movement is allowed. All brands of touchpads seem to have some amount of unstable X/Y right at finger transitions. We used to have something in xf86-input-wacom that waited 4 samples before allowing movement when coming into proximity but I can't find that logic any more. We can add history reset in easy enough during touch count transitions and it wouldn't be to hard to go back to requiring wcmRawSample's worth of packets before movement. We also need to be updating oldX/Y when resetting filter window. Without this and in absolute mode, I could envision in Gimp that lifting 1 finger away during 2 finger case could cause a line to be drawn towards the remaining finger as the filter window clears out the old touches. This could be the jump? > >> >> 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. > > > You are right. I think that is the root cause of the jump, which I do not > have a way to correct, and ST app users do not like. I'm thinking something like above could help out a lot. I have some ideas how to do it but will be the weekend before I can play with it to much. Chris > > Ping -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lis
Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT
On Mon, Jan 9, 2012 at 7:22 AM, Chris Bagwell wrote: > > I'd like to understand this better if ya don't mind. > > First up, is this usecase for absolute or relative mode? Very good question ;-). To be honest, I didn't think about that when I worked on it. It was for touchscreen devices. So, I assumed absolute mode. But, from the code, it is clear that I have not taken care of that... > I'll phrase it like that instead of touchscreen/touchpad since some people > put > touchpad in absolute mode. Also, are gestures enabled or disabled? I would suggest that wcmMT only applies to absolute mode unless you see if differently. Under this assumption, gestures will have no meaning. > 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). The issue is not with gestures. It is the "raw" ST value we get from the kernel that is jumpy. > Maybe you should try today's git and see if the issue is reproducible any > more. Will try, but not for this issue I think. > 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. > As mentioned above, the jump was "raw", we can not use the ST events reported from the kernel as is when there are more than one finger on the tablet. > 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. How did that work? > 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. > You are right. I think that is the root cause of the jump, which I do not have a way to correct, and ST app users do not like. Ping -- 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
Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT
On Mon, Jan 9, 2012 at 7:51 AM, Ping Cheng wrote: > On Sun, Jan 8, 2012 at 9:56 PM, Peter Hutterer > wrote: >> >> On Sun, Jan 08, 2012 at 12:16:57AM -0800, Ping Cheng wrote: >> > On Saturday, January 7, 2012, Chris Bagwell >> > 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
Re: [Linuxwacom-devel] linuxwacom project - asustek eeenote tablet
I'd like to summarize where we are with Eee Note's for mailing list archive.
Mike was able to log some USB packets when using tablet under Windows
and sent them to me directly. This showed that the device works
almost exactly like a Bamboo tablet. We were assuming it was more
TabletPC and thats why we were not having success.
Packets started flowing correctly after adding the USB PID to
hid-core's blacklist and then using this in Wacom driver:
+static const struct wacom_features wacom_features_0x179F =
+ { "EeeNote ASUSTek Digitizer", WACOM_PKGLEN_BBFUN, 16480, 12410, 255,
+ 0, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
There is one outstanding issue. This device does not use the same
bits to indicate in-proximity that Bamboo's/TabletPC's are using but
everything else is the same. For the short term, you can edit the
file wacom_wac.c and modify the function wacom_bpt_pen(). Look for
line that says:
prox = (data[1] & 0x20) == 0x20; <--- Linux 3.3 or later
or
prox = (data[1] & 0x30) == 0x30; <--- Linux 3.2 or earlier
and change that to:
prox = (data[1] & 0x10) == 0x10;
I will see if there is a bit that is common between all products that
we can use for in-proximity or if there is some kind of if() statement
we can add to work with multiple product types.
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
Re: [Linuxwacom-devel] [PATCH 2/2] Add a new property: WACOM_PROP_ENABLE_MT
On Sun, Jan 8, 2012 at 9:56 PM, Peter Hutterer wrote: > On Sun, Jan 08, 2012 at 12:16:57AM -0800, Ping Cheng wrote: > > On Saturday, January 7, 2012, Chris Bagwell > 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. Changing the kernel MT code?! You bet ;-). Ping -- 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
