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
Comments
@leonardder commented on 1 Aug 2017, 03:16 GMT+10:
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.
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. :(
I wouldn't expect it to be HID; HID and serial are two very different things.
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. |
@jcsteh commented on 1 aug. 2017 02:10 CEST:
Yes, exactly.
It is called Hims USB Driver, not very helpful. Interesting enough, the driver installer also seems to install some FTDI stuff.
This is the newer models driver, right?
Here is a working link. |
@leonardder commented on 1 Aug 2017, 16:12 GMT+10:
Very likely FTDI then.
Yup: papenmeier.py. See the calls to the ftdi2 module. |
@jcsteh commented on 1 aug. 2017 08:36 CEST:
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. |
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. |
Definitely not FTDI2. |
Yup. Looking at the BRLTTY source, it seems only the SyncBraille is FTDI.
In NVDA, that's a separate driver.
|
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: