-
Notifications
You must be signed in to change notification settings - Fork 110
wait for HID device ready; allow longer mouse movements #15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Try a simple operation in each constructor. If it fails, wait one second and try again (once). Fixes adafruit#13. 2. Don't limit mouse movements to [-127, 127]. Use multiple reports to move further if necessary. I believe this was suggested by Mike Barela (@TheKitty).
self.send(0x0) | ||
except OSError: | ||
time.sleep(1) | ||
self.send(0x0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a nested try
, so we can at raise the exception and report it if the wait->retry
doesn't work?
And to extend that, is there an actual error number we can attribute this too? Could be useful so that we don't treat ALL OSErrors as needing to wait (unless we're confident that is the only one that will be encountered).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The second self.send()
will throw OSError
if it fails, just like the first. But that won't get caught so it will bubble up to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the error number will be the same across all ports, or even from 2.x to 3.0. There are a couple of different conditions that are reported up that might be recoverable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was afraid we couldn't narrow down on the error number; cest la vie. For the exception, I was just wondering if there was a better way to report than the status LED. But, since we're dealing with situations very early in the program running, REPL output is unlikely. And clearly, if the REPL is running, HID is probably fully initialized. Only other way around it is to have the user put their instance creation in a try
and catch any exception themselves...
This looks good to me as is then. I'll let @tannewt review and final approve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks!
Updating https://github.com/adafruit/Adafruit_CircuitPython_HID to 3.0.0 from 2.1.0: > Merge pull request adafruit/Adafruit_CircuitPython_HID#15 from dhalbert/wait_for_ready > Merge pull request adafruit/Adafruit_CircuitPython_HID#12 from dhalbert/consumer_control > Merge pull request adafruit/Adafruit_CircuitPython_HID#11 from sommersoft/new_docs
Try a simple operation in each constructor. If it fails, wait one second
and try again (once). Fixes HID devices not ready when main.py starts #13.
to move further if necessary. I believe this was suggested by @TheKitty.