Native driver for Freedom Scientific braille displays #7727
Comments
|
An early try build is here: https://ci.appveyor.com/project/NVAccess/nvda/build/try-freedomscientific-native-14592%2c331e13db/artifacts This has had some testing with a Focus 40 blue. If you have a FS display, please test this build. I'm especially interested in
|
|
CC @xtstoll, @DGartmann: You both are users who either reported issues related to the Focus displays in the past, or have an open issue. Would you be able to test this try build and provide your feedback? |
|
@LeonarddeR: How are we supposed to test this build? Is it an installable version that should replace the current "Next" build? |
|
@DGartmann: You can install this build, but I'd advise to run this build either as a portable copy, or just run the build from the executable file without installing. There shouldn't be incompatibilities with configuration in case of the native driver. |
|
Hi, |
|
@bramd This build is working correctly. Thanks for fixing. |
|
I need to test this |
|
@derekriemer Which model do you have? |
|
@xtstoll: This behaviour is not covered by this new driver. The intended behaviour should be implemented in NVDA core itself in order for other displays to benefit from it as well/ |
|
I'm on a focus 40. typing anything at all renders only one dot, but only if I release all the keys at the same time.
Here's a log. Now typing ⠇⠇⠇⠇⠇⠇⠇⠇⠇ but releasing a key first. |
|
Also, I can do this. LeftGDF+Right GDF: |
|
Does it look like this won't be available for 2018.2? Interestingly, I just tried it in the next build that I just downloaded a few minutes ago, and there's no VFO or Freedom Scientific mentioned when I hit change in the new Settings under the braille category. It's got a lot of options but no VFO. But, my existing installed ordinary copy of NVDA release, currently on 2018.1, doesn't list it either. How did I have it working before? I tested this try build at one point. I don't know how I selected it just with existing copies of NVDA let alone the try build. When I tested this before with this try build however, it was working with my Focus 14 blue. |
|
It's not in next. |
|
@derekriemer It has been a while, but I've a Focus again for testing so I can finish this driver. Could you retest my branch? I think I've solved the handling of keys when multiple keys are released at the same time. |
LeonarddeR
added
component/braille-display-drivers
and removed
component/braille
labels
|
@bramd I've tried your branch from source and the driver is working beautifully. Only thing which is missing are new assignments for alt+shift+tab and for windows+tab added in 2018.3. Is there anything which needs particular testing? |
|
Whoohoo this is exciting! I have a 5th generation Focus 40 Blue now. Please let me know if you need any testing with it, and which build I should grab for it. @bramd |
|
@MarcoZehe commented on Sep 19, 2018, 7:59 AM GMT+2:
Yes please! This has not been tested with the fifth generation displays and that is a must for including it in NVDA, not supporting these displays would be a regression. I would like to clean up/refactor the code before doing a new build. I hope to finish this in the upcoming weeks. Can you give me the vendor ID (VID) end product ID (PID) as displayed in Device manager for the display? Strangely, older Focus models show up in their own category in device manager and not in USB devices as you might expect. You can find the IDs on the details tab in the device properties. Select "Hardware IDs" from the list and you should see an ID in the form "USB\VID_xxx&PID_xxx". Without the correct IDs, the NVDA driver will not be able to detect the device at all. |
|
Got them for you! This display still shows up in that extra section. The value I got is: USB\VID_0F4E&PID_0114 |
|
@MarcoZehe Thanks, that's the same ID as older generations, so it should
work just fine. Please try this build:
https://ci.appveyor.com/api/buildjobs/laf2w8qm7phbn64q/artifacts/output%2Fnvda_snapshot_pr1234-5%2Ca3fb2291.exe
Please note that this build is not digitally signed and you will likely
get a warning while running it.
Things you can test:
* Is automatic detection of the braille display working?
* Does it work over USB and Bluetooth?
* Does it work when it's selected manually and if so, does the port
selection work as expected?
* Do all keys work and generate the expected key name (test using input
help (nvda+1))?
* Is braille input working as expected?
* Do you notice an other differences/regressions compared to the old driver?
Thanks!
|
|
@bramd commented:
Yes, except when initially pairing the display via Bluetooth. Here's what I did:
See above, apart from the initial connection where it is not detected unless I switch to the driver once explicitly, yes.
The port is auto, and the display is found in all cases.
Yes. The one peculiarity, which I've also seen on other display, with input help is, though, that the pan next and pan previous keys as well as the wiz wheel up and down produce the actual function, are not trapped and don't speak the function they perform. But they do perform the actions as expected, so they work, too.
Yes.
No. It appears to be slightly more responsive. But that's a good thing. ;) |
|
OK, just oticed when plugging the display back in, that the driver sees the disconnection, but not the reconnection. So the transition from USB to Bluetooth and back does not work, I have to reselect the driver for the new connection to be used. So all you need to do to reproduce this is to connect and disconnect (and then turn on) the display to alter between USB and Bluetooth. The driver doesn't auto-detect the new connection, neither when on Auto nor when the Freedom driver is selected directly. |
|
Could you please do the following:
A possible cause could be that bdDetect simply acts to quickly. This also happens with Hims devices when they are in the boot process, i.e. they enable the USB interface while the display is not yet ready to handle connections. For Hims, this has been solved by increasing the amount of connection attempts or the per connection timeout. Also, some ports bring themselves in a broken state while disconnected too quickly. See this snippet from the handy tech driver: A nice test case could be manually selecting the display driver, and, after the display is properly connected, just open the display selection again and select the same driver. |
|
All right, here we go, be aware, this is a long comment with lots of log entry. After step 2, I got: DEBUG - braille.BrailleHandler.setDisplayByName (07:49:41.658): After disconnecting the display from USB, I got: ERROR - unhandled exception (07:49:57.563): (this means that a device connected to the computer is not working properly.) I then reconnected the display, but NVDA didn't react at all. I waited about 30 seconds, then pressed NVDA+N to open the menu to switch the diplay. The log continues straight from where I left off above, notice the time stamp changing, there was no activity in-between, so there was no notice of the display reconnecting. IO - inputCore.InputManager.executeGesture (07:50:38.730): It then displayed the NVDA menu. So it did detect the display again, but only after I pressed an NVDA command. |
|
I think the reason why it only picked up the device after opening the NVDA menu, was that there were no attempts to write to the braille display in the period of 30 second that you waited. It looks like the display driver did terminate after the 30 seconds of inactivity, why you would expect it to terminate as soon as there is connection loss. |
|
I was under the impression that it would work similarly to the Handy Tech auto detect, where after you reconnect the display, it just starts working, even without executing an NVDA command first.
… Leonard de Ruijter ***@***.***> hat am 4. Oktober 2018 um 08:16 geschrieben:
I think the reason why it only picked up the device after opening the NVDA menu, was that there were no attempts to write to the braille display in the period of 30 second that you waited. It looks like the display driver did terminate after the 30 seconds of inactivity, why you would expect it to terminate as soon as there is connection loss.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#7727 (comment)
|
|
It should work this way, yes. The reason why it doesn't, is that auto
detection isn't enabled as soon as you disconnect the display. It
re-enables as soon as the previous display driver terminates, and that
seems to happen only after you explicitly change focus or trigger
something else that writes braille.
Could you try disconnecting and reconnecting the device when in an
editor with blinking cursor?
|
|
Hm, the results are inconclusive. Often, when I disconnect and reconnect the display via USB, the connection is then established via Bluetooth instead. A typical log entry looks like this: ERROR - unhandled exception (11:58:52.460): One thing that then doesn't work without me reloading the Auto driver from the Braille Settings dialog is to switch the display connection to USB. The connection is lost, but not reestablished via USB, even though the display is already available. From the whole log, which is about 1 MB from just 3 minutes of testing, it looks like 2 out of 3 times, the connection is made via Bluetooth if the PC is paired, and only once per USB, and that only if I initialize the driver from the Braille Settings, choosing Auto. All other times it seems to prefer Bluetooth. Let me know if you want the whole log, I'll send it to you via e-mail, then, don't want to put that whole thing up here on Github. |
|
@MarcoZehe I was doing some tests with an older Focus Blue display today. When I disconnect the USB cable from this display, it turns off, when I reconnect the cable it turns on and immediately establishes a USB connection. Is this not the case for your newer display? Another interesting observation with this display is that it switches to a USB connection as soon as the cable is plugged in, even if you're having an active Bluetooth connection. It seems the Freedom Scientific driver detects this and switches to USB as well. I improved braille auto detection to keep scanning for compatible USB devices for the current driver, even if there is a Bluetooth connection. So with the following build you can connect a Focus on Bluetooth, plug in USB and it will switch immediately and automatically to USB: https://ci.appveyor.com/api/buildjobs/qqr2tq2m3ncljmfy/artifacts/output%2Fnvda_snapshot_pr1234-6%2C2194af16.exe I opened a new issue for faster detection of USB device disconnects. I don't want to hold the driver until that's implemented and tested with all kinds of displays, so I think it is best handled in a separate issue/patch. |
It is now with the new try build you just sent. It definitely wasn't the case with the older build from end of September. The newer display takes slightly longer to boot, that is, the time display (new to the newer displays) and the battery status appear a bit later after connecting the cable than with the older displays. We're talking about half to 1 second more.
Yes, this works fine with my display as well.
Sounds good. |
|
@MarcoZehe Thanks for the feedback. Do you feel this driver still has any regressions from the old one that should be solved before including it in NVDA? I also read in the documentation that the new generation has a menu button between the braille keys. Is this button only for internal functions, or can it be used in screen readers? If so, can you send me a debug log of a key press/release of this button? |
|
I think this driver is good for a pull request.
The menu button is for internal functions. It is never sent to the screen reader, nothing is added to the log when I press it.
Go for it!
|
|
@bramd One thing missing from the old driver are the new assignments for the Windows+tab and Alt+Shift+tab added in 2018.3. Adding them should be trivial, so maybe worth doing it before opening a pr. |
|
@lukaszgo1 Sure, I'll add those. |
|
Hi.
It seems to be working ok with bluetooth with my focus 14 5.71. Did not
try USB yet.
1. paired a new computer (litterally) with it. No driver downloaded or
anything, just paired it from pc settings.
2. NVDA didn't just magicly detect it. I turned the display off and back
on and NVDA still didn't grab it. Turned NVDA off and back on and it
worked. I don't know the keybindings for NVDA at this point but have the
feeling it's still impossible to use a computer from a braille display
exclusively, but what I did know seemed to be working. I can try
specific things if you want.
Cheers:
Aaron Spears, A.K.A. valiant8086. General Partner - Valiant Galaxy Associates "We make Very Good Audiogames for the blind community - http://valiantGalaxy.com"
<Sent with Thunderbird 52.1.0 portable>
…On 10/15/2018 3:49 AM, Marco Zehe wrote:
When I disconnect the USB cable from this display, it turns off,
when I reconnect the cable it turns on and immediately establishes
a USB connection. Is this not the case for your newer display?
It is now with the new try build you just sent. It definitely wasn't
the case with the older build from end of September. The newer display
takes slightly longer to boot, that is, the time display (new to the
newer displays) and the battery status appear a bit later after
connecting the cable than with the older displays. We're talking about
half to 1 second more.
Another interesting observation with this display is that it
switches to a USB connection as soon as the cable is plugged in,
even if you're having an active Bluetooth connection. It seems the
Freedom Scientific driver detects this and switches to USB as
well. I improved braille auto detection to keep scanning for
compatible USB devices for the current driver, even if there is a
Bluetooth connection. So with the following build you can connect
a Focus on Bluetooth, plug in USB and it will switch immediately
and automatically to USB:
https://ci.appveyor.com/api/buildjobs/qqr2tq2m3ncljmfy/artifacts/output%2Fnvda_snapshot_pr1234-6%2C2194af16.exe
Yes, this works fine with my display as well.
I opened a new issue for faster detection of USB device
disconnects. I don't want to hold the driver until that's
implemented and tested with all kinds of displays, so I think it
is best handled in a separate issue/patch.
Sounds good.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7727 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APLbQYfjLl4X_2szov6DmrZGNLjABwrgks5ulD4UgaJpZM4QSB5z>.
|
Braille output and wizWheels are working. Tested on a Focus 40 blue Freedom Scientific braille displays are now supported by braille display auto detection (#7727) When an auto detected braille display is connected via Bluetooth, NVDA will keep searching for USB displays supported by the same driver and switch to a USB connection if it becomes available The bumper keys now work correctly on Freedom Scientific braille displays (#8849) Co-Authored-By: Leonard de Ruijter <leonardder@users.noreply.github.com> fixes #7727 fixes #4464 fixes #8849 fixes #8729
The current driver for Freedom Scientific braille displays uses a DLL from FS to communicate with the displays. To benefit from upcoming improvements to NVDA's braille support such as autodetection (see #1271), a native implementation of this driver is prefered.
I started work on such a driver in the branch at https://github.com/bramd/nvda/tree/freedomscientific-native.
The text was updated successfully, but these errors were encountered: