Dell XPS 2 in 1 7390 support

[dotellie]

I think this is right? Sorry I got kinda lost in all the instructions but the device does show up in gnome now at least. 😅

Off-topic from this PR but I also have a Bamboo Ink Plus that works but doesn't show up. I'm fairly certain that this relates to #57 but again, I'm not really familiar with the project so the details very much just fly over my head. I tried patching according to the workaround which didn't work either. The device id seems to be just 2 but I'll put the xinput watch-props log here:

Device 'Wacom HID 48EE Pen stylus':
	Device Enabled (143):	1
	Coordinate Transformation Matrix (145):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	Device Accel Profile (269):	0
	Device Accel Constant Deceleration (270):	1.000000
	Device Accel Adaptive Deceleration (271):	1.000000
	Device Accel Velocity Scaling (272):	10.000000
	Device Node (266):	"/dev/input/event9"
	Wacom Tablet Area (279):	0, 0, 28800, 18000
	Wacom Rotation (280):	0
	Wacom Pressurecurve (281):	0, 0, 100, 100
	Wacom Serial IDs (282):	18670, 0, 2, 0, 0
	Wacom Serial ID binding (283):	0
	Wacom Pressure Threshold (284):	26
	Wacom Sample and Suppress (285):	2, 4
	Wacom Enable Touch (286):	0
	Wacom Hover Click (287):	1
	Wacom Enable Touch Gesture (288):	0
	Wacom Touch Gesture Parameters (289):	0, 0, 250
	Wacom Tool Type (290):	"STYLUS" (268)
	Wacom Button Actions (291):	"Wacom button action 0" (292), "Wacom button action 1" (293), "Wacom button action 2" (294), "None" (0), "None" (0), "None" (0), "None" (0), "Wacom button action 3" (295)
	Wacom button action 0 (292):	1572865
	Wacom button action 1 (293):	1572866
	Wacom button action 2 (294):	1572867
	Wacom button action 3 (295):	1572872
	Wacom Pressure Recalibration (296):	1
	Wacom Panscroll Threshold (297):	1300
	Device Product ID (267):	1386, 18670
	Wacom Debug Levels (298):	0, 0
Property 'Wacom Serial IDs' changed.
	Wacom Serial IDs (282):	18670, 0, 2, 0, 0

[jigpu]

The tablet definition looks good, but it looks like you'll need to move your addition to the meson.build file. I believe moving the line as follows should do the trick. Note that the below patch will not directly apply to meson.build, but it has enough context for you to do the move manually:

--- /dev/fd/63	2019-09-12 10:11:31.244201555 +0000
+++ /dev/fd/62	2019-09-12 10:11:31.244201555 +0000
@@ -131,2 +131,3 @@
 data/isdv4-12c.tablet
+data/isdv4-48ee.tablet
 data/isdv4-50b4.tablet
@@ -153,3 +154,2 @@
 data/isdv4-488f.tablet
-data/isdv4-48ee.tablet
 data/isdv4-502a.tablet

[jigpu]

As for recognizing the stylus, could you post a short evemu-record log of the pen making a single stroke?

[dotellie]

@jigpu Awesome, thanks! I was wondering why Travis was failing. Someone on Reddit mentioned however that their XPS which is the FHD version and not the UHD version had a different ID. Should I add something for that in this PR or do I leave it? https://www.reddit.com/r/Dell/comments/cx0fkc/xps_13_2_in_1_7390_linux_boot_attempt/f01kq00?utm_source=share&utm_medium=web2x

[dotellie]

Also here is a log 😄
evemu-log.txt

[jigpu]

Its pretty common for OEMs to use different IDs for small revisions, especially if they involve a change to the screen. Making a version of the tablet definition for their 48ED tablet and adding it to your pull request would be most appreciated :)

BTW, to keep the final merged commit history clean, would you mind "squashing" your data and fix commits into just one good commit?

[jigpu]

As for the stylus ID, it looks like 0x807B is the magic number. Hopefully that does the trick for getting it recognized.

[dotellie]

Should be done now 😄
I know some people that like to be able to see changes between commits while the PR is still active but squashing is absolutely no problem 😉

The stylus fix still doesn't seem to work however for some reason or another...

[jigpu]

Hmm, what distro/version are you using? I think some older versions of GNOME won't show anything even if the stylus is defined properly, but I can double-check if yours might be affected.

Also, since I don't see the "Stylus" line defined in your commit, would you mind sharing the complete tablet file you're currently testing as well as the libwacom.stylus file? I'll check it over for errors.

