Bug 99961

are these produced with the same server code? I'm trying to reproduce this here but every recording so far produces the same line in the GIMP. I can see the wavyness you refer to, but I seem to get it with both drivers.

I'm using a I5 as well, but I doubt this is in the kernel code anyway.

Do me a favour please: run sudo evemu-record > pen.evemu, select the wacom tablet, then draw a line that has those waves. Cancel the recording.

Open a new document, run sudo evemu-play /dev/input/eventX < pen.evemu - that replays on the device (select the right event node!), does it recreate the waves?

if so, switch to the wacom driver, restart X, do the same thing again with evemu-replay - does it recreate the waves?

If so, please attach the recording here because then I can replay it to figure out where things are going wrong.

Hi Peter,

First of all, thank you very much for working on the wacom driver in libinput.

I recorded the events with evemu as you suggested, let me explain the steps that I did

1) First I uninstalled the xf86-input-driver, because when this driver is installed the strokes behave correctly, even if Xorg.0.log shows me that libinput is used as driver.

2) Then I rebooted the system and made sure that libinput is used as driver by checking xorg log with grep -e "Using input driver 'libinput'" /var/log/Xorg.0.log

I got Using input driver 'libinput' for 'Wacom Intuos4 6x9 Pen'

3) Then I opened krita with a document of 1920X1080 snapped it on the left side of the screen and snapped the terminal on right half of the screen. I then tested the stroke, which were wavy as I showed you earlier. I then proceeded to record the events with evemu as you suggested with evemu-record > pen.evemu , i got a prompt to enter the number of event which was 17 I am attaching the log here as **pen-evemu**

4) I then replayed this event in a new document as you suggested and the wavy lines were reproduced.

5) I then installed xf86-input-wacom and commented the tablet related lines in 40-libinput.conf like i mentioned in my earlier comment to make sure xf86-input-wacom is used as driver

6) I rebooted the system, check the xorg log to make sure libinput is not used for wacom, I got the output of grep as - Using input driver 'wacom' for 'Wacom Intuos4 6x9 Pen'

7) I then proceeded to check if replaying earlier recording would reproduce the wavy lines. this time the event number was changed to 5, so I had to change the number from 17 to 5 in while replaying with sudo evemu-play /dev/input/eventX < pen.evemu. There was not stroke made and nothing happened.

8) The strokes were smooth and perfect with wacom driver, I then re recorded event with evemu as saved the recording as **pen-wacom.evemu**. I am attaching this log too. **this is with xf86-input-wacom driver **

9) I then replayed the event and the stroke was played correctly and it was smooth.

Note : please try to make the stroke in one rapid movement across the screen

Attached evemu logs
pen.evemu -> libinput
pen-wacom.evemu -> xf86-input-wacom

Created attachment 129943 [details]
evemu log of xf86-input-wacom

Created attachment 129944 [details]
evemu log of libinput

regarding Step 7 in my earlier comment , I once again tried to replay the libinput evemu recording with xf86 driver and this time i was able to play it. the strokes were not wavy but smooth though. So playing the libinput evemu recording with xf86 driver gave smooth lines too

confirmed, this is a libinput bug, looks like the wacom driver does coordinate smoothing to avoid that and we should too. Should have a patch by tomorrow.

ok, sorry, this is a bit more complicated than I thought and will take me a while

@  Peter Hutterer , thanks for working on this. I can wait :)

I finally got around to testing Qt with xf86-input-libinput and various tablets, and I see this too.

Sometimes when "jittery lines" have happened in the past, people have said that we're doing the coordinate conversion wrong here:

http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp#n1171

given a xXIDeviceEvent, we convert event_x and event_y from fixed 16.16 format to floating-point by simply dividing by 65536.0.  The alternate way might be to use axis valuators.  But it seems to me that using either xf86-input-wacom or xf86-input-evdev, I don't normally see jittery lines using this approach.  (But maybe sometimes one driver or the other has been buggy... not sure.  Krita users and developers complain about it from time to time, and usually I can't reproduce it the same way that they're complaining about.)  With xf86-input-libinput I definitely do see the jitters though, so it's good that you can too.  Good luck with the fix.

Do you think using event_x and event_y is the right way to do it?  Or should we rather do it like this: https://codereview.qt-project.org/#/c/110334/2/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp  Which way is do you think is more portable between all 3 drivers, and the least likely to ever see these jitters again?

I have an Intuos 3 with all the styli, Intuos Pro, Bamboo CTH-470, a couple of Genius and a Trust tablet for testing.  FWIW, those knockoffs don't work with xf86-input-libinput at all right now (it says it doesn't recognize them as tablets), whereas xf86-input-evdev works fine.  But that's a different bug.

BTW is this related to https://bugs.freedesktop.org/show_bug.cgi?id=92186 in any way?

afaict so far these jittery lines here are caused by libinput not doing any coordinate smoothing like the wacom driver does. The sensors aren't that accurate, so this causes the occasional movement. I have a patchset here that does the same 4-event averaging that xf86-input-wacom does and it seems to work fine - the patchset just needs to be tidied up more.

As for which fields to use: it must be driver independent, anything else is a bug. the valuators have the highest precision but are in device units, the events_x/y have the pre-formatted coordinates relative to the window. I'd recommend those anyway because it'll make the wayland integration easier (wayland only provides the event x/y equivalents).

ok, I have a branch available that should fix this problem, any testing would be much appreciated:
https://github.com/whot/libinput/tree/wip/tablet-wobbly-lines-v2

build instructions are available here:
https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html

Hi Peter

I tested the branch that you linked. My initial test run shows no sign of bent or wiggly lines. The strokes are smooth as butter.

Thank you for working on this and coming up with a patch so quickly.

I'll keep on testing for a 2-3 days while painting. I'll let you know if I encounter any things weird. I doubt it I will encounter anything though. 

Thanks once again

P.S. As a token of gratitude for fixing this, I can draw anything that you wish, feel free to email me with the description :)

https://lists.freedesktop.org/archives/wayland-devel/2017-March/033397.html

commit 411a3a4766144c93795c2bda9aa9f89a3602c896
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Mar 7 16:00:45 2017 +1000

    tablet: add axis smoothing

I;m having this exact issue under Manjaro Linux KDE 18.04. I've tested kernel version 4.19, 5,9, 5.1, 5.2, 5.3, all have wobbly lines. I tested this on Wacom Cintiq Pro 32 (DTH-3221). On the same machine, Wacom Intuos Pro (PTH-660) doesn't have this issue. The issue doesn't happen under Windows either. Can anyone take a look into this bug to see if there was a regression? Thank you!

After fiddling with the settings, I found the real problem lies with kcm-wacomtablet providing incorrect default settings:
Raw Sample Rate = 1
Suppress Rate = 0
While the correct default settings should be:
Raw Sample Rate = 4
Suppress Rate = 2
I will report to kcm-wacomtablet instead. Sorry for the false alarm!

(In reply to Tyson Tan from comment #16)
> I;m having this exact issue under Manjaro Linux KDE 18.04. I've tested
> kernel version 4.19, 5,9, 5.1, 5.2, 5.3, all have wobbly lines. I tested
> this on Wacom Cintiq Pro 32 (DTH-3221). On the same machine, Wacom Intuos
> Pro (PTH-660) doesn't have this issue. The issue doesn't happen under
> Windows either. Can anyone take a look into this bug to see if there was a
> regression? Thank you!