00:55 <rjo_> sb0: forget what i said about the hub for these thorlabs motor controllers being a usb hub. it is not ;)

00:55 <rjo_> but its not much different. the full protocol is in http://www.thorlabs.us/software/apt/APT_Communications_Protocol_Rev_14.pdf

04:39 <rjo> weird. my posts from the freenode webchat never made it here...

04:39 <rjo> zyp, ysionneau: the hardware is sufficiently non-hid that pywinusb.hid does not work.

04:40 <rjo> ysionneau: i went back to hdapi and rewrote everything. this works: http://paste.debian.net/131250/

04:51 <zyp> rjo, how come it works with hidapi but not pywinusb.hid?

05:00 <rjo> pywinusb.hid wants to auto-discover the things you can do with the device. looked like there is a much higher level hid api which that hardware does not implement (correctly). you don't just send reports, you look up pages and usage ids for the different reports etc.

05:02 <zyp> yeah, that's the whole point of hid

05:03 <zyp> that sounds actually way more suited than my current approach with hidapi of just assuming a given report format

05:03 <zyp> shame it's windows only

05:03 <zyp> more suited for my application, that is

05:03 <rjo> well. if the device does not do it correctly, it's not suited ;)

05:04 <zyp> can you call a device not following the hid standard a hid device? :)

05:05 <rjo> half-hid.

05:05 <zyp> windows won't bind the hid driver to hid devices without a valid report descriptor, so whatever you're doing, you're going to need that

05:06 <rjo> there are report descriptors but i could not match them to the raw report format that is described in the (crappy) datasheet of the device.

05:07 <rjo> i have to admit that i was pissed by the weird terminology of the hid standard as well. so i gave up relatively early.

05:08 <zyp> heh

05:26 <rjo> zyp: what about this first padding byte in the reports. under windows it seemed to want that on write but the reads did not return that padding byte.

05:27 <rjo> meaning writes are 9 byte, reads are 8 byte.

05:27 <zyp> with hidapi?

05:28 <zyp> or plain windows hid?

05:28 <rjo> hidapi on windows.

05:28 <rjo> your dll in fact.

05:29 <zyp> hidapi should be consistent over all platforms

05:29 <zyp> hidapi takes the report id as first byte

05:29 <zyp> and if you don't have multiple reports, you need to put a zero there

05:29 <rjo> one would hope so

05:29 <rjo> and on reads?

05:30 <rjo> does it return a report id?

05:30 <zyp> the report id is always the first byte of the report if you are using ids at all

05:31 <rjo> i am not, i believe.

05:32 <rjo> " For devices with multiple reports, make sure to read an extra byte for the report number." does that mean that "devices without multiple reports" do not need that byte and start with data right away?

05:33 <rjo> on read

05:33 <zyp> ok, I looked at my code, you're not getting a padding byte on reads if there's no report id

05:33 <zyp> but you need it on writes

05:35 <zyp> http://cgit.jvnv.net/arcin/tree/autotest.py#n93 <- see how I'm adding the padding byte on line 94, but not on line 110

06:04 <rjo> yep. weird api...

06:06 <zyp> I believe it's to cope with certain OS APIs expecting report ids out of band

06:08 <zyp> «we don't know if the first byte is a report id that we have to strip off or not, so let's just always strip it off and require a padding byte if there's none»

06:09 <zyp> wheras on a read you know whether you have something to prepend or not

09:54 <ysionneau> rjo: ah! great that you had it to work!

21:50 <GitHub151> [artiq] jboulder opened pull request #4: Update installing.rst (master...patch-1) http://git.io/jWMw4A