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!