-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wacom Tablet and Pen support issues #4617
Comments
cc @jchv |
Would be nice to collect |
So I start sway with |
Just start the client with |
Unfortunately, some of these problems may be related to libinput. It would be helpful to run |
Also, I am really sorry, but I still dont understand what you mean by "the client". The client as in the sway instance?
I have done that, here is the log for issue 3 of the mentions issues. I have reproduced issue number three here and right after just closed the application and quit sway. The link contains both the log from libinput as well as sway. |
The client is the app you're using, Xournalpp.
|
First of all, sorry for the delay. I really want to help to improve this as best as I can, i.e. provide logs that actually help. |
I haven't forgotten about this issue, btw. I was able to crash things by pressing tablet pad buttons rapidly and just generally trying to cram a lot of inputs in. It seems to crash XWayland too and I'm kind of curious if maybe wlroots is the culprit in this one. I don't really see a whole lot of code on the Sway end that's suspect. |
Any progress on this? |
You can help by making sure all crashes are reported, debugging them and sending patches to fix them. |
I'm currently at a loss on these. Usually, it doesn't crash on my end, but when it does, it does so in a chaotic way that changes depending on whether valgrind is running. I can cause it to crash by doing something weird like spamming the tablet pad buttons a lot, but if I'm not doing that things are actually pretty stable for me. Being able to narrow it down to a specific piece of code would be great, but I've not gotten any progress on doing so. |
Hmm, well, this is interesting. I just pulled master again and tried to reproduce a crash. However, no matter what I did, it didn't seem to break at all. Everything now seems to work reliably... I'm not really sure what might've happened. |
Things crash a lot less now. It seems to be trivial to crash Krita's splashscreen by spamming tablet pad buttons. Usually Xwayland crashes, infrequently Sway crashes shortly after Xwayland does. Here's a log with SWAY_DEBUG=1 and backtrace. https://gist.github.com/jchv/03acbfee73da34dd571d6e5c3e7607c5 Digging through, it happens because of this line:
...in I suspect this is probably not directly caused by whatever causes Xwayland to crash. Xwayland crashes in
Krita also crashes, but I suspect that is a red herring and it is crashing exactly how it would if the X11 server disappeared in other circumstances. It dies inside an exit handler.
I am no longer able to crash Xournalpp running as a Wayland application. I am not sure what changed on that front. |
Can you try compiling Sway, wlroots and Xwayland with debugging symbols to get better stack traces? Also the Sway stack trace is missing. Once you get that, please report the Xwayland bug upstream. |
FWIW, I haven't been able to reproduce this at all anymore. There is no more segfaults or weird behaviors when mashing tablet buttons. I have not experienced a random crash in over a month, and I've been actively using my graphics tablet with Sway. I suspect the bug was probably upstream, but I am not sure where: It couldn't have been XWayland, which hasn't had remotely relevant changes for months. Sadly, having failed to triage it, it's hard to really know. This is, of course, my fault. I am still kind of clumsy with NixOS and simply was not able to figure out exactly how to get debug info for all packages. Is anyone else still having trouble with Sway 1.4 and updated libinput/XWayland? Does anyone have a hunch for what may have fixed this? It may be time to close this bug if not. |
I just updated everything and tried it. |
Hmm. I just tried Xournal++ and I am not seeing any issues. This bug was tricky to begin with, so maybe it's just not manifesting for me right now/anymore. But I would keep an eye out for software updates (for related components.) I'm searching to see if I can figure out what has changed with my setup since the last time I crashed sway with tablet. |
I'v a Wacom Intuos S and I have this bug too, but using any GTK+ app with |
@Eragonfr I have the same Wacom model and was seeing the same visual glitches in MyPaint and Xournalpp. A solution for me was to attach the wacom pen to its own
(Note: adapt your identifier if needed) With that I get two different pointers: one for the normal mouse and one for the pen. Since the normal cursor will disappear after 10 seconds, you will only see one cursor after that time. You also wont be seeing those visual glitches. That was my experience at least. However, some other problems appear with this configuration. The most annoying of them is that it somehow screws up the |
Thanks for sharing this solution, it's not what i'm expecting from sway(because i want only one cursor) but that work. |
Good to know it worked for you. Yeah, I also think it is a strange behaviour. But at least I got to learn how to use seats :P |
Hi all, There's a lot of issues in this thread that make it hard to track what's been fixed and what's still a problem. It would be great for organization purposes if separate tickets for each issue that is still present with sway/wlroots master could be opened instead. A number of fixes for tablet input got merged recently, that should address some of the issues noted in this thread.
I cannot reproduce these in sway/wlroots master with Xournal++ 1.0.18, is this still happening?
I can reproduce this, but I'm inclined to say this is an issue on Xournal's end. We send button 1 and 2 events (as per
Does this continue to happen? Unfortunately I can't attempt to look into this, as this issue with my tablet precludes actually using the buttons for anything.
This sounds an awful lot like https://gitlab.freedesktop.org/xorg/xserver/-/issues/709, which should be fixed in Xwayland master as of 3 weeks ago.
This has been fixed in sway master, particularly #5240. |
Thank you so much for looking into these issues and for fixing so many of them. I'll admit my debugging skills are just not quite sharp enough to understand some of these issues and I struggled to root cause a lot of the problems. I can at least confirm that the Xwayland fix for pressing Wacom tablet buttons appears to have resolved that issue for me. I'll update my system to Sway master later on and torture test the tablet integration to see if I can see any issues. |
On my Lenovo Thinkpad L380 Yoga, the included pen and touch screen work flawlessly. The only config command I included is below (not sure if it is necessary). The buttons on the pen seem to work as left and middle click for the first and second button respectively. Xournal++ senses the amount of pressure I use when writing with the pen and when I use the first button it switches to the eraser temporarily as intended. Regarding the touch screen, long press registers as a right click too. Based on previous comments on this issue, I was expected a much worse experience. I'm curious to see if others are having a similar experience.
Edit: Forgot to mention that touch screen scrolling works as intended. |
I'm going to go ahead and close this issue in favor of filing one ticket per any outstanding issue. It seems like there aren't that many left 🙂 |
I would like to report a few (critical) issues with the new graphic tablet support.
I will try to give as much details as possible. Unfortunately, I am not a developer, so I don't know how to fix those issues and can only report them as best as I can.
First of all, some information about the setup:
Sway version 1.2-rc1-61-g352a3e1f (Oct 8 2019, branch 'master')
running on Arch Linux (using all the latest packages and the wlroots-git package from the AUR in order to build sway)
Tablet and Pen Wacom Intuos S with Pen (2018 Model)
Application to test tablet functionality Xournalpp (installed from the Arch Linux Community repo), using this since it is the only application I know of which runs natively under Wayland
I have built sway from the current state of the master branch and ran it from a tty.
Since this issue ticket regards one specific pull request (#4570) but there is more than one issue, I am listing the issues numerically and divide each issue into "expected behaviour", "actual behaviour" and "steps to reproduce" (it is assumend that the latest state of the master branch of sway is built and used, the tablet is connected via bluetooth and the first step is always to open Xournalpp).
Here are the issues I am facing:
First and foremost, for some reason, the "resolution" (for the lack of a better word) the tablet is drawing in, is really bad. So what happens is, that when there are lines drawn very quickly, the line that is drawn is just a succession of straight liner rather than a smooth curve. To see what I mean, look at this
![picture](https://user-images.githubusercontent.com/40417462/66402693-8e8e8c00-e9e5-11e9-8b5b-61f826873554.png)
expected behaviour
quick movements of the pen draw smooth curves
actual behaviour
straight consecutives lines are drawn
steps to reproduce
draw curves and lines very quickly and with a swift motion
For the buttons on the pen itself, the order is "reversed", so what is actually the first button on the pen is recognised as the second button by the application and the second button is recognised as the first button. So by that I mean, the first button is the one closest to the tablet. After setting this to Eraser in Xournalpp and setting the second button to the Hand-Tool, using each button it can be observed that button one is assigned to the Hand-Tool and button two is assigned to the eraser.
expected behaviour
buttons are assigned in the correct order
actual behaviour
button assignment is reversed
steps to reproduce
set the pen buttons in Xournalpp accordingly as test which button does what
This is the biggest issue so far: After assigning an action to the button(s) and using them, things start to "fall apart". The CPU usage spikes, everything becomes very unresponsive and slow and in the end its a hit or miss if the action that was intended is actually carried out, i.e. for example pressing the button to erase and then actually erasing some of the drawings. It is really hard to explain what I mean by that, therefore I tried to record a log as instructed.
Sometimes, this does produce a crash of Xournalpp and even sway itself, but unfortunately, these crashes dont happen consistently, so I can not reproduce them reliably. I will therefore provide a stack trace as soon as I can find out how to reliably force this crashing.
expected behaviour
when using pen buttons, actions are performed as expected and everything works smoothly
actual behaviour
when using pen buttons, everything becomes unresponsive, the movement of the cursor itself lags behind and is slow and abrupt instead of smooth, quick and continuous, actions are not performed as expected, for example erasing using a button or moving the page is not working properly and sometimes not working at all
steps to reproduce
assign custom functions to the buttons of the pen in the settings of Xournalpp and try using them extensively
Pressure sensitivity, although supported by the tablet and pen and application, is not working.
expected bevaviour
pressure sensitivity is working as expected once it is enabled in the settings
actual behaviour
pressure sensitivity is not working, putting pressure on the pen does not change the thickness of the lines drawn
steps to reproduce
enable pressure sensitivity in the settings of Xournalpp
Please let me know if there is anything else that I could provide in order to help.
EDIT: Logs for issues 1 and 2: Log
For some reason, I can not reproduce issue 4 at the moment, so pressure sensitivity is working. I have not change anything since first reporting the issue(s), my computer has been in sleep-mode since then and I have not done anything else in between. I attached a log anyway and will update this once I can get a log when it is not working as expected.
The text was updated successfully, but these errors were encountered: