Ubuntu 16.10 Abs_pressure not reported from kernel evdev to xserver-xorg-evdev

[Aidan Walton]

Please refer to bug filed with freedesktop.org:

https://bugs.freedesktop.org/show_bug.cgi?id=98575

I modified a driver for the Bosto Tablet 22HD and others, this has been working without problems across the last several releases and continues to work with 16.04.1 LTS.

When I upgraded to 16.10, pressure readings are lost from all applications, X & Y data still visible.

evtest shows correct EV_ data for ABS_X ABS_Y and ABS_PRESSURE, but when xinput is used.

xinput --list --long <device>

The Valuator for pressure is listed, but no changes occur as the tool is used. The parameters of the Valuator can still be modified using xinput tweaking tools, but no pressure reported.

All X apps requiring pressure data fail.

I made a fresh install of 16.10, loaded the driver .... same issue.

I run 16.04.1 LTS, everything fine.
I have others users of my driver code also using 16.04.1 without issue.

[Aidan Walton (aidan-walton)]

Created attachment 127721
Bosto Tablet removed and replugged. Note I have a tiny userspace program to detach the usbhid driver and then attach bosto_2g driver.

Hi,
I have a Bosto22HD. Some years ago I hacked the hanwang driver into my own and have been supporting this since as no other option was available. I recently upgraded to Ubuntu 16.10 and began having problems, but to be honest I'm not 100% sure this is related to the upgrade.

When my driver registers with the usb subsystem I can inspect the output of evtest and I see everything reported correctly. I attach copies. Clearly we can see the ABS_PRESSURE events streaming from the kernel. However when the driver is picked up by xfree86_evdev (?), i.e. the logs from Xorg.0.log... I see no detection of and ABS_pressure Valuator. However xinput shows the Valuator as being available, yet I do not see pressure val changes.

Something is going on between kernel and X drivers? (evdev > xfree86-evdev)

I even tried:
libevdev-tweak-device --abs ABS_PRESSURE --val 2047 /dev/input/event5

Sure enough xinput shows the property change as requested.

[Aidan Walton (aidan-walton)]

Created attachment 127722
evtest ouput shows correct device EV_ and ABS_PRESSURE reporting within the same SYNC block

[Aidan Walton (aidan-walton)]

Created attachment 127723
xinput --list --long out of proximity

[Aidan Walton (aidan-walton)]

Created attachment 127724
xinput --list --long in proximity

[Aidan Walton (aidan-walton)]

Created attachment 127725
xinput --list --long in contact

[Aidan Walton (aidan-walton)]

My kernel:
4.8.0-26-generic

My Ubuntu Packages:
xserver-xorg-input-evdev (1:2.10.2-1ubuntu1) This contains /usr/lib/xorg/modules/input/evdev_drv.so

I assume this is what xinput is working with?

Finally my driver:
https://github.com/aidyw/bosto-2g-linux-kernel-module

Thanks

[Aidan Walton (aidan-walton)]

Created attachment 127727
xinput --test Seems Pressure is not reported here...No surprise. But contact is seen as Button press 1

[Aidan Walton (aidan-walton)]

Within applications eg, Krita (2.9.7), Gimp, mypaint, I can move as expected, but as pressure is missing I cant draw any lines.

With Krita(3+) its a different story, I can draw, but without pressure (full pressure all the time.)

Final comment. This driver did work in all these applications in the past, and recently on Ubuntu 16.04, even 16.10 (but it was a late night, so exactly when this showed up is a bit fuzzy)

[Peter Hutterer (peter-hutterer)]

can you get me a recording from evemu-record instead of evtest. I can replay that one easily, evtest requires manual work. same thing though: sudo evemu-record > tablet.evemu, select your device, and generate a stylus movement.

This may be to do with libinput if you switched to libinput recently. xinput list-props <device> will show you which driver, check the property prefixes for the driver name.

I don't see anything obviously wrong with the protocol yet, but the evemu one should help identifying that.

[Aidan Walton (aidan-walton)]

Created attachment 127745
Simple test. Out prox, in prox(pen), touch/move(pen), out, in(eraser), touch/move(eraser), out

It seems to be what I personally expected. Obviously evdev is supressing many values that remain unchanged between sync reports, but in there are blocks that contain all events in one sync block.

[Aidan Walton (aidan-walton)]

Seems I'm not moved over to libinput just yet, or Wayland ;)

All prefix read 'evdev'. Best only to change one thing at once I guess.

[Aidan Walton (aidan-walton)]

Just to be sure. I tested again xinput to be sure nothing has changed, and indeed its the same. Valuator 2 : Ab Pressure, range correct, no change in the value.

Xorg.0.log, evdev does not report Abs Pressure
[ 78193.711] (II) config/udev: Adding input device Bosto Kingtee 22HD (/dev/input/event5)
[ 78193.711] (**) Bosto Kingtee 22HD: Applying InputClass "evdev tablet catchall"
[ 78193.711] (II) Using input driver 'evdev' for 'Bosto Kingtee 22HD'
[ 78193.711] (**) Bosto Kingtee 22HD: always reports core events
[ 78193.711] (**) evdev: Bosto Kingtee 22HD: Device: "/dev/input/event5"
[ 78193.711] (--) evdev: Bosto Kingtee 22HD: Vendor 0xb57 Product 0x9016
[ 78193.711] (--) evdev: Bosto Kingtee 22HD: Found absolute axes
[ 78193.712] (--) evdev: Bosto Kingtee 22HD: Found x and y absolute axes
[ 78193.712] (--) evdev: Bosto Kingtee 22HD: Found absolute tablet.
[ 78193.712] (II) evdev: Bosto Kingtee 22HD: Configuring as tablet
[ 78193.712] (**) evdev: Bosto Kingtee 22HD: YAxisMapping: buttons 4 and 5
[ 78193.712] (**) evdev: Bosto Kingtee 22HD: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[ 78193.712] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:0b.1/usb1/1-3/1-3.2/1-3.2:1.0/input/input43/event5"
[ 78193.712] (II) XINPUT: Adding extended input device "Bosto Kingtee 22HD" (type: TABLET, id 11)
[ 78193.712] (II) evdev: Bosto Kingtee 22HD: initialized for absolute axes.
[ 78193.712] (**) Bosto Kingtee 22HD: (accel) keeping acceleration scheme 1
[ 78193.712] (**) Bosto Kingtee 22HD: (accel) acceleration profile 0
[ 78193.712] (**) Bosto Kingtee 22HD: (accel) acceleration factor: 2.000
[ 78193.712] (**) Bosto Kingtee 22HD: (accel) acceleration threshold: 4

[Peter Hutterer (peter-hutterer)]

this is your own driver, right? Please set the abs resolution for x/y, it'll make libinput handle the tablet better (well, at all, libinput refuses tablets without x/y resolution). that's a side note.

Using the evdev driver, I'm getting a fair number of pressure updates here (xinput test-xi2 and xinput test) and gimp sort-or responds to drawing. Not sure what's happening there. what versions does ubuntu ship these days?

[Aidan Walton (aidan-walton)]

Id set the resolution if I knew how. Looking at the function in kernel input.h, resolution is not defined. Tell me how?

Ubuntu's xinput is 1.6.2-1, but isn't this just a utility ...

[Aidan Walton (aidan-walton)]

If I use xinput --test-xi2 I only see Valuator's 0 & 1. 2(Pressure) is missing.

[Aidan Walton (aidan-walton)]

Hmm, I took my driver code, booted into an old install I had of Ubuntu 16.04, compiled it. Working! pressure seen in xinput, apps responding to pressure as expected.

??? What's changed in 16.10 I wonder, or what's screwed on my install of 16.10?

[Aidan Walton (aidan-walton)]

Okay, I tried Ubuntu 16.10 fresh install. Not working.

Ubuntu 16.04.1 LTS Working.
Hmmm

[Peter Hutterer (peter-hutterer)]

look for input_abs_set_res() to set the resolution in the kernel.

xinput is just the tool, the versions that matter are the X server version (xserver-xorg) and the evdev driver's version (xserver-xorg-input-evdev)
one of the two may be at fault here, I suspect it's more likely evdev but I'm not sure what change could've done this. I recommend installing evdev from git and if that doesn't work either then you can bisect.

Otherwise it's something specific to Ubuntu, I guess.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[vasdi (vasdi)]

I have Huion 420 tablet, it uses evdev driver and I have the same bug.

[Aidan Walton (aidan-walton)]

Thanks vasdi, can you perhaps, confirm if this problem does not present when you run 16.04.1 LTS. I'm trying to work out what changed between the two releases.

Thanks

[Aidan Walton (aidan-walton)]

Thanks Peter,
I added the resolution data as you requested. It does appear correctly now in the Valuator data, but it makes no difference to the pressure information.

I just want to reiterate. With fresh installs of Ubuntu, 16.10 directly from a live disk, I see the same problem.
With 16.04.1 LTS from a live disk, everything is okay. So we clearly have something changed in Ubuntu.

The problem is I have no idea which version of xf86-evdev is actually compiled into the xserver-xorg-input-evdev package. I have tried to track this down, but its not referenced in any material I can find. What I can say is the the libevdev.so in both release packages are identically sized, all symbols are exactly the same, and well, this I think would hint strongly that they are using the exact same version of the evdev driver.

I could try somehow to compile the very latest from git and I looked into it, but there are a few dependencies and I'm really trying to get to the root cause and of course hopefully resolve effectively for Ubuntu if it really is an issue.

Does the source compile into the .so I need

I have opened a bug with Ubuntu: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1639337 , and, yes, apparently others are suffering the same, well one other at the moment.

Please excuse my ignorance, I am certainly not very experienced with any of this and there is much I have to learn.

[Mike H (uint64)]

Note, this bug does not only apply to USB digitizers but to built-in digitizers in some 2-in-1's as well (I am experiencing exactly the same behavior on a fresh install of 16.10 but instead with the pen on my lenovo miix 700 tablet, 100% vanilla drivers from the ubuntu install).

The pressure events show up just fine when watching from evtest, but xinput never seems to get ABS_PRESSURE updates. xinput sees the device axis just never gets update, which pins the pressure at zero. This is not a bug at the driver level, It's almost definitely some kind of regression in xorg/xinput/touch code..

Since the pressure is stuck at zero, this bug doesn't just stop pressure sensing, it's a total creative showstopper - makes it impossible to draw in any of the various art programs because pressure=0 --> nothing gets drawn in most programs, Krita segfaults, etc. etc.

[Peter Hutterer (peter-hutterer)]

I think ubuntu tracks the xf86-input-evdev version, so if the package is version 2.10.4, then that's the upstream version too..... yep:
http://packages.ubuntu.com/yakkety/xserver-xorg-input-evdev

libevdev.so is an unrelated package, it's a dependency for the driver but it's not likely to be the source of the issue (especially if the .so is the same). The xf86-input-evdev driver usually sits in /usr/lib/xorg/modules/input/evdev_drv.so

as for the dependencies, you should get there with apt-get build-dep xserver-xorg-input-evdev. check for the exact usage, I never remember (on an RPM distry myself) but google will help there. Once that's done, the git driver should compile just fine. A quick check shows that the ubuntu version doesn't seem to have any patches over upstream, so I'really need you to try the git version and bisect to figure out what's going on.

But 16.10 is on 2.10.2, so you're most likely running into bug 95315 that was fixed in 2.10.3

[vasdi (vasdi)]

I will tell even more: downgrading to xserver-xorg-input-evdev_2.10.1-1ubuntu2_amd64.deb fixes the problem.

[Aidan Walton (aidan-walton)]

Well, thats interesting. Did you have dependency issues when you
installed this .deb?
It would be good if you shared your findings, perhaps directly with
Peter Hutterer, he maintains the libevdev code within xorg. Follow the
link I posted initially to the freedesktop bug report.

However I don't like much the idea of installing this package:
Breaks: xserver-xorg-core (<< 2:1.18.0-1)
Replaces: xserver-xorg-core (<< 2:1.18.0-1)

Hmmm, no thanks.

Did this go smoothly for you?

On 12 November 2016 at 07:19, vasdi <email address hidden> wrote:
> I will tell even more: downgrading to xserver-xorg-input-
> evdev_2.10.1-1ubuntu2_amd64.deb fixes the problem.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1639337
>
> Title:
> Ubuntu 16.10 Abs_pressure not reported from kernel evdev to xserver-
> xorg-evdev
>
> Status in network-manager package in Ubuntu:
> Confirmed
>
> Bug description:
> Please refer to bug filed with freedesktop.org:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=98575
>
> I modified a driver for the Bosto Tablet 22HD and others, this has
> been working without problems across the last several releases and
> continues to work with 16.04.1 LTS.
>
> When I upgraded to 16.10, pressure readings are lost from all
> applications, X & Y data still visible.
>
> evtest shows correct EV_ data for ABS_X ABS_Y and ABS_PRESSURE, but
> when xinput is used.
>
> xinput --list --long <device>
>
> The Valuator for pressure is listed, but no changes occur as the tool
> is used. The parameters of the Valuator can still be modified using
> xinput tweaking tools, but no pressure reported.
>
> All X apps requiring pressure data fail.
>
> I made a fresh install of 16.10, loaded the driver .... same issue.
>
> I run 16.04.1 LTS, everything fine.
> I have others users of my driver code also using 16.04.1 without issue.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1639337/+subscriptions

[Aidan Walton (aidan-walton)]

I'm not sure this is related.... I refer you to the comments from
other Ubuntu users regarding downgrading to 2.10.1, by installing
xserver-xorg-input-evdev_2.10.1-1ubuntu2_amd64.deb. This seems to have
fixed the issue.
I have not done this and probably will not make this change. I think
it will force a downgrade also to the xserver-xorg-core package. I
don't much like that idea.

But if what this other person says can be confirmed (see the ubuntu
bug tracker) then I think something else if wrong.??

On 11 November 2016 at 00:04, <email address hidden> wrote:
> Comment # 19 on bug 98575 from Peter Hutterer
>
> I think ubuntu tracks the xf86-input-evdev version, so if the package is
> version 2.10.4, then that's the upstream version too..... yep:
> http://packages.ubuntu.com/yakkety/xserver-xorg-input-evdev
>
> libevdev.so is an unrelated package, it's a dependency for the driver but
> it's
> not likely to be the source of the issue (especially if the .so is the
> same).
> The xf86-input-evdev driver usually sits in
> /usr/lib/xorg/modules/input/evdev_drv.so
>
> as for the dependencies, you should get there with apt-get build-dep
> xserver-xorg-input-evdev. check for the exact usage, I never remember (on an
> RPM distry myself) but google will help there. Once that's done, the git
> driver
> should compile just fine. A quick check shows that the ubuntu version
> doesn't
> seem to have any patches over upstream, so I'really need you to try the git
> version and bisect to figure out what's going on.
>
> But 16.10 is on 2.10.2, so you're most likely running into bug 95315 that
> was
> fixed in 2.10.3
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.

[vasdi (vasdi)]

Yakkety version of xserver-xorg-core is 2:1.18.4-1ubuntu6 (> 2:1.18.0-1) so it should be ok.

[Peter Hutterer (peter-hutterer)]

(In reply to Aidan from comment #20)
> I'm not sure this is related.... I refer you to the comments from
> other Ubuntu users regarding downgrading to 2.10.1, by installing
> xserver-xorg-input-evdev_2.10.1-1ubuntu2_amd64.deb. This seems to have
> fixed the issue.

See bug 95315 comment 10. That's the issue and it was first introduced in
2.10.2 and then reverted again in 2.10.3. So the above means that this is what we're looking at here - please update to 2.10.3 and it should be fixed.

[Mike H (uint64)]

Hi all,
 per the bug Aidan & I had going @ https://bugs.freedesktop.org/show_bug.cgi?id=98575 , Peter H has suggested that the bug is likely one that was in xserver-xorg-input-evdev-1:2.10.2 that has already been fixed in xserver-xorg-input-evdev-1:2.10.3 - so the fix for Ubuntu now is to update the 16.10 repos to the next version and we should all get pressure working again.

 In the meantime, I've been out of the ubuntu loop for awhile - what's the current kosher way for me to upgrade my package now but still get ubuntu upstream updates in the future? any experienced ubuntu users want to chime in on this? would help the newer users as well to discover that fixes to their problems are already done :D

[Aidan Walton (aidan-walton)]

I forget to mention vasdi.... I did downgrade to xserver-xorg-input-evdev_2.10.1-1ubuntu2_amd64.deb and indeed it solved the problem.

Although I'm sure you will agree, an upgrade is preferable, so no doubt this needs to be addressed in the official Ubuntu repos.
Thanks
Aidan

[Peter Hutterer (peter-hutterer)]

closing based on comment 21

[viccan3 (viccan3)]

Hi, this bug is affecting me. Fix please. I need the tablet for work!

[Brian (thwaller)]

downgrade to xserver-xorg-input-evdev_2.10.1-1ubuntu2_amd64.deb does not solve for me, it depends on xorg-input-abi-22 which is not installable. I am on Ubuntu 17.04.

[Aaren Twedt (twedta)]

Can confirm that the downgrade solution no longer works on 17.04 due to xorg-input-abi-22 dependency.

[Aidan Walton (aidan-walton)]

Hi, its been some time..

Okay please allow me to open this problem up once more. Perhaps you have some further info.
Regarding the build of evdev in Ubuntu. Now using Ubuntu 17.10 and the package: xserver-xorg-input-evdev (1:2.10.5-1ubuntu1) is installed. I think its clear that the evdev version is ahead of the point you mentioned when closing this bug report.

However, I still have problems with ABS_PRESSURE. Most applications, it seems those using XIv1 see pressure and act accordingly. A specific application, Krita, apparently uses XIv2, and does not see pressure.

If I look at xinput --test 8, my tablet.

motion a[0]=24032 a[1]=12372 a[2]=825
motion a[0]=24035 a[1]=12372 a[2]=829
motion a[0]=24040 a[1]=12372 a[2]=833
motion a[0]=24044 a[1]=12372 a[2]=835

a[0] = x, a[1] = y, a[2] = pressure

But when I watch the XI2 xinput test-xi2 8

EVENT type 17 (RawMotion)
    device: 8 (8)
    detail: 0
    flags:
    valuators:
          0: 26332.00 (26332.00)
          1: 16756.00 (16756.00)

I never see pressure. So it seems that the valuator seen by xinput does not get translated to an xi2 extended valuator.

xinput version 1.6.2
XI version on server: 2.3

Why is this?

[Peter Hutterer (peter-hutterer)]

that is ... weird. the code paths are supposed to be the same and if the raw motion doesn't see the axis, the xi1 event is not supposed to see the axis either. RawMotion is what comes straight from the device, before the other events are assembled.

I replayed attachment 127745 here and the pressure valuator definitely shows up with xi2 as well. Note however that unlike XI 1.x where the valuators are continuous, XI2 has a bitmask with the valuators set as they come in from the device. IOW, events like these:

EVENT type 17 (RawMotion)
    device: 25 (25)
    detail: 0
    flags:
    valuators:
          2: 591.00 (591.00)

Or even like these:

EVENT type 17 (RawMotion)
    device: 25 (25)
    detail: 0
    flags:
    valuators:
          0: 7642.00 (7642.00)
          2: 617.00 (617.00)

So afaict, the evdev driver works correctly and events are sent to clients as expected. Not sure why krita doesn't see it, but right now I'm ETIME on almost everything so you'll have to investigate that yourself, sorry.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev/issues/7.