Native driver for Eurobraille Esys displays

[leonardder]

Formally a duplicate of closed #5176, but that one specifically talks about including the current add-on based driver by Eurobraille.

I wonder, has a native driver been considered, either by Eurobraille, NV Access or a third party? The current add-on based driver has the following issues:

1. Slow response for several keys, including routing and scrolling. This also occurs in JAWS and Supernova, probably an issue in a common part of the current driver
2. No native integration for the Esys braille keyboard, so NVDA's braille input does not work
3. When trying to initialize the driver without a display connected, it takes ages to time out. Even when a display is connected, there is a bug which causes the display not always being detected properly.

[zstanecic]

@leonardder 1Slow response for several keys, including routing and scrolling. This also occurs in JAWS and Supernova, probably an issue in a common part of the current driver
Does it works better in window eyes or either cobra?
2No native integration for the Esys braille keyboard, so NVDA's braille input does not work
Is this thingie working in another screenreaders?
And... another thing: have you tried to contact eurobraille, and report the problem, because it can be error in the protocol, or the firmware itself. This display is used in Croatia, too, so uf there is native implementation in the plans, i can contact some people, with the distributor itself, as i know who sells this display in croatia.

[dkager]

Could (1) be a firmware issue?

[leonardder]

@dkager commented on 12 aug. 2017 12:30 CEST:

Could (1) be a firmware issue?

No. There is a tool by Eurobraille called Esyview, which registers key presses on the device. Performance for this tool is ok.

[gregjozk]

Hi,

anyone who would contact Eurobraille must have had a lot of luck :) When I tried to contact them and report problems with their driver back, they have not responded.

Regards, Jožef

[leonardder]

@leonardder commented on 12 aug. 2017 13:28 CEST:

@dkager commented on 12 aug. 2017 12:30 CEST:

Could (1) be a firmware issue?

No. There is a tool by Eurobraille called Esyview, which registers key presses on the device. Performance for this tool is ok.

Coming back to this, it seems, at least for the cursor routing, it yet turns out to be a firmware problem. Ugh.

[leonardder]

@gregjozk commented on 14 aug. 2017 05:28 CEST:

Hi,

anyone who would contact Eurobraille must have had a lot of luck :) When I tried to contact them and report problems with their driver back, they have not responded.

Regards, Jožef

It seems they are giving preference tho their own add-on, which is 18 megs in size and doesn't care about NVDA's input layer, except for cursor routing.

@zstanecic commented on 11 aug. 2017 14:38 CEST:

Does it works better in window eyes or either cobra?

I'm unable to test this, but this is very unlikely.

Is this thingie working in another screenreaders?

Yes, this at least works in BRLTTY and VoiceOver. I belief that for JAWS and SuperNova, their own input layer is used.

And... another thing: have you tried to contact eurobraille, and report the problem, because it can be error in the protocol, or the firmware itself. This display is used in Croatia, too, so uf there is native implementation in the plans, i can contact some people, with the distributor itself, as i know who sells this display in croatia.

There has been contact with Eurobraille about this, yes.

[leonardder]

I'm glad to tell you that @BabbageCom has reached accordance with Eurobraille about creating a native driver. I will start with a driver on behalf of Babbage in the near future.

[leonardder]

There is a first driver to test in the @BabbageCom eurobraille-native branch. I will probably be able to create a pr in one of next weeks.

[zstanecic]

Hi @leonardder, can you give me the try build, as we have users in croatia, wich use the esys displays? W dniu 30.10.2017 o 17:04, Leonard de Ruijter pisze:

…

There is a first driver to test in the @BabbageCom <https://github.com/babbagecom> eurobraille-native branch. I will probably be able to create a pr in one of next weeks. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7488 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKohkwU5vj-RsVHF02G5KO59n3ANHiB9ks5sxfN4gaJpZM4O0ivl>.

[leonardder]

I'm afraid this is not ready for that broad testing. May be later this week.

[leonardder]

There is a try build at the following URL:
https://ci.appveyor.com/api/buildjobs/sfk9lihn6whmc4qg/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14595%2C02990ab1.exe

This try build has the issue that. when using a device with recent firmware, the output for a device gets into a locked up state. This state can be resolved with a restart of NVDA, not by re-initiating the device from the braille settings dialog. We are currently working together with Eurobraille to get a fix for this.

[aaclause]

Hello,
I've been tested with an Esys. It works like a charm.
Well, it's now possible to change the input braille table and gestures! :)
Thanks

[clementb49]

Hello,
I just tested this driver with an Esytime on the firmware 1.06 and I get the following error.

Traceback (most recent call last):
  File "hwIo.pyc", line 127, in _notifyReceive
  File "brailleDisplayDrivers\eurobraille.pyc", line 287, in _onReceive
  File "brailleDisplayDrivers\eurobraille.pyc", line 326, in _handleSystemPacket
TypeError: ord() expected a character, but string of length 0 found
ERROR - braille.BrailleHandler.setDisplayByName (20:20:08.566):
Error initializing display driver
Traceback (most recent call last):
  File "braille.pyc", line 1547, in setDisplayByName
  File "brailleDisplayDrivers\eurobraille.pyc", line 236, in __init__
  File "brailleDisplayDrivers\eurobraille.pyc", line 383, in _sendPacket
  File "hwIo.pyc", line 89, in write
WindowsError: [Error 87] Paramètre incorrect.
INFO - braille.BrailleHandler.setDisplayByName (20:20:08.632):
Loaded braille display driver noBraille, current display has 0 cells.

[leonardder]

@clementb49: This is interesting. Could you test another try build with the log level on debug warning?
https://ci.appveyor.com/api/buildjobs/j06by9jnwdhnbbxv/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14596%2C04361f93.exe

