Analysis: the pressure data from the tablet itself is fine, you can check this with this script:
https://github.com/whot/input-data-analysis/tree/master/pressure-over-time
so this rules out any low-level device/kernel issues.

But the xinput test and xinput test-xi2 also show the x/y axis updates to be just fine. This indicates that the problem may be either fixed or in blender after all.


(In reply to YAFU from comment #0)
> Kubuntu Linux 14.04 64bits
> xserver-xorg-input-evdev version: 1:2.8.2-1ubuntu2

those are quite old packages and ubuntu has a tendency to patch a lot. I suggest you try a more recent version of evdev and/or the server.

also, I'm assuming that this is an evemu-record of a sequence that did reproduce the issue?

Created attachment 123864 [details]
evemu-record_blend files

Hi. In Kubuntu 16.04 I still have the same problem.
Kernel 4.4.0-21-generic
xserver-xorg-input-evdev version: 1:2.10.1-1ubuntu2

I attached a new file with evemu-record while I drew in blender. I also share the .blend files. If you have a tablet with pressure sensitivity using evdev, you can open those .blend files in Blender 3D and draw on the square. You remember to do slow strokes.
I have the confirmation that another person with  UC-Logic WP5540U has the same problem, but I do not know if it happens in every tablet using evdev driver.

I really do not know much about these technical data. There in the Blender report developers explain what the problem they see.

what's the output from xinput test "UC-LOGIC Tablet WP5540U Pen" when you move the stylus? and then the same again for xinput test-xi2 please (with the window maximised)

In Kubuntu 14.04 (kde/plasma 4) "xinput test" works only when I work over Gtk applications. In Kubuntu 16.04 (Plasma 5) "xinput test" works on Gtk and kde/Qt apps, but does not work on Blender.
So, the output of "xinput test" I share here is working on the desktop in Kubuntu 16.04. And the output of "xinput test-xi2" when work on Blender (maximized window). All of them with vertical movements.

Created attachment 123881 [details]
xinput outputs

thanks. note that xinput is an X application like GTK/KDE applications, it receives the same events. Unlike evemu it doesn't sit above/below anything, it's side-to side with other applications.

anyway, in this output I cannot see the symptom bastien describes in https://developer.blender.org/T48204#373424

Technical details: x input events don't always contain all axes, they contain either a first+num valuators (XI 1.x) or a valuator mask (XI 2.x). So when only y and pressure update you'd get a first valuator: 1, num_valuators 2.

In the comment there is the example of 1:391 and 2:0 which would indicate that the first+num valuators is incorrect and triggers a 0 pressure. If that was the case we'd see this in the xinput test output too. But there is no indication that happens so I'm now rather convinced that blender messes up the first + num valuator handling somehow.

the last comment https://developer.blender.org/T48204#374467 shows the correct handling of axes, so now I'm mostly confused as to why the axes_count (same as num_valuators, just different names to call it by) is wrong.

Keep trying to reproduce it with evemu-record and xinput test running. when the xinput test shows something like
    motion a[1]=16587 a[2]=0
then stop the recording and attach the evemu-record and xinput test output here.

Please restart frequently so that the evemu-record output is short. You'll get a a[2]=0 whenever you stop touching the surface, please ignore those.

Thank you.
What I do not understand is this: The problem happens all the time in Blender with vertical strokes and pressure sensitivity enabled, is always reproducible. According to my little understanding, if this were an xinput or evdev problem this problem should be visible in each log which I have sent you (and all of whom I have shared in Blender bug report).

Anyway I will try to get/reproduce that you ask me.

yes, it should be visible. But moreover - it should also be visible in other applications but so far only blender seems to have these issues. So that does hint at blender being at fault here.

Uuuuuuh… reading xinput code I see:

for(loop=0; loop<button->axes_count; loop++) {
    printf("a[%d]=%d ", button->first_axis + loop, button->axis_data[loop]);
}

…while in Blender we are currently doing something like that:

for(loop=button->first_axis; loop<button->axes_count+button->first_axis; loop++) {
    printf("a[%d]=%d ", loop, button->axis_data[loop]);
}

Stupid mistake, and easy to fix… Will commit this evening so that YAFU can confirm tomorrow whether it works or not. Sorry for the noise. :/

Compiled Blender from Master. Yes, it's working fine now!

Thanks Peter and Bastien!

excellent, thanks for fixing!