#26 better reaction on /dev/hidraw read errors

[T.M.]

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.

[Emil Ljungdahl]

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.

[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.

[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.

[T.M.]

Olaf Meeuwissen wrote:

@T.M.> Can you still reproduce the hanging with the latest code?

It does not hang anymore if the hidraw device is not readable. Good!
This seems to be much better now. It is also very fast detecting this,
just half a second or so.

What I see is the following:

$ openambit &
[1] 399
$ QObject: Cannot create children for a parent that is in a different
thread.
(Parent is QNetworkAccessManager(0xf33b60), parent's thread is
QThread(0x1020978), current thread is QThr

(I already reported this mysterious threading thing.)

I mean something else: there's still no message at all about what really
happened and what's the problem AND that the user can probably solve the
problem. Also the GUI doesn't say anything, just "no device found". OK,
my binaries are from friday or saturday. May be you did something in the
last days.

Thanks for your work and your perseverance. I use openambit multiple
times every week!

T.M.

[Emil Ljungdahl]

Moved to github