#358 CTL-471 CursorProximity doesn't work

[airi sakura]

Cannot change Wacom CTL-471 cursor proximity. It is painfully low and causes cut out issues if i lift the pen up too high. The value is higher on Windows and I never had any issues until using it on Linux. This parameter is important for my use case and I'd really appreciate a fix...

input:

xsetwacom --set 9 CursorProximity 100

output:

Property 'Wacom Proximity Threshold' does not exist on device.

---

output from xsetwacom --list:

Wacom Bamboo One S Pen stylus       id: 9   type: STYLUS    
Wacom Bamboo One S Pen eraser       id: 10  type: ERASER  

version 0.36.0 i don't think i'm doing anything wrong sorry i'm new to linux

[airi sakura]

Ok, so I guess if I'm not wrong CursorProximity is a "pad" attribute but I don't have a pad option in the above list... How can I fix that? Or is it a bug?

I'm running Manjaro's newest kernel (4.15.0-1) if that matters...

Though I'm pretty sure it wasn't showing up in the other few distros I tried before sticking with Manjaro these past few days.

[Jason Gerecke]

We don't apply a threshold to pen/eraser devices (the "CursorProximity" property is only valid for "cursor" devices). If the hardware reports that the pen is in (or out of) proximity, our driver reports the same. Some devices (e.g. Intuos Pro) have an "in range" state which occurs while the pen is too far away to be considered "in proximity". I'm not sure if your particular device has such a state, but it could explain why the pen feels different under Windows and Linux. We stop updating pen data while "in range", but otherwise still treat it as being in proximity (e.g. leaving touch input disabled and button states valid).

If the CTH-471 has this state, we could theoretically add support for it. That said, supporting "in range" was pretty tricky for the Intuos Pro and wouldn't be a high priority for us to extend to the 471...

Could you explain your use-case and why its problematic for the pen to cut out if lifted too high? Perhaps there's a different way to tackle your problems than "in range" (assuming it's even available for your tablet).

[airi sakura]

here is a video of my use case: https://www.youtube.com/watch?v=94mFYR4ZGVg

