Skip to content
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

support for Optelec convertcard #6731

Closed
Bamze66 opened this issue Jan 14, 2017 · 38 comments · Fixed by #7884
Closed

support for Optelec convertcard #6731

Bamze66 opened this issue Jan 14, 2017 · 38 comments · Fixed by #7884
Labels
component/braille p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Milestone

Comments

@Bamze66
Copy link

Bamze66 commented Jan 14, 2017

Hi. I have an braille wouager and a Optelec convertecard wich makes it possible to use braille voyager for newer computers. I am not expert, but as i understand it, the card convert braille voyager and even other older braildisplays from Tieman to a newer protocols like alva.
However this card is working on jaws, Windows eyes, and other screenreaders. However nvda does not work with this card. I believe it is more then me who have this issue, a new brailledisplay is not the cheepest eithem you can buy. so support for this would be an good idea. I am not a programer, but i'm not believe this is an bigger task to fix. That could be integrated in that allready alva drivers wich is allready included in NVDA.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Jan 14, 2017 via email

@Bamze66
Copy link
Author

Bamze66 commented Jan 14, 2017 via email

@dkager
Copy link
Collaborator

dkager commented Jan 14, 2017

I have heard of this card and even seem to recall there being a reason why it it not in NVDA. But I don't know what device ID it uses. We could ping Optelec, unless @jcsteh can shed some light.

@josephsl
Copy link
Collaborator

josephsl commented Jan 14, 2017 via email

@jcsteh
Copy link
Contributor

jcsteh commented Jan 14, 2017 via email

@Bamze66
Copy link
Author

Bamze66 commented Jan 15, 2017 via email

@dkager
Copy link
Collaborator

dkager commented Jan 15, 2017

Could you share the log file:

  • NVDA menu
  • Tools
  • View log
  • Copy the bottom lines, which should say something about an error.

I wonder if our alvaw32.dll is too old. Upgrading this library would add a lot of dependencies if I remember correctly.

@Bamze66
Copy link
Author

Bamze66 commented Jan 15, 2017 via email

@dkager
Copy link
Collaborator

dkager commented Jan 15, 2017

Yeah, it looks to me like the library from Optelec doesn't find the display.

@Bamze66
Copy link
Author

Bamze66 commented Jan 15, 2017 via email

@jcsteh
Copy link
Contributor

jcsteh commented Jan 15, 2017 via email

@gregjozk
Copy link
Contributor

Hi,

discussion about problems with protocol converter can be found at issue #5493, where has been already told, that a newest library is too big to be included in NVDA core... Whatever I still have a problem but as work around I have begun using a BRLTTY also on 64-bit systems when I wanted to use an ALVA Satellite. When I use other screen readers, I use Satellite with protocol converter.
I'm refferencing this to #5493, because the protocol converter supports both Braille Voyager braille displays and Satellite braille displays.

@dkager
Copy link
Collaborator

dkager commented Jan 16, 2017

Fair enough, but is the old (current) library supposed to support the converter?
Is the raw protocol documented anywhere? This might be tricky to get right on Bluetooth.

@Bamze66
Copy link
Author

Bamze66 commented Jan 16, 2017 via email

@gregjozk
Copy link
Contributor

gregjozk commented Jan 16, 2017 via email

@jcsteh
Copy link
Contributor

jcsteh commented Jan 17, 2017

@dkager commented on 17 Jan. 2017, 12:48 am AEST:

Fair enough, but is the old (current) library supposed to support the converter?

I don't know. I assumed so, but that seems not to be the case.

I do know that the converter has a different USB product id. That is, it doesn't show up as a 640 or a 680; it has its own id. I guess the older dll mustn't know about this id.

Is the raw protocol documented anywhere?

I do have the documentation from Optelec, yes. It's not publicly available, though. (Don't get me started on how ridiculous that is.) If someone wants to work on this, I can probably provide it.

This might be tricky to get right on Bluetooth.

I don't think the converter supports Bluetooth? As for the BC640/680, I also have the Bluetooth protocol documentation. Unfortunately, it's a completely different protocol to the one they use for USB.

@gregjozk
Copy link
Contributor

Yes, protocol converter supports only USB, cause this works with displays (Voyager and Satellite), which do not have a BT interface.

@dkager
Copy link
Collaborator

dkager commented Jan 17, 2017

I have a BC6, so I could give this a shot. But a few remarks first:

  • It is not completely certain that the DLL is the culprit. I could ask Optelec about it, we also had contact last year when I extended the BC6 keymap.
  • I am not experienced enough in this to do it without looking at an existing driver. Maybe the one for the Brailliant BI?
  • Or is the user base small enough to justify an addon with latest DLL? In The Netherlands there are still quite a few users of this display, so that would increase the threshold a bit for them.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Jan 17, 2017 via email

@jcsteh
Copy link
Contributor

jcsteh commented Jan 17, 2017

@dkager commented on 17 Jan. 2017, 5:32 pm AEST:

  • It is not completely certain that the DLL is the culprit. I could ask Optelec about it, we also had contact last year when I extended the BC6 keymap.

I do have contacts at Optelec, but we haven't had any contact since the merge with VFO. I can try poking them if need be.

  • I am not experienced enough in this to do it without looking at an existing driver. Maybe the one for the Brailliant BI?

brailliantB is probably the best driver to start with. It has to support both HID and Bluetooth serial and uses the new hwIo stuff for both.

  • Or is the user base small enough to justify an addon with latest DLL? In The Netherlands there are still quite a few users of this display, so that would increase the threshold a bit for them.

