Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91715

Bug#1126911: linux-image-6.12.63+deb13-amd64: wacom_serial4 doesn't work. Probe fails with error -1.

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Some additional info and a hacky workaround along with suggestions for a 
proper fix,


Problem still exists in linux-image-6.12.73+deb13-amd64.

I wrote a patch to add the model detection logic from wacom_serial4 into 
inputattach's wacom_iv_init() function. 
(joystick-1.8.1/utils/inputattach.c:L637.) Adapting it to use the 
write() call instead of serio_write(), and to output the result as a 
printf() to the console. I then ran that modified version of inputattach 
on my bare metal host machine. This resulted in the correct tablet model 
being detected and written to the console by inputattach. From that 
we've revealed two things:


1) The kernel's command definitions are correct for this device. (Wacom 
Digitizer II in my case)

2) Bare metal usermode can communicate with the device just fine, but 
the driver in kernel mode does _not_.


To confirm that, I wrote a patch for wacom_serial4 to add some 
additional dev_info() / dev_err() / dev_dbg() calls into it's error 
codepaths during wacom_connect(), wacom_setup(), and 
wacom_send_and_wait(). So that we could see exactly where the error was 
occurring. The result was that the -1 error was being returned by the 
serio_write() call at drivers/input/tablet/wacom_serial4.c:L431. Which 
was triggered by the first attempt at sending a command to the device 
from the kernel module. (REQUEST_MODEL_AND_ROM_VERSION 
at drivers/input/tablet/wacom_serial4.c:L510.) According to the header 
for that inline function, serio_write() can fail if the given serio 
structure has a NULL write fp member, so I altered the patch to test for 
that, but it revealed that the structure's write fp member was defined 
at the time of the error.


The _actual_ failure is due to the Keyspan USB serial port driver being 
written to by wacom_serial4, before it has had the chance to send the 
urb data to the device via it's relevant *_outdat_callback() function. 
(In my specific case the usa2x_outdat_callback() function.) If 
wacom_serial4 calls serio_write() in rapid succession before the 
relevant *_outdat_callback() function can be called, then serio_write() 
will always return failure during subsequent calls when using that UART 
until the *_outdat_callback() function completes.


Unfortunately, there is seemingly no mechanism for serio to report when 
the UART is busy waiting for an output to occur. I.e. No completion 
object to wait on nor event to look for. Nor is there seemingly any 
documentation about what the expectations of returning from 
serio_write() makes of the underlying UART driver. I.e. Should the 
underlying UART driver be ready to accept more data from the caller once 
serio_write() returns? Or is it the responsibility of the caller to 
resend the data if the underlying UART driver is still busy with 
servicing a previous call to serio_write() that has returned to the 
caller? The use of similar preexisting code elsewhere in the kernel to 
wacom_serial4's call to serio_write() suggests the former, or at the 
very least, I would assume any such similar code used in conjunction 
with a Keyspan USB serial adapter to have similar issues as wacom_serial4.


As an additional setback for a proper fix, the Wacom Digitizer II with 
ROM version 1.4, (the only device I have to test), doesn't echo back 
sent bytes to the host. So we cannot use the interrupt handler as a 
workaround for the lack of a write sync mechanism in the kernel. As the 
handler is not invoked when writing individual bytes to the tablet 
during the wacom_send() call.


Due to the above limitations, the attached patch for wacom_serial4 is a 
hack if there's ever been one. A simple delay introduced into the 
wacom_serial4 driver during sending to help prevent failures while 
sending the initial detection and setup cmds. (Along with some extra 
logging and clean up to make it easier to detect problems in the 
future.) This was enough to get the device to work on my Debian 13 
system, and allowed me to use GIMP with my Digitizer II successfully.


A proper fix would need official documentation from the kernel 
developers on what the requirements of calls to serio_write() are on 
UART drivers, and then either a write sync primitive for users of serio 
to wait on after calls to serio_write(), or some official extension of 
serio's API that will flush the underlying UART driver's write callback 
so it's ready for new data immediately upon return to the caller. (Maybe 
something like "serio_write_and_flush()"?)


Have a good Day!

-Patrick Hibbs

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#1126911: linux-image-6.12.63+deb13-amd64: wacom_serial4 doesn't work. Probe fails with error -1. Patrick Hibbs <hibbsncc1701@gmail.com> - 2026-02-03 22:10 +0100
  Bug#1126911: linux-image-6.12.63+deb13-amd64: wacom_serial4 doesn't work. Probe fails with error -1. Patrick Hibbs <hibbsncc1701@gmail.com> - 2026-03-17 10:30 +0100

csiph-web