#333 startup anomaly

[Stanislav Vacl]

Hello,
on the notebook Thinkpad X61 Tablet I have installed Archlinux + OpenRC init. This is a serial device. xf86-input-wacom causes startup delay when X server starts. The delay is about 4 minutes. After that time X server starts normaly. In log is this period clearly visible. Without wacom driver X server starts normally. Where could it be wrong? I enclose a log of X server. 4.8.14 kernel.
thanks

[Jason Gerecke]

Do you use a static xorg.conf file or do you use the inputattach program? The X driver's serial code does not work as well and I'd recommend inputattach instead.

[Stanislav Vacl]

Thank you Jason for your answer. Currently I do not use any xorg.conf file. But if I try sudo inputattach -w8001 /dev/ttyS0 like decribed in arch wiki and then use startx problem still persists. If I try for example LinuxMint Live cd or ubuntu Live cd there is no problem with X start. Currently I am running kernel 4.8.14. Xorg 1.19.1 and xf86-input-wacom 0.34. On those cd is mostly kernel 4.8.xx or 4.4. branch Xorg 1.18 and wacom 0.33. From which version is serial code broken? Will be support enabled again?

[Jason Gerecke]

Apologies for my delay in responding...

It looks like the most recent updates to the w8001 kernel driver occurred in Linux 4.3, 4.5, 4.7, and 4.8. The most recent updates to the serial code in the X driver occurred in xf86-input-wacom 0.30.0 and 0.33.0. Based on what you've said, the only notable difference between whatever CD had Linux 4.8 and your current installation is the presence of Xorg 1.19 and (possibly) OpenRC init. There was a pretty major change to how Xorg handles input devices in 1.19, but I wouldn't think that it would cause symptoms like you experience. Its also possible that the CD used an init system that was able to start inputattach in parallel (whereas I believe OpenRC can't do parallel startup?), but the pen probably wouldn't work for those 4 minutes even if the rest of the system came up fast.

Can you check your /var/log/syslog to see if it contains any hints about what may be going wrong? You might also try using the isdv4-serial-debugger command to see if it is able to connect to the device more quickly or point out any problems. I'm not terribly familiar with the serial code, but perhaps your system is trying to use the wrong baud rate when using inputattach?

[Anonymous]

I've had this problem, too, for months, maybe close to a year. Here are some dumps that you may find useful:

Distro: Debian Stretch, fully updated
Kernel: Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux
xserver-xorg-input-wacom: 0.34.0-1 (removing this package eliminates the problem but deprives me of my tablet)

$ sudo grep "Using input driver" /var/log/Xorg.0.log
[    47.354] (II) Using input driver 'evdev' for 'Power Button'
[    47.381] (II) Using input driver 'evdev' for 'Fujitsu FUJ02E3'
[    47.382] (II) Using input driver 'evdev' for 'Video Bus'
[    47.382] (II) Using input driver 'evdev' for 'Fujitsu FUJ02B1'
[    47.384] (II) Using input driver 'evdev' for 'Fujitsu FUJ02BF'
[    47.384] (II) Using input driver 'evdev' for 'Power Button'
[    47.389] (II) Using input driver 'evdev' for 'CNF8248'
[    47.390] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[    47.445] (II) Using input driver 'synaptics' for 'AlpsPS/2 ALPS GlidePoint'
[    47.558] (II) Using input driver 'wacom' for 'Serial Wacom Tablet FUJ02e7'
[   547.663] (II) Using input driver 'evdev' for 'lircd-uinput'
[   547.677] (II) Using input driver 'wacom' for 'Serial Wacom Tablet FUJ02e7 eraser'
[   547.679] (II) Using input driver 'wacom' for 'Serial Wacom Tablet FUJ02e7 touch'

(as the OP mentioned, notice the 8 minute, 20 second gap between initial detection of the Wacom tablet and its full initialisation)

$ sudo grep EE /var/log/Xorg.0.log
[    43.439] (EE) Failed to load module "vesa" (module does not exist, 0)
[   547.661] (EE) Serial Wacom Tablet FUJ02e7 stylus: Invalid type 'cursor' for this device.
[   547.661] (EE) Serial Wacom Tablet FUJ02e7 stylus: Invalid type 'pad' for this device.
[  1362.154] (EE) BUG: triggered 'if (in_input_thread())'
[  1362.154] (EE) BUG: ../../../../os/io.c:656 in WriteToClient()
[  1362.154] (EE) ******** WriteToClient called from input thread *********
[  1362.154] (EE) 
[  1362.154] (EE) Backtrace:
[  1362.154] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4a) [0x556246c9046a]
[  1362.155] (EE) 1: /usr/lib/xorg/Xorg (WriteToClient+0x162) [0x556246c93aa2]
[  1362.155] (EE) 2: /usr/lib/xorg/Xorg (WriteEventsToClient+0x252) [0x556246b36aa2]
[  1362.155] (EE) 3: /usr/lib/xorg/Xorg (TryClientEvents+0x120) [0x556246b36c40]
[  1362.155] (EE) 4: /usr/lib/xorg/Xorg (0x556246ad7000+0x633aa) [0x556246b3a3aa]
[  1362.155] (EE) 5: /usr/lib/xorg/Xorg (DeliverEventsToWindow+0x1d7) [0x556246b3a697]
[  1362.155] (EE) 6: /usr/lib/xorg/Xorg (0x556246ad7000+0x146d69) [0x556246c1dd69]
[  1362.155] (EE) 7: /usr/lib/xorg/Xorg (0x556246ad7000+0x1526cf) [0x556246c296cf]
[  1362.155] (EE) 8: /usr/lib/xorg/Xorg (XIChangeDeviceProperty+0x358) [0x556246c2a088]
[  1362.155] (EE) 9: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0x10df9) [0x7f2162c1ddf9]
[  1362.155] (EE) 10: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0x7322) [0x7f2162c14322]
[  1362.155] (EE) 11: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0x8864) [0x7f2162c15864]
[  1362.155] (EE) 12: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0xab6d) [0x7f2162c17b6d]
[  1362.155] (EE) 13: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0x616b) [0x7f2162c1316b]
[  1362.155] (EE) 14: /usr/lib/xorg/modules/input/wacom_drv.so (0x7f2162c0d000+0x63a6) [0x7f2162c133a6]
[  1362.155] (EE) 15: /usr/lib/xorg/Xorg (0x556246ad7000+0x1bb5dc) [0x556246c925dc]
[  1362.155] (EE) 16: /usr/lib/xorg/Xorg (0x556246ad7000+0x1bdcd1) [0x556246c94cd1]
[  1362.155] (EE) 17: /usr/lib/xorg/Xorg (0x556246ad7000+0x1bb436) [0x556246c92436]
[  1362.155] (EE) 18: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f216b6ea000+0x7494) [0x7f216b6f1494]
[  1362.155] (EE) 19: /lib/x86_64-linux-gnu/libc.so.6 (clone+0x3f) [0x7f216b43493f]
[  1362.155] (EE) 
 *********