It isn't an ideal solution, but nor is the current situation. I'll discuss with others here. We do have a BC640, though it's not currently with me at the moment.

@leonardder commented on 17 Jan. 2017, 5:34 pm AEST:

An add-on with dll doesn't have to mean that we have to throw away the
driver in core. The add-on can just replace the driver in core IMO.

I disagree. It is difficult to explain, will confuse users and will thereby create additional support load.

@dkager
Copy link
Collaborator

dkager commented Jan 18, 2017

I wonder if there would be any other benefits to a Python-based driver. For me as BC640 user support for the converter card isn't very interesting. But maybe something like automatic reconnect or thread safety.
If nothing else I'll gladly test the new driver if it is realized. Maybe poking VFO is a good idea. Your contacts are probably better than mine. :)

@gregjozk
Copy link
Contributor

gregjozk commented Jan 18, 2017 via email

@jcsteh
Copy link
Contributor

jcsteh commented Jan 18, 2017 via email

@LeonarddeR
Copy link
Collaborator

Related issue: #7733.

@LeonarddeR
Copy link
Collaborator

This will be covered by #7733. I'm not treating this issue as duplicate though, since it covers a specific case which is currently not available in NVDA, whereas other Alva users can already use most if not all functions of their displays.

@LeonarddeR
Copy link
Collaborator

@Adriani90 reported in #1586 that the Converter Card isn't working as expected.

It would be really helpful if we could have a log file of what's going wrong when trying to connect to the particular Voyager display you mentioned. Would you or the user your mentioned be able to retrieve a log with debug logging enabled? To have as much debug information as possible, please also do the following

  1. Open a python console (nvda+control+z)

  2. Paste the following in the console, and press enter:
    import config; config.conf['debugLog']['hwIo']=True

  3. Try to connect to the Voyager using the new Optelec driver.

@LeonarddeR
Copy link
Collaborator

@gregjozk: Do you still have no possibilities to test this device?

@LeonarddeR LeonarddeR added the p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Feb 26, 2018
@LeonarddeR
Copy link
Collaborator

@michaelDCurran: I labeled this p2, since the converter card is promised to work in 2018.1, and it looks like it doesn't, though we followed the protocol and there aren't issues with native BC devices. I think it should at least be a show stopper for a release of 2018.1 until we've found out what's causing the problem reported by @Adriani90

@LeonarddeR
Copy link
Collaborator

Here is a try build that is likely to fix this issue.

@Adriani90
Copy link
Collaborator

Dear all,

first of all sorry for the delay. We had to conduct more testings. I am unfotunately not allowed to upload things at this time, so I will paste the Content of the log files in here. But this should not be a Problem because searching for the "alva" or "enter" will bring you to the relevant results.

@Adriani90
Copy link
Collaborator

Adriani90 commented Mar 1, 2018

First file: NVDA 2017.4, Braille extender addon installed, alvaw32.dll replaced by .dll as of 04.12.2013:

Edit by @LeonarddeR: Removed log snippet.

@Adriani90
Copy link
Collaborator

As you can see, the Display works.

@Adriani90
Copy link
Collaborator

Adriani90 commented Mar 1, 2018

File 2: NVDA Try Build provided by @LeonarddeR, alvaw32.dll has not been replaced:

Edit by @LeonarddeR: Removed all irrelevant information

DEBUG - hwIo.Hid.__init__ (08:53:44.372):
Opening device \\?\hid#vid_0798&pid_0699&col01#7&14bb817d&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
DEBUG - hwIo.Hid.__init__ (08:53:44.410):
Report byte lengths: input 3, output 43, feature 16
DEBUG - hwIo.Hid.getFeature (08:53:44.411):
Get feature: '\x05\x00\xf4\x00\x04\x00,\x00\x00\x00\x00\x00\x00\x00\x00\x00'
DEBUG - hwIo.Hid.getFeature (08:53:44.411):
Get feature: '\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
ERROR - braille.BrailleHandler.setDisplayByName (08:53:44.411):
Error initializing display driver
Traceback (most recent call last):
  File "braille.pyc", line 1569, in setDisplayByName
  File "brailleDisplayDrivers\alva.pyc", line 194, in __init__
  File "brailleDisplayDrivers\alva.pyc", line 146, in _updateSettings
  File "brailleDisplayDrivers\alva.pyc", line 303, in _handleTime
ValueError: year is out of range
INFO - braille.BrailleHandler.setDisplayByName (08:53:44.477):
Loaded braille display driver noBraille, current display has 0 cells.

@Adriani90
Copy link
Collaborator

Adriani90 commented Mar 1, 2018

The same result can be obtained when replacing the alvaw32.dll with the alvaw32.dll from 04.12.2013.

So, the value error says "year out of range".

Since it could be related to the addon Braille extender as well, @andre9642, do you have any workarounds in your addon for such cases?

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Mar 1, 2018 via email

@LeonarddeR
Copy link
Collaborator

@Adriani90, could you please test this build? Just to make sure, it is not necessary to perform tests regarding the unused dll.

@Adriani90
Copy link
Collaborator

Adriani90 commented Mar 1, 2018 via email

@LeonarddeR
Copy link
Collaborator

Outstanding problems should have been fixed in NVDA 2018.1RC2. Closing this again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/braille p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
9 participants