Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-13 Thread Martin Pieuchot 
On 12/09/16(Mon) 21:14, Frank Groeneveld wrote:
> On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote:
> > 
> > I just committed your driver, with some tweaks in the manpage.
> 
> Great, thank you!
> 
> > > It is quite likely related to this discussion:
> > > 
> > > http://marc.info/?l=openbsd-misc=140529029513846=2
> > > http://marc.info/?l=openbsd-misc=140589215905202=2
> > > http://marc.info/?l=openbsd-misc=141676273919602=2
> > 
> > Indeed.  This is a common issue to all WSMOUSE_TYPE_TPANEL pointers.
> > 
> > If you're interested in fixing this problem you should look at X11
> > ws(4) driver.  If you can modify the driver and the wscons(4) layer
> > such that it isn't necessary to open a different node to calibrate
> > your device then plugging a device after starting a Xserver wouldn't
> > be a problem.
> 
> Thanks for the pointers, that is most probably the cause indeed. I'll
> try to dig into this. Is the solution you propose the best one, or would
> it also be possible to let the ws driver reopen the device on a failed
> read and fix it like that?

Reopening the device is the problem.  Because the question is when?  If
you can have a working solution for your tablet and a standard mouse
both using the mux, without sending any even to say "hey a new input
device is there, please do something", that would be perfect.

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-12 Thread Frank Groeneveld 
On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote:
> 
> I just committed your driver, with some tweaks in the manpage.

Great, thank you!

> > It is quite likely related to this discussion:
> > 
> > http://marc.info/?l=openbsd-misc=140529029513846=2
> > http://marc.info/?l=openbsd-misc=140589215905202=2
> > http://marc.info/?l=openbsd-misc=141676273919602=2
> 
> Indeed.  This is a common issue to all WSMOUSE_TYPE_TPANEL pointers.
> 
> If you're interested in fixing this problem you should look at X11
> ws(4) driver.  If you can modify the driver and the wscons(4) layer
> such that it isn't necessary to open a different node to calibrate
> your device then plugging a device after starting a Xserver wouldn't
> be a problem.

Thanks for the pointers, that is most probably the cause indeed. I'll
try to dig into this. Is the solution you propose the best one, or would
it also be possible to let the ws driver reopen the device on a failed
read and fix it like that?

Frank

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-12 Thread Martin Pieuchot 
On 11/09/16(Sun) 15:10, Mike Burns wrote:
> On 2016-09-11 16.14.44 +0200, Frank Groeneveld wrote:
> > I've also made some progress regarding the scaling bug. It seems the
> > device is not properly detached from Xorg when it is unplugged, because
> > the log starts getting spammed with loads of messages like this:
> > 
> > [   202.482] (EE) ws: wacom: read error Input/output error
> > 
> > When I create an xorg.conf that only contains the wsmouse device of the
> > Wacom tablet and disabled all other wsmouse devices,  I cannot controle
> > the device anymore after plugging it in again. Without the xorg.conf I
> > can control it, but with the wrong scale.
> > 
> > I think this difference is caused by the fact that the "all containing"
> > /dev/wsmouse is still passing data to Xorg for the Wacom device, but
> > the tablet specific /dev/wsmouse1 device is not. Switchting to a console
> > somehow forces Xorg to reopen the /dev/wsmouse1 device which results in
> > a working mouse pointer (or in good scaled mouse pointer movement in the
> > case of not using an xorg.conf file to disable other wsmouse devices).

I just committed your driver, with some tweaks in the manpage.

> > Does anybody see why the ws driver start to print these errors? Am I
> > missing an important call on detachment?
> 
> It is quite likely related to this discussion:
> 
> http://marc.info/?l=openbsd-misc=140529029513846=2
> http://marc.info/?l=openbsd-misc=140589215905202=2
> http://marc.info/?l=openbsd-misc=141676273919602=2

Indeed.  This is a common issue to all WSMOUSE_TYPE_TPANEL pointers.

If you're interested in fixing this problem you should look at X11
ws(4) driver.  If you can modify the driver and the wscons(4) layer
such that it isn't necessary to open a different node to calibrate
your device then plugging a device after starting a Xserver wouldn't
be a problem.

Cheers,
Martin

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-11 Thread Mike Burns 
On 2016-09-11 16.14.44 +0200, Frank Groeneveld wrote:
> I've also made some progress regarding the scaling bug. It seems the
> device is not properly detached from Xorg when it is unplugged, because
> the log starts getting spammed with loads of messages like this:
> 
> [   202.482] (EE) ws: wacom: read error Input/output error
> 
> When I create an xorg.conf that only contains the wsmouse device of the
> Wacom tablet and disabled all other wsmouse devices,  I cannot controle
> the device anymore after plugging it in again. Without the xorg.conf I
> can control it, but with the wrong scale.
> 
> I think this difference is caused by the fact that the "all containing"
> /dev/wsmouse is still passing data to Xorg for the Wacom device, but
> the tablet specific /dev/wsmouse1 device is not. Switchting to a console
> somehow forces Xorg to reopen the /dev/wsmouse1 device which results in
> a working mouse pointer (or in good scaled mouse pointer movement in the
> case of not using an xorg.conf file to disable other wsmouse devices).
> 
> Does anybody see why the ws driver start to print these errors? Am I
> missing an important call on detachment?

It is quite likely related to this discussion:

http://marc.info/?l=openbsd-misc=140529029513846=2
http://marc.info/?l=openbsd-misc=140589215905202=2
http://marc.info/?l=openbsd-misc=141676273919602=2

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-11 Thread Frank Groeneveld 
On Thu, Sep 08, 2016 at 07:44:33PM +0200, Ulf Brosziewski wrote:
> Maybe one day I'll get it right:
> s/wsmouse_input_sync()/wsmouse_input_sync(ms->sc_wsmousedev)/

Haha, you did get it right indeed. Attached my working updated patch,
with your suggested API usage. Looks cleaner like this.

I've also made some progress regarding the scaling bug. It seems the
device is not properly detached from Xorg when it is unplugged, because
the log starts getting spammed with loads of messages like this:

[   202.482] (EE) ws: wacom: read error Input/output error

When I create an xorg.conf that only contains the wsmouse device of the
Wacom tablet and disabled all other wsmouse devices,  I cannot controle
the device anymore after plugging it in again. Without the xorg.conf I
can control it, but with the wrong scale.

I think this difference is caused by the fact that the "all containing"
/dev/wsmouse is still passing data to Xorg for the Wacom device, but
the tablet specific /dev/wsmouse1 device is not. Switchting to a console
somehow forces Xorg to reopen the /dev/wsmouse1 device which results in
a working mouse pointer (or in good scaled mouse pointer movement in the
case of not using an xorg.conf file to disable other wsmouse devices).

Does anybody see why the ws driver start to print these errors? Am I
missing an important call on detachment?

Thanks.

Frank
Index: share/man/man4/uwacom.4
===
RCS file: share/man/man4/uwacom.4
diff -N share/man/man4/uwacom.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/uwacom.4 5 Sep 2016 18:36:32 -
@@ -0,0 +1,60 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2016 Frank Groeneveld 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: September 5 2016 $
+.Dt UWACOM 4
+.Os
+.Sh NAME
+.Nm uwacom
+.Nd Wacom USB tablets
+.Sh SYNOPSIS
+.Cd "uwacom*  at uhidev?"
+.Cd "wsmouse* at uwacom? mux 0"
+.Sh DESCRIPTION
+The
+.Nm
+driver provides basic support for Wacom USB tablets.
+Access to these devices is through the
+.Xr wscons 4
+framework.
+.Pp
+Absolute positioning of the mouse cursor can be done by hovering the pen above 
the tablet. Touching the tablet with the pen tip will emulate mouse button 0, 
while the two pen buttons will emulate button 1 and button 2.
+.Pp
+The
+.Nm
+driver supports the following Wacom tablets:
+.Pp
+.Bl -column "Intuos Draw" "Model Number" -offset 6n
+.It Em Name Ta Model Number
+.It Li Intuos Draw Ta CTL-490
+.Sh SEE ALSO
+.Xr uhidev 4 ,
+.Xr usb 4 ,
+.Xr wsmouse 4
+.Sh HISTORY
+The
+.Nm
+driver
+first appeared in
+.Ox 6.1 .
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An Frank Groeneveld fr...@frankgroeneveld.nl .
+.Sh BUGS
+To make axis scaling work correctly, the device should be plugged in when X 
starts. Advanced features such as pen tip pressure are not supported.
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.432
diff -u -p -r1.432 GENERIC
--- sys/arch/amd64/conf/GENERIC 4 Sep 2016 10:22:05 -   1.432
+++ sys/arch/amd64/conf/GENERIC 5 Sep 2016 18:36:32 -
@@ -244,6 +244,8 @@ umass*  at uhub?# USB Mass Storage devi
 ubcmtp*at uhub?# Broadcom USB trackpad
 wsmouse* at ubcmtp? mux 0
 uhidev*at uhub?# Human Interface Devices