[dotellie]

I'm running Fedora 30 with a custom 5.3 kernel, Gnome 3.32.2.

libwacom.stylus

...
[0x807B]
# Bamboo Ink Plus
Name=Bamboo Ink Plus
Buttons=2
HasEraser=false
Axes=Tilt;Pressure;Distance
Type=General
...

isdv4-48ee.tablet

# Active electrostatic (AES) sensor used by the Dell XPS 13 2 in 1 7390 (UHD)
 
[Device]
Name=Wacom ISDv4 48ee
ModelName=
DeviceMatch=i2c:056a:48ee
Class=ISDV4
Width=11
Height=7
IntegratedIn=Display;System
Styli=0x807B
 
[Features]
Stylus=true
Touch=true
Buttons=0

I'm actually not 100% sure how many buttons the stylus has. It has one button which very briefly activates bluetooth and is supposed to bring up Windows ink or something and two "normal" buttons on the side. I guessed the bluetooth button doesn't count in this case.

[jigpu]

That data looks fine to me... Did you bring the stylus into proximity above the control panel (I can't remember if it asks you to do this, but is 100% required to the stylus to show up)?

I would set Buttons=1 on the stylus. The Bluetooth button is a separate device that doesn't figure in to the count, and one of the two "normal" buttons is handled within the sensor firmware as an eraser switch. Only the other "normal" button is normally programmable.

EDIT: Using Buttons=1 might prevent the button from being configurable if/when you get this working. #12 (comment)

[dotellie]

It asks you to bring it into proximity which I did do, yes. I tried changing the amount of buttons which also didn't help.

Is there any way to disable that eraser switch though? I don't think it's working quite right (switching on and off at random) and frankly, it's only annoying. I honestly thought it was a bug when I first noticed that the lower button sort of switched between modes. On my normal Intous tablet it doesn't act like this but rather I can bind both buttons to whatever I want and the tip only ever acts as a pen which would be far preferable IMO.

[bentiss]

I'm running Fedora 30 with a custom 5.3 kernel, Gnome 3.32.2.

@dotellie can you tell me a little bit more on this "custom" kernel? I personally just got one 7390 and I have to blacklist intel-lpss-pci to not have a crash at boot,. This means the I2C adapter is not there, and so I do not see the wacom panel.

[dotellie]

@bentiss Sure! So what I did was essentially just to apply a patch I found on that Reddit thread mentioned earlier which "fixes" LPSS by disabling something (I don't remember the exact details). Then I simply applied the patch to the Fedora master kernel and built an RPM which made it so that the touchscreen works. It also fixes a few other things but does however seem to break suspend. I'll see if I can write a blog post or something about the process.

[bentiss]

@dotellie OK, thanks.

Do you still have the patch lying somewhere (or the reddit URL)? It might solve me some time to redo the work here.

[bentiss]

Hmm, I guess this is https://pastebin.com/sqPv8ShP?

For those reading that and needing it, bug is opened at https://bugzilla.kernel.org/show_bug.cgi?id=203485

[bentiss]

@whot, @jigpu, I see that @dotellie used Styli=0x807B in the config file. Here, I can at least use the following pens on the same monitor:

• Dell PN579X (0x805b)
• Dell PN557W (0x0231)
• HP Active Pen G2 (0x806b)

Shouldn't we instead create an AES pen group and add all of those in this group?
Note that the PN557W is not tilt capable, so there might be a need to create subgroups based on the generation

[jigpu]

@bentiss Just slightly ahead of you :) I've been gathering info on the pens and various generations of AES hardware so we can eventually make appropriate groups. Almost ready to get back to @whot about my findings.

[jigpu]

@dotellie I gave your log a second look and noticed that the pen sends two different IDs. Could you try replacing 0x807B with 0xFFFF807B in both the tablet and stylus definitions?

I wonder if the two IDs where some of the flakiness you've experienced comes from. It also looks like both IDs suffer from the same issue as linuxwacom/xf86-input-wacom#74, which would definitely cause eraser issues for you...

EDIT: Corrected issue link

[dotellie]

@jigpu That ID seems to have done it! Thank you so much for all the help! That bug also seems like exactly what I'm experiencing. Is there a way to help out with the issue or do you have everything you need?

[jigpu]

Glad to hear it! The only thing I'm missing for the other bug is time to tackle it, but once I find some I'll start working on a fix. (EDIT: Pushed up a possible fix that does the simplest possible thing -- no guarantee it works, but if it does...)

Would you mind, however, running our capture.sh script and recording several single strokes? I want to understand more about what the hardware is sending to cause our kernel driver to send both 0x807B and then later 0xFFFF807B.

[bentiss]

I want to understand more about what the hardware is sending to cause our kernel driver to send both 0x807B and then later 0xFFFF807B.

See the following patch:

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 5ded94b7bf68..6b529d54f334 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -272,10 +272,10 @@ static void wacom_hid_usage_quirk(struct hid_device *hdev,
 		    b->report_size == 8) {
 			features->quirks |= WACOM_QUIRK_AESPEN;
 			usage->hid = WACOM_HID_WD_TOOLTYPE;
-			field->logical_minimum = S16_MIN;
-			field->logical_maximum = S16_MAX;
-			a->logical_minimum = S32_MIN;
-			a->logical_maximum = S32_MAX;
+			field->logical_minimum = 0;
+			field->logical_maximum = U16_MAX;
+			a->logical_minimum = 0;
+			a->logical_maximum = U32_MAX;
 			b->usage[0].hid = WACOM_HID_WD_SERIALHI;
 			b->logical_minimum = 0;
 			b->logical_maximum = U8_MAX;

The issue is that hid-core converts the signed 16 bits value into a signed 32 bits. However, in wacom-wac.c the code interprets this as an unsigned, which adds 0xffff0000 to the value.

In wacom_wac_pen_serial_enforce() we call hid_field_extract() without snto32() which leads to the 2 different values during the serial enforcing phase and the normal retrieval of values.

So either we apply my patch above, either we check for min < 0 in wacom_wac_pen_serial_enforce() and append or not snto32().

Actually, we might want to do both: this would prevent future issues for a non modified report descriptor.

---

My issue is now why gnome-terminal is crashing when I use the pen...

[jigpu]

Thanks for the quick find @bentiss! I think I'd prefer to add checks for min < 0 to both wacom_wac_pen_serial_enforce() and wacom_wac_pen_event() rather than making changes to wacom_hid_usage_quirk(). The latter would definitely be cleaner, but the former is more explicit about how to deal with the awkward native data format. I don't want to have to rely on descriptor rewriting any more than absolutely necessary.

[bentiss]

We can always discuss it later on the LKML or at XDC, but I suspect we want both. The field is definitively used as an unsigned one in the whole driver, so I do not really understand why it was declared as a signed int in the report fixup quirk. The fact that the firmware exports a signed int in some cases should likely not be fixed in a report fixup, and I agree with you here.

So to cover up the FW case, we want to add the check also to mimic hid-core.c and not have the same issue later on.

[jigpu]

Just to be clear, the reason the quirk defines the field as signed is because that's how its typically declared by our devices. The quirk was introduced to deal with the fact that some earlier hardware didn't define min/max at all; its just making the descriptor "normal". I don't have a single example of an AES device defining the fields as unsigned.

[inducer]

Any progress here? I have one of these machines. I added

Styli=0x805b

for the "Dell Active Pen PN579X" to isdv4-48ee.tablet from 1da2630 and the following snippet to libwacom.stylus:

[0x805b]
Name=Dell Active Pen PN579X
Buttons=2
HasEraser=false
Axes=Pressure;Distance;Tilt;
Type=General

With these changes, pen support is pretty much perfect, so IMO this would be well worth merging. (But I agree that a stylus class for AES2 is probably the way to go in the medium term.)

[boberfly]

Hello all,

I have a Dell XPS 7390 2-in-1 4k/UHD here and the out-of-the-box experience on Kubuntu 19.10 is almost flawless except for the eraser always being activated, in which linuxwacom/xf86-input-wacom#74 fixed that for me nicely with a Bamboo Ink Plus.

One final issue I have and I am not sure if it's more of a hardware issue with the bamboo as Windows has this problem as well, is having wavy lines in diagonal strokes shown here (I am MIstaED on there):
https://www.reddit.com/r/Dell/comments/dc5z9v/xps_7390_bamboo_ink_plus_problems/

Does anyone here have this same configuration and can report back if you have this issue? Every program/desktop has this issue, but to be specific I have tested with Krita and Blender 2.81's grease pencil.

Cheers!

[inducer]

I have two copies of the "Dell Active Pen PN579X", and neither is drawing wavy diagonal lines for me.

[jigpu]

Pull request has been rebased and merged.

[cgevans]

Sorry if I'm misreading the comments here, but was this pull request supposed to include a stylus definition for 0x805b? It doesn't seem to.

Edit: oops, I now see #178 , sorry.