Hi there. I'm trying to implement a little script which watches for a certain bluetooth button device to appear, then read events from it, and handle gracefully if it disappears.
I actually found your post on https://stackoverflow.com/questions/15944987/python-evdev-detect-device-unplugged/16500472#16500472 and I'm using that as an example.
However, the interesting thing is that when my bluetooth device goes to sleep, it appears that select() returns with descriptor in the read array. When I go and call read() or read_one() on the corresponding InputDevice I get:
Traceback (most recent call last):
File "key_controller.py", line 67, in <module>
event = dev.read_one()
File "/usr/local/lib/python2.7/dist-packages/evdev/eventio.py", line 54, in read_one
event = _input.device_read(self.fd)
IOError: [Errno 19] No such device
So interestingly, it seems that it takes a while for udev to actually tell me that the device is gone (so that I can tear down the fd in the selected set. I dealt with this by just doing an os.path.exists() on the devices' .fn field, which seems to work.
Not sure if this should be considered a bug or expected behavior, but given these devices can appear and disappear, it might be nice for the python evdev api to be able to handle that more gracefully somehow. I expected read_one() to return None in this case, and for there to maybe be some kind of other flag I could check to see if this InputDevice instance was still "valid".
Hi there. I'm trying to implement a little script which watches for a certain bluetooth button device to appear, then read events from it, and handle gracefully if it disappears.
I actually found your post on https://stackoverflow.com/questions/15944987/python-evdev-detect-device-unplugged/16500472#16500472 and I'm using that as an example.
However, the interesting thing is that when my bluetooth device goes to sleep, it appears that select() returns with descriptor in the read array. When I go and call read() or read_one() on the corresponding InputDevice I get:
So interestingly, it seems that it takes a while for udev to actually tell me that the device is gone (so that I can tear down the fd in the selected set. I dealt with this by just doing an os.path.exists() on the devices' .fn field, which seems to work.
Not sure if this should be considered a bug or expected behavior, but given these devices can appear and disappear, it might be nice for the python evdev api to be able to handle that more gracefully somehow. I expected read_one() to return None in this case, and for there to maybe be some kind of other flag I could check to see if this InputDevice instance was still "valid".