My hypothesis is that the driver is connecting to the wrong HID interface.
Also, it would be very helpful if you could start a python console (nvda+control+z, and provide me the result of the following line of code.

import hwPortUtils; list(hwPortUtils.listHidDevices())

In case you don't know, from the python console, you get into the output pane by pressing f6.

[clementb49]

Hello
I tested the new build. Here is the log in debug mode:

accRole failed: (-2147024809, 'Param\xe8tre incorrect.', (None, None, None, 0, None))~~~

And the result of python console after executing the line. 
~~~>>> import hwPortUtils; list(hwPortUtils.listHidDevices())
[{'usbID': u'VID_C251&PID_1130', 'devicePath': u'\\\\?\\hid#vid_c251&pid_1130&mi_00#7&1f91b224&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VID_C251&PID_1130&REV_0100&MI_00'}, {'devicePath': u'\\\\?\\hid#atk4002#3&2f32b022&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VEN_ATK&DEV_4002'}, {'usbID': u'VID_C251&PID_1130', 'devicePath': u'\\\\?\\hid#vid_c251&pid_1130&mi_02#7&73db74b&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VID_C251&PID_1130&REV_0100&MI_02'}, {'usbID': u'VID_C251&PID_1130', 'devicePath': u'\\\\?\\hid#vid_c251&pid_1130&mi_01#7&32c1ce62&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VID_C251&PID_1130&REV_0100&MI_01'}, {'devicePath': u'\\\\?\\hid#elan1200&col01#5&150f7c31&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VEN_ELAN&DEV_1200&Col01'}, {'devicePath': u'\\\\?\\hid#elan1200&col02#5&150f7c31&1&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VEN_ELAN&DEV_1200&Col02'}, {'devicePath': u'\\\\?\\hid#elan1200&col03#5&150f7c31&1&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}', 'hardwareID': u'HID\\VEN_ELAN&DEV_1200&Col03'}]~~~

[leonardder]

@clementb49 commented on 7 nov. 2017 11:17 CET:

accRole failed: (-2147024809, 'Param\xe8tre incorrect.', (None, None, None, 0, None))~~~

This debug warning is unrelated. Do you still experience the same errors as before with this build?

What makes it a bit difficult here is that there are at least three HID devices corresponding with the matching in the driver. However, the logging should provide that information as well.

[leonardder]

@clementb49: Could you please provide a full log including all debugWarnings and errors for the following try build? You may also sent your log to leonard_dev at babbage dot com.

https://ci.appveyor.com/api/buildjobs/mwa0huhklyw5ftfq/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14597%2C7d59f663.exe

[leonardder]

I've been able to track the issue down, so this new try build should work:
https://ci.appveyor.com/api/buildjobs/neym15rmykr1fq64/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14602%2Ca21cb782.exe

@clementb49: Thanks a lot for your help.

There is one known issue with this build for esytime, it will print a debug warning in the log about a packet being ignored. This is expected and will be dealt with in a new build if that has to be made.

[leonardder]

Here is a new try build for Eurobraille displays:

https://ci.appveyor.com/api/buildjobs/lh7ch81jysq61q5b/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14624%2C539d139b.exe

This driver implements many more keyboard assignments, not yet added to the user guide. Also, scrolling is implemented for Esytime and Iris, as well as other functions.

[aaclause]

Hello,
Why put these gestures there?

"kb:1": ("br(eurobraille):dot1+dot6+backspace",),
"kb:2": ("br(eurobraille):dot1+dot2+dot6+backspace",),
"kb:3": ("br(eurobraille):dot1+dot4+dot6+backspace",),
"kb:4": ("br(eurobraille):dot1+dot4+dot5+dot6+backspace",),
"kb:5": ("br(eurobraille):dot1+dot5+dot6+backspace",),
"kb:6": ("br(eurobraille):dot1+dot2+dot4+dot6+backspace",),
"kb:7": ("br(eurobraille):dot1+dot2+dot4+dot5+dot6+backspace",),
"kb:8": ("br(eurobraille):dot1+dot2+dot5+dot6+backspace",),
"kb:9": ("br(eurobraille):dot2+dot4+dot6+backspace",),
"kb:0": ("br(eurobraille):dot3+dot4+dot5+dot6+backspace",),
"kb:,": ("br(eurobraille):dot2+backspace",),
"kb:/": ("br(eurobraille):dot3+dot4+backspace",),
"kb:*": ("br(eurobraille):dot3+dot5+backspace",),
"kb:-": ("br(eurobraille):dot3+dot6+backspace",),

[leonardder]

@Andre9642 commented on 16 nov. 2017 19:01 CET:

Why put these gestures there?

Good point, they came straight from a document from Eurobraille, but I realised they should be numpad keys. I will implement those in a next build.

[leonardder]

Here is a new build just before the weekend. I also updated the user guide according to the new key assignments added recently:
https://ci.appveyor.com/api/buildjobs/34bho3pstoq3xe2q/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14629%2C21e62bee.exe

To clarify, I'm creating try builds regularly for Eurobraille to test internally as the driver requires an added parameter for hwIo.Hid.

[leonardder]

Here is a try build again. If the feedback is positive, I will file a pull request this week:
https://ci.appveyor.com/api/buildjobs/1sjk0dwsij4pd0hx/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14686%2C309df283.exe

[clementb49]

Hello, I tested this build on an Esytime Evolution, and it's almost perfect, except a few details.
The L5 key should be used to advance the current line according to the braille display width.
The L6 key is used for Insert/NVDA menu.
The L7 is for Alt and L8 is for Control.
Next, L2+L3 key combination generates Windows key, and finally L2+L4 is for Context Menu.
If you could remap those keys, it would be great.
Thank you for your had work.

[leonardder]

@clementb49 commented on 6 dec. 2017 15:59 CET:

If you could remap those keys, it would be great.

I could, however the point is that I follow the key assignment as Eurobraille prescribed them to me. Are the current assignments in any way not intuitive as defaults?

[clementb49]

Hi Leonard,
Yes, they are not intuitive at all. The trick is that Esytime L5-L8 keys are disposed from back to front of the device. So, it differs from all other Eurobraille devices where they are from left to right. When keyboard is in HID mode, everything is fine except for L8 (which I had to remap manually to L5, because the keyboard firmware automatically replace it by a press to Control, so I couldn’t advance on the current line). If you can, you should differenciate Esytime from other devices to install proper key assignments.
Regards.

[leonardder]

@clementb49: Could you tell whether the build below improves things for you?
https://ci.appveyor.com/api/buildjobs/fydjo354xn379p66/artifacts/output%2Fnvda_snapshot_try-eurobraille-native-14717%2C16f8c522.exe