XP-Pen Deco 01 tablet has no pressure sensitivity on linux #62185

New Issue

Michael D. · 2019-03-04T17:49:55+01:00

Michael D. commented

2019-03-04 17:49:55 +01:00

System Information
Operating system: Linux (tested on Slackware 14.2, Debian 8)

Blender Version
Tested both 2.80 (March 04, 16:48:10 - 3730d16347) and 2.79

Short description of error
Currently on linux the XP-Pen Deco 01 tablet seems to have no pressure sensitivity in blender.
Other applications work fine (MyPaint, Krita, Gimp).

I'm using the official driver (https://www.xp-pen.com/download/index/cid/36.html - although i tried it without as well, no change (without, only MyPaint works, Krita/Gimp need the driver)).

Looking through xinput, i noticed that it lists the device as "UGTABLET DECO 01" twice, also there's an "XPPEN Tablet" entry which only shows when the driver is running.
Both "UGTABLET DECO 01" entrys list pressure for some reason. Although just the pen should have pressure (this isn't a touch device).

One lists it as
Label: Abs Pressure
Range: 0.000000 - 2047.000000

The other
Label: Abs Pressure
Range: 0.000000 - 8191.000000

I'm assuming the last one is the pen (it's advertised as 8000 pressure levels). Could it be that blender mistakenly reads the wrong of the 2 values?

Also borrowed an XP-Pen Artist 13.3 (a "cintiq like" monitor with tablet) from a friend, to see if it's just this XP-Pen model, and it has the same issue (and also shows up twice).

Attached the long xinput output.

Exact steps for others to reproduce the error
In the image editor, new texture > paint mode. Brush does not react to pressure.xinput-long.txt

**System Information** Operating system: Linux (tested on Slackware 14.2, Debian 8) **Blender Version** Tested both 2.80 (March 04, 16:48:10 - 3730d16347a5) and 2.79 **Short description of error** Currently on linux the XP-Pen Deco 01 tablet seems to have no pressure sensitivity in blender. Other applications work fine (MyPaint, Krita, Gimp). I'm using the official driver (https://www.xp-pen.com/download/index/cid/36.html - although i tried it without as well, no change (without, only MyPaint works, Krita/Gimp need the driver)). Looking through xinput, i noticed that it lists the device as "UGTABLET DECO 01" twice, also there's an "XPPEN Tablet" entry which only shows when the driver is running. Both "UGTABLET DECO 01" entrys list pressure for some reason. Although just the pen should have pressure (this isn't a touch device). One lists it as Label: Abs Pressure Range: 0.000000 - 2047.000000 The other Label: Abs Pressure Range: 0.000000 - 8191.000000 I'm assuming the last one is the pen (it's advertised as 8000 pressure levels). Could it be that blender mistakenly reads the wrong of the 2 values? Also borrowed an XP-Pen Artist 13.3 (a "cintiq like" monitor with tablet) from a friend, to see if it's just this XP-Pen model, and it has the same issue (and also shows up twice). Attached the long xinput output. **Exact steps for others to reproduce the error** In the image editor, new texture > paint mode. Brush does not react to pressure.[xinput-long.txt](https://archive.blender.org/developer/F6760428/xinput-long.txt)

Michael D. commented

2019-03-04 17:49:55 +01:00

Added subscriber: @CanOfColliders

Michael D. changed title from ~~XP-Pen Deco 01 tablet has no pressure sensitiviy on linux~~ to XP-Pen Deco 01 tablet has no pressure sensitivity on linux

2019-03-04 18:07:21 +01:00

Brecht Van Lommel commented

2019-03-04 19:00:31 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-03-04 19:00:31 +01:00

Are you using the builds from https://builder.blender.org/download/? Can you mention the exact version you tested?

Michael D. commented

2019-03-04 19:34:12 +01:00

Yes, i was using 2019-03-04 14:25 f4677547d4, just upgraded it to March 04, 16:48:10 - 3730d16347, same issue.

Yes, i was using 2019-03-04 14:25 f4677547d430, just upgraded it to March 04, 16:48:10 - 3730d16347a5, same issue.

Michael D. commented

2019-03-06 08:59:17 +01:00

I just tried a few different machines and on one of them the pressure did work in blender. The only difference to the others i could tell was that this one was not on an LTS kernel (my desktop runs on 4.4.172, which is also an LTS release from january 30).

So i just setup 2 vms, debian 9 stable (4.9.0-8) and debian 8 lts (3.16.0-6). Both fresh installs, updated today. Same issue. In 9 it works, in 8 LTS it does not. This only affects blender apparently (other painting apps do work with pressure on both).

Noticed on xinput list that on 9, where it does work, it shows up as 3 devices sharing the same name (2x as a virtual core keyboard, once as a virtual core pointer). Where as on the ones where it does not work, it only shows twice as a pointer, no keyboard entry at all.

I just tried a few different machines and on one of them the pressure did work in blender. The only difference to the others i could tell was that this one was not on an LTS kernel (my desktop runs on 4.4.172, which is also an LTS release from january 30). So i just setup 2 vms, debian 9 stable (4.9.0-8) and debian 8 lts (3.16.0-6). Both fresh installs, updated today. Same issue. In 9 it works, in 8 LTS it does not. This only affects blender apparently (other painting apps do work with pressure on both). Noticed on `xinput list` that on 9, where it does work, it shows up as 3 devices sharing the same name (2x as a virtual core keyboard, once as a virtual core pointer). Where as on the ones where it does not work, it only shows twice as a pointer, no keyboard entry at all.

Brecht Van Lommel commented

2019-03-06 12:15:19 +01:00

You could try running xinput test-xi2 and draw with the tablet a bit, to figure out which the device it is that we should be reading the pressure from.

You could try running `xinput test-xi2` and draw with the tablet a bit, to figure out which the device it is that we should be reading the pressure from.

Michael D. commented

2019-03-06 12:41:10 +01:00

Okay i just tried it. All the pressure seems to come from the XPPEN Tablet, which is unique and created when the XP-Pen driver software is open/running. Don't see any change at all from the multiple UGTABLET DECO 01 entrys.

EVENT type 6 (Motion)
	device: 19 (19)
	detail: 0
	flags: 
	root: 1256.20/724.87
	event: 76.20/109.87
	buttons: 1
	modifiers: locked 0x10 latched 0 base 0 effective: 0x10
	group: locked 0 latched 0 base 0 effective: 0
	valuators: 
		2: 8191.00
	windows: root 0x1f2 event 0x6000001 child 0x0

The valuators value goes smoothly up and down up if i press down with the pen.
Device ID 19 was

⎜ ↳ XPPEN Tablet id=19 [slave pointer (2)]

Okay i just tried it. All the pressure seems to come from the `XPPEN Tablet`, which is unique and created when the XP-Pen driver software is open/running. Don't see any change at all from the multiple `UGTABLET DECO 01` entrys. ``` EVENT type 6 (Motion) device: 19 (19) detail: 0 flags: root: 1256.20/724.87 event: 76.20/109.87 buttons: 1 modifiers: locked 0x10 latched 0 base 0 effective: 0x10 group: locked 0 latched 0 base 0 effective: 0 valuators: 2: 8191.00 windows: root 0x1f2 event 0x6000001 child 0x0 ``` The `valuators` value goes smoothly up and down up if i press down with the pen. Device ID 19 was `⎜ ↳ XPPEN Tablet id=19 [slave pointer (2)]`

Jeroen Bakker commented

2020-01-20 16:53:51 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-01-20 16:53:51 +01:00

Changed status from 'Confirmed' to: 'Needs Developer To Reproduce'

Jeroen Bakker commented

2020-01-20 16:53:51 +01:00

In order to add support for specific device we need to be able to have access to the device. So marking this for now as Known Issue, with low priority and needs developer to reproduce.

Robert Guetzkow commented

2020-11-23 11:33:46 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-11-23 11:33:46 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

Robert Guetzkow commented

2020-11-23 11:33:46 +01:00

@Jeroen-Bakker The triagers are currently in the process of cleaning up old tickets. I don't think this should be marked as a known issue and given a priority unless the ticket is confirmed, based on current bug tracker policies.

@CanOfColliders Is this still a problem with current drivers for the tablet and Blender 2.91 or 2.92 ?

@Jeroen-Bakker The triagers are currently in the process of cleaning up old tickets. I don't think this should be marked as a known issue and given a priority unless the ticket is confirmed, based on current bug tracker policies. @CanOfColliders Is this still a problem with current drivers for the tablet and Blender [2.91 or 2.92 ](https://builder.blender.org/download/)?

Michael D. commented

2020-11-23 14:17:38 +01:00

@Jeroen-Bakker I'm sorry i must have missed the notification for this in january. I still have the xp-pen deco stashed away, and would be willing to donate it to any dev that wants to toy with it more, but from my point of view this can be closed.

@rjg It sort of works. After lots of back and forth my solution eventually ended up being a rule for xorg to match the usbid and force it to use the wacom driver there (and not even attempting to work with the official xp-pen linux driver anymore). This somehow worked fine in blender (and everywhere else, pressure and everything). Not ideal of course.
I did however in the meanwhile switch to a different (HUION kamvas 22 plus) tablet so i'm not entirely sure if something changed.

@Jeroen-Bakker I'm sorry i must have missed the notification for this in january. I still have the xp-pen deco stashed away, and would be willing to donate it to any dev that wants to toy with it more, but from my point of view this can be closed. @rjg It sort of works. After lots of back and forth my solution eventually ended up being a rule for xorg to match the usbid and force it to use the wacom driver there (and not even attempting to work with the official xp-pen linux driver anymore). This somehow worked fine in blender (and everywhere else, pressure and everything). Not ideal of course. I did however in the meanwhile switch to a different (HUION kamvas 22 plus) tablet so i'm not entirely sure if something changed.

Brecht Van Lommel commented

2020-11-23 15:53:59 +01:00

We've fixed these types of issues before without access to the device, it's really the only practical way without buying dozens of tablets.

When I last looked at this the xinput output did not seem to have enough info to figure out the right fix for this case, which is the value corresponding to XDeviceInfo.type.

The better fix here is probably to change the logic we have for detecting which devices are tablets from the code we copied from Wine, to e.g. the same logic as in the latest Qt code. The risk with such a change is that it may break other devices and so you'd have to be prepared to handle bug reports related to that.

We've fixed these types of issues before without access to the device, it's really the only practical way without buying dozens of tablets. When I last looked at this the `xinput` output did not seem to have enough info to figure out the right fix for this case, which is the value corresponding to `XDeviceInfo.type`. The better fix here is probably to change the logic we have for detecting which devices are tablets from the code we copied from Wine, to e.g. the same logic as in the latest Qt code. The risk with such a change is that it may break other devices and so you'd have to be prepared to handle bug reports related to that.

Robert Guetzkow commented

2020-11-23 17:18:24 +01:00

@brecht Should this be set to confirmed and known issue then?

@brecht Should this be set to *confirmed* and *known issue* then?

Brecht Van Lommel commented

2020-11-23 17:51:19 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'