I was just looking at the Suunto Eon Steel support added and was wondering if anyone had tried it on a Mac. Specifically:
Since the EON appears to identify as a USB HID device, the oh so wonderful MacOS kernel driver will probably grab it right? 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? Or by accident? And there is no corresponding call to libusb_release_interface() in close either ....
It's obviously working fine on Linux and Windows, but I can't see how it would work on a Mac unless I'm misinterpreting what the device actually looks like from a USB point of view. I don't have one to test with but wanted to look into adding support for it. I dug around Suunto DM5 and, at least on the Mac, it seems to be using hidapi although again, since I don't actually have one in my hands ....
Thanks, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Sun, Mar 8, 2015 at 12:31 PM, Janice McLaughlin janice@moremobilesoftware.com wrote:
I was just looking at the Suunto Eon Steel support added and was wondering if anyone had tried it on a Mac.
Sadly, I can't claim to know whether it works or not. I have no MacOS anywhere.
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.
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.
I have no idea what MacOS does about those things.
Linus
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Mar 8, 2015, at 3:42 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Mar 8, 2015 at 12:31 PM, Janice McLaughlin janice@moremobilesoftware.com wrote:
I was just looking at the Suunto Eon Steel support added and was wondering if anyone had tried it on a Mac.
Sadly, I can't claim to know whether it works or not. I have no MacOS anywhere.
Bring it over and we can test this. Easy enough :-)
/D
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Mar 8, 2015, at 4:37 PM, Dirk Hohndel dirk@hohndel.org wrote:
On Mar 8, 2015, at 3:42 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Mar 8, 2015 at 12:31 PM, Janice McLaughlin janice@moremobilesoftware.com wrote:
I was just looking at the Suunto Eon Steel support added and was wondering if anyone had tried it on a Mac.
Sadly, I can't claim to know whether it works or not. I have no MacOS anywhere.
Bring it over and we can test this. Easy enough :-)
/D
Ummm, there was no wink there. Is this possible? Seriously, I'd be happy to do the work if someone (anyone? anyone? {she looked longingly}) could temporarily lend me their EON Steel .....
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Sun, Mar 8, 2015 at 4:37 PM, Dirk Hohndel dirk@hohndel.org wrote:
Bring it over and we can test this. Easy enough :-)
I can bring it over some time earlyish afternoon (after swimming). If you're not home I'll just leave it by your front door or something.
Linus
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Mar 8, 2015, at 3:42 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Mar 8, 2015 at 12:31 PM, Janice McLaughlin janice@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
-
Dirk Hohndel -
Janice McLaughlin -
Linus Torvalds