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
Native driver for Handy Tech braille displays #7590
Conversation
…Modular Evolution 88 and logs received packets and key presses
…Routign is not yet supported.
… specific packets such as firmware version lookup
… add a joystick to a new active braille at a later date. Also, fixed numcells, which should be 16
…/return for shift+tab/tab
… modify after copy-paste
…ject to rename get_keys to a keys property, some whitspace fixes, implemented old protocol for writing braille cells, construct name dynamically for models where this makes sense.
Completed code inspection and all looks good except one potential issue: When a device id packet, the one consisting of 0xfe followed by the model id, is received from a hid to serial converter, the code currently does not check if there are more bytes beyond those two, so in theory, if that packet got lumped together with another one, that last one might get lost. Is this a ghost I'm seeing or actually relevant? |
@FelixGruetzmacher commented on 16 okt. 2017 15:41 CEST:
Hmm, very true indeed.
I think this should be considered. Is it true that non-extended packages are always two bytes in size? |
@michaelDCurran: Could you please review the last few commits? |
Yes, I believe this to be the case in all scenarios we are considering here. Also, just looked at your change and I believe this addresses it. Thank you. |
@bramd and @FelixGruetzmacher, I wonder whether we should put a timer or a safety guard on the _awaitingAck property. To give an example:
Note that this is currently not very relevant, as it is an edge case and the connection is lost when disabling and enabling the device anyway. However, when when #1271 gets into view, this is certainly an issue, as braille auto detection won't be triggered and thus the connection won't be reinstated. We really should come up with a generic framework for protocols where we rely on ACKs |
Maybe we should stop waiting for an ack after, say, 0.2 s, and increase a
missing_ack counter. If an ack is received at some point, that counter
should drop back to zero. If it reaches 3, meaning 3 consecutive missing
acks, that amounts to a connection loss. That stops the edge case from
causing trouble, but still honors the reason why an ack was put in place at
all, namely, detecting fatal errors.
Leonard de Ruijter <notifications@github.com> schrieb am Di., 17. Okt. 2017
um 09:05 Uhr:
… @bramd <https://github.com/bramd> and @FelixGruetzmacher
<https://github.com/felixgruetzmacher>, I wonder whether we should put a
timer or a safety guard on the _awaitingAck property. To give an example:
1. Connect a Modular Evolution 88
2. Disable the device with the right side switch
3. Change focus, braille is sent to the device
4. awaitingAck is stuck in the True position. Setting it back to False
raises a serial error and NVDA falls back to no braille
Note that this is currently not very relevant, as it is an edge case and
the connection is lost when disabling and enabling the device anyway.
However, when when #1271 <#1271>
gets into view, this is certainly an issue, as braille auto detection won't
be triggered and thus the connection won't be reinstated.
We really should come up with a generic framework for protocols where we
rely on ACKs
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ARU1KMmZgaVcnCAifvTpapERc0gpB9Boks5stFHPgaJpZM4PT5As>
.
|
@FelixGruetzmacher commented on 17 okt. 2017 09:14 CEST:
My problem with a timer is that it might, or might not, conflict with thread safety. I'd rather only work with a counter or with waitForRead. However, calling wiatForRead from the background thread simply has no effect, as it doesn't allow reading to take place while waiting. :P This is an issue that will be solved in #1271 as well. If you guys agree, I don't think this issue should block this driver from landing into a release. I've been working with this driver for weeks now and I haven't seen any missed ACKs except for the edge case I mentioned. |
I stand convinced.
Leonard de Ruijter <notifications@github.com> schrieb am Di., 17. Okt. 2017
um 09:27 Uhr:
… ***@***.**** <https://github.com/FelixGruetzmacher> commented on 17
okt. 2017 09:14 CEST
<#7590 (comment)>:
Maybe we should stop waiting for an ack after, say, 0.2 s, and increase a
missing_ack counter. If an ack is received at some point, that counter
should drop back to zero. If it reaches 3, meaning 3 consecutive missing
acks, that amounts to a connection loss. That stops the edge case from
causing trouble, but still honors the reason why an ack was put in place at
all, namely, detecting fatal errors.
My problem with a timer is that it might, or might not, conflict with
thread safety. I'd rather only work with a counter or with waitForRead.
However, calling wiatForRead from the background thread simply has no
effect, as it doesn't allow reading to take place while waiting. :P This is
an issue that will be solved in #1271
<#1271> as well.
If you guys agree, I don't think this issue should block this driver from
landing into a release. I've been working with this driver for weeks now
and I haven't seen any missed ACKs except for the edge case I mentioned.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7590 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ARU1KOlFLv8Fd69jhjhi-scrlsExTBLTks5stFb0gaJpZM4PT5As>
.
|
@michaelDCurran: I did some small typo fixes to the user guide yesterday and added some gestures that weren't yet in there. I think the user guide is clear about the old devices (Modular with old firmware and Braillino) not being supported). But if you consider this to be to early for 2017.4, I can understand this. However, note that we should also consider that landing too much braille changes in one release increases the chance of unresolved bugs. |
Actually, I think a good intermediate solution would be merging this pr while keeping the com server for now. This way, people only have to install the add-on provided by handy tech, and this is clearly documented. |
and... will this be merged into 2017.4?
it will be great, because this driver is more responsive than the com
server in the MS word with braille.
W dniu 01.11.2017 o 08:29, Leonard de Ruijter pisze:
…
Actually, I think a good intermediate solution would be merging this
pr while keeping the com server for now. This way, people only have to
install the add-on provided by handy tech, and this is clearly documented.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7590 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKohk3k0nJD0QzabXf_vwTFqkT1xwoOoks5syB3KgaJpZM4PT5As>.
|
In this case, we'd have to remove the changes to setup.py and readme.md
from the pr. Is that correct?
If so, could someone do this please?
|
so, michael, will this be merged in this release?
W dniu 01.11.2017 o 22:52, Michael Curran pisze:
… In this case, we'd have to remove the changes to setup.py and readme.md
from the pr. Is that correct?
If so, could someone do this please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7590 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKohkx-Ennx054_bCiO2KhA7oYeDPMc_ks5syOgGgaJpZM4PT5As>.
|
Just a heads up that I will wait until tomorrow Friday 0 uTC to do
translation freeze.
If this pr can be changed so that setup.py and readme.md reflect your
proposal of keeping the COM server, I'll merge it to master.
As this PR will affect translations (changes.t2t at least), it needs to
be merged before the freeze.
|
There is a commit on the way where I reverted the removal of the com server. Note that I still removed one line from the readme, stating that you need the handy tech universal driver when running from source. This is no longer the case. You still need the handy tech universal driver installed when running from source with the Handy Tech add-on, but that's no longer our responsibility. |
Ah, and there's another file, comInterfaces_sconscript. The handy tech com server python file is no longer delivered with NVDA, but built on demand again. This has actually always been the case before NVDA 2016.4 or so, so I see no problems with this. |
Link to issue number:
Closes #7458.
fixes #5806.
closes #5418.
Summary of the issue:
A rewrite of the driver for Handy Tech braille displays. This is a native implementation which doesn't depend on the Handy Tech COM server.
Description of how this pull request fixes the issue:
Extensive discussion can be found in #7458. This is a first implementation of a native driver, which supports most Handy Tech displays. Notable changes for users include:
Testing performed:
Known issues with pull request:
Change log entry:
New features
Changes