Further to this thread (http://sourceforge.net/mailarchive/message.php?msg_id=31884990):
My previous post focused on HID_QUIRK_MULTI_INPUT, which splits the tabletinto multiple devices, one of which (almost) works as a pointer device. The main problem with MULTI_INPUT is that this pointer device has no pressure information. Maybe that's easy to fix. However, I've figured out some more information regarding the tablet without the quirk applied, which I will describe in the rest of this post.
AFAICS, the reason that the pen doesn't drive the cursor is that the ABS_X and ABS_Y channels are being reported to evdev as ABS_Z and ABS_RX. Others have had similar problems. This thread seems very relevant, with code snippets: https://bugzilla.redhat.com/show_bug.cgi?id=473144
(especially comments 11, 28 and 42). See also http://email@example.com/msg09730.html
. The gist of these posts is that the device in question registered two different sets of axes. The first two axes took up channels ABS_X and ABS_Y, leaving only ABS_Z and ABS_RX for the true axes. It's worth noting that ABS_PRESSURE and other messages seem to be handled correctly.
In the present case (of the UC-LOGIC TWHA60), the false axes described in the HID header claim to have resolution 40000x25000. The working axes claim 2048x2048. IIRC, there is some known weirdness on this tablet regarding the activation of a proprietary mode with enhanced resolution. If this enhanced mode is not being activated then even after we solve the axis problem, there may be more work to do. Perhaps that should take precedence?
Apologies for the lack of copy/pasted debug info in this post. Will provide it either today or tomorrow, so you can get it straight from the horse's mouth (not interpreted through the mind of a newbie :) ). If I haven't updated in the mean-time, please feel free to ask for specific read-outs!
It's worth noting that I now have access to a Windows machine, so could capture Windows USB traffic if that sounds useful.