Pressure of MousePen i608X not worked

Bug #927029 reported by Anton Yarth
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Wizardpen
Confirmed
High
Unassigned

Bug Description

I have MousePen i608X and it's work perfect(stylus, not mouse) with wizardpen only after using my init-utility that sends bytes to tablet.
Without utility tablet works without detecting pressure. I capture bytes from windows driver and found place in that this bytes sends to device in driver. This driver holds also EasyPen M406 and EasyPen i405X. Maybe driver sends another bytes to those EasyPen tablets, because in same place in driver are placed another bytes sends that's not used with my tablet.

 Code of utility in my git: http://github.com/Marisa-Chan/init-tablet

 Your may include my utility to your package or integrate sources in one full-featured driver.

VID_0458 PID_5005 EasyPen M406
VID_0458 PID_5010 EasyPen i405X
VID_0458 PID_5011 MousePen i608X

Martin Owens (doctormo)
tags: added: patch-included
Changed in wizardpen:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Nikolai Kondrashov (spbnick) wrote :

This will also work with M610X.

I have also found this feature report with the help of viktoria.s (http://ubuntuforums.org/member.php?u=1276886), who captured the Windows driver traffic for her i608X.

I have mostly implemented a kernel driver for it, however, sending this feature report in the kernel in a straight-forward way doesn't work. I'll be receiving a KYE EasyPen i405X tomorrow and hopefully will be able to complete the driver after that.

Do you have access to an EasyPen M406? I would be able to add support for it to the kernel driver, if you could get some dumps for me.

After the kernel driver is done the tablet will work with xf86-input-evdev driver without configuration. Also, it may be possible to use xf86-input-wacom also.

AFAIK, the WizardPen driver is discontinued. It was rather a hack right from the start. The proper way is to implement a kernel driver and then use evdev or wacom X.org drivers.

Revision history for this message
Martin Owens (doctormo) wrote :

Hey Nikolai, thanks for working on the kernel driver. We have a wizardpen users mailing list which I've been getting users to join so they can be ready to test any driver developments. https://launchpad.net/~wizardpen-testers It might be worth sending an email there.

The WixardPen driver here was discontinued, it's only reason for being here at all was that there was nothing to replace it, so out of necessity it needed to be decommissioned in a gradual way. This project always had the intention of not continuing once the promised kernel driver was finished.

For Ubuntu 12.04 we'll need to make sure there is a new deb built with the kernel module, because even if you finished the driver tomorrow I doubt you could get it into the kernel mainline and that then into the Ubuntu release. But people using the LTS will have to be able to get their tablets working and this is certainly the best way to do it without requiring them to break their kernel upgrades as we've talked about before.

Revision history for this message
Anton Yarth (llancelot7) wrote :

I have'nt access to EasyPen M406, but trying reverse driver for other tablets for finding other init-codes, but no luck for now. In driver for i608X/i405X/M406 it's easy to find init-bytes, because driver uses wdf.

Revision history for this message
Anton Yarth (llancelot7) wrote :

Looks like driver uses only one tablet mode - i tried another modes of work, and init-bytes are same. Windows driver handles and converts absolute to relative, checks buttons "pressed" on work surface. In other words all makes by software part. And in driver only few places with "sending bytes"-function, it looks like i608X/i405X/M406 use one init code.

Revision history for this message
Anton Yarth (llancelot7) wrote :

Hmm, not tested, but used bytes in MacOS driver for i608X:

in function "_SetDeviceParam"
05 12 14 11 12 00 00 00

and in this function uses initialization for "TouchScrollArray"
05 13 XX YY 00 00 00 00
where YY - return parameter "GetTouchScrollModel"+1
and XX - touchscroll index number (starts from 01)

in function "SetDefaultDeviceParam"
05 12 10 09 12 00 00 00

Revision history for this message
Nikolai Kondrashov (spbnick) wrote :

Thanks, Anton.

Personally, I prefer not looking into the driver code, as there might be legal problems.
I'm not sure if using the information obtained by a third person in such a way is illegal, though.

Still, it is usually sufficient to look at the USB traffic to figure out the protocol.

I think the basic "tablet mode enabling" report is sufficient for now.

I've got the tablet now and will resume implementing the kernel driver this evening.

Revision history for this message
Martin Owens (doctormo) wrote :

If you looked at the files then there is a possibility the owner could claim you copied it. But information from a third party is sanitised as it's effectively clean room reverse engineering. Consult your lawyer or the SFLC if in any doubt.

Revision history for this message
Nikolai Kondrashov (spbnick) wrote :

Thanks, Martin.

Revision history for this message
Nikolai Kondrashov (spbnick) wrote :

Just got the kernel driver working with KYE EasyPen i405X. Will be polishing it a bit and publishing soon.

Revision history for this message
Nikolai Kondrashov (spbnick) wrote :

Anton, if you continue reverse-engineering the driver, please don't post the implementation details. Like function names, the order they're called in, etc. If you uncover something useful, please just post the description of the protocol. This way it will be proper clean-room reverse-engineering.

Thanks :)

Revision history for this message
Anton Yarth (llancelot7) wrote :

Ok, but useful bytes for now is only captured in windows, so it's lawfully for now. And this is only for making support tablet's, which we don't have, but i understand law problems.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.