Surface Go: pen triggers eraser under X11 but not Wayland #52
Comments
ShapeShifter499
changed the title
|
I have the same problems as @ShapeShifter499 . I've compiled the wacom driver following the instructions looked into the log files by first running which printed I then enable debug messages via and looked into Here is one moment where the stylus switches to the eraser: And in the following there is a situation with the eraser switching back to the stylus: As @ShapeShifter499 mentioned in the other thread, the switch seems to have something to do with the tilt, as the pen tool seems to switch only when the tilt changes. Although I don't understand some of the events happening there, I find it interesting that right before the change, it seems like a button event is detected while right after the change there are these weird serial update messages. I also fiddled around with gdb a little but I did not find anything useful in the stack traces of the events. I hope this helps a little. I would really love to see this fixed somehow. |
|
Another quick update: After that, I also got the debug output between device access (in my case /dev/input/event19) and the wacom event dispatcher that parses the events and forwards them to the tool handling. Here is another log output of a sudden (and wrong) tool switch: I noticed that the switches from stylus to eraser and eraser to stylus correlate with the lines. This call is located in line 1044 in |
|
Should this line be fixed or am I misunderstanding the code? xf86-input-wacom/src/wcmISDV4.c Line 724 in 26cc501 Changed to |
Although the line looks suspicious, I don't think that the ISDV4 backend is involved at all. In my logs, only the USB backend is used. Or am I missing something? Furthermore, the channel is initialized at xf86-input-wacom/src/wcmISDV4.c Line 684 in 26cc501 and never changes after that. So one would have to compute the channel from the device type or something first. |
|
I haven't had a time to look into this yet (sorry!) but @Baldurius is correct that the ISDv4 backend isn't going to be used for this device. The issue will be in either I find the following lines from the log particularly suspect, however: These are the kernel events that are received and basically translate to: The presence of Lines 799 to 801 in 2062126 One effect of protocol 5 in particular is the driver "discovering" tool type information from the ABS_MISC value. In particular, the mask 0x008 is used to determine if a tool is an eraser. At least for the above log this is the case, and might be why the driver suddenly thinks an eraser is present: Lines 1157 to 1183 in 2062126 I don't know what data the Surface Go pen is sending through ABS_MISC, but one way to see if it is a protocol issue would be to change the first hunk of code above to something more like the following so that the driver forces the use of generic protocol: |
|
Yes! The pen is working now! Thank you very much @jigpu for the valuable insights. First I tried your suggestion and substituted Then I looked for Line 1611 in 2062126 into While this resolve the eraser issue, the lines were sometimes cut off. I then continued looking for ABS_MISC and commented out Lines 1266 to 1269 in 2062126 Now the stylus and even the eraser work as expected. This is of course far from a proper fix. I printed some more of these ABS_MISC events: To me this looks like angle information (angle * 100) in 45 degree steps. This would also explain @ShapeShifter499 's observation that it has something to do with pen angle. |
|
@jigpu any new updates with this? Seems really close to a fix. |
|
Sorry, this hasn't been able to bubble to the top of my priority queue yet 🙁 Its good to hear that you were able to isolate something that changes the behavior though -- it definitely will save some time trying to understand what needs to be changed. I do somewhat wonder about the source of the ABS_MISC data, but it ultimately doesn't matter since we obviously can't assume non-Wacom hardware abuses the evdev protocol in the way we expect. |
|
@jigpu From the hid-recorder logs on linuxwacom/libwacom#75 under Seems to be the azimuth. This would fit @Baldurius' range of values and @ShapeShifter499's observed behavior. |
|
@Baldurius I tried making a patch of your workaround that I could apply in the PKGBUILD used by the official Arch Linux xf86-input-wacom package. After compiling and installing the pen side works but the eraser side does not. Are you using the official Arch Linux compiled kernel? Are you making use of any xorg.conf settings? UPDATE: ok so a xorg.conf is needed with the above workaround. 60-wacom.conf.txt saved to /etc/X11/xorg.conf.d/60-wacom.conf Works in most but I cannot get Xorunal++ working. Still would like to know your exact config @Baldurius |
|
@Baldurius @jigpu any further updates yet? |
|
Any updates on this? It's been a while |
|
I was able to spend some time on this Friday and have a set of patches that will hopefully work. They're on my other machine at the moment but I'll post them here as soon as I can. |
|
@jigpu I hope they work. I also suspect that it might fix linuxwacom/libwacom#70 But I'm not sure. |
Many Wacom devices use a non-standard meaning for several axes and we should be careful not to apply those meaning when receiving events from a generic device. Incorrectly using the non-standard meanings can cause the driver or userspace to become confused. Ref: linuxwacom#52 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Generic devices don't store tool ID information in ABS_MISC, so we should be careful to not accidentally interpret other miscellaneous data as such. Ref: linuxwacom#52
It seems that some non-Wacom tablets have an ABS_MISC axis that makes our driver try to apply special Wacom-only axis behaviors. This commit makes the driver use WCM_PROTOCOL_GENERIC for any device that does not have Wacom's VID. Ref: linuxwacom#52 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
|
I've pushed a branch with the fixes to my repository. You can get a copy by running the following |
|
@jigpu Good news, it seems to have completely solved the issue for me. It also seems to have solved linuxwacom/libwacom#70 Testing on both tablets. Works fine in, Xournal++, "Stylus labs Write", and GIMP. For Xournal++ I needed to enable the "Enable GTK Touch/Scrolling workaround" under Edit > Preferences > Touchscreen (seems to be apart of new code present in Xournal++ v1.0.12) I do have a question about the code, is it disregarding tilt altogether? Is there any plans to try to properly include tilt? I don't know if I actually will need tilt but would be nice to know if there will be plans to properly handle tilting. Would be nice to have in case anyone is attempting to use Linux and do artwork with the tablet |
|
@jigpu oh one more thing. Keeps giving me a "battery low" message for my stylus when it nears the screen for the first time, both tablets. |
|
@jigpu Do you need any logs from this before the code gets accepted upstream? |
|
@ShapeShifter499 no, the "battery low" message won't be impacted by this particular patch and should be handled in a separate issue. The kernel driver would be responsible for that, so you'd either need to report it to https://bugzilla.kernel.org/ (or the developer of the kernel modifications if you're using them). Same for the ABS_MISC tilt information (if it provides anything of values over the ABS_TILT_X/Y that I thought it was already reporting. |
|
@jigpu I'm a bit confused. I wouldn't know if tilt is being handled properly or not since I never had any stylus device before that supported it. I only "guessed" because it seemed like when I was tilting the issue was triggered and later confirmed by @Baldurius. My question about tilt is, should it be still handled with the code you posted or is it being ignored? The "battery low" might be because I haven't connected the bluetooth bit of my Pen as @qzed mentioned at linuxwacom/libwacom#89 |
|
@jigpu ok with messing around in Krita, seems tilt works great! I think the code should be merged into mainline. But I have a question. In 'xinput test' what are the different values exactly referring to? what is |
|
@ShapeShifter499 glad to get confirmation that tilt is working correctly :) The sensor sends As for the |
|
@jigpu I'm going to reopen because a new release should also be made. |
|
@jigpu Should this change go into the upstream 70-wacom.conf? Doesn't seem the stylus, eraser, and touch are properly detected without it. Still requires the previous patches though. |
|
That might be a good idea. Would you mind submitting a pull request with the modification? Are there other Surface devices with other IDs that would also benefit? Also, as a matter of course, we normally mark issues as resolved once the code is merged since we'll obviously be making a release at some point anyway :) |
|
/cc @qzed You might want to chime in here about the configuration bits. |
After some back and forth on this linuxwacom/libwacom#75 It was determined the issue lies somewhere in xf86-input-wacom. But the exact fix is unknown and it's not clear what part of code is failing here.
When using the pen in X11 and Gnome, the pen is triggering the eraser (or whatever tool the 'eraser' end was set to). Applications like GIMP, Xournal, and Stylus Labs Write all showed the same issue.
However under Wayland and Gnome these issues went away. The pen tip wrote fine with pressure sensitivity and the eraser end erased lines. All previously tested applications no longer had issue.
So this is where I'm at now, I'd like to see X11 support fixed as there are still some quirks with Wayland.
The text was updated successfully, but these errors were encountered: