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
Add support for custom providers for braille display auto detection #14531
Conversation
See test results for failed build of commit f748e46ba0 |
See test results for failed build of commit 52662b1e0c |
I'm pretty sure all these tests failures are unrelated. |
See test results for failed build of commit 7a36ab513c |
self._handlers = collections.OrderedDict() | ||
self._handlers = OrderedDict[ | ||
HandlerKeyT, | ||
Union[BoundMethodWeakref[HandlerT], AnnotatableWeakref[HandlerT]] |
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.
this type also might be worth turning into a named variable, as it is used repeatedly
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.
Same issue as abbove, nesting TypeVars in variables doesn't seem to be respected by PyRight.
@LeonarddeR can you address merge conflicts now that #14524 is merged |
Done. |
See test results for failed build of commit 35813eaf81 |
Fix for #14531 Summary of the issue: Error 'property' object is not iterable when enabling autodetect for the first time with Bluetooth on. Description of user facing changes None Description of development approach The detector was trying to save the bdDefsCache on the _DeviceInfoFfetcher class (not the instance).
As part of Pull request #14531, I ordered display order in bdDetect alphabetically. However, it seems that querying Albatross first has a major negative impact on detecting other displays using the same Serial to USB converter (see Pull request #13045) Description of user facing changes Handy Tech displays such as the Modular Evolution instantly auto detect again. Description of development approach Restored the order, Albatross is last in the dictionary again. I'm pretty unhappy with how these displays work, but it looks like it's a design thing in the displays itself.
Link to issue number:
Related to #3564, #2315
Summary of the issue:
Currently, USB and Bluetooth devices are supported for braille display detection. Other devices using other protocols or software devices aren't supported. This pr intends to add support for this.
Description of user facing changes
Noone. User shouldn't experience anything different for now.
Description of development approach
Testing strategy:
As this touches braille display auto detection quite a lot, probably merge this early in the 2023.2 cycle.
Known issues with pull request:
bdDetect.Detector does no longer take constructor parameters, rather queueBgScan should be called explicitly. This is because if we queue a scan in the constructor of Detector, the detector could switch to a display and disable detection before the _detector was set on the braille handler. Ideally we should use a lock as well, but that might be something as a follow up for both this pr and #14524. Note that though we're changing the constructor of a public class in bdDetect, the doc string of the class explicitly states that the Detector class should be used by the braille module only. That should be enough warning for users not to use this class and therefore I don't consider this API breaking.
Change log entries:
For Developers
Code Review Checklist: