Dell XPS 15 2-in-1 (9575)

[JLTastet]

Please find attached the output from sysinfo.sh.

Note that some commands gave errors when ran as root, so I have run the script both as root and non-root. I also ran it for both Wayland and Xorg, since some commands seem to be Xorg-specific.

Additionally, the command libinput-list-devices seems to have been replaced by libinput list-devices (note the missing dash), and was giving errors, so I have attached the output of the latter command separately.

• libinput.txt
• xps-9575-wayland.tar.gz
• xps-9575-wayland-root.tar.gz
• xps-9575-xorg.tar.gz
• xps-9575-xorg-root.tar.gz

Should I also open an issue for libwacom itself, or is it enough ?

Here is some additional info, which might or might not be relevant:

• Neither the pen nor the tablet are recognized by gnome-control-center.
• On Xorg, the pen works perfectly, including pressure sensitivity and tilt.
• On Wayland, I also get pressure sensitivity and tilt in most applications (all GTK2 apps + the "Test Your Settings" box in gnome-control-center), but not all. My own GTK3 toy program does not see the pressure and tilt axes on Wayland, but only on Xorg.
• The pen experience for GTK2 applications (Xournal, GIMP) on Wayland is heavily degraded, with a notably lower accuracy and some artifacts (exactly like point 2 mentioned in HP Spectre x360 Convertible 13-ac0XX #32).

Not sure whether this has anything to do with libwacom, or whether this is a libinput issue.

Thanks!

[JLTastet]

I forgot to mention the physical layout of buttons. The pen has three buttons: two on the side + a bluetooth button at the top, and no erasing tip.

When the side button closer to the tip is pressed, the pen is identified as eraser instead.
The other side button sends BTN_STYLUS events, while the top button is identified as a keyboard and sends LEFTMETA + F20.

[jigpu]

Thanks for the sysinfo! I've gone ahead and opened a new issue in libwacom to add support for this device. You'll find a link to it just above this comment. I've also created a tablet definition file based on the data and made a pull request to resolve the issue. Go ahead and download this file and then move it to /usr/share/libwacom/isdv4-486a.tablet and reboot. Afterwards, check to see if the device shows up in the Wacom panel of GNOME Control Center. Leave a comment on the issue or pull request that letting us know that it works (or not).

As for the issues that you're seeing under Wayland, tablet support is definitely rough and we still recommend Xorg for our users right now. That said, if you want to help us diagnose and hopefully fix these issues, just let me know. Seeing how the GTK3 program "MyPaint" works would be a good starting point since I've tested it in the past and didn't see any obvious issues. I'll have to have another look at Xournal and GIMP under Wayland to see if I can reproduce your symptoms since it's been a while since I was using Wayland. The issue is probably a libinput one, but XWayland and even GTK2 itself could potentially be mangling things.

[JLTastet]

@jigpu Thanks for your help! I will try your file now and report whether it works.

Regarding the Wayland issues, I am more than willing to help, since I rely on several features which cannot be found in Xorg, like per-screen DPI scaling, multitouch or simply proper touch support. I actually have quite a few bug reports in the pipeline regarding touch/stylus support on Wayland. I will report them as soon as I realistically can, and maybe even have a look at the code :)

Regarding MyPaint, I tested the latest version of it on Wayland and I got the same issue as with Xournal and GIMP. So it seems more and more likely that the issue comes from libinput. I will test again after adding the definition.

Ok let's reboot now!

[JLTastet]

@jigpu I just rebooted and the tablet now shows up in the control panel, but not the stylus.

Possibly unrelated issue: on the first reboot, the Gnome session froze and I had to SysRq the machine. I will see if this happens again, but I doubt this is libwacom's fault.

Thanks for your work!

[JLTastet]

BTW, the issues I had under Wayland are still present.

[jigpu]

Odd that the stylus isn't showing up. I may have to give Fedora a try since a fresh Ubuntu 18.04 install (it's what I have on my USB stick right now :D) doesn't show that symptom. Nothing shows up without an appropriate tablet definition, and both the stylus and tablet tabs get populated afterwards. I've tried with both a Wacom-branded pen and an OEM pen, although there shouldn't be a difference... Let me do a little more investigating.

