[Qemu-devel] [PATCH] [RFC] usb-wacom

[Qemu-devel] [PATCH] [RFC] usb-wacom

[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/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.

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[Anthony Liguori]

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

François Revol wrote:
> 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.
>
>
>   

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[François Revol]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

> 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.

> François Revol wrote:
> > 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 ?


[-- Attachment #2: qemu-usb-wacom-for-haiku.diff.txt --]
[-- Type: text/plain, Size: 1567 bytes --]

Index: hw/usb-wacom.c
===================================================================
--- hw/usb-wacom.c	(révision 5002)
+++ hw/usb-wacom.c	(copie de travail)
@@ -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;
     }
 

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[Jamie Lokier]

François Revol wrote:
> 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.

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

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[François Revol]

> > 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.

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[Jamie Lokier]

François Revol wrote:
> > > 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

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[François Revol]

> François Revol wrote:
> > > > 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?

Well not random, it would just stay on the same position until next
touch, just like with touch screens.

François.

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[andrzej zaborowski]

Hiya,

2008/8/14 François Revol <revol@free.fr>:
> 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.

>
> 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.

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).

> 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

Re: [Qemu-devel] [PATCH] [RFC] usb-wacom

[François Revol]

> 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.

> > 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.

> > 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.