usb-wacom
RFC PATCH 1/1 usb-wacom
Hi there.
We use QEMU a lot to debug Haiku, http://haiku-os.org/
I also wrote a little php script that use it to demo images online, serving a VNC java applet to connect to it with VNC.
http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.php
It's a bit like what live.OSZoo does, but simpler.
To accomodate the VNC setup, I tried to use the usb tablet emulation. It turns out Haiku has a driver for Wacom tablets:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/input/wacom
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacom
However, it didn't really work very well with qemu's usb-wacom code.
First, mouse stayed in the top-left corner... Seems coords were set to 0,0 when no button is pressed, which is wrong, most tablets actually sense the stylus even when it's not yet touching the surface.
Also, coords were wrong.
Our driver takes the pos from the hardware, and scales them from model- dependant hardcoded max values:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacom/TabletDevice.cpp#L115
down to [0.0f, 1.0f], which represents the whole screen. Since QEMU reports absolute mouse position scaled from screen size to INT16_MAX this didn't really work.
Now, I'm not sure those max values are correct for all Penpartner devices, or if they were calibrated on a specific item.
Best would be to actually read them from the HID descriptor, but QEMU doesn't provide one, and I read some penpartner tablets actually have wrong descriptors anyway.
Finaly, I fixed button handling according to our driver, not sure all drivers handle them the same. pressure indicates left button, and a flag tells about right one. I mapped middle button to the eraser to at least be useful in tablet-aware software though I'm not sure it's the best way.
And... oh well seems we don't need to tell we have a contact, the driver assumes it always for penpartner so it seems correct.
I left debug macro I used just in case.
http://revolf.free.fr/beos/patches/qemu-usb-wacom-for-haiku.diff.txt
Now at least it works perfectly with our driver, appart from high cpu usage but that's surely be fixed by polling less often.
Comments ?
François.
Hi Francois,
Can you please send the patch to the mailing list attached as a text/plain attachment or inlined. Then we can review and possibly commit it.
Thanks,
Anthony Liguori
Quoted 40 lines · François Revol
Hi there.
We use QEMU a lot to debug Haiku, http://haiku-os.org/
I also wrote a little php script that use it to demo images online, serving a VNC java applet to connect to it with VNC.
http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.php
It's a bit like what live.OSZoo does, but simpler.To accomodate the VNC setup, I tried to use the usb tablet emulation. It turns out Haiku has a driver for Wacom tablets:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/input/wacom
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacomHowever, it didn't really work very well with qemu's usb-wacom code.
First, mouse stayed in the top-left corner... Seems coords were set to 0,0 when no button is pressed, which is wrong, most tablets actually sense the stylus even when it's not yet touching the surface.
Also, coords were wrong.
Our driver takes the pos from the hardware, and scales them from model-
dependant hardcoded max values:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacom/TabletDevice.cpp#L115
down to [0.0f, 1.0f], which represents the whole screen.
Since QEMU reports absolute mouse position scaled from screen size toINT16_MAXthis didn't really work.
Now, I'm not sure those max values are correct for all Penpartner devices, or if they were calibrated on a specific item.
Best would be to actually read them from the HID descriptor, but QEMU doesn't provide one, and I read some penpartner tablets actually have wrong descriptors anyway.Finaly, I fixed button handling according to our driver, not sure all drivers handle them the same. pressure indicates left button, and a flag tells about right one. I mapped middle button to the eraser to at least be useful in tablet-aware software though I'm not sure it's the best way.
And... oh well seems we don't need to tell we have a contact, the driver assumes it always for penpartner so it seems correct.
I left debug macro I used just in case.
http://revolf.free.fr/beos/patches/qemu-usb-wacom-for-haiku.diff.txt
Now at least it works perfectly with our driver, appart from high cpu usage but that's surely be fixed by polling less often.
Comments ?
François.
Quoted 3 lines
Can you please send the patch to the mailing list attached as a text/plain attachment or inlined. Then we can review and possibly commit it.
Sorry, not used to this ml.
Here it is.
Btw, you top-posted ;)
François.
Quoted 55 lines
Quoted 54 lines · François Revol
Hi there.
We use QEMU a lot to debug Haiku, http://haiku-os.org/
I also wrote a little php script that use it to demo images online, serving a VNC java applet to connect to it with VNC.
http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.phpQuoted 1 line
Quoted 1 line
It's a bit like what live.OSZoo does, but simpler.
To accomodate the VNC setup, I tried to use the usb tablet emulation.
It turns out Haiku has a driver for Wacom tablets:http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/input/wacom
Quoted 2 lines
However, it didn't really work very well with qemu's usb-wacom code.
First, mouse stayed in the top-left corner... Seems coords were set to
0,0 when no button is pressed, which is wrong, most tablets actually
sense the stylus even when it's not yet touching the surface.Also, coords were wrong.
Our driver takes the pos from the hardware, and scales them from model-
dependant hardcoded max values:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacom/TabletDevice.cpp#L115Quoted 1 line
Quoted 1 line
down to [0.0f, 1.0f], which represents the whole screen.
Since QEMU reports absolute mouse position scaled from screen size to
INT16_MAXthis didn't really work.
Now, I'm not sure those max values are correct for all Penpartner devices, or if they were calibrated on a specific item. Best would be to actually read them from the HID descriptor, but QEMU
doesn't provide one, and I read some penpartner tablets actually have
wrong descriptors anyway.Finaly, I fixed button handling according to our driver, not sure all
drivers handle them the same. pressure indicates left button, and a flag tells about right one. I mapped middle button to the eraser to at
least be useful in tablet-aware software though I'm not sure it's the
best way.And... oh well seems we don't need to tell we have a contact, the driver assumes it always for penpartner so it seems correct.
I left debug macro I used just in case.
Quoted 7 lines
Quoted 7 lines
http://revolf.free.fr/beos/patches/qemu-usb-wacom-for-haiku.diff.txt
Quoted 1 line
Quoted 1 line
Now at least it works perfectly with our driver, appart from high cpu
usage but that's surely be fixed by polling less often.Comments ?
usb-wacom.c +20 -14
@@ -29,6 +29,16 @@#include "console.h" #include "usb.h" +/* debug usb-wacom */ +//#define DEBUG_USB_WACOM + +#ifdef DEBUG_USB_WACOM +#define DPRINTF(fmt, args...) \ +do { printf("usb-wacom: " fmt , ##args); } while (0) +#else +#define DPRINTF(fmt, args...) +#endif +/* Interface requests */ #define WACOM_GET_REPORT 0x2101#define WACOM_SET_REPORT 0x2109
@@ -132,8 +142,8 @@ {USBWacomState *s = opaque; - s->x = x; - s->y = y; + s->x = (x *5040 /0x7FFF ); + s->y = (y *3780 /0x7FFF ); s->dz += dz; s->buttons_state = buttons_state; }
@@ -199,26 +209,22 @@if (s->buttons_state &MOUSE_EVENT_LBUTTON ) b |=0x01 ;if (s->buttons_state &MOUSE_EVENT_RBUTTON ) - b |=0x02 ; + b |=0x40 ;if (s->buttons_state &MOUSE_EVENT_MBUTTON ) - b |=0x04 ; + b |=0x20 ;/* eraser */ if (len <7 )return 0 ; buf[0 ] = s->mode; - buf[5 ] =0x00 ; -if (b) { - buf[1 ] = s->x &0xff ; - buf[2 ] = s->x >>8 ; - buf[3 ] = s->y &0xff ; - buf[4 ] = s->y >>8 ; + buf[5 ] =0x00 | (b &0xf0 ); + buf[1 ] = s->x &0xff ; + buf[2 ] = s->x >>8 ; + buf[3 ] = s->y &0xff ; + buf[4 ] = s->y >>8 ; +if (b &0x3f ) { buf[6 ] =0 ; }else { - buf[1 ] =0 ; - buf[2 ] =0 ; - buf[3 ] =0 ; - buf[4 ] =0 ; buf[6 ] = (unsigned char )-127 ; }
Quoted 10 lines · François Revol
Hi there.
We use QEMU a lot to debug Haiku, http://haiku-os.org/
I also wrote a little php script that use it to demo images online, serving a VNC java applet to connect to it with VNC.
http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.php
It's a bit like what live.OSZoo does, but simpler.To accomodate the VNC setup, I tried to use the usb tablet emulation. It turns out Haiku has a driver for Wacom tablets:
Quoted 8 lines
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/input/wacom
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacomHowever, it didn't really work very well with qemu's usb-wacom code.
First, mouse stayed in the top-left corner... Seems coords were set to 0,0 when no button is pressed, which is wrong, most tablets actually sense the stylus even when it's not yet touching the surface.
I see similar problems with Windows Server 2003 guest and the USB tablet emulation. The pointer jumps about randomly, so it's not usable. It works fine with Windows XP guest.
-- Jamie
Hiya,
2008/8/14 François Revol <[email protected]>:
Quoted 3 lines
First, mouse stayed in the top-left corner... Seems coords were set to 0,0 when no button is pressed, which is wrong, most tablets actually sense the stylus even when it's not yet touching the surface.
The wacom-tablet was implemented to emulate a touchscreen originally, because Linux doesn't by default have drivers for any hotpluggable touchscreen. Reporting 0,0 when not touching allows the emulation to be used with tslib. With a real tablet the stylus can also be too far above the surface for the coords to be avilable, but I don't know what coords are being reported then.
Quoted 10 lines
Also, coords were wrong.
Our driver takes the pos from the hardware, and scales them from model- dependant hardcoded max values:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/input_server/devices/wacom/TabletDevice.cpp#L115
down to [0.0f, 1.0f], which represents the whole screen. Since QEMU reports absolute mouse position scaled from screen size toINT16_MAXthis didn't really work.
Now, I'm not sure those max values are correct for all Penpartner devices, or if they were calibrated on a specific item.
I'm don't know either I'm afraid, for my use case it didn't matter because tslib will calibrate the input anyway. It may be useful adding the correct HID descriptors (I though we already had them).
Quoted 9 lines
Best would be to actually read them from the HID descriptor, but QEMU doesn't provide one, and I read some penpartner tablets actually have wrong descriptors anyway.
Finaly, I fixed button handling according to our driver, not sure all drivers handle them the same. pressure indicates left button, and a flag tells about right one. I mapped middle button to the eraser to at least be useful in tablet-aware software though I'm not sure it's the best way.
I'll check if this works with Linux also, when I get a chance. I didn't look at your patch yet as I'm away form my desktop
Cheers
Quoted 9 lines
Quoted 5 lines
First, mouse stayed in the top-left corner... Seems coords were set to
0,0 when no button is pressed, which is wrong, most tablets actually
sense the stylus even when it's not yet touching the surface.I see similar problems with Windows Server 2003 guest and the USB tablet emulation. The pointer jumps about randomly, so it's not usable. It works fine with Windows XP guest.
XP likely disregards mouse up packets and caches the last position.
François.
Quoted 8 lines
The wacom-tablet was implemented to emulate a touchscreen originally, because Linux doesn't by default have drivers for any hotpluggable touchscreen. Reporting 0,0 when not touching allows the emulation to be used with tslib. With a real tablet the stylus can also be too far
above the surface for the coords to be avilable, but I don't know what
coords are being reported then.
I don't either, but it actually depends on the model, and the penpartner doesn't seem to repport if it's in range or not. See hasContact variable in the Haiku driver is hardcoded for it. Which means it should always send valid coords, likely the last known ones, else the Haiku driver would also cause problems with real hardware, and would have been fixed to cache.
Quoted 6 lines
Quoted 2 lines
Now, I'm not sure those max values are correct for all Penpartner devices, or if they were calibrated on a specific item.
I'm don't know either I'm afraid, for my use case it didn't matter because tslib will calibrate the input anyway. It may be useful adding the correct HID descriptors (I though we already had them).
They are present in the generic usb-tablet emulation OTH. I'll try to ask someone who knows about those values.
Quoted 11 lines
Quoted 8 lines
Finaly, I fixed button handling according to our driver, not sure all
drivers handle them the same. pressure indicates left button, and a flag tells about right one. I mapped middle button to the eraser to at
least be useful in tablet-aware software though I'm not sure it's the
best way.I'll check if this works with Linux also, when I get a chance. I didn't look at your patch yet as I'm away form my desktop
Thanks.
François.
Quoted 11 lines · François Revol
Quoted 9 lines
Quoted 5 lines
First, mouse stayed in the top-left corner... Seems coords were set to
0,0 when no button is pressed, which is wrong, most tablets actually
sense the stylus even when it's not yet touching the surface.I see similar problems with Windows Server 2003 guest and the USB tablet emulation. The pointer jumps about randomly, so it's not usable. It works fine with Windows XP guest.
XP likely disregards mouse up packets and caches the last position.
Would caching the last position cause the mouse to jump all over the screen from frame to frame (no intermediate motion) as if it's reading random absolute coordinates?
-- Jamie
Quoted 12 lines
Quoted 11 lines · François Revol
Quoted 10 lines
Quoted 6 lines
First, mouse stayed in the top-left corner... Seems coords were set
to
0,0 when no button is pressed, which is wrong, most tablets actually
sense the stylus even when it's not yet touching the surface.I see similar problems with Windows Server 2003 guest and the USB tablet emulation. The pointer jumps about randomly, so it's not usable. It works fine with Windows XP guest.
Quoted 6 lines
Quoted 1 line
XP likely disregards mouse up packets and caches the last position.
Would caching the last position cause the mouse to jump all over the screen from frame to frame (no intermediate motion) as if it's reading
random absolute coordinates?
Well not random, it would just stay on the same position until next touch, just like with touch screens.
François.