[libhid-discuss] Re: rewriting the hid parser

[Frederik Reiß]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Lepple schrieb:
> Hi Frederik,
> 
> 
>> First: It is not realy necessary to support multiple backends in libhid,
>> since libusb is already ported to many platforms: [0],[1].
> 
> In theory, yes. In practice, it requires recompiling the kernel in *BSD
> to prevent uhid from binding to the device (no reference handy, but it
> has been discussed online at one time or another). Maybe this has changed.
> 
> In OS X, you also cannot grab the device away from the kernel, but
> again, their HID API is more capable than the Linux or *BSD kernel APIs.
> At least it seems that claiming the device is not necessary in OS X, as
> long as something else is not actively using the device.
> 
> libusb-win32 requires a special driver to bind to a USB device, and I
> have heard that it is a pain to work with. Supposedly there is a
> successor to WDM that allows user-space USB device access in Windows,
> but I have not looked into that. All USB-enabled versions of Windows
> have allowed user-space HID access, however.

o.k. very good reasons to support multiple backends.


>> Second: If you want to rewrite the hidparser from libhid why not just
>> "steal" it from lsusb? lsusb seems to parse the complete device
>> descriptor. It looks much cleaner than the current implementation in
>> libhid. We would only need to chagne the lsusb parser to store the
>> parsed descriptor in an data structure and write a function to find the
>> device the user wants to open.
> 
> Good point. Originally, Martin Krafft wanted to rewrite the parser so
> that we could license both libphidgets and libhid under the Artistic
> license (in addition to the fact that the MGE code is very hard to
> maintain). But at this point, you are probably right that we could use
> the one in lsusb, since it has been tested with a lot more devices than
> libhid.

Then we should take this to the libhid-discuss list to decide if it's
acceptable to stay with the GPL (and use the lsusb hid parser) or if we
want libhid licensed under the Artistic license (and write ouer own
parser). We could also ask the guys who wrote lsusb if we can use thier
code and license it under the Artistic license.


>> Third: I have thought about the user visible part of the libhid api. I
>> think your (Apples) cookie idea is cool, so i would propose something
>> like this:
> 
>> hid_set_debug(level);
>> hid_set_debug_stream(stream);
> 
>> hid_open(&dev, &matcher, retrys);
>> hid_close_device(dev);
>> hid_reset_device(dev);
> 
>> hid_get_report_raw(dev, cookie, &buffer, &buffer_size, timeout);
>> hid_set_report_raw(dev, cookie, buffer, buffer_size, timeout);
> 
>> hid_set_report_value(dev, cookie, value, timeout);
>> hid_get_report_value(dev, cookie, &value, timeout);
> 
>> hid_set_idle(dev, cookie, duration);
>> hid_get_idle(dev, cookie, &duration);
> 
>> hid_dump_tree(dev);
> 
> Would all of these return error values only?

yes


>> some little explanation:
>> * merge hid_open and hid_force_open
> 
> Agreed, we just didn't want to break compatibility after we found it was
> necessary to add hid_force_open. This is another good reason for a 0.3.x
> API change.
> 
>> * merge hid_init and hid_cleanup in hid_open/close (not sure how useful
>> this would be)
> 
> Hmm, I vaguely remember that there was a reason for doing that...
> something to do with multiple threads, maybe?  What if you want to reopen
> a device that has been unplugged?

hmm ... you are right this would result in an second call to usb_init().
So we would need 2 more functions:

hid_init()
hid_cleanup()

naturally hid_is_opened() and hid_is_initialised() should also be present.


> In NUT, we have a driver daemon that runs in the background, constantly
> sending values to upsd. We try to have this driver stay running at all
> times, so if the device disappears, it loops to wait for it to come back
> (since usually it is just a transient failure).
>
>> * since we can use cookies to distinguish the report types we don't
>> need 7 different functions for the user to deal with.
>> * The *_raw functions should return/take data similar to
>> hid_get/set_*_report
>> * The *_value functions should return/take values similar to
>> hid_*_item_string
>> * hid_dump_tree dumps all avialable reports/endpoints and thier
>> corresponding cookies
> 
> I don't really want people to get into the habit of using the cookies
> directly, so maybe hid_dump_tree shouldn't print them.

But if the user needs something like [0] to get the cookie is not very
elegant. So we would need at last 2 functions to deal with:

hid_get_cookie_for_path(path, pathlen)
his_get_cookie_for_endpoint(endpoint)


> Would you mind if we take this thread to the libhid-discuss list?
i will send this mail also to the list.

[0]
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/HID/index.html

Frederik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFxdNOcLHece3p3gARAvOfAJ44s983nZ5tmsw4p85ZrJ66rYFppACggx9z
d34sTNisgJjetuhr+4iddNE=
=egjF
-----END PGP SIGNATURE-----