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

Convert papenmeier braille display drivers to hwIo where possible #7587

Open
LeonarddeR opened this issue Sep 11, 2017 · 12 comments
Open

Convert papenmeier braille display drivers to hwIo where possible #7587

LeonarddeR opened this issue Sep 11, 2017 · 12 comments

Comments

@LeonarddeR
Copy link
Collaborator

In the current situation, we have two Papenmeier drivers, both not utilizing the hwIo module. Using hwIo is a prerequisite for a driver to be included in braille display auto detection (#1271).

Porting papenmeier_serial to hwIo should be relatively easy. See #7581 for a reference pull request that handles such a conversion.

The newer Papenmeier driver confuses me a little. Some questions remain unclear to me:

  1. There are three types of devices in this driver. Displays using brxcom, using pyserial and using ftdi2. Would it be possible to drop brxcom support, for example by using HID to talk to these devices?
  2. If both drivers would be fully native, would it be possible to merge them?
  3. Are there users of these drivers willing to test possible conversions to hwIo?
@jcsteh
Copy link
Contributor

jcsteh commented Sep 12, 2017

@leonardder commented on 12 Sep 2017, 01:14 GMT+10:

Using hwIo is a prerequisite for a driver to be included in braille display auto detection (#1271).

Not quite. The prerequisite is that the driver must be thread-safe; i.e. it is safe to initialise or call the display method from either the main or a background thread.

  • ftdi2 itself is probably thread safe, since it's essentially a serial interface. That would need to be tested though.
  • Using a wx.Timer directly is not thread safe. However, you can get around this by creating and starting the timer in the main thread. core.callLater is probably the simplest way to call something in the main threadafter a delay, but you could roll your own if you needed to. Alternatively, we could create a new thingy which runs a timer in the background thread using waitable timers.
  • Note that using a timer is not ideal, as you're continually waking up NVDA to poll the display, but if that's the only way to do it for these displays, it's not a problem as such (and we're already doing that).

I can't answer any of your other questions, as I don't have any experience with these displays.

@LeonarddeR
Copy link
Collaborator Author

@jcsteh commented on 12 sep. 2017 08:27 CEST:

  • ftdi2 itself is probably thread safe, since it's essentially a serial interface. That would need to be tested though.

Probably, though as I reported in #7459, it isn't that trivial to add Ftdi2 to hwIo.

@Adriani90
Copy link
Collaborator

I know some users of These Braille Displays. I can help out with testings.

@Adriani90
Copy link
Collaborator

Adriani90 commented Jun 7, 2018

To your question 1, according to Papenmeier's userguide for BRAILLEX Live / Live+ / Live20, BRXCom is definitely required to connect those Braille Displays via USB or Bluetooth with the Screen Reader.

@Adriani90
Copy link
Collaborator

to clarify, after talking with someone from Papenmeier, BRXCom is required only for braille displays which have and input keyboard to send input gestures.

@LeonarddeR
Copy link
Collaborator Author

@Adriani90 commented on 8 Jun 2018, 18:27 CEST:

to clarify, after talking with someone from Papenmeier, BRXCom is required only for braille displays which have and input keyboard to send input gestures.

Thanks for this information.
Due to the complexity of the current drivers (support for serial connections, ftdi2 and BRXCom, I won't be able to do something to do the hwIo conversion unless I have a braille display to work with.

@LeonarddeR
Copy link
Collaborator Author

See also #8819.

It would be really helpful if we could get in touch with the original authors of this driver. @jcsteh or @josephsl, could one of you be of assistance in finding them on github? not sure whether @halim and @aliminator are the correct people.

@LeonarddeR LeonarddeR self-assigned this Jun 5, 2019
@LeonarddeR
Copy link
Collaborator Author

I finally got hold of a display with FTDI chip, this is good!

@LeonarddeR
Copy link
Collaborator Author

I've started with an attempt to update the Papenmeier driver to support braille display auto detection. However, the current driver can be considered the most complex driver in core and is coded in a very non object oriented way. Therefore, I don't dare to touch the driver without official protocol documentation from the manufacturer.

@Adriani90: Do you think you could be of any assistance for this?

@Adriani90
Copy link
Collaborator

@LeonarddeR I think programmatically unfortunately I am not as experienced as to help here, but I can certainly establish a contact with the author of this driver, Tobias Platen. he was at the same university like me where I studied until 2015. The guys are really taff in this regard. The university has a center especially for blind and visually impaired people, called Blindenzentrum (BliZ). They have many Papenmeier and other braille displays there.
If you want to establish contact also directly, the university is called
THM - technische Hochschule Mittelhessen.
https://www.thm.de/bliz/en/

@LeonarddeR
Copy link
Collaborator Author

@Adriani90: It would be awesome if you'd be able to establish the first contact. May be they are motivated to update the driver themselves.

I haven't yet officially stopped with the FTDI chip work. The hard part is the papenmeier driver itself really.

@Adriani90
Copy link
Collaborator

Halim might be able to help out in august. I try to reach Tobias Platen. I think he has the most advanced knowledge of the driver.

@LeonarddeR LeonarddeR removed their assignment Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants