Wacom Bamboo Fun (small) doesn't work

[HaiColon]

I tried out a "Wacom Bamboo Fun small" graphics tablet on Haiku. It doesn't work at all, the mouse doesn't move when I move the pen over the tablet. There is an error printed in the syslog (see attachment).

If there is anything I can do to help with this, like trying some things out, just tell me what to do.

[HaiColon]

Additional info:

Vendor ID: 056a Device ID: 0017

listusb output: 056a:0017 /dev/bus/usb/0/0 "Wacom Co.,Ltd." "CTE-450" ver. 0116

[HaiColon]

I felt adventurous and tried changing the source code myself to add my Wacom tablet by using maxX and maxY values for my graphics tablet that I found on the internet. Well, the tablet does react now to the pen, left and right clicking works, but the mouse cursor stays in the top left corner, jiggling around from left to right, but never more than 2 cm to the right and not down at all. And after about a minute my mouse stops working until I unplug the Wacom tablet (that's reproducible, happened every time I tried).

I thought I'd mention this because this looks to me like this could be a bug. As far as I know this should have made the tablet work but then again, I don't even know what those maxX and maxY values are for (resolution of the active space on the tablet in pixels?) and although I did find some of those values that are defined in the Haiku Wacom driver on the internet for some of the models, some others where slightly different in Haiku so maybe Wacom tablets in Haiku need some special values here that are specific to Haiku and that's why it didn't work.

Well, I hope this info helps ;)

[idefix]

The problem is that control transfer 2 fails. This prevents the tablet to go into 'Wacom'-mode, causing the behaviour you see.

As I described in ticket:4192, the Linux driver tries control transfer 2 five times before giving up, because some tablets don't pick it up the first time.

[idefix]

I've created a patch​ that will try control transfer 2 five times before giving up.

Could you apply the patch and post the relevant syslog-output?

[idefix]

(patch) try setting the tablet to 'Wacom'-mode five times before giving up

[bga]

I also have a Bamboo (although not the Fun version) and I tried this patch but it did not make any difference. here is my syslog:

2009-09-24 07:34:19 KERN: usb hub 64: port 2: new device connected
2009-09-24 07:34:20 KERN: wacom: add_device() - wacom detected
2009-09-24 07:34:20 KERN: wacom:  ... success!
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2500) error: status: 0x18400001; token: 0x002805e1;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 2 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2560) error: status: 0x184007ff; token: 0x00280569;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 3 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: ====================================
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e25c0) error: status: 0x18400001; token: 0x002805e1;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 2 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2620) error: status: 0x184007ff; token: 0x00280569;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 3 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: ====================================
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2680) error: status: 0x18400001; token: 0x002805e1;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 2 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e26e0) error: status: 0x184007ff; token: 0x00280569;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 3 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: ====================================
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2740) error: status: 0x18400001; token: 0x002805e1;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 2 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e27a0) error: status: 0x184007ff; token: 0x00280569;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 3 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: ====================================
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2800) error: status: 0x18400001; token: 0x002805e1;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 2 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: usb error uhci 5: td (0x041e2860) error: status: 0x184007ff; token: 0x00280569;
2009-09-24 07:34:20 KERN: wacom: add_device() - control transfer 3 failed: -2147442667
2009-09-24 07:34:20 KERN: wacom: retData: 0 - 0
2009-09-24 07:34:20 KERN: ====================================
2009-09-24 07:34:20 KERN: wacom: count: 5
2009-09-24 07:34:20 KERN: wacom: add_device() - set 'Wacom'-mode failed
2009-09-24 07:34:20 KERN: wacom: device_open() open: 2

Hope this helps.

[mmlr]

From looking at that patch it seems like you figured out that these wacoms are just plain normal HID devices and they use the standard (but in this case vendor specific) feature report interface to program the tablet. If this is the case for all these wacom devices, then the whole wacom driver stack should be moved into usb_hid as a WacomDevice. The wacom input_server device add-on right now "parses" the raw data with known offsets, but if these are HID devices then these items should be easily extractable from the normal HIDReport as HIDReportItems. Also the feature report should be available as a normal HIDReport with which the individual fields can be retrieved as HIDReportItems, their data set per SetData() and then the report sent via HIDReport::SendReport(). This would allow for these devices to not need the hardcoded raw data format parsing but use the normal HID reports instead. This would make support for them generic with regards to new devices or devices using a slightly different format.

[idefix]

Replying to bga:

Hope this helps.

Well, it tells us that no matter how hard we try setting it to 'Wacom'-mode, it won't listen. :)

When I looked at the code, I was wondering why control transfer 1 goes to interface #0, while control transfer 2 goes to interface #1. So I tried changing the interface number to 0 and 2 and both interface numbers were accepted by my Wacom Graphire 2; setting it to 'Wacom'-mode. I'm guessing that the newer Wacom tablets are a bit pickier as to which interface the control transfer goes, so in the new patch​ I've changed interface #1 to interface #0. Maybe that will cause the Bamboo to pick it up?

[idefix]

(patch) changed interface #1 to #0

[idefix]

Replying to mmlr:

From looking at that patch it seems like you figured out that these wacoms are just plain normal HID devices and they use the standard (but in this case vendor specific) feature report interface to program the tablet. If this is the case for all these wacom devices, then the whole wacom driver stack should be moved into usb_hid as a WacomDevice.

Yes, while looking through the code I was wondering what these send_request lines specifically did, so I did a bit of digging through the USB and HID specifications and the Linux driver. What I've written in the comments of the patch is essentially what I came up with so far.

The wacom input_server device add-on right now "parses" the raw data with known offsets, but if these are HID devices then these items should be easily extractable from the normal HIDReport as HIDReportItems.

I don't know this for sure yet. I know the Wacom tablet acts as an HID device when setting it to 'Wacom'-mode, but I don't know if the tablet-data it is sending in 'Wacom'-mode is also a normal HIDReport.

[bga]

patch v2 does not result into errors anymore, but the device does not work anyway (at least my mouse pointer is not being moved by it).

2009-09-24 22:07:48 KERN: usb hub 64: port 2: new device connected
2009-09-24 22:07:49 KERN: wacom: add_device() - wacom detected
2009-09-24 22:07:49 KERN: wacom:  ... success!
2009-09-24 22:07:49 KERN: wacom: retData: 2 - 2
2009-09-24 22:07:49 KERN: ====================================
2009-09-24 22:07:49 KERN: wacom: count: 0
2009-09-24 22:07:49 KERN: wacom: device_open() open: 2

[idefix]

Replying to bga:

patch v2 does not result into errors anymore

That's good to hear! So my guess was correct, the newer tablet are a bit pickier.

, but the device does not work anyway (at least my mouse pointer is not being moved by it).

Yes, that's because the device id's and their corresponding maxX and maxY values have to be added to the input-server addon. Just like HaiColon did in comment:2.

[stippi]

Thanks a bunch, I applied the patch in hrev33301. When I have access to my Wacom again, I want to look into merging the wacom driver into the HID driver. Or are you interested in giving that a try, idefix? The kernel side for this should be fairly easy. The input_server side needs to be changed such that the kernel driver reports the tablet size and anything else needed by the input_server add-on, and then that add-on should be seriously simplified.

[idefix]

Replying to stippi:

Thanks a bunch, I applied the patch in hrev33301.

Thanks, but that patch wasn't meant to be applied as it contains some unneeded debugging output and doesn't follow the Haiku Code Guidelines. :)
I have a cleaned-up patch ready for the kernel part, but haven't had the time to update the input-server addon so I didn't post that one yet. Hopefully I'll have some time tomorrow to update the addon part and post the final patch.

When I have access to my Wacom again, I want to look into merging the wacom driver into the HID driver. Or are you interested in giving that a try, idefix?

Looking at the amount of code I've written so far, I don't consider myself to be up for that task. So I think I'll pass. :)

If you have access to your Wacom again, could you test if your Intuos2 still works with this change? I suspect it would, but then again there must be a reason why the original driver had interface #1 as its destination for control transfer 2.

[idefix]

Replying to idefix:

I have a cleaned-up patch ready for the kernel part, but haven't had the time to update the input-server addon so I didn't post that one yet. Hopefully I'll have some time tomorrow to update the addon part and post the final patch.

Earlier than planned: wacom_bamboo.patch​

Changes:

• cleaned-up kernel addon
• added four Wacom Bamboo models to input_server addon

This should get the Bamboo tablets working in Haiku.

[idefix]

(patch) cleaned-up kernel addon and added four Bamboo models to input_server addon

[idefix]

Replying to bga:

patch v2 does not result into errors anymore, but the device does not work anyway (at least my mouse pointer is not being moved by it).

Does the latest patch​ make your Bamboo tablet work?

[bga]

Yes, it does. Although it only works for a few seconds and then seems to stall completely.

[idefix]

Strange, I have no idea what's causing this behaviour but the original reporter also experienced something like that:

HaiColon wrote:

[...] And after about a minute my mouse stops working until I unplug the Wacom tablet (that's reproducible, happened every time I tried).

Does something show up in the syslog when the tablet stops working?

[bga]

Nothing that I remember. I can try it again to check.

[idefix]

I doubt it, but hrev34932 might also fix your stalling problem. I've attached an updated patch​.

[idefix]

(patch) cleaned-up kernel addon and added four Bamboo models to input_server addon (updated)

[stippi]

Is the stalling problem fixed now? I've applied the new patch in hrev36843. Last time I used my Intuos, it worked completely reliable, in fact I have it attached at all times now and it works whenever I want to use it.

[waddlesplash]

No reply in 9 years, and it's fixed for stippi, so assuming it's fixed elsewhere.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone