issues with graphic tablet

[freeasinbear]

Qubes version: 3.2

Affected VMs: dom0, fedora and debian

Expected behavior: Graphic tablet to work after being connected to dom0 or when passed to another VM via qvm-usb

Actual behavior: The tablet gets recognized and tthe light blinks when writing (like it's recognizing that the tablet is sending input), but the mouse won't move. This happens both if I install the device in dom0 or in any other Template/StandaloneVM

Steps to reproduce the behavior:
(I add that reboots have been tried for both operations, without success)
On dom0/fedora:

• install kernel-devel;
• Install the digimend drivers from source (https://github.com/DIGImend/digimend-kernel-drivers);
• Connect the device

On Debian:

• install latest kernel image (4.9.0-2) with headers and activate it as described here (https://www.qubes-os.org/doc/managing-vm-kernel/#installing-kernel-in-debian-vm);
• Install digimend drivers from source;
• Connect the device and pass it to the debian VM with qvm-usb -a

General notes: Everything was working fine in my previous Debian distro (not with qubes), so we are sure there is nothing wrong with the drivers, the kernel image nor my tablet. I also tried giving the tablet mouse input from dom0 as described here (https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-mouse), but it doesn't work.

Maybe this is not a bug, but only an undocumented issue. I hope we can find a solution for other people in my same situation that for now have to rely on less secure distros to use devices like that.

[marmarek]

This is a tricky thing. Short answer: probably not implemented feature.

There are few possible ways to approach this:

1. Assign the whole device directly to the target VM, for example using qvm-usb or assigning the whole USB controller. This in theory should work, but in practice there will be few problems:

   • mouse cursor (drawn by dom0) will not follow tablet actions, which may be confusing
   • there may be some weird interactions between table actions and mouse actions - for example clicking not where mouse is visible, but where it's moved by tablet

2. Connecting the device to dom0 (having USB controller in dom0), or using input-proxy to pass it there. This is probably better approach, especially the second option, but it's currently not implemented:

   • input-proxy do not support tablet devices - this in theory should be easy (a matter adding proper metadata - min/max - to the protocol handshake, and filtering events based on this info)
   • gui virtualization do not support advanced input data, like pressure force, angle etc; this means even if dom0 will know this data, VM will not be able to use it

From your report, I understand that the first method does not work at all for you, right?

[marmarek]

This is a tricky thing. Short answer: probably not implemented feature.

There are few possible ways to approach this:

1. Assign the whole device directly to the target VM, for example using qvm-usb or assigning the whole USB controller. This in theory should work, but in practice there will be few problems:

   • mouse cursor (drawn by dom0) will not follow tablet actions, which may be confusing
   • there may be some weird interactions between table actions and mouse actions - for example clicking not where mouse is visible, but where it's moved by tablet

2. Connecting the device to dom0 (having USB controller in dom0), or using input-proxy to pass it there. This is probably better approach, especially the second option, but it's currently not implemented:

   • input-proxy do not support tablet devices - this in theory should be easy (a matter adding proper metadata - min/max - to the protocol handshake, and filtering events based on this info)
   • gui virtualization do not support advanced input data, like pressure force, angle etc; this means even if dom0 will know this data, VM will not be able to use it

From your report, I understand that the first method does not work at all for you, right?

[freeasinbear]

Yeah right, and neither with the second method, by connecting the device directly to dom0, that gives me the same result (led turning on while writing something, but no output/mouse movement), which is probably related to:

• gui virtualization do not support advanced input data, like pressure force, angle etc; this means even if dom0 will know this data, VM will not be able to use it

[freeasinbear]

Yeah right, and neither with the second method, by connecting the device directly to dom0, that gives me the same result (led turning on while writing something, but no output/mouse movement), which is probably related to:

• gui virtualization do not support advanced input data, like pressure force, angle etc; this means even if dom0 will know this data, VM will not be able to use it

[evadogstar]

When I was on Qubes without sys-usb Wacom works for me (only cursor movement and clicks). Hope this functions will be available at input proxy. It's good point to start from (without pressure, angel etc for start is ok and easy to add).

[evadogstar]

When I was on Qubes without sys-usb Wacom works for me (only cursor movement and clicks). Hope this functions will be available at input proxy. It's good point to start from (without pressure, angel etc for start is ok and easy to add).

[marmarek]

Related: #2281 - it wouldn't have pressure etc available for the VM, but position and clicks should work.

[marmarek]

Related: #2281 - it wouldn't have pressure etc available for the VM, but position and clicks should work.