+uwacom*at uhidev?  # USB Wacom tablet
+wsmouse* at uwacom? mux 0
 ums*   at uhidev?  # USB mouse
 wsmouse* at ums? mux 0
 uts*   at uhub?# USB touchscreen
Index: sys/dev/hid/hid.h
===
RCS file: /cvs/src/sys/dev/hid/hid.h,v
retrieving revision 1.4
diff -u -p -r1.4 hid.h
--- sys/dev/hid/hid.h   20 Jan 2016 01:26:00 -  1.4
+++ sys/dev/hid/hid.h   5 Sep 2016 18:36:32 -
@@ -127,6 +127,7 @@ int hid_is_collection(const void *, int,
 #define HUP_MICROSOFT  0xff00
 /* XXX compat */
 #define HUP_APPLE  0x00ff
+#define HUP_WACOM  0xff00
 
 /* Usages, Power Device */
 #define HUP_INAME  0x0001
Index: sys/dev/usb/files.usb

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-08 Thread Ulf Brosziewski 
Maybe one day I'll get it right:
s/wsmouse_input_sync()/wsmouse_input_sync(ms->sc_wsmousedev)/

On 09/07/2016 12:12 AM, Ulf Brosziewski wrote:
> Hi, I was a bit hasty, I should have mentioned that calling
> wsmouse_input_sync is required here. The equivalent of your
> code would would be this:
> 
> if (x != 0 || y != 0 || buttons != ms->sc_buttons) {
>   wsmouse_position(ms->sc_wsmousedev, x, y);
>   /* ignore proximity, it will cause invalid button 2 events */
>   if ((data[0] & 0xf0) != 0xc0)
>   wsmouse_buttons(ms->sc_wsmousedev, buttons);
>   wsmouse_input_sync();
> }
> 
> The WSMOUSE_INPUT macro - a substitute for the old wsmouse_input
> function - does include that call (see wsmousevar.h).
> 
> There is a set of functions for reporting input states:
> wsmouse_buttons, wsmouse_motion, wsmouse_position, wsmouse_touch,
> and wsmouse_mtstate (and the somewhat special wsmouse_set and
> wsmouse_mtframe). A driver can call them in any order, and it
> doesn't need to check whether there are deltas, wsmouse does
> this anyway. However, a frame must be finished by a call to
> wsmouse_input_sync. It is this function that generates the
> wscons events.
> 
> The new interface has been introduced in 6.0.
> 
> On 09/06/2016 09:00 PM, Frank Groeneveld wrote:
>> On Tue, Sep 06, 2016 at 02:19:28PM +0200, Ulf Brosziewski wrote:
>>> Just a remark on your use of the wsmouse interface (which isn't well
>>> known and documented yet): wsmouse_set is a function for uncommon
>>> cases. To report a pair of absolute coordinates use wsmouse_position,
>>> that is, instead of
>>> wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0);
>>> wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_Y, y, 0);
>>> you should use
>>> wsmouse_position(ms->sc_wsmousedev, x, y);
>>> Likewise, for reporting the button state there is
>>> wsmouse_buttons(ms->sc_wsmousedev, buttons);
>>> There is no need for the WSMOUSE_INPUT macro here.
>>
>> Seems like a cleaner API indeed, but those functions don't seem to work
>> for me. Both mouse movement and button reporting stop functioning when
>> replaced by those calls. How old is this API, might it be some outdated
>> sources on my side? Something else I'm doing wrong?
>>
>> Frank
>>
>>
> 
>

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-07 Thread Frank Groeneveld 
On Wed, Sep 07, 2016 at 12:12:43AM +0200, Ulf Brosziewski wrote:
> Hi, I was a bit hasty, I should have mentioned that calling
> wsmouse_input_sync is required here. The equivalent of your
> code would would be this:
> 
> if (x != 0 || y != 0 || buttons != ms->sc_buttons) {
>   wsmouse_position(ms->sc_wsmousedev, x, y);
>   /* ignore proximity, it will cause invalid button 2 events */
>   if ((data[0] & 0xf0) != 0xc0)
>   wsmouse_buttons(ms->sc_wsmousedev, buttons);
>   wsmouse_input_sync();
> }
> 
> The WSMOUSE_INPUT macro - a substitute for the old wsmouse_input
> function - does include that call (see wsmousevar.h).
> 
> There is a set of functions for reporting input states:
> wsmouse_buttons, wsmouse_motion, wsmouse_position, wsmouse_touch,
> and wsmouse_mtstate (and the somewhat special wsmouse_set and
> wsmouse_mtframe). A driver can call them in any order, and it
> doesn't need to check whether there are deltas, wsmouse does
> this anyway. However, a frame must be finished by a call to
> wsmouse_input_sync. It is this function that generates the
> wscons events.
> 
> The new interface has been introduced in 6.0.
> 

That explains, thanks you very much for the detailed reply. My sources
were less than a week old, so it will probably just work with the sync
call.

I'll probably send an updated diff when I've fixed the scaling issue.

Frank

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-06 Thread Frank Groeneveld 
On Tue, Sep 06, 2016 at 02:19:28PM +0200, Ulf Brosziewski wrote:
> Just a remark on your use of the wsmouse interface (which isn't well
> known and documented yet): wsmouse_set is a function for uncommon
> cases. To report a pair of absolute coordinates use wsmouse_position,
> that is, instead of
>   wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0);
>   wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_Y, y, 0);
> you should use
>   wsmouse_position(ms->sc_wsmousedev, x, y);
> Likewise, for reporting the button state there is
>   wsmouse_buttons(ms->sc_wsmousedev, buttons);
> There is no need for the WSMOUSE_INPUT macro here.

Seems like a cleaner API indeed, but those functions don't seem to work
for me. Both mouse movement and button reporting stop functioning when
replaced by those calls. How old is this API, might it be some outdated
sources on my side? Something else I'm doing wrong?

Frank

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-06 Thread Ulf Brosziewski 
Just a remark on your use of the wsmouse interface (which isn't well
known and documented yet): wsmouse_set is a function for uncommon
cases. To report a pair of absolute coordinates use wsmouse_position,
that is, instead of
wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0);
wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_Y, y, 0);
you should use
wsmouse_position(ms->sc_wsmousedev, x, y);
Likewise, for reporting the button state there is
wsmouse_buttons(ms->sc_wsmousedev, buttons);
There is no need for the WSMOUSE_INPUT macro here.


On 09/05/2016 09:04 PM, Frank Groeneveld wrote:
> On Sun, Sep 04, 2016 at 02:25:06PM +0200, Martin Pieuchot wrote:
>>> - One bug still left: when the device is attached after X has started,
>>>  it seems the scaling is done wrongly. I had this problem with the
>>>  hacked ums driver as well. Most of the time it is fixed by switching
>>>  between console and X.
> 
> Correction: the problem can only be fixed by making sure the device is
> plugged in before starting X. After suspend a restart of X is needed to
> make scaling work again.
> 
>>
>> This is a common problem for drivers needing calibration.  Does the X driver
>> opens your device through /dev/wsmouseN or does it uses the mux?
> 
> I think that's weird for this device tough: input is always report from
> zero till the maximum values in the driver. No matter how or when you
> attach it.
> I'm not sure how the X driver opens the device. I've based it off ums(4)
> mostly, so it will probably be the same as ums(4) does.
> 
>>> - Documentation is still absent, I'll gladly write it when you guys
>>>  apporve of the code I wrote.
>>
>> I'll be happy to do so, could you provide a man page for this driver?
> 
> Attached a new diff with documentation.
> 
>>> What do you guys think? Any comments or suggestions? Any ideas on how to
>>> attach to all three uhidevs?
>>
>> Yes, you have to match the device id.  uhidev(4) attaches to the 3 first
>> interfaces of your first configuration.  And you want a single piece of code
>> driving all these interfaces.  Do you have some documentation for the device
>> you're hacking on?  Do you know what you can do with these interfaces?  It's
>> important to know otherwise you
>> might spend as much work refactoring the driver to extend it than you
>> spent in the beginning.
> 
> Unfortunately I couldn't find any documentation except for the Linux
> device driver implementation (but it supports all kinds of Wacom
> tablets, so it isn't exactly readable).
> I've written this driver by using the broken device descriptor
> and reverse-engeneering with commands such as:
> 
> cat /dev/uhid6 | hexdump -e '9/1 "%02x " "\n"'
> 
> And just moving the pen and seeing which bytes change.
> 
> It seems only the first uhidev device actually reports inputs. The last
> uhidev device seems to have the most correct descriptor, but never
> reports any data. My guess is that it's there for Windows users without
> the driver: they can recognize the tablet as a reported generic mouse.
> 
> As far as I can understand the Linux driver, they only use the data from
> the reportid that my driver uses. For completeness I've attached lsusb
> output from a Linux computer as well.
> 
> Frank
>

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-04 Thread Martin Pieuchot 

On 09/03/16 20:15, Frank Groeneveld wrote:

On Wed, Aug 10, 2016 at 03:42:34PM +0200, Martin Pieuchot wrote:

I'd ignore it as a first step, then revisit this later.


Attached a first stab at a seperate driver. Some points of interest:

- I've decided against using a custom hid descriptor, but instead define
  the needed inputs in the driver. This seems more readable to me.


I agree.


- Driver attaches to one uhid, but there are three uhidev devices and
  numerous uhids in this device, including a non-working uhid that ums
  attaches to (ums0 in the attached dmesg output).


See below.


- One bug still left: when the device is attached after X has started,
  it seems the scaling is done wrongly. I had this problem with the
  hacked ums driver as well. Most of the time it is fixed by switching
  between console and X.


This is a common problem for drivers needing calibration.  Does the X 
driver opens your device through /dev/wsmouseN or does it uses the mux?



- Documentation is still absent, I'll gladly write it when you guys
  apporve of the code I wrote.


I'll be happy to do so, could you provide a man page for this driver?


What do you guys think? Any comments or suggestions? Any ideas on how to
attach to all three uhidevs?


Yes, you have to match the device id.  uhidev(4) attaches to the 3 first 
interfaces of your first configuration.  And you want a single piece of 
code driving all these interfaces.  Do you have some documentation for 
the device you're hacking on?  Do you know what you can do with these 
interfaces?  It's important to know otherwise you

might spend as much work refactoring the driver to extend it than you
spent in the beginning.

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-09-03 Thread Frank Groeneveld 
On Wed, Aug 10, 2016 at 03:42:34PM +0200, Martin Pieuchot wrote:
> I'd ignore it as a first step, then revisit this later.

Attached a first stab at a seperate driver. Some points of interest:

- I've decided against using a custom hid descriptor, but instead define
  the needed inputs in the driver. This seems more readable to me.
- Driver attaches to one uhid, but there are three uhidev devices and
  numerous uhids in this device, including a non-working uhid that ums 
  attaches to (ums0 in the attached dmesg output).
- One bug still left: when the device is attached after X has started,
  it seems the scaling is done wrongly. I had this problem with the
  hacked ums driver as well. Most of the time it is fixed by switching
  between console and X.
- Documentation is still absent, I'll gladly write it when you guys
  apporve of the code I wrote.

What do you guys think? Any comments or suggestions? Any ideas on how to
attach to all three uhidevs?

Thanks.

Frank
Index: hid/hid.h
===
RCS file: /cvs/src/sys/dev/hid/hid.h,v
retrieving revision 1.4
diff -u -p -r1.4 hid.h
--- hid/hid.h   20 Jan 2016 01:26:00 -  1.4
+++ hid/hid.h   3 Sep 2016 13:09:24 -
@@ -127,6 +127,7 @@ int hid_is_collection(const void *, int,
 #define HUP_MICROSOFT  0xff00
 /* XXX compat */
 #define HUP_APPLE  0x00ff
+#define HUP_WACOM  0xff00
 
 /* Usages, Power Device */
 #define HUP_INAME  0x0001
Index: usb/files.usb
===
RCS file: /cvs/src/sys/dev/usb/files.usb,v
retrieving revision 1.129
diff -u -p -r1.129 files.usb
--- usb/files.usb   27 Jun 2016 11:42:47 -  1.129
+++ usb/files.usb   3 Sep 2016 13:09:25 -
@@ -446,3 +446,8 @@ filedev/usb/uberry.cuberry
 device upd: hid
 attach upd at uhidbus
 file   dev/usb/upd.c   upd
+
+# Wacom tablets
+device uwacom: hid, hidms, wsmousedev
+attach uwacom at uhidbus
+file   dev/usb/uwacom.cuwacom
Index: usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.666
diff -u -p -r1.666 usbdevs
--- usb/usbdevs 1 Jun 2016 09:48:20 -   1.666
+++ usb/usbdevs 3 Sep 2016 13:09:25 -
@@ -4397,6 +4397,7 @@ product WACOM GRAPHIRE0x0010  Graphire
 product WACOM GRAPHIRE3_4X50x0013  Graphire3 4x5
 product WACOM GRAPHIRE4_4X50x0015  Graphire4 Classic A6
 product WACOM INTUOSA5 0x0021  Intuos A5
+product WACOM INTUOSS2 0x033b  Intuos S 2 (CTL-490)
 
 /* WAGO Kontakttechnik products */
 product WAGO SERVICECABLE  0x07a6  Service Cable 750-923
Index: usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.678
diff -u -p -r1.678 usbdevs.h
--- usb/usbdevs.h   1 Jun 2016 09:48:54 -   1.678
+++ usb/usbdevs.h   3 Sep 2016 13:09:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.678 2016/06/01 09:48:54 mglocker Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -4404,6 +4404,7 @@
 #defineUSB_PRODUCT_WACOM_GRAPHIRE3_4X5 0x0013  /* Graphire3 
4x5 */
 #defineUSB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015  /* Graphire4 
Classic A6 */
 #defineUSB_PRODUCT_WACOM_INTUOSA5  0x0021  /* Intuos A5 */
+#defineUSB_PRODUCT_WACOM_INTUOSS2  0x033b  /* Intuos S 2 
(CTL-490) */
 
 /* WAGO Kontakttechnik products */
 #defineUSB_PRODUCT_WAGO_SERVICECABLE   0x07a6  /* Service 
Cable 750-923 */
Index: usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.672
diff -u -p -r1.672 usbdevs_data.h
--- usb/usbdevs_data.h  1 Jun 2016 09:48:54 -   1.672
+++ usb/usbdevs_data.h  3 Sep 2016 13:09:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.672 2016/06/01 09:48:54 mglocker Exp $ 
*/
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -11208,6 +11208,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOSA5,
"Intuos A5",
+   },
+   {
+   USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOSS2,
+   "Intuos S 2 (CTL-490)",
},
{
USB_VENDOR_WAGO, USB_PRODUCT_WAGO_SERVICECABLE,
Index: usb/uwacom.c
===
RCS file: usb/uwacom.c
diff -N usb/uwacom.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ usb/uwacom.c3 Sep 2016 13:09:25 -
@@ -0,0 +1,233 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2016 Frank Groeneveld 
+ *
+ * Permission to use, copy, modify, and

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-10 Thread Martin Pieuchot 
On 08/10/16 13:46, Frank Groeneveld wrote:
> On Mon, Aug 08, 2016 at 02:31:41PM +0200, Martin Pieuchot wrote:
>>
>> Search for UHIDEV_CLAIM_ALLREPORTID, at least upd(4) uses it.
> 
> I've tried to implement a simple driver using this technique and it
> seems this can only be used to claim all report_ids under one uhidev
> device. The tablet acts as three though, with the usefull info being
> under the first and a non-working wsmouse attaches to the a report_id
> under the last uhidev.
> 
> Would it be possible to claims these as well? Or should I just make it
> work under the first uhidev and ignore the fact that a non-working
> wsmouse is attached?

I'd ignore it as a first step, then revisit this later.

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-10 Thread Frank Groeneveld 
On Mon, Aug 08, 2016 at 02:31:41PM +0200, Martin Pieuchot wrote:
> 
> Search for UHIDEV_CLAIM_ALLREPORTID, at least upd(4) uses it.

I've tried to implement a simple driver using this technique and it
seems this can only be used to claim all report_ids under one uhidev
device. The tablet acts as three though, with the usefull info being
under the first and a non-working wsmouse attaches to the a report_id
under the last uhidev.

Would it be possible to claims these as well? Or should I just make it
work under the first uhidev and ignore the fact that a non-working
wsmouse is attached?

Thanks again for your help.

Frank

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-08 Thread Martin Pieuchot 
On 08/08/16 13:31, Frank Groeneveld wrote:
> [...]
>> I afraid you'll need to match the two interfaces of your device,
>> something which is not trivial with the current framework.
> 
> Do you know of a driver that currently does this?

Search for UHIDEV_CLAIM_ALLREPORTID, at least upd(4) uses it.

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-08 Thread Frank Groeneveld 
On Mon, Aug 08, 2016 at 11:12:02AM +0200, Martin Pieuchot wrote:
> > ...
> > Is the attached patch acceptable? Or would it be better to write a
> > seperate driver, such as uwacom, that does the same as ums, except that
> > it doesn't call hidms_input, but implements that itself?
> 
> I believe that a new driver makes more sense.  Because if one wants to
> extend your work to fully support the drawing table it won't be able to
> do it in ums(4).

That's what I thought after building the current patch, thanks for
confirming this.

> I afraid you'll need to match the two interfaces of your device,
> something which is not trivial with the current framework.

Do you know of a driver that currently does this?

> Newer versions of libinput include some support for various Intuos
> devices, you might want to look at this if you haven't done it already.

Thanks for the hint, didn't know. I'll dig into this.

Frank

Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-08 Thread Martin Pieuchot 
On 08/07/16 19:30, Frank Groeneveld wrote:
> I recently acquired a new Wacom drawing tablet: an Intuos Draw, which
> seems to be called an Intuos S 2 internally. I couldn't get this tablet
> to work in OpenBSD. One of the HID descriptors describes a mouse, so
> ums(4) attaches to it, but no data is ever registered. After digging
> around in the Linux driver, it appears that the actual data is reported
> in a different descriptor, one that is (possibly on purpose) incorrect.
> 
> After writing a correct device descriptor I had to work around two other
> problems:
> 
> - X & Y data is reported in big endian format.
> - Mouse button 1 data is flakey, the linux driver uses pressure to work
>   around this.
> 
> To get the tablet to function correctly, I chose to implement quirks for
> this in hidms(4). Attached patch makes the tablet function with mouse
> movement and all three stylus events (tip touch and 2 buttons) without
> any needed configuration. This is enough functionality for for me, I
> just use it as a mouse replacement to avoid getting RSI.
> 
> Example dmesg output on attachment:
> 
> uhidev0 at uhub3 port 2 configuration 1 interface 0 "Wacom Co.,Ltd.
> Intuos PS" rev 2.00/1.00 addr 3
> uhidev0: iclass 3/0, 192 report ids
> ums0 at uhidev0 reportid 16: 3 buttons
> wsmouse1 at ums0 mux 0
> uhid0 at uhidev0 reportid 192: input=4, output=0, feature=0
> uhidev1 at uhub3 port 2 configuration 1 interface 1 "Wacom Co.,Ltd.
> Intuos PS" rev 2.00/1.00 addr 3
> uhidev1: iclass 3/0, 3 report ids
> uhid1 at uhidev1 reportid 2: input=63, output=0, feature=0
> uhid2 at uhidev1 reportid 3: input=63, output=0, feature=0
> uhidev2 at uhub3 port 2 configuration 1 interface 2 "Wacom Co.,Ltd.
> Intuos PS" rev 2.00/1.00 addr 3
> uhidev2: iclass 3/1, 1 report id
> ums1 at uhidev2 reportid 1: 5 buttons
> wsmouse2 at ums1 mux 0
> 
> The first tattached umse is the functioning one that is added by this
> patch.

Nice.

> Is the attached patch acceptable? Or would it be better to write a
> seperate driver, such as uwacom, that does the same as ums, except that
> it doesn't call hidms_input, but implements that itself?

I believe that a new driver makes more sense.  Because if one wants to
extend your work to fully support the drawing table it won't be able to
do it in ums(4).

I afraid you'll need to match the two interfaces of your device,
something which is not trivial with the current framework.

Newer versions of libinput include some support for various Intuos
devices, you might want to look at this if you haven't done it already.

Fix Wacom Intuos S 2 descriptor and make wsmouse work

2016-08-07 Thread Frank Groeneveld 
I recently acquired a new Wacom drawing tablet: an Intuos Draw, which
seems to be called an Intuos S 2 internally. I couldn't get this tablet
to work in OpenBSD. One of the HID descriptors describes a mouse, so
ums(4) attaches to it, but no data is ever registered. After digging
around in the Linux driver, it appears that the actual data is reported
in a different descriptor, one that is (possibly on purpose) incorrect.

After writing a correct device descriptor I had to work around two other
problems:

- X & Y data is reported in big endian format.
- Mouse button 1 data is flakey, the linux driver uses pressure to work
  around this.

To get the tablet to function correctly, I chose to implement quirks for
this in hidms(4). Attached patch makes the tablet function with mouse
movement and all three stylus events (tip touch and 2 buttons) without
any needed configuration. This is enough functionality for for me, I
just use it as a mouse replacement to avoid getting RSI.

Example dmesg output on attachment:

uhidev0 at uhub3 port 2 configuration 1 interface 0 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev0: iclass 3/0, 192 report ids
ums0 at uhidev0 reportid 16: 3 buttons
wsmouse1 at ums0 mux 0
uhid0 at uhidev0 reportid 192: input=4, output=0, feature=0
uhidev1 at uhub3 port 2 configuration 1 interface 1 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev1: iclass 3/0, 3 report ids
uhid1 at uhidev1 reportid 2: input=63, output=0, feature=0
uhid2 at uhidev1 reportid 3: input=63, output=0, feature=0
uhidev2 at uhub3 port 2 configuration 1 interface 2 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev2: iclass 3/1, 1 report id
ums1 at uhidev2 reportid 1: 5 buttons
wsmouse2 at ums1 mux 0

The first tattached umse is the functioning one that is added by this
patch.

Is the attached patch acceptable? Or would it be better to write a
seperate driver, such as uwacom, that does the same as ums, except that
it doesn't call hidms_input, but implements that itself?

Frank
Index: hid/hidms.c
===
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.3
diff -u -p -r1.3 hidms.c
--- hid/hidms.c 22 May 2016 22:06:11 -  1.3
+++ hid/hidms.c 2 Aug 2016 19:15:09 -
@@ -109,6 +109,9 @@ hidms_setup(struct device *self, struct 
return ENXIO;
}
 
+   hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS, HUD_TIP_PRESSURE),
+   id, hid_input, >sc_loc_tip_press, );
+
/*
 * Try to guess the Z activator: check WHEEL, TWHEEL, and Z,
 * in that order.
@@ -368,6 +371,11 @@ hidms_input(struct hidms *ms, uint8_t *d
dz = -dz;
if (ms->sc_flags & HIDMS_REVW)
dw = -dw;
+   if (ms->sc_flags & HIDMS_BE16_X)
+   dx = be16toh(dx);
+   if (ms->sc_flags & HIDMS_BE16_Y)
+   dy = be16toh(dy);
+
 
if (ms->sc_tsscale.swapxy && !ms->sc_rawmode) {
int tmp = dx;
@@ -388,6 +396,13 @@ hidms_input(struct hidms *ms, uint8_t *d
for (i = 0; i < ms->sc_num_buttons; i++)
if (hid_get_data(data, len, >sc_loc_btn[i]))
buttons |= (1 << HIDMS_BUT(i));
+
+   if (ms->sc_flags & HIDMS_USE_TIP_PRESS) {
+   if (hid_get_data(data, len, >sc_loc_tip_press) > 10)
+   buttons |= (1 << HIDMS_BUT(0));
+   else
+   buttons &= ~(1 << HIDMS_BUT(0));
+   }
 
if (dx != 0 || dy != 0 || dz != 0 || dw != 0 ||
buttons != ms->sc_buttons) {
Index: hid/hidmsvar.h
===
RCS file: /cvs/src/sys/dev/hid/hidmsvar.h,v
retrieving revision 1.1
diff -u -p -r1.1 hidmsvar.h
--- hid/hidmsvar.h  8 Jan 2016 15:54:13 -   1.1
+++ hid/hidmsvar.h  2 Aug 2016 19:15:09 -
@@ -43,18 +43,21 @@ struct tsscale {
 struct hidms {
int sc_enabled;
int sc_flags;   /* device configuration */
-#define HIDMS_SPUR_BUT_UP  0x001   /* spurious button up events */
-#define HIDMS_Z0x002   /* Z direction available */
-#define HIDMS_REVZ 0x004   /* Z-axis is reversed */
-#define HIDMS_W0x008   /* W direction available */
-#define HIDMS_REVW 0x010   /* W-axis is reversed */
-#define HIDMS_LEADINGBYTE  0x020   /* Unknown leading byte */
-#define HIDMS_ABSX 0x040   /* X-axis is absolute */
-#define HIDMS_ABSY 0x080   /* Y-axis is absolute */
-#define HIDMS_TIP  0x100   /* Tip switch on a digitiser pen */
-#define HIDMS_BARREL   0x200   /* Barrel switch on a digitiser pen */
-#define HIDMS_ERASER   0x400   /* Eraser switch on a digitiser pen */
-#define HIDMS_MS_BAD_CLASS 0x800   /* Mouse doesn't identify properly */
+#define HIDMS_SPUR_BUT_UP  0x0001  /* spurious button up events */
+#define