i play a music game called osu (http://osu.ppy.sh/) at a kind of high level (you aim to the circles and use a key on your keyboard to click them, most higher ranked players play with a tablet)

i've tried to switch around my playstyle/how i hold the pen but i only have around 0.75cm of height until the pen will cut out and stop tracking on linux --- it's really uncomfortable to hold it that low without dragging.

I switched to linux because the wacom drivers for windows have bad input latency (rawsample + suppress turned to 1 and 0 is great which i can't seem to do on windows) and also the sound latency on windows sucks. Linux has solved all of these problems for me and i'd really like to continue playing on this OS

the game might get an official linux release in the future so this may be a problem for other people that decide to switch operating systems

this might be a strange use case but i'd really appreciate it if something could be done about the issue

if i can help test anything i'd be glad to

[Jason Gerecke]

I've made some modifications to our input-wacom driver which tries to add minimal "in range" support for your device. You'll want to run the following commands to get and build the driver. I'm not 100% sure about that the "pacman" command, but I think its right for your system...

$ sudo pacman -S base-devel linux415-headers
$ git clone https://github.com/jigpu/input-wacom.git -b bamboo-inrange
$ cd input-wacom
$ ./autogen.sh
$ make

To load the new driver, run sudo rmmod wacom && sudo insmod 4.5/wacom.ko from inside the input-wacom directory. Afterwards, you should be able to run cat /sys/module/wacom*/version and see the following version number reported: v2.00-0.38.0.12.g87a0500. If that matches up, go ahead and see if you can hover the pen at any higher than normal.

You can switch back to the stock driver at any time by running sudo rmmod wacom && sudo modprobe wacom or rebooting (the stock driver should report a version of v2.00). If things seem to be working, you can permanantly install the modified driver by running sudo make install.

If the modification seems to work, please try to test the tablet outside of just the "osu" game to see if there are any unexpected side-effects (e.g. try using it instead of a mouse for a bit, and see if you notice any weird effects or proximity issues around 0.75cm of height).

I'll include a link to the wiki page here as well, just in case: http://linuxwacom.sourceforge.net/wiki/index.php/Input-wacom

[airi sakura]

I've followed your instructions and have done some testing... but the driver doesn't actually function any differently during use.. sort of

The reported version is indeed the one you listed above but when I run sudo libinput debug-events:

the TABLET_TOOL_PROXIMITY value now will report at a distance of 1.00 but the cursor won't actually move until it reaches a value of 0.77 (the old maximum value for TABLET_TOOL_PROXIMITY on the stock driver) at which point TABLET_TOOL_AXIS will start to report events too.

A concern: can the value be made any higher? I can't test to see how much better it is for the above reason but i'm not sure a 2.5mm difference will be a full fix

thanks for the speedy work :)

[airi sakura]

-

[Jason Gerecke]

Hmm, okay. Could you please try running git pull from inside the "input-wacom" directory and then rebuild and test the driver as previously outlined? The version of the updated version should be v2.00-0.38.0.13.g1f0a1fb.

I've intentionally left cursor motion disabled if the pen is in this "in range" state for the moment, but you should be able to see the proximity flag change at a greater distance if this works. Although its not what you're looking for, it matches up with the behavior of the Intuos Pro codepath. We left cursor motion disabled in the "in range" state because otherwise cursor movement seems to get a bit noisy/jittery. It might be sensible to enable it for the Bamboo if it has less hover height than the Intuos, but I'd like to consider that question seperately for the moment.

[airi sakura]

the hover distance is definitely higher now, TABLET_TOOL_PROXIMITY first detects the pen around at around 2cm when measured with a ruler and the cursor will start moving somewhere bewtween 1.25 and 1.4cm.

i'm currently in the middle of reinstalling the game i play because i had to fix something but i'll try that in a few minutes with an included Raw Input setting

currently a weird "bug" i see in desktop usage is that when the pen first enters TABLET_TOOL_PROXIMITY the cursor will teleport to the top left corner of the screen until it enters TABLET_TOOL_AXIS range

i personally don't mind jitter since the cursor doesn't seem to leave centre by that much and would rather the cursor at least move than just cut out if out of range

[airi sakura]

the game feels much better to play now - the cursor cuts out much less now (if at all)

[Jason Gerecke]

Good to know. New version which should fix the jump has been made. Pull/build/test again and let me know how it works (version: v2.00-0.38.0.14.g8978982). If your pen has an eraser, it would be particularly useful to know if that is still functioning properly, especially if you bring the eraser into prox slowly. I have a feeling the modified code may sometimes (always?) end up treating the eraser like the stylus when that happens (I assume the tablet will starts sending position data before it knows it knows wether the tip or eraser end is being used -- one of the hazards of "in range").

Probably the simplest way to test would be to open two terminals and run xinput test <stylus_id> and xinput test <eraser_id> in each. Then, use the eraser for a bit. If everything is working right, only the window ran with the eraser ID should ever print anything out. If there's any output from the stylus ID window, that means I'll have at least one more modification to make...

[airi sakura]

I have an eraser ID when i run xsetwacom --list devices but i don't think my pen actually has one, sorry - the eraser end of the pen has never moved the cursor on any operating system.

i don't have xinput installed on manjaro but if you need me to test anything with it i can download it

[airi sakura]

oh and yeah the jump was fixed and things still work well

[Jason Gerecke]

Okay, good to know. I'll have to find somebody with an eraser to test this before sending it to the mailinglist, but at least you can benefit from it in the meantime :)

[airi sakura]

thanks for everything!! i've been able to play without any issues!

i had 2 questions but you don't have to answer the last one:

- where can I learn more about the things you're doing with tablets/programming this type of thing?

• do you know if there's anything that can be done on my side to further reduce cursor input latency with these tablet drivers other than RawSample and Suppress? it's ok if you don't know, i was just wondering

sorry if this is a bad place to ask but you seem pretty knowledgeable

[Jason Gerecke]

Something like tablet / driver programming is going to require hands-on time to learn. Documentation is spotty so you'll probably have to have to work with existing developers to find your way around the code, practices, etc. I got involved with this project years and years ago when I was annoyed by the lack of pressure sensitivity in a Java program I was using at the time. I worked with the developers here to understand the application side of things and add in support. Later on I returned to work on the driver itself. Depending on exactly what you're interested in learning there are different groups that you can get in touch with. Some will have bugs or features they haven't gotten around to fixing which would be a good place for someone new to get their feet wet. The Xorg foundation in particular has an excellent programam for students they call the "Endless Vacation of Code".

As for reducing input latency, reducing RawSample is about your only option. The Suppress option doesn't really impact latency, just jitter. With RawSample set to 1, the X driver should immediatly report events as they're recieved from the kernel. The kernel doesn't do any filtering that would introduce latency, so the hardware-to-X11 latency should be very minimal. You could potentially get a tablet with a faster report rate (most tablets report events every ~7ms, but IIRC some of the new professional tablets will send updates every 6 or 5ms).

You might see if there are sources of output latency that you could reduce. A CRT will have less latency than an LCD, and higher refresh rates will usually have lower latencies than lower rates. Performance-boosting features like double-buffering can also introduce one additional frame-time of latency -- pretty significant at 60Hz (16.6ms).

[airi sakura]

ok, thanks for the information, i appreciate it : )

[Aaron Skomra]

Linuxwacom has moved from Sourceforge to Github. If this is still an issue please reopen the bug at https://github.com/linuxwacom/input-wacom/issues