That backtrace goes into the log every time I try use the touchscreen and/or stylus - otherwise, it seems ot work normally. At current count, it repeats about 64 times.

My hypothesis is that something between the X driver and the kernel driver are getting into a fight and, after about 8 minutes, one of them wins out.

[Jason Gerecke]

We recently had a possible explanation for this issue submitted at https://github.com/linuxwacom/xf86-input-wacom/issues/8. If the driver is waiting 250 seconds (4 minutes, 10 seconds) for hardware, we would get the kinds of delays seen here. I should have a patch for testing available shortly.

[Anonymous]

This is excellent news! Since my Wacom installation could find neither the pad nor the cursor, it fits the facts that it spent 250 seconds trying to find each before giving up - or 500 in total. To test this hypothesis, is there a way for me to disable pad and cursor autodetection? If so, I can use this as a workaround until the patch is out.

[Stanislav Vacl]

Thak you guys. This is excelent news! Temporaly solution for Arch linux instalation is to downgrade xorg-server to 1.18.4, xorg-server-common 1.18.4, xf86-input-libinput 0.20 and xf86-input-wacom driver to 0.33 via pacman. But patch will be better :-)

[Jason Gerecke]

Looking more closely at this bug, the explanation offered on Github doesn't quite meet reality. I'm pretty sure at this point that this is actually a bug in the Xorg server; the xf86WaitForInput funtion that is mentioned takes a timeout in microseconds, but appears to now treat the value as being in milliseconds. This is almost certianly the source of the slowdown. I'll be submitting a patch to the xorg-devel list shortly...

[Jason Gerecke]

The attached patch has been sent to the xorg-devel list. It appears that Xorg 1.19 introduced a bug which causes the xf86WaitForInput function to sleep for 1000x longer than intended. Our driver calls this function several times durring the initlaization sequence of an serial ISDv4 tablet. The driver is programmed to wait for a varying amount of time in different circumstances, but in some cases it can be for 250 milliseconds. If those cases are what are going slow, the X server bug can result in a wait of up to 250 seconds (4 minutes, 10 seconds) instead.

Its possible that at least one instance of this 250 second delay manifesting itself is due to our driver initially choosing the wrong baud rate for communication. It may be possible to work around this issue by creating a file with the following contents and saving it to /etc/X11/xorg.conf.d/99-wacom-baudrate.conf

Section "InputClass"
    # Workaround for https://sourceforge.net/p/linuxwacom/bugs/333/
    # BaudRate should be either 38400 or 19200.
    Identifier "Wacom baudrate fix"
    MatchDriver "wacom"
    Option "BaudRate" "38400"
EndSection

After a reboot, the X server will hopefully boot faster. If not, try changing the baud rate to 19200 and rebooting again. Unfortunately, I can't say which is the correct speed for any particular tablet... Its also possible that neither will totally fix things and that there's a call to xf86WaitForInput elsewhere which still slows down the boot process. Hopefully the fix is accepted and works its way into distributions quickly.

[Anonymous]

Unfortunately, neither configuration of /etc/X11/xorg.conf.d/99-wacom-baudrate.conf worked on my machine. In fact, setting the baudrate to 19200 locked up my computer for over a half hour before I hard shut it down!

[Stanislav Vacl]

Same results. Setting baudrate to 19200 or 38400 locks computer for long time. Until I hard shut it down.

[Jason Gerecke]

Thanks for the feedback. I'll take another look through the code and see if there are other temporary workarounds I can suggest since that one clearly did not work. Stanislav's suggestion of temporarily downgrading the X server to 1.18 may also be an option if you can convince your package manager to do so.

The fix has been accepted into the X server, so we'll wait for it to make its way into an eventual release (hopefully as a 1.19.x in the coming weeks; if not, as 1.20 in the coming months).

[Jason Gerecke]

Fix has finally been released as part of xorg-server 1.19.4