Question about Suunto EON Steel on MacOS

[Janice McLaughlin]

On Mar 8, 2015, at 3:42 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:

> On Sun, Mar 8, 2015 at 12:31 PM, Janice McLaughlin
> <janice at moremobilesoftware.com> wrote:
>> Specifically:
>> 
>> Since the EON appears to identify as a USB HID device, the oh so wonderful MacOS kernel driver will probably grab it right?
> 
> Not necessarily. Since it doesn;'t have any HID descriptors, there's
> not a whole lot MacOS can actually do with it - it won't be usable as
> a keyboard or joystick or something like that. So what would a MacOS
> kernel driver do with it? I have no idea.
> 
> So only testing woudl tell, I suspect.

Yes, I agree. But I know from the Apple USB list that the kernel HID driver will "own" any HID Device that no one else show's interest in. By Design. It's being "helpful". And any device that says it's an HID has to conform to the USB HID protocol so the kernel driver can do very basic communication. And the way that you get around the kernel driver being so "helpful" is to install what they call a codeless kext, which is essentially a "driver" made up of only a config file that says, I'm "interested" in that VID/PID combination if one shows up. Then that means the kernel driver doesn't grab it and *then* it's available to eg: a user land application. AND the OS doesn't support the equivalent of libusb_set_auto_detach_kernel_driver() so the whole thing is quite the opposite of "helpful".

>> Which means in suunto_eonsteel_device_open(), the call to libusb_claim_interface(eon->handle, 0) will fail. (Been there, done that). But there is no return code checking on the call so the open will continue. Is that on purpose?
> 
> That was on purpose. It's not like checking errors will help. It's
> more likely to hurt. So it tries to detach the kernel driver and claim
> the interface, but it's one of those "let's do the best we can, and
> then just access the device".
> 
> There are people who think that you should check every error you can.
> I don't partake of that religion: error checking is only useful if you
> *care* about the error and there is some reason to do something
> different.

Well there's that. But I thought that maybe it wasn't checking on purpose knowing it would actually fail in some cases, eg: MacOS, but that it didn't matter and that the minimal libusb support needed would work without having to claim the interface. I've not actually got my hands on an HID device before and so I'm kinda winging it and guessing what happens. Which prompted the question.

> I have no idea what MacOS does about those things.
> 
>                      Linus

I'm just making an educated WAG.

Janice



------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
libdivecomputer-devel mailing list
libdivecomputer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel