Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a native driver for Hims displays #7459

Closed
LeonarddeR opened this issue Jul 31, 2017 · 10 comments · Fixed by #7712
Closed

Provide a native driver for Hims displays #7459

LeonarddeR opened this issue Jul 31, 2017 · 10 comments · Fixed by #7712
Assignees
Milestone

Comments

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Jul 31, 2017

I've started investigating some more details for a native driver for Hims devices today. This should fix #6063 and #6086.

One major problem is that Hims devices use a custom USB driver, which presents itself as a generic USB serial. However, it is neither native serial nor HID. I've tried to sniff the data sent from and to the device using a free tool called Device Monitoring Studio or Free USB Analyzer, and I'm perfectly able to interpred the data, so that's at least one positive thing.

I started with creating a new class called Usb in the hwIo module, which is actually a copy of the Hid class excluding the Hid specific part (i.e. the Hid __init function in hwIo.py except for line 244--256. According to the USB sniffer, it seems output packages are at least 10 bytes in size for the current driver, incoming packages seem to be 4 bytes or more. So, I create a new Usb object with the proper path, onReceiveSize=4 and writeSize=10, but writing using this object doesn't seem to deliver anything to the device, that is, the USB sniffer doesn't detect any traffic.

@jcsteh: I'd like to have your advice on this. Is this the proper way to pump data into a device, or should I set up the file handle differently for example?

@jcsteh
Copy link
Contributor

jcsteh commented Aug 1, 2017

@leonardder commented on 1 Aug 2017, 03:16 GMT+10:

I've started working on a native driver for Hims devices today. This should fix #6063 and #6086.

Note that I do now have the documentation for HanSoneConnect.dll, which should allow us to fix #6063 for the current driver. We can discuss getting you access to those docs if you're interested. Obviously, a native driver would be better long term, but given the USB serial issues discussed below, this might be a bit trickier than we thought.

One major problem is that Hims devices use a custom USB driver, which presents itself as a generic USB serial. However, it is neither native serial

When you say it isn't native serial, do you mean it doesn't show up as a com port? What is the driver called? It's possible there is an API we can use. For example, FTDI2 has its own API when in non-com port mode, as used by the papenmeier driver. I tried to get the HIMS USB driver to take a look at the .inf file myself, but all download links I can find for it seem to be broken. :(

nor HID.

I wouldn't expect it to be HID; HID and serial are two very different things.

@jcsteh: I'd like to have your advice on this. Is this the proper way to pump data into a device, or should I set up the file handle differently for example?

I don't even think writing raw USB directly to a device is possible in Windows unless you use the WinUSB driver. I'm not sure what your sniffer tool is using, though. Honestly, I have no experience with this at all; I've only dealt with com ports and HID.

@LeonarddeR
Copy link
Collaborator Author

@jcsteh commented on 1 aug. 2017 02:10 CEST:

When you say it isn't native serial, do you mean it doesn't show up as a com port?

Yes, exactly.

What is the driver called?

It is called Hims USB Driver, not very helpful. Interesting enough, the driver installer also seems to install some FTDI stuff.

It's possible there is an API we can use. For example, FTDI2 has its own API when in non-com port mode, as used by the papenmeier driver.

This is the newer models driver, right?

I tried to get the HIMS USB driver to take a look at the .inf file myself, but all download links I can find for it seem to be broken. :(

Here is a working link.

@jcsteh
Copy link
Contributor

jcsteh commented Aug 1, 2017

@leonardder commented on 1 Aug 2017, 16:12 GMT+10:

It is called Hims USB Driver, not very helpful. Interesting enough, the driver installer also seems to install some FTDI stuff.

Very likely FTDI then.

It's possible there is an API we can use. For example, FTDI2 has its own API when in non-com port mode, as used by the papenmeier driver.

This is the newer models driver, right?

Yup: papenmeier.py. See the calls to the ftdi2 module.

@LeonarddeR
Copy link
Collaborator Author

LeonarddeR commented Aug 1, 2017

@jcsteh commented on 1 aug. 2017 08:36 CEST:

Very likely FTDI then.

I'm afraid not, since none of the VID?PID combinations for the Hims devices belong to the FTDI part of the driver. But, I can always try to talk to the display using the ftdi2 module and see what it does, of course.

The Hims specific USB driver inf file talks about the USB module being an Intel 82930 test board. Either Hims used this driver package as a skeleton, or they are really using this board. This page suggests the latter.

@LeonarddeR
Copy link
Collaborator Author

Looking in my mail archive, I found a mail from Hims with relevant details. The USb driver is a Bulk driver. As I didn't have an idea what bulk was supposed to mean, I simply ignored that word, thinking that it hadn't any value, but it seems it has.

@LeonarddeR
Copy link
Collaborator Author

Definitely not FTDI2.

@jcsteh
Copy link
Contributor

jcsteh commented Aug 2, 2017 via email

@LeonarddeR
Copy link
Collaborator Author

Good news, I figured out the read/write strategy for bulk devices. It has two end points, whereas HID devices seem to use only one end point for writing. I will create a new Bulk class for this in hwIo.

@LeonarddeR
Copy link
Collaborator Author

CC @bramd, since he's also fiddling with Bulk support lately.

I'm leaning towards giving priority to #1271 and base the new driver on that code, since it makes things a whole lot simpler at some point. Probably requires some discussion with NV Access about priorities though.

@LeonarddeR LeonarddeR self-assigned this Oct 21, 2017
@LeonarddeR
Copy link
Collaborator Author

It turns out that the handles created by the ftdi2 module are ftdi2 specific (i.e. they don't support generic (async) read/write operations). This will make hwIo support for these a bit more complicated if not impossible.

I actually tested this with a Baum Vario Pro, which supports both the Ftdi2 module and has a generic serial port. Hopefully the latter is also the case with the sync braille.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants