better reaction on /dev/hidraw read errors

[mbernasocchi]

From https://sourceforge.net/u/muellerto/: On my Arch Linux the device /dev/hidraw1 is not usable as intended. I debugged this. The device is owned by root and only root can read and write it. (I'm working to solve this, it's a silly udev problem.) What I suggest to do here is a much better reaction on this problem. Version 0.1 said only "Failed to open device" not telling the user any further information, what device?, why failed? and so on. Version 0.2 hangs for a long time not showing anything, then telling the user the window could not be created. Note: on some Linuxes /dev/hidraw1 can be not readable by a normal user. You should check this and give the user a clear message about the real problem.

[mbernasocchi]

From Emil: Thanks for the feedback. The ownership issue is a known issue, for 0.1 it was documented in the wiki (and how to solve it), and for 0.2 it should be solved when installing the application (installs a udev.rules file in */lib/udev/rules.d). Have you tried making an install? Anyhow, the hanging in 0.2 is not good, it should be fixed.

[mbernasocchi]

From T.M.: (I don't know why my postings disappear here ... Try it again and again.) I got it! Your rules file works great, my rule which was exactly (!) the same did not work. OK, now I made a step forward. I could load up several moves to Movescount.

[mbernasocchi]

From Olaf Meeuwissen: Emil suggested in private communication I take a look at this. Having done so, I am not sure that the problem still exists. Using 47fa66f83 on Debian wheezy and an Ambit with an as of yet unsupported firmware version, I am not able to reproduce hanging. With all debugging output enabled I ran the ambitconsole example application with and without the udev rules in effect. Without, I get:

libambit INFO: /path-to/libambit.c:78 libambit_detect(): Searching devices
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:86 libambit_detect(): match!
libambit INFO: /path-to/libambit.c:101 libambit_detect(): Trying to open device
No clock found, exiting

With udev rules in effect I see:

libambit INFO: /path-to/libambit.c:78 libambit_detect(): Searching devices
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:84 libambit_detect(): vendor_id=1493, product_id=0010
libambit INFO: /path-to/libambit.c:86 libambit_detect(): match!
libambit INFO: /path-to/libambit.c:101 libambit_detect(): Trying to open device
libambit INFO: /path-to/libambit.c:500 device_info_get(): Reading device info
libambit INFO: /path-to/libambit.c:138 libambit_detect(): Successfully opened device "Suunto Ambit (Bluebird)" SW: 2.0.6, Supported: NO
Device: Suunto Ambit (fw_version: 2.0.6) is not supported yet!
libambit INFO: /path-to/libambit.c:156 libambit_close(): Closing

In either case, the feedback is immediate for me. I agree that the feedback could be a bit more informative and the detection a little smarter (there's little point in looping over the same device seven times!) but I cannot reproduce the hanging behaviour. @T.M.> Can you still reproduce the hanging with the latest code? I will have a go at improving libambit_detect() and see if I can come up with a patch.

[svenstorp]

@paddy-hack: Did you investigate the possibility to make it "smart" enough to detect permission errors? I think that is the single most important error message we can give the user...

[paddy-hack]

4799eab at least logs the reason why libambit cannot hid_open() the device but this information is not available yet to library users like openambit. I'd like to get that done as well and refactor the clock detection code a bit, maybe even move some of the udevmonitor stuff from openambit to libambit. As that is a bit bigger and more speculative, I'll do that on a separate branch.

[mbernasocchi]

using the packaged version or running directli the build binary I get: libambit_detect(): Reason: Permission denied

sudo make install is the only way to make it work

[mbernasocchi]

my comment was actually to say that there is something going on wrong with the packages :)

[paddy-hack]

Improvements in the device detection now lead to messages in the GUI that try to indicate why things went wrong.