Bug 371827 - [BOSTO] Pen Pressure not working
Summary: [BOSTO] Pen Pressure not working
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: 4.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-10-29 16:13 UTC by Aidan Walton
Modified: 2018-10-29 02:08 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aidan Walton 2016-10-29 16:13:04 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Build Identifier: 3.0.91 & 3.0.1.1

The latest versions of Krita seem to no longer receive pressure data from Tablet. I use a Bosto 22HD and I wrote the driver for it. Pressure is reported through USB sub_system using ABS_PRESSURE. It worked in all previous Krita versions. Still works with the current Ubuntu distro version of Krita which is: 2.9.7.(But this has major OpenGL problems on my system, really really slow to render).
This is resolved in the +3 release. GREAT!! Thanks.

Pressure reports properly within Gimp and other apps. Yet no longer Krita.
It's a real shame, as Krita is far superior IMHO.
If I need to change something in the driver code, please let me know, otherwise, what actually have you changed? What do you expect from Xorg configs etc.
I know Krita is cross platform, but something similar to Gimps Input Device configuration would be very useful. Just a thought. 

Reproducible: Always
Comment 1 Aidan Walton 2016-10-30 11:36:46 UTC
A little debug info.
This is from 2.9.7 at start-up:
Legacy integer arithmetics implementation 
################################### 
# Adding a tablet device: Bosto Kingtee 22HD 
Device Type: "Stylus" 
# Building tablet axes remapping table: 
Abs X 0 -> 0 
Abs Y 1 -> 1 
Abs Pressure 2 -> 2 
Abs Misc 3 -> 6 
# Axes limits data 
X:        0 10206 
Y:        0 7422 
Z:        0 0 
Pressure: 0 1024 
Rotation: 1919251566 1919505920 
T. Pres:  0 0 


As can be seen the tablet is detected and correctly mapped and tablet debug shows the pressure level correctly eg.
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  714, 649 gpos: 2691,1193 hires:  2692.82, 1193.29 prs: 0.889648 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  714, 649 gpos: 2691,1193 hires:  2692.82, 1193.29 prs: 0.889648 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  714, 649 gpos: 2691,1193 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  715, 649 gpos: 2692,1193 hires:  2693.19, 1193.08 prs: 0.890625 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  715, 649 gpos: 2692,1193 hires:  2693.19, 1193.08 prs: 0.890625 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  715, 649 gpos: 2692,1193 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  716, 648 gpos: 2693,1192 hires:  2693.94, 1192.67 prs: 0.890625 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  716, 648 gpos: 2693,1192 hires:  2693.94, 1192.67 prs: 0.890625 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  716, 648 gpos: 2693,1192 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  716, 648 gpos: 2693,1192 hires:   2694.7, 1192.46 prs: 0.891602 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  716, 648 gpos: 2693,1192 hires:   2694.7, 1192.46 prs: 0.891602 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  716, 648 gpos: 2693,1192 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  717, 648 gpos: 2694,1192 hires:  2695.45, 1192.05 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  717, 648 gpos: 2694,1192 hires:  2695.45, 1192.05 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  717, 648 gpos: 2694,1192 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  718, 648 gpos: 2695,1192 hires:   2696.2, 1191.84 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  718, 648 gpos: 2695,1192 hires:   2696.2, 1191.84 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  718, 648 gpos: 2695,1192 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  718, 647 gpos: 2695,1191 hires:  2696.58, 1191.63 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  718, 647 gpos: 2695,1191 hires:  2696.58, 1191.63 prs: 0.892578 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  718, 647 gpos: 2695,1191 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  719, 647 gpos: 2696,1191 hires:  2697.33, 1191.22 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  719, 647 gpos: 2696,1191 hires:  2697.33, 1191.22 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  719, 647 gpos: 2696,1191 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  720, 647 gpos: 2697,1191 hires:  2698.08, 1191.01 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  720, 647 gpos: 2697,1191 hires:  2698.08, 1191.01 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  720, 647 gpos: 2697,1191 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  721, 646 gpos: 2698,1190 hires:  2698.84,  1190.8 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  721, 646 gpos: 2698,1190 hires:  2698.84,  1190.8 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  721, 646 gpos: 2698,1190 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  721, 646 gpos: 2698,1190 hires:  2699.59,  1190.6 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  721, 646 gpos: 2698,1190 hires:  2699.59,  1190.6 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  MouseMove        btn: 0 btns: 1 pos:  721, 646 gpos: 2698,1190 " 
"[       ]  TabletMoveEx     btn: 0 btns: 1 pos:  722, 646 gpos: 2699,1190 hires:  2700.34, 1190.18 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 " 
"[       ]  TabletMove       btn: - btns: - pos:  722, 646 gpos: 2699,1190 hires:  2700.34, 1190.18 prs: 0.893555 Stylus Pen id: 0 xTilt: 0 yTilt: 33750992 rot: -33.2027 z: 0 tp: 0 "

But in 3+ I see none of this. It feels like you only see a generic mouse. At startup nothing is mentioned about tablet detect. Even if I turn on detailed debugging, (export QT_LOGGING_RULES="krita*=true"; krita). I see nothing related to tablet mapping.
Tablet debug from 3+ shows only this reference to Source 0, without any reference to a pressure field, looks like just a mouse to me:

krita.tabletlog: vvvvvvvvvvvvvvvvvvvvvvv START TABLET EVENT LOG vvvvvvvvvvvvvvvvvvvvvvv
krita.tabletlog: "[       ] Enter            "
krita.tabletlog: "[       ] FocusIn          "
krita.tabletlog: "[       ] KeyRelease       key: 0x1000004 mod: 0x0 text: \r"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 439 gpos: 2525,1106 Source:0"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 440 gpos: 2525,1107 Source:0"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 441 gpos: 2525,1108 Source:0"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 442 gpos: 2525,1109 Source:0"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 443 gpos: 2525,1110 Source:0"
krita.tabletlog: "[       ] MouseMove        btn: 0 btns: 0 pos:  259, 444 gpos: 2525,1111 Source:0"

How are you deciding on the source, what do you want to see from the hardware and what can I change either from the driver in terms of event reporting, or from evdev to make krita see it now.

Info needed, thanks.
Comment 2 Halla Rempt 2016-10-30 11:49:24 UTC
To really look into this and get you answers other than this is where it's done: https://phabricator.kde.org/diffusion/KRITA/browse/master/libs/ui/input/wintab/kis_tablet_support_x11.cpp, which isn't very helpful, I need clear my head from the current cold. Sorry! Maybe tomorrow. 

But the big difference between 2.9 and 3.0 is that 3.0, like Qt, uses xcb now. We do have our own tablet code, but it's forked from Qt5. You could perhaps check whether a Qt5 application like its own tablet demo sees your tablet?
Comment 3 Halla Rempt 2016-10-31 15:25:36 UTC
Do you get any message like

"QApplication: Failed to get list of tablet devices" 

?
Comment 4 Aidan Walton 2016-10-31 18:58:41 UTC
(In reply to Boudewijn Rempt from comment #3)
> Do you get any message like
> 
> "QApplication: Failed to get list of tablet devices" 
> 
> ?

Hi,
Well I see nothing about failing to get Tablet devices, it works, but without pressure. I just spent the weekend recoding my driver, and now even 2.9.7 crashes as soon as I touch the screen. It tracks the movement and responds to stylus keys etc, in both 3.0 and 2.9 but 3.0 has no pressure and 2.9 now crashes with a screen touch.

If you can tell me how you map BTN_TOUCH, BTN_TOOL_PEN, BTN_TOOL_RUBBER etc from evdev, we might get somewhere.

Ah well, Gimps very happy, no problems. Everything working just fine.
Comment 5 Aidan Walton 2016-10-31 21:58:22 UTC
(In reply to Boudewijn Rempt from comment #3)
> Do you get any message like
> 
> "QApplication: Failed to get list of tablet devices" 
> 
> ?

Well, this is not so easy to fathom. 
If it helps and you have a chance, please take a look.

# xinput --list --long 11
Bosto Kingtee 22HD                      	id=11	[slave  pointer  (2)]
	Reporting 5 classes:
		Class originated from: 11. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Unknown" "Button Unknown" "Button Unknown" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Abs X
		  Range: 0.000000 - 10206.000000
		  Resolution: 0 units/m
		  Mode: absolute
		  Current value: 7502.000000
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Abs Y
		  Range: 0.000000 - 7422.000000
		  Resolution: 0 units/m
		  Mode: absolute
		  Current value: 5450.000000
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Abs Pressure
		  Range: 0.000000 - 2048.000000
		  Resolution: 0 units/m
		  Mode: absolute
		  Current value: 0.000000
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Abs Misc
		  Range: 0.000000 - 0.000000
		  Resolution: 0 units/m
		  Mode: absolute
		  Current value: 2.000000


We can see everthing needed including presure.

 
# tail -f /var/log/Xorg.0.log
[ 38062.162] (II) config/udev: Adding input device Bosto Kingtee 22HD (/dev/input/mouse2)
[ 38062.162] (II) No input driver specified, ignoring this device.
[ 38062.162] (II) This device may have been added with another device file.
[ 38062.233] (II) config/udev: Adding input device Bosto Kingtee 22HD (/dev/input/event5)
[ 38062.233] (**) Bosto Kingtee 22HD: Applying InputClass "evdev tablet catchall"
[ 38062.233] (II) Using input driver 'evdev' for 'Bosto Kingtee 22HD'
[ 38062.233] (**) Bosto Kingtee 22HD: always reports core events
[ 38062.233] (**) evdev: Bosto Kingtee 22HD: Device: "/dev/input/event5"
[ 38062.233] (--) evdev: Bosto Kingtee 22HD: Vendor 0xb57 Product 0x9016
[ 38062.233] (--) evdev: Bosto Kingtee 22HD: Found absolute axes
[ 38062.233] (--) evdev: Bosto Kingtee 22HD: Found x and y absolute axes
[ 38062.233] (--) evdev: Bosto Kingtee 22HD: Found absolute tablet.
[ 38062.233] (II) evdev: Bosto Kingtee 22HD: Configuring as tablet
[ 38062.233] (**) evdev: Bosto Kingtee 22HD: YAxisMapping: buttons 4 and 5
[ 38062.233] (**) evdev: Bosto Kingtee 22HD: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[ 38062.233] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:0b.0/usb2/2-6/2-6:1.0/input/input76/event5"
[ 38062.233] (II) XINPUT: Adding extended input device "Bosto Kingtee 22HD" (type: TABLET, id 11)
[ 38062.233] (II) evdev: Bosto Kingtee 22HD: initialized for absolute axes.
[ 38062.233] (**) Bosto Kingtee 22HD: (accel) keeping acceleration scheme 1
[ 38062.233] (**) Bosto Kingtee 22HD: (accel) acceleration profile 0
[ 38062.233] (**) Bosto Kingtee 22HD: (accel) acceleration factor: 2.000
[ 38062.233] (**) Bosto Kingtee 22HD: (accel) acceleration threshold: 4


Well its mapped by evdev for sure, but no mention of pressure? yet xinput shows it. Alos udev maps the device as a generic mouse, as indeed it should. So the question is for you is Qt recognising these Valuators.

I refer to this old bug:  https://bugreports.qt.io/browse/QTBUG-48370
Description
It's not detected as a tablet, so only works as a mouse.
[     0.001 D] unknown - input device  WALTOP International Corp. Slim Tablet
[     0.001 D] unknown -    has 13 buttons
[     0.001 D] unknown -    has valuator "Abs X" recognized? true
[     0.001 D] unknown -    has valuator "Abs Y" recognized? true
[     0.001 D] unknown -    has valuator "Abs Pressure" recognized? true
[     0.001 D] unknown -    has valuator "Rel Vert Wheel" recognized? true
[     0.001 D] unknown -    it's a scrolling device

So this was a Waltop tablet, as can be seen Qt seems to identify the needed functions based on the Valuator Label: Abs Presssure.

And as you can see my xinput displays the exact same Valuator Label from my Bosto.

I think there is nothing much more I can change in the driver. Any thoughts.

And while I may have your attention, the final Valutor Label: Abs Misc, I am using to define the current tool. Either Pen or Eraser.

I send '2' for PEN and '10' for ERASER. I have no idea if you even take any notice of this, but I could send other EV_ codes instead, or any value you would like to see in this 'Abs Misc' Valuator.

This does seem to be the current Linux generic method for mapping a Tablet into X, so I don't want to start hacking xconfigs if this can work out of the box.

Help if you can.
Thanks
Comment 6 Halla Rempt 2016-11-01 08:10:40 UTC
Hm... We've got our own fork of the file mentioned in that bug -- because we've added some more tablets, like the ones that advertise themselves as uc-logicwhich means we should regularly check for the delta. I've added the patch from that bug to our fork now (in the rempt/impex-refactoring branch, not master -- if you want to test that, build from that branch.)

I'm not really deep into that code, though... I think you might have a better chance of checking whether it's doing the right thing than me!
Comment 7 Mark Dolan 2017-04-08 18:49:56 UTC
Just to add a vote to this, exactly the same issue exists for me with a monoprice mp 22 which has the same digitizer.
Comment 8 Thomas Iguchi 2018-03-26 16:36:57 UTC
Same problem with the Huion GT 191 (screen tablet device), there's no pressure sensitivity. All line strokes appear at full pressure.

However there is a workaround: the Huion pen has a button for switching the brush tool (usually from brush to eraser and vice versa). When I click that button Krita all of a sudden is sensitive to pressure and all brushes start working.

The bug reappears only when Krita is restarted.


Krita
  Version: 4.0.0 (git 4ba5152)

OS Information
  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: darwin
  Kernel Version: 17.4.0
  Pretty Productname: macOS High Sierra (10.13)
  Product Type: osx
  Product Version: 10.13

OpenGL Info 
  Vendor:  Intel Inc. 
  Renderer:  "Intel Iris OpenGL Engine" 
  Version:  "4.1 INTEL-10.30.14" 
  Shading language:  4.10 
  Requested format:  QSurfaceFormat(version 3.2, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile  QSurfaceFormat::OpenGLContextProfile(CoreProfile)) 
  Current format:    QSurfaceFormat(version 4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile  QSurfaceFormat::OpenGLContextProfile(CoreProfile)) 
     Version: 4.1
     Supports deprecated functions false 
     is OpenGL ES: false
Comment 9 Halla Rempt 2018-03-27 05:59:06 UTC
Thomas, you do not have the same problem, since you do not use the operating system as the original reporter. It's an interesting data point, but it's just not a bug in Krita; it's an issue with the driver. We cannot work around that, especially not on macOS, since on macOS we use the OS's tablet integration, there is no tablet-specific code in Krita on macOS.
Comment 10 Siris8280 2018-03-28 06:36:20 UTC
Pen pressure not working full stop! Tried the OpenGL trick and I also tried to open screen resolution because I heard that works. It says to hold shift while you click with your pen but nothing happens. Stuck for ideas.
Comment 11 Halla Rempt 2018-03-28 07:18:13 UTC
This bug was reported for Linux. So don't change the platform to Windows CE. And if you're on Windows and you do not have pressure with your tablet, the problem is ALWAYS with the tablet driver. Either the wintab driver is broken or incorreclty installed, or you haven't turned on Windows Ink.  In any case, adding comments about tablets on Windows to this bug is wrong. Don't do it.

Aidan, can you please test again with 4.0? A lot has happened since 3.0. We don't have the hardware since Bosto refused to send us test hardware, instead allowing us as a special favor to buy their tablets at the full price, which offer we naturally declined. We cannot buy every tablet under the sun.
Comment 12 Aidan Walton 2018-03-30 09:52:29 UTC
I just upgraded to 4.0 and unfortunately it still shows the same behaviour. No pressure. Just as a quick comparison I also then just tried MyPaint and Gimp. Both have fully functional pressure sensitivity.

Ooops, how frustrating.
Aidan
Comment 13 Aidan Walton 2018-03-30 11:35:50 UTC
Hey, this is such a shame. I remember Krita working just fine some time back. So whatever changed has still not been resolved. Or quite simply I am missing something obvious. I have said this before and I wish to help, but it seems we are coming at this from the wrong angle.
I have limited options from a driver point of view. The evdev system in Linux is well defined. OK, exactly how the 'Abs Misc' Valuator Class is handled is a corner case.

But.... It seems very clear. XIValuatorClass: Label: Abs Pressure. Is very obviously used for one purpose and one purpose only. Pen pressure reporting.

My driver does exactly this, and these other applications seem very satisfied to use it appropriately. 

BTW as a side note, when I try to enable tablet event logging "SHIRT+CTRL+T" I get no output to the console.???? So its quite impossible to even attempt to debug this from an application level. I cant find any documentation to help any further.

So from what I understand this is how the Linux device stack looks:

X11:
Linux kernel → libevdev → xf86-input-evdev → X server → X client

Wayland:
Linux kernel → libevdev → libinput → Weston → Wayland client

If I examine xinput (X11) or libinput (Wayland) both report pressure to the client.

What one earth is Krita doing with this well defined information?

I'm done!
Comment 14 Dmitry Kazakov 2018-03-30 13:14:31 UTC
Hi, Aidan!

Starting from Krita 3.x we use XI2, the second version of XInput library. That is, basically, the main difference between Krita 2 and Krita 3+. Could you check if you driver supports that?

Please ping me on IRC to get more information about it... My nick is dmitryK|log
Comment 15 Dmitry Kazakov 2018-03-30 13:22:23 UTC
Basically, you need to open libs/ui/input/wintab/qxcbconnection_xi2.cpp, go to function QXcbConnection::xi2SetupDevices() and check:

1) If this function is ever called
2) What happens in this function

Just a wild guess: the most probable reason for absence of the pressure with your driver is that it doesn't send XI_HierarchyChangedMask and XI_DeviceChangedMask events, which triggers tablet device rescan in Krita.
Comment 16 Andrew Crouthamel 2018-09-28 03:22:50 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 17 Andrew Crouthamel 2018-10-29 02:08:00 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!