I also don't (immediately) see any issues with performance under Wayland in Ubuntu, so I'll keep an eye out for that when trying Fedora as well.

[JLTastet]

I just checked that the stylus is not recognized either under Xorg. I will try again after updating everything to nightly (once it works...) and also check whether the performance issues are still present.

[JLTastet]

I have just noticed something that might be of interest.

While trying to run the nightly version of Gnome Shell (via jhbuild run gnome-shell --wayland), the following line was printed to STDERR (among other seemingly unrelated warnings):

(gnome-shell:6665): mutter-WARNING **: 00:09:57.365: Could not get tablet information for 'Wacom HID 486A Pen': (null)

[JLTastet]

@jigpu If you manage to find some time, could you quickly check if you can reproduce this Wacom-related Gnome Shell bug under Wayland ? Just be aware that it can render your session unusable, so be prepared to SysRq or hard reboot.

[jigpu]

Looks like Carlos already has you covered with a fix for the gnome shell bug you reported :)

I haven't had any luck reproducing the performance or artifact issues on my own similar Dell convertible. Strokes are drawn equally fast and well regardless of if I'm using Xorg or Wayland. Has switching to the nightly version made any difference for you? If you're still experiencing the issues, try recording a video of them for me to better understand what's going on. Also, could you provide the source to your toy GTK3 program that wasn't getting pressure data? I'd like to see if it works locally or not...

[JLTastet]

Switching to the nightly version significantly reduced (but did not eliminate) the artifacts, and I can still feel that there is an extra lag in Wayland compared to Xorg. The pen is nonetheless much more usable now.

The resolution issue is still present, and affects both 3.28 and nightly identically.

I have attached three test PDF files (converted from .xoj Xournal files) to show the issue. All of them were written in the same conditions, with the page fitting the whole screen in portrait mode, and writing at roughly the same velocity.

• Wayland, 3.28
• Wayland, nightly (3.30+)
• Xorg, 3.28

The artefacts are quite obvious, and the difference in resolution can easily be seen by zooming on the files and placing them side-by-side.

I'll try to record a video tomorrow (it is getting late now...) and send you a minimal version of the code as soon as I can (note that I am a GTK beginner and that I used the Rust bindings, so the bug might be on my end).

[JLTastet]

BTW, the stylus is still not recognized with Gnome nightly (after applying your patch again to libwacom nightly).

[JLTastet]

@jigpu Here is the source code of my toy GTK3 program, as well as its output both under Xorg and Wayland:

• list_devices.tar.gz
• output-xorg.txt
• output-wayland.txt

The easiest way to install Rust is to use rustup. To download the dependencies, compile them, compile the program and run it, just go to the directory where Cargo.toml is located and run cargo run.

[jigpu]

Thanks, the PDFs are quite helpful :) At first blush, it almost looks like there's no smoothing occurring in the Wayland output. Our X driver does a little bit of smoothing which -- especially for an AES pen -- would make strokes look nicer. I'd have to look through the libinput source code to see if they smooth coordinates or not.

Was your hand resting on or touching the display when you made these? Palm rejection should be happening in the kernel, but maybe something along those lines could explain the artifacts. There might be something about the beginning or end of strokes that is throwing libinput off, since that seems to be only where they occur.

I haven't had a chance to try out your GTK3 code yet, but I'll let you know my results when I can.

[JLTastet]

Not sure if my hand was touching the display. I will try to do some more controlled tests this evening, and maybe open an issue on the libinput gitlab (if there isn't one already) so we can track our progress there.

Regarding smoothing, we could probably infer the tablet resolution by looking at the raw input (somewhere in /dev/input/eventXY ?), and compare that to the libinput result (libinput record ?).

[JLTastet]

I have filed an issue against libinput and uploaded my updated tests as well as the dump and event log:
-> https://gitlab.freedesktop.org/libinput/libinput/issues/138