Braille Display Driver for the BrailleNote family of products

[nvaccessAuto]

Reported by on 2011-12-26 19:42
Braillenote is a wellknown notetaker from Pulsedata, now humanwhare that supports a braille terminal mode.
There are models with 18 and 32 cells and with braille and qwerty keyboards. There are many generations of the braillenote (classic, mPower, Apex and maybe more). I have only access to a Braillenote bt 32, that is, the classic model with 32 cells and a braille keyboard. The device communicates through the serial port. newer models have USB ports too but I didn't find any information about protocol changes and such. The only description is found in BRLTTY source package for the serial protocol used by the brailleNote classic bt. Maybe newer models work with the same protocol but I'm not sure... Also no idea about what keys the qwerty keyboard units return.

BrailleNote website: http://www.humanware.com/en-usa/products/blindness/braillenotes
The braillenote implementation of its own protocol have some bugs, one is that when pressing dot7 or dot8 the unit reports that was pressed space+dot7 or space+dot8. Moreover many key combinations are intersepted by the unit and are not sent to the computer.

The attached driver works very well with my Braillenote unit. Cursor routing keys and thumb keys are mapped to NVDA functions as close as possible to the braillenote ones. Braille keyboard keys are mapped to keyboard key presses simulating many navigation tasks: arrows, pageup up and down, end, home, tab, shift tab, showGui and such. pressing H activates and deactivates keyboard help and default combinations can be tested.

Keynames used are the following:

• tprevious, tback, tadvance, tnext for the four thumb keys (from left to right).
• d1...d8 to braille keyboard dots (backspace is d7 and enter d8).
• Space to spacebar.

Gesture.ini changes work with these names.

More testing is needed I think. However I supose it is stable to be included in snapshots for testing purposes, if you think this is to be included in NVDA main distribution. If there is a serial communications error the driver stops communicating so NVDA is not flooded with errors. Tested with main-4852.

Hope this helps someone.

Comments and sugestions are wellcome.

Rui Batista
Blocked by #426
Blocking #2857

[nvaccessAuto]

Attachment brailleNote.py added by ragb on 2011-12-27 21:13
Description:
Braillenote brailleDisplay driver.

[nvaccessAuto]

Comment 1 by jteh on 2011-12-28 22:59
If this uses a serial port, how do you specify which port? As a general rule, we've chosen not to support serial displays in NVDA, as it requires too much technical understanding and configuration by the user, which in turn makes the user interface more complicated.

[nvaccessAuto]

Comment 2 by ragb (in reply to comment 1) on 2011-12-28 23:24
Replying to jteh:

If this uses a serial port, how do you specify which port? As a general rule, we've chosen not to support serial displays in NVDA, as it requires too much technical understanding and configuration by the user, which in turn makes the user interface more complicated.

For now I'm checking all COM ports (name.startswith("COM")) and prob for the status tag on the braillenote. If the device answers with what is expected accordint to the protocol I consider that it is a braillenote. Obviously this is not a perfect solution. Asking the user to choose the COM port can be an option (config file? GUI?) but has you say it his too much technical. And it has another problem: using USB to serial converters the COM pport number can change when you plug and unplug the converter device.

Although I truly understand your point, I think that not supporting serial communications can prevent the usage of some old braille displays with NVDA. Many libraries and schools here in Portugal have displays of this kind (not the braillenote but others from thiemen and other brands). BRLTTY is an option but it is not user friendly though.

[nvaccessAuto]

Comment 3 by ragb (in reply to comment 2) on 2012-01-02 13:23
Replying to ragb:

Replying to jteh:

If this uses a serial port, how do you specify which port? As a general rule, we've chosen not to support serial displays in NVDA, as it requires too much technical understanding and configuration by the user, which in turn makes the user interface more complicated.

Although I truly understand your point, I think that not supporting serial communications can prevent the usage of some old braille displays with NVDA. Many libraries and schools here in Portugal have displays of this kind (not the braillenote but others from thiemen and other brands). BRLTTY is an option but it is not user friendly though.

More on this issue: on the dev list some user wanted to connect a baum display using rs232 (or an usb to serial converter).

http://lists.nvaccess.org/pipermail/nvda-dev/2012-January/023133.html

My personal opinion is that it is better to have same way to configurre serial ports than making impossible the usage of serial braille displays. My suggestion would be something like per-braliedisplay additional settings lie we have for speech. Do you think it is worth a new ticket?

[nvaccessAuto]

Comment 4 by jteh on 2012-01-02 22:17
There's already a ticket for serial displays: #426. Aside from the difficulty in configuration as already mentioned, this would also make auto detecting displays impossible in the future. Probing serial ports is dangerous and could cause unexpected side effects with other devices. In addition, the support load would be increased, as many users would not understand how to configure these displays. Finally, introducing display specific settings is pretty tricky because the driver would have to be loaded and initialised before the new settings could appear, which obviously isn't possible if the display hasn't been configured yet (chicken and egg situation). It isn't a problem for speech synths because they can function with default settings.

BRLTTY isn't user friendly, but nor is finding and configuring serial ports. This is why I don't see BRLTTY as a problematic option for serial displays. Both require extra knowledge and configuration.

[nvaccessAuto]

Comment 5 by ragb on 2012-11-03 12:02
If #426 gets implemented, I think the driver can be included in NVDA core (instead of beeing an add-on). It would be also good supporting newer models of the braillenote, but I need testers or a device to hack on, which seems both dificult to find :).

Adding blocking information ad reassigning to me 8since I have a device here to text with).

[nvaccessAuto]

Comment 6 by nvdakor on 2012-11-03 17:05
I have an Apex which I would be happy to test our development code. However, I think we should leave BN driver as an add-on, as all we could do at this stage is an abstract implementation, as different serial devices use different settings.
I think we need to do the following:

• Contact NvDA support list to see if there are any serial display users. I'm sure at least one of them is a programmer who can help us with this task.
• Once we find some testers, we can gather their input and start implementing the necessary code.
• For ports, we might also need to probe available Bluetooth com ports and present them in the list of ports (I'll write a basic User Guide description of the port settings in the userGuide.t2t).
  Thanks.

[nvaccessAuto]

Comment 7 by jteh (in reply to comment 6) on 2012-11-05 00:07
Replying to nvdakor:

I think we should leave BN driver as an add-on, as all we could do at this stage is an abstract implementation, as different serial devices use different settings.

I don't follow. The driver can just probe with different serial settings. Surely, each model of display has predefined serial settings?

• For ports, we might also need to probe available Bluetooth com ports and present them in the list of ports (I'll write a basic User Guide description of the port settings in the userGuide.t2t).

That should already happen. However, if there's a predefined bluetooth name pattern for each model of device, we can auto-scan based on this name.

[nvaccessAuto]

Comment 8 by ragb (in reply to comment 7) on 2012-11-05 11:39
Replying to jteh:

Replying to nvdakor:

I think we should leave BN driver as an add-on, as all we could do at this stage is an abstract implementation, as different serial devices use different settings.

I don't follow. The driver can just probe with different serial settings. Surely, each model of display has predefined serial settings?

I don't follow either. The current driver only supports classic braillenote devices, which have predefined baudrate and parity settings (38000bps, odd parity and 1 stop bit, if I remember correctly). Moreover, I don't know of any display that can be configured to use different serial port settings... However we probbly are talking about different problems.

• For ports, we might also need to probe available Bluetooth com ports and present them in the list of ports (I'll write a basic User Guide description of the port settings in the userGuide.t2t).

That should already happen. However, if there's a predefined bluetooth name pattern for each model of device, we can auto-scan based on this name.

That's what we do already. Some people already pointed out that some devices (mainly notetakers) might have different ames, but I don't know about serious complains for this or specific examples. But I think this is out of scope of this ticket.

[nvaccessAuto]

Comment 9 by nvdakor on 2012-11-25 10:18
Hi,
Now that I have my unit back, I decided to respond today:
For notetakers with different names: yes, some Apex users prefer to change their device name to something other than ApexNNNNNN where NNNNNN is the serial number of the device e.g. mine is 000723, so my device name would be Apex000723.
So, in case of newer displays apart from Classic, we could ask that we tweak the settings for pK and mPower (PK is a special case, as it is a rebranded Pronto from Baum), with people asked to use serial port (if #426 comes to life). For Bluetooth connection (for mPower and pK), we could ask users to change the device name to "braillenote" or "braillenote pk" so the probing algorithm can find it easily, as it was done with Brailliant and Focus series.
For Apex, there are three possibilities:

• Serial port: Again, this depends on whether Support for serial braille displays #426 comes to fruition; however Apex doesn't have a serial port, hence one needs to use a USB to serial converter specifically made for the Apex. Luckily, I have such a converter and a machine with serial port, so I can help you with testing.
• USB client: one can install Apex USB client driver and find the virtual com port.
• Bluetooth: just like iPhone method (where VoiceOver searches for devices with predetermined string for its name), we could use the same method to find Apex (just search for a device with the string name of apex within a device name string).
  Of these three, I think Bluetooth would be the easiest, followed by serial and USB client.
  I'll ask HumanWare to contact you if you wish to talk to them (or, I think talking to HW Europe or Austrailia would be helpful). In the conversation, you could ask them to provide you with keycodes for QT so we can also implement QT support.
  as for command structure, recent versions of KeySoft has "bypass" command where pressing the next command would allow the screen reader to execute a command that would have been captured by KeySoft. This allows us to expand our command structure and prepare for eventual implementation of Support for entry of computer braille via a braille keyboard #808 and contracted braille entry by assigning NVDA commands to use space bar, backspace and enter keys. Also, I think we could use this time to reassign some BN-NVDA keys to follow braille gesture assignments for other displays and to closely mirror that of native KeySoft commands (I'm sure you have the BN Apex's command summary; if not, I'll send it to you privately).
  Thanks.

[nvaccessAuto]

Comment 10 by jteh (in reply to comment 9) on 2012-11-25 10:27
This is still unclear to me:
Replying to nvdakor:

For notetakers with different names: yes, some Apex users prefer to change their device name to something other than ApexNNNNNN where NNNNNN is the serial number of the device

As you note below, as long as the user can't remove the "Apex" prefix, we'll be fine. If they can, we won't be able to do automatic Bluetooth detection.

For Bluetooth connection (for mPower and pK), we could ask users to change the device name to "braillenote" or "braillenote pk" so the probing algorithm can find it easily,

So there is no built-in name prefix that doesn't change?

[nvaccessAuto]

Comment 11 by nvdakor on 2012-11-25 10:54
Hi,
By default, the names of these devices are:

• mPower: braillenote
• PK: braillenote pk
• Apex: apexNNNNNN
  Users can change these names from Options/connectivity under KeySoft. However, as some Apex users use it as a display under iOS, they will need to keep the default name. If we tell NVDA users that they need to name their units using the default name string, it would be fine (as you said above).
  I sent an email to Matthew Janusauskas (mjanusauskas) at HW and told him to contact the NVDA devs involved if you need a word from the maker itself. Thanks.

Changes:
Changed title from "Braille Display Driver for the Braillenote" to "Braille Display Driver for the BrailleNote family of productsn"

[nvaccessAuto]

Comment 12 by jteh on 2012-11-25 11:01
Let me try to ask this more clearly. I realise users can change the name, but can they change it completely or is there always part of it that stays constant? The reason I ask is that on Baum displays and on the new !HumanWare Brailliant B series, you can change the last part of the name, but the prefix stays the same, so detection is never broken. For example, mine is "HWG Brailliant Jamie". Even though I could customise the last bit (normally the serial number) to "Jamie", I can't customise the "HWG Brailliant" bit. From what you've said, I'm guessing this isn't the case for !BrailleNote, but I just want to be certain.

[nvaccessAuto]

Comment 13 by nvdakor on 2012-11-25 11:06
Hi,
Oh that - my apologies...
Yes, the user can change the entire string - that is, a user can change the name of an Apex from apexNNNNNN to something like "joslee" (without quotes).
I could ask a KeySoft developer at HW to see if Apex (or even mPower or PK) returns any (fixed" string (just like Brailliant Bi series). Thanks.

[nvaccessAuto]

Comment 14 by ragb (in reply to comment 13) on 2012-11-25 12:52
Replying to nvdakor:

Yes, the user can change the entire string - that is, a user can change the name of an Apex from apexNNNNNN to something like "joslee" (without quotes).

I could ask a KeySoft developer at HW to see if Apex (or even mPower or PK) returns any (fixed" string (just like Brailliant Bi series). Thanks.

If you have access to keysoft developers, you may ask a more important question: does the pk, mpower and apex, use the same communication protocol as the classic units? Moreover, if they support US communication, we may ned to know evice hardware and such so we know where to connect.

The only reason this driver only supports the classic braillenotes is that I only have access to to on e of those (and, untill June, it was the only display available to me).

[nvaccessAuto]

Comment 15 by nvdakor on 2012-11-25 13:04
Hi Rui,
I told the KS dev to contact Jamie so both parties can talk about this task. If you would like to contact HumanWare, the email address is support@humanware.com; or, if you wish to talk to one of the KS devs, his name is Alex Bec, and his address is alex.bec@humanware.com. In the email, I asked him if there are any differences between Classic, mPower, PK and Apex as far as serial communication is concerned and about protocols, including BT device name and considerations when using USB client (in case of Apex).

[nvaccessAuto]

Comment 16 by jteh on 2012-11-25 21:32
Rui, I have a fairly recent version of the Braillenote protocol specification which i can send you privately.

[nvaccessAuto]

Comment 17 by ragb on 2012-11-26 04:19
i,

Looking at the braillenote protocol and the message from HW developer, I can tell the following:

• Implementing bluetooth support seems quite trivial, given the bluetooth name follow some pattern (brailleNote pk or something). We can tell the user that the name must sttart with a given string. In any case, we may remove the filtering out of bluetooth ports (see NVDA should work without audio output #425) so a bluetooth port can be used as a serial port.
• I'm not quite sure of the protocol details for the QT models (i.g. if they work on older braillenote qt or anything), neither what are these new weel thing all about (probably something like the focos schroll weels, but it is just a guess). Are there much user interest on this?
• hey don't say how we can communicate to the braillenote using USB client, that is, we need details about port names, hardware ids or if their driver provides any higher level API.
• Either than bluetooth support and USB connection (if more USB details are available), I think we will probably need access to some units to implement and test the protocol. At least a BT and a QT unit, if it is decided to support qwerty keyboard entry (I'm not sure of if that is really needed or not). I can check with the local dealer if they borrow me an Apex unit, but I very much dobt it.

Rui Batista

[nvaccessAuto]

Comment 18 by nvdakor on 2012-11-26 19:52
Hi,
Scroll wheel can be thought of as a combination of whiz wheels and function keys.
Description: a circle with four tactile buttons on the top, left, right and bottom. A wheel with six ridges is at the center with a center button in the middle.
In normal KeySoft functions, this wheel acts as a scroll - turning the circle clockwise would move down through a list or a file, while turning it counterclockwise would do opposite action. The tactile buttons are used for carrying out some functions, including top and bottom of file, exit and context changes. The center button is the enter key.
In current driver (at least with JfW), the four tactile buttons are assigned to arrow keys (up, down, left and right), with the center button assigned to enter key. The wheel scroll action is assigned: clockwise is down arrow, counterclockwise is up arrow, respectively.
The QT entry came with KeySoft 9.2 for Apex (as far as I know). However, QT can switch between QWERTY and braille keyboard input mode.
I think, for now, we could tell QT users to use their keyboard as braille keyboard. Eventually, if enough interests are there, we could provide a mechanism to use QWERTY keyboard (this also means we can support Braile Sense Plus/U2 QWERTY).

[nvaccessAuto]

Comment 19 by nvdakor on 2012-11-26 19:53
Hi,
For device names:

• mPower: braillenote (I'm not sure if our NVDA source can distinguish between lowercase and uppercase letters).
• PK: braillenote pk.
• Apex: apexNNNNNN (where six N's are the last six digits of the serial number), so we can search for the name "apex".

[nvaccessAuto]

Comment 20 by ragb (in reply to comment 19) on 2012-11-26 22:01
Replying to nvdakor:

Hi,

For device names:

• mPower: braillenote (I'm not sure if our NVDA source can distinguish between lowercase and uppercase letters).
• PK: braillenote pk.
• Apex: apexNNNNNN (where six N's are the last six digits of the serial number), so we can search for the name "apex".

I can't implement support for this. Are you able to test the braillePorts branch with a bluetooth-capable braillenote?

[nvaccessAuto]

Comment 21 by nvdakor on 2012-11-27 01:21
Hi,
Yes, I can test braillePorts branch (I did a normal checkout of that branch), and yes, I have an Apex which I'm using it as a braille display (via BRLTTY) via Bluetooth connection.

[nvaccessAuto]

Comment 22 by ragb (in reply to comment 21) on 2012-11-27 12:27
Replying to nvdakor:

Hi,

Yes, I can test braillePorts branch (I did a normal checkout of that branch), and yes, I have an Apex which I'm using it as a braille display (via BRLTTY) via Bluetooth connection.

Ok. Please update your branch. In change set:braillePorts:5606 I added untested support for automatic bluetooth port detection. Please see if it works. If not please attach the log.
If no automatic port selection is show, please try the emulated bluetooth serial port (it should show on the ports list on braille settings dialog).

[nvaccessAuto]

Comment 23 by nvdakor on 2012-11-27 22:32
Hi,
Test was a success - NVDA finds Apex (you need to specify the com port in use).
To prepare for implementation of #808, I propose that we revise majority of commands to follow that of other displays, namely avoiding alphanumeric keys (that is letter keys so that most of the commands can be executed using keys with space, dot 7 or dot 8). I'll do more testing (including emulating QT set using a USB keyboard attached to my Apex), and I'll write back to you.

[nvaccessAuto]

Comment 24 by jteh (in reply to comment 23) on 2012-11-27 23:37
Replying to nvdakor:

Test was a success - NVDA finds Apex (you need to specify the com port in use).

That suggests automatic Bluetooth detection failed. It's slightly possible you have a non-Microsoft Bluetooth stack, in which case this isn't a problem with the new code.

[nvaccessAuto]

Comment 25 by jteh on 2012-11-28 04:42
Actually, the problem is possibly that the Bluetooth name in the code is lower case, but I think Joseph noted it has an upper case a ("Apex").

[nvaccessAuto]

Comment 26 by jteh on 2012-11-28 05:09
Changes:
Milestone changed from None to 2013.1

[nvaccessAuto]

Comment 27 by nvdakor (in reply to comment 26) on 2012-11-28 05:29
Replying to jteh:

Try "APEX" (all caps). In either case, I think we should let users choose com port. Also, if you don't mind, I'd like to attach a txt file containing proposed gestures for BN under NVDA (with provisions for QT commands to be implemented later; well, let's focus on BT).
Also, I think we should ask some BN mPower and Apex users to test this branch so they can give you and Rui some feedback.

[nvaccessAuto]

Comment 28 by ragb (in reply to comment 27) on 2012-11-28 14:09
Replying to nvdakor:

Replying to jteh:

Try "APEX" (all caps). In either case, I think we should let users choose com port.

Ok, change. Please test and see if the automatic port option is shown. I agree users should choose comport, since they may want to change their device's name for some reason and there is no reason for we to filter out bluetooth serial ports, since choice is explicit.

Btw, if you connect your APEX using USB, does it apear ann aditional comport on the list?
If so, please enter the following code on the NVDA's console and past here the output

import hwPortUtils
list(hwPortUtils.listComPorts())

Also, if you don't mind, I'd like to attach a txt file containing proposed gestures for BN under NVDA (with provisions for QT commands to be implemented later; well, let's focus on BT).

Also, I think we should ask some BN mPower and Apex users to test this branch so they can give you and Rui some feedback.

Please do. Probably we will merge this into main soon so they may test it easily.

[nvaccessAuto]

Comment 29 by ragb on 2012-11-28 16:56
Hi,

Probabl it make no sence to document the current braille commands (which are too many, in my opinion) and change them next. So I'd say we can reduced them and change them (using always chordds to account for #808).

Regards,

Rui Batista
Changes:
Changed title from "Braille Display Driver for the BrailleNote family of productsn" to "Braille Display Driver for the BrailleNote family of products"

[nvaccessAuto]

Comment 30 by nvdakor on 2012-11-28 18:59
Hi,
USB: Yes, when I connect my Apex to my computer using USB, NVDA detects the new port and displays the following under the port selection combo box:
Serial: Apex Virtual USB COM Port (COM4)
I assume com4 is the port assignment on my computer.
And I'm typing this mesage with my Apex connected to my computer via USB with my Apex showing text on the braille display.

[nvaccessAuto]

Comment 31 by ragb (in reply to comment 30) on 2012-11-28 19:11
Replying to nvdakor:

Hi,

USB: Yes, when I connect my Apex to my computer using USB, NVDA detects the new port and displays the following under the port selection combo box:

Serial: Apex Virtual USB COM Port (COM4)

I assume com4 is the port assignment on my computer.

And I'm typing this mesage with my Apex connected to my computer via USB with my Apex showing text on the braille display.

It would be nice if you can give here the output of the code I sent on a previous comment, so we can be sure of the data do implement automatic port detection.

[nvaccessAuto]

Comment 32 by nvdakor on 2012-11-28 19:59
Hi,
Here's the output of list(hwPortUtils.listComPorts()):
u'BT Port (COM1)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM1'}, {'friendlyName': u'BT Port (COM11)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM11'}, {'friendlyName': u'BT Port (COM22)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM22'}, {'friendlyName': u'BT Port (COM6)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM6'}, {'friendlyName': u'BT Port (COM13)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM13'}, {'friendlyName': u'BT Port (COM10)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM10'}, {'friendlyName': u'Apex Virtual USB COM Port (COM4)', 'hardwareID': u'USB\VID_1C71&PID_C004&REV_0090', 'port': u'COM4'}, {'friendlyName': u'BT Port (COM21)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM21'}, {'friendlyName': u'BT Port (COM12)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM12'}, {'friendlyName': u'BT Port (COM7)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM7'}, {'friendlyName': u'BT Port (COM20)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM20'}, {'friendlyName': u'BT Port (COM14)', 'hardwareID': u'Bluetooth\0004&0002', 'port': u'COM14'}

Thanks.

[nvaccessAuto]

Attachment BN commands under NVDA.txt added by nvdakor on 2012-11-28 20:09
Description:
New command set for BrailleNote under NVDA. Closely matches KeySoft commands.

[nvaccessAuto]

Comment 33 by ragb on 2012-11-29 17:36
I'm not sure we can trust on the ports name to imlement USB port detection. Do you know if these USB ids are constant? Maybe HW can give an hint on this.

On another note: I'll implement a basic set of commands for the driver to be merged (and write the manual entry) and then we can discuce more commands and implement apex / pk / qwerty (is qwerty needed?) later, per haps in #808 to unify chords. An alternative would be to merge #426 and leave this driver out, so we can continue it's development on a separate branch and don't have to write the manual entry for the braillenote and later modify it.

[nvaccessAuto]

Comment 34 by jteh on 2012-11-29 21:29
The USB VID and PID should be constant for a given model. The question is whether there are any other models that have different VIDs/PIDs. If someone can provide the .inf file for the Apex USB driver, we can answer that question easily enough.

Rui, see the code I wrote relating to USB_IDS in the baum driver. The hardware ID is formatted a bit differently, but the concept is the same. Start with a USB_IDS set with "VID_1C71&PID_C004". We can always add more later.

[nvaccessAuto]

Comment 35 by nvdakor on 2012-11-30 07:37
Hi,
For inf file, you might want to ask HW for a copy. Or I can ask one of my friends (who uses NVDA) to test using his Apex with NVDA via USB connection to see if we get the same ID's for USB.
For the next task: I think we should let BN users have a go with it and give you feedback. So, I propose that we merge the work done on braillePorts to main, stating that this is just a preliminary work and the command set may change. As for scroll wheel, PK and QWERTY entry support, let's wait for a while. PK is a special case, as it might use a hybrid of the BN protocol and Baum - need to make sure; if PK uses Baum protocol, then we can just add PK to list of supported devices (the Baum's counterpart is Pronto!).
I think QT entry is a low priority for now (there are some QT users on the BrailleNote Users forum (which I'm a moderator of) who might show an interest on QT entry later).
Thanks.

[nvaccessAuto]

Comment 36 by ragb (in reply to comment 35) on 2012-11-30 10:11
Replying to nvdakor:

Hi,

For inf file, you might want to ask HW for a copy. Or I can ask one of my friends (who uses NVDA) to test using his Apex with NVDA via USB connection to see if we get the same ID's for USB.

I'll ask humanware. Meanwhile we will start with your id, if there are more we can add them easily.

For the next task: I think we should let BN users have a go with it and give you feedback. So, I propose that we merge the work done on braillePorts to main, stating that this is just a preliminary work and the command set may change. As for scroll wheel, PK and QWERTY entry support, let's wait for a while. PK is a special case, as it might use a hybrid of the BN protocol and Baum - need to make sure; if PK uses Baum protocol, then we can just add PK to list of supported devices (the Baum's counterpart is Pronto!).

As far as I know PK uses the braillenote protocol. It uses keysoft and so on. Pronto is the same hardware but I believe the software is differente.

Regards,

Rui Batista

I think QT entry is a low priority for now (there are some QT users on the BrailleNote Users forum (which I'm a moderator of) who might show an interest on QT entry later).

Thanks.

[nvaccessAuto]

Comment 37 by ragb on 2012-11-30 12:11
Hi,

I added support for USB connection to the Apex. Please try it and tell me if the USB option apears. Please tell me also if bluetooth and automatic options apear and work.

[nvaccessAuto]

Comment 38 by nvdakor on 2012-11-30 23:57
Hi,
Using 5613. USB nor automatic does not appear. Tried to revert to 5612 but to no avail.
as a response to Jamie's question, I'm using Toshiba Bluetooth Stack under Win8. Thanks.

[nvaccessAuto]

Comment 39 by jteh on 2012-12-01 00:11
Ah. The Toshiba Bluetooth stack isn't currently supported for automatic detection; see #2419.

[nvaccessAuto]

Comment 40 by ragb (in reply to comment 38) on 2012-12-02 16:42
Replying to nvdakor:

Hi,

Using 5613. USB nor automatic does not appear. Tried to revert to 5612 but to no avail.

I can't find the bug that is causing no detection. I'm trying to find vid and pid by humanware, which of cuorse match your device. Does anyone as any ideas?.

Regarding bluetooth, Humanware sent me the following information:

Apex by name: By default the Bluetooth Name would be APEXxxxxxx where xxxxxx is the serial number. However, user can change that to whatever they want.  In that case, they would lose the detection possibility
Apex by Mac address: Addresses of the Apex Bluetooth range from (0x00,0x25,0xEC,0x00,0x00,0x00) to (0x00,0x25,0xEC,0x01,0x86,0x9F)

I'll try implementing it by macaddress. @Jcsthe, do you thin it may work, wven with toxaiba's tack?

[nvaccessAuto]

Comment 41 by jteh (in reply to comment 40) on 2012-12-02 21:43
Replying to ragb:

I can't find the bug that is causing no detection. I'm trying to find vid and pid by humanware, which of cuorse match your device. Does anyone as any ideas?.

The string is actually USB\VID_1C71&PID_C004; obviously, you'll need to escape the backslash or use a raw string for Python. It didn't show up like this when Joseph pasted it because it got squashed by Trac formatting. (Joseph, for future reference, when pasting code in Trac, you need to enclose it within !and.)

I'll try implementing it by macaddress. @Jcsthe, do you thin it may work, wven with toxaiba's tack?

hwPortUtils doesn't know anything about the Toshiba stack at all, so no, it won't work for the Toshiba stack. I need access to a Bluetooth adapter which uses the Toshiba stack to have any chance of working on this, but haven't been able to get hold of one. I suspect it's only used for built-in Bluetooth chips, which makes this even more unlikely.

[nvaccessAuto]

Comment 42 by nvdakor on 2012-12-03 06:32
Hi,
I'm actually using a Toshiba Bluetooth dongle with the BT stack from Toshiba installed.
Ironically, the ports list for BN does not appear when BN is not connected to the computer via USB. Although my computer has paired with my Apex, when NvDA BraillePorts version is launched and when I go to braille settings, NvDA does not list ports list when choosing BN as a driver.
I'll paste the log surrounding this event on the next post.

[nvaccessAuto]

Comment 43 by nvdakor on 2012-12-03 07:13

Hi,
Sorry for the long one this time. Here's a log of the event and what I did:

1. Set Apex to terminal mode via Bluetooth and pair the Apex with the pC. Did not connect the USB cable:
   IO - inputCore.InputManager.executeGesture (22:37:22):
   Input: kb(laptop):b
   IO - speech.speak (22:37:22):
   Speaking braille displays'
   IO - inputCore.InputManager.executeGesture (22:37:22):
   Input: kb(laptop):b
   ERROR - unhandled exception (22:37:22):
   Traceback (most recent call last):
   File "gui\settingsDialogs.pyc", line 1323, in onDisplayNameChanged
   File "gui\settingsDialogs.pyc", line 1341, in updatePossiblePorts
   ValueError: u'COM4' is not in list
   IO - speech.speak (22:37:22):
   Speaking [- inputCore.InputManager.executeGesture (22:37:23):
   Input: kb(laptop):tab
   IO - speech.speak (22:37:23):
   Speaking [u'Translation table: combo box English (U.S.) grade 2 collapsed Alt+t'](u'BrailleNote']
   IO)
   IO - inputCore.InputManager.executeGesture (22:37:37):
   Input: kb(laptop):tab
   IO - speech.speak (22:37:37):
   Speaking to computer braille for the word at the cursor check box not checked Alt+x'
   IO - inputCore.InputManager.executeGesture (22:37:38):
   Input: kb(laptop):shift+tab
   IO - speech.speak (22:37:38):
   Speaking table: combo box English (U.S.) grade 2 collapsed Alt+t'
   IO - inputCore.InputManager.executeGesture (22:37:38):
   Input: kb(laptop):shift+tab
   IO - speech.speak (22:37:38):
   Speaking display: combo box BrailleNote collapsed Alt+d'
   IO - inputCore.InputManager.executeGesture (22:37:39):
   Input: kb(laptop):downArrow
   IO - speech.speak (22:37:39):
   Speaking [Then exit terminal mode on Apex, reenter terminal mode but set connection port to USB client (on the Apex). Then connect the USB cable between Apex and the PC:
   IO - inputCore.InputManager.executeGesture (22:37:39):
   Input: kb(laptop):upArrow
   IO - speech.speak (22:37:40):
   Speaking [u'BrailleNote'](u'brltty']

2.)
IO - inputCore.InputManager.executeGesture (22:37:40):
Input: kb(laptop):tab
IO - speech.speak (22:37:40):
Speaking combo box Serial: Apex Virtual USB COM Port (COM4) collapsed Alt+p'
IO - inputCore.InputManager.executeGesture (22:37:44):
Input: kb(laptop):enter
INFO - braille.BrailleHandler.setDisplayByName (22:37:44):
Loaded braille display driver brailleNote, current display has 32 cells.
IO - speech.speak (22:37:44):
Speaking Music window'
IO - speech.speak (22:37:44):
Speaking View list'

1. BrailleNote displays what's on the screen. Then on the PC, enter NvDA's braille settings dialog, but some internal error occurs:
   IO - inputCore.InputManager.executeGesture (22:37:50):
   Input: kb(laptop):r
   DEBUGWARNING - watchdog.watcher (22:37:51):
   Trying to recover from freeze, core stack:
   File "nvda.pyw", line 164, in
   File "core.pyc", line 345, in main
   File "wx_core.pyc", line 8010, in MainLoop
   File "wx_core.pyc", line 7306, in MainLoop
   File "wx_core.pyc", line 14669, in
   File "gui__init_.pyc", line 130, in showGui
   File "gui__init__.pyc", line 390, in onActivate
   File "wx_windows.pyc", line 2190, in PopupMenu
   File "gui__init__.pyc", line 191, in onBrailleCommand
   File "gui__init__.pyc", line 155, in _popupSettingsDialog
   File "gui\settingsDialogs.pyc", line 70, in init
   File "gui\settingsDialogs.pyc", line 1238, in makeSettings
   File "wx_controls.pyc", line 494, in init

IO - speech.speak (22:37:51):
Speaking Settings dialog'
IO - braille.BrailleBuffer.update (22:37:51):

1. On the Apex, exited terminal mode, disconnect USB cable and reentered terminal mode on the Apex, this time using Bluetooth as the connection type:
   IO - speech.speak (22:37:51):
   Speaking display: combo box BrailleNote collapsed Alt+d'
   IO - braille.BrailleBuffer.update (22:37:51):
   Braille regions text: Settings dlg ', u'Braille display: BrailleNote + cbo Alt+d'
   IO - braille.BrailleHandler.update (22:37:51):
   Braille window dots: 6 12 1235 123 - 256 1234 123 1 13456 25 - 6 12 1235 123 6 1345 135 2345 15 - 4 346 - 14 12 135 -
   IO - braille.BrailleBuffer.update (22:37:51):
   Braille regions text: Settings dlg ', u'Braille display: BrailleNote + cbo Alt+d'
   IO - braille.BrailleHandler.update (22:37:51):
   Braille window dots: 6 12 1235 123 - 256 1234 123 1 13456 25 - 6 12 1235 123 6 1345 135 2345 15 - 4 346 - 14 12 135 -
   ERROR - unhandled exception (22:37:57):
   Traceback (most recent call last):
   File "wx_misc.pyc", line 1358, in Notify
   File "brailleDisplayDrivers\brailleNote.pyc", line 199, in _readKeys
   File "serial\serialwin32.pyc", line 205, in inWaiting
   SerialException: call to ClearCommError failed
   IO - inputCore.InputManager.executeGesture (22:38:00):
   Input: kb(laptop):tab
   IO - speech.speak (22:38:00):
   Speaking combo box Serial: Apex Virtual USB COM Port (COM4) collapsed Alt+p'
   IO - braille.BrailleBuffer.update (22:38:00):
   Braille regions text: Settings dlg ', u'Port: Serial: Apex Virtual USB COM Port (COM4) + cbo Alt+p'
   IO - braille.BrailleHandler.update (22:38:00):
   Braille window dots: 6 1234 135 1235 2345 25 - 6 234 12456 24 1 123 25 - 6 1 1234 15 1346 - 6 1236 24 1235 2345 136 1 123 -

This was because BN is recognized by Windows 8 as a Windows Mobile device, so had to terminate WMDC sync connection when switching ports.

1. Once BN is set to use Bluetooth connection:
   IO - inputCore.InputManager.executeGesture (22:38:01):
   Input: kb(laptop):home
   IO - speech.speak (22:38:01):
   Speaking BT Port (COM1)'
   IO - braille.BrailleBuffer.update (22:38:01):
   Braille regions text: Settings dlg ', u'Port: Serial: BT Port (COM1) + cbo Alt+p'
   IO - braille.BrailleHandler.update (22:38:01):
   Braille window dots: 6 1234 135 1235 2345 25 - 6 234 12456 24 1 123 25 - 6 6 12 2345 - 6 1234 135 1235 2345 -
   IO - inputCore.InputManager.executeGesture (22:38:03):
   Input: kb(laptop):enter
   ERROR - braille.BrailleHandler.setDisplayByName (22:38:03):
   Error initializing display driver
   Traceback (most recent call last):
   File "braille.pyc", line 1238, in setDisplayByName
   File "brailleDisplayDrivers\brailleNote.pyc", line 168, in terminate
   AttributeError: 'NoneType' object has no attribute 'Stop'
   ERROR - braille.BrailleHandler.setDisplayByName (22:38:03):
   Error terminating previous display driver
   Traceback (most recent call last):
   File "braille.pyc", line 1245, in setDisplayByName
   File "brailleDisplayDrivers\brailleNote.pyc", line 168, in terminate
   AttributeError: 'NoneType' object has no attribute 'Stop'
   INFO - braille.BrailleHandler.setDisplayByName (22:38:03):
   Loaded braille display driver noBraille, current display has 0 cells.
   IO - speech.speak (22:38:03):
   Speaking Display Error dialog Could not load the brailleNote display.'
   IO - speech.speak (22:38:03):
   Speaking button'
2. After pressing enter, I attempted to connect to the Apex via BT again, this time with success:
   IO - speech.speak (22:39:06):
   Speaking Settings dialog'
   IO - speech.speak (22:39:06):
   Speaking combo box Serial: BT Port (COM1) collapsed Alt+p'
   IO - inputCore.InputManager.executeGesture (22:39:06):
   Input: kb(laptop):shift+tab
   IO - speech.speak (22:39:06):
   Speaking display: combo box BrailleNote collapsed Alt+d'
   IO - inputCore.InputManager.executeGesture (22:39:07):
   Input: kb(laptop):downArrow
   IO - speech.speak (22:39:07):
   Speaking [- inputCore.InputManager.executeGesture (22:39:07):
   Input: kb(laptop):upArrow
   IO - speech.speak (22:39:07):
   Speaking [u'BrailleNote'](u'brltty']
   IO)
   IO - inputCore.InputManager.executeGesture (22:39:08):
   Input: kb(laptop):tab
   IO - speech.speak (22:39:08):
   Speaking combo box Serial: BT Port (COM1) collapsed Alt+p'
   IO - inputCore.InputManager.executeGesture (22:39:09):
   Input: kb(laptop):enter
   INFO - braille.BrailleHandler.setDisplayByName (22:39:11):
   Loaded braille display driver brailleNote, current display has 32 cells.

So it appears that NvDA is using the last known connection port. If it happens to be USB and if the user is using BT or USB cable is not plugged in, NVDA will fail to show a list of detected ports.

[nvaccessAuto]

Comment 44 by ragb on 2012-12-03 12:03
Hi Joseph,

Can you test changeset,braillePorts,5615 for the following:

1. USB connection. Tell me if "USB" no apears on the ports lists and if it works.
2. Not valid ports. Choose your port, and then disconnect it and try to access the braille display settings dialog. Hopefully, with James's corrections it works but there is no harm on verifying :).

p.s. By mistake I posted this comment on #426. Sorry.

[nvaccessAuto]

Comment 45 by nvdakor on 2012-12-03 18:44
Hi,
Test was a success - USB does appear at the top of the list right below automatic (so USB is the second item). These two will only appear when the BN is set to use USB client terminal connection; if using Bluetooth (BT), USB nor automatic will not appear (I understand this).
Also, when braille module is searching for Bluetooth devices, it is searching for "braillenote" device. So, initially, when switching to BT from USB, NVDA may say that it failed to load BN driver. After another attempt, NVDA does connect to Apex via Bluetooth.
In regards to hot swapping of ports: There's no way to change a given port during terminal session - the user needs to exit to main menu or switch to another task, enter braille terminal and change the port from there. In other words, the user will need to use a single connection (either USB or BT). When hot swapping of ports is required, the user needs to do the following (while NVDA is running):
From USB to bluetooth:

1. Exit braille terminal from BN, then disconnect USB cable.
2. Enter braille terminal, then choose Bluetooth.
3. Make sure that PC is paired with the BN and remember the com port number.
4. From NVDA's braille settings, select BN then choose the BT com port. Initially, NVDA may say it failed to load braille driver. If this occurs, press ENtER again to attempt to open BT connection. At this time, it should work.

From BT to USB:

1. Exit braille terminal, reenter it and set the connection port to USB client.
2. When BN says "braille terminal," connect the USB cable.
3. From NVDA's braille settings, select BN, then choose USB. It should work as expected.

So the key would be that the user needs to connect/disconnect USB cable during port transition phase.
I think the issue of port swapping may come up when dealing with drivers which supports USB and/or BT in addition to serial (#426), most prominently Braille Sense Plus which supports serial (rS232) in addition to Bluetooth. Thanks.

[nvaccessAuto]

Comment 46 by ragb (in reply to comment 45) on 2012-12-03 21:58
Replying to nvdakor:

Hi,

Test was a success - USB does appear at the top of the list right below automatic (so USB is the second item). These two will only appear when the BN is set to use USB client terminal connection; if using Bluetooth (BT), USB nor automatic will not appear (I understand this).

Hmm, this is interesting. So there is a setting also on the braillenote to set the type of connection used. This makes me think that, further than automatic, USB and bluetooth options seem a bit redundant, since only one of those can apear at the same time. Which makes me think that we could remove those and simply use automatic. Serial ports must be still there of course, even virtual ones (i.g. bluetooth, usb).

Also, when braille module is searching for Bluetooth devices, it is searching for "braillenote" device. So, initially, when switching to BT from USB, NVDA may say that it failed to load BN driver. After another attempt, NVDA does connect to Apex via Bluetooth.

The list of ports is only updated when you enter the settings dialog or change the driver in the braille display combo box.

In regards to hot swapping of ports: There's no way to change a given port during terminal session - the user needs to exit to main menu or switch to another task, enter braille terminal and change the port from there. In other words, the user will need to use a single connection (either USB or BT). When hot swapping of ports is required, the user needs to do the following (while NVDA is running):

[...]

So the key would be that the user needs to connect/disconnect USB cable during port transition phase.

No driver supports such a thing I believe. If the braillenote has to restart some of its applications, in particular the terminal, we can't do much about it.... I believe the instructions you provided are general to any screen reader so they are more or less described on the braillenote's documentation.

I think the issue of port swapping may come up when dealing with drivers which supports USB and/or BT in addition to serial (#426), most prominently Braille Sense Plus which supports serial (rS232) in addition to Bluetooth. Thanks.

I believe we can check that when implementing port selection for those displays, if needed at all.

[nvaccessAuto]

Comment 47 by jteh (in reply to comment 45) on 2012-12-03 22:03
Replying to nvdakor:

Also, when braille module is searching for Bluetooth devices, it is searching for "braillenote" device. So, initially, when switching to BT from USB, NVDA may say that it failed to load BN driver. After another attempt, NVDA does connect to Apex via Bluetooth.

Are you saying NVDA reports an error even when you have the correct port selected? This would suggest the initial handshake isn't working properly for some reason in this case.

[nvaccessAuto]

Comment 48 by ragb on 2012-12-05 16:19
Hi,

I committed the manual entry for the braillenote and what'new.

Regards,

Rui Batista

[nvaccessAuto]

Comment 49 by nvdakor on 2012-12-05 17:41
Hi,
I'll infor BN user community to see if we can get testers. I'll tell them to email me if they find any issues so we can continue this ticket after testing. Thanks.b

[nvaccessAuto]

Comment 50 by jteh on 2012-12-05 21:17
A tiny bit of code review on the brailleNote driver:

The docstring needs to be updated. Currently, it says:

This driver is experimental. It only supports serial communcation (rs-232) and (hopefully) bluetooth.

You define an ACCEPTED_COMMANDS list, but it is never used. Even if it were, it might be better to use a set, as I imagine you intended to use it to test for the presence of an item.

_keyNames and _dotNames are constants (rather than private variables), so it might be better to name them KEY_NAMES and DOT_NAMES. However, this one is up to you.

This last one is more an observation than anything else. _getUSBPorts and _getBluetoothPorts each call hwPortUtils.listComPorts. This isn't a hugely expensive call, but being pedantic about efficiency, it should probably only be called once. However, I see why you did it this way; putting all of that in one function would make things a lot less readable.

[nvaccessAuto]

Comment 51 by ragb (in reply to comment 50) on 2012-12-06 00:39
Replying to jteh:

A tiny bit of code review on the brailleNote driver:

The docstring needs to be updated. Currently, it says:

This driver is experimental. It only supports serial communcation (rs-232) and (hopefully) bluetooth.

Thanks, forgot that one.

You define an ACCEPTED_COMMANDS list, but it is never used. Even if it were, it might be better to use a set, as I imagine you intended to use it to test for the presence of an item.

Not needed at all.

_keyNames and _dotNames are constants (rather than private variables), so it might be better to name them KEY_NAMES and DOT_NAMES. However, this one is up to you.

_dotNames is generated at runtime although its value should remain constant... I'll leave it for now, I guess :)

.

This last one is more an observation than anything else. _getUSBPorts and _getBluetoothPorts each call hwPortUtils.listComPorts. This isn't a hugely expensive call, but being pedantic about efficiency, it should probably only be called once. However, I see why you did it this way; putting all of that in one function would make things a lot less readable.

I believe the efficiency gains would be very tiny. Moreover, with this I can avoid sorting ports on the constructor (and evaluate all the generator) when selecting automatic, so USB comes first.

[nvaccessAuto]

Comment 52 by jteh on 2012-12-07 11:06
Merged in b41bcdf. New tickets should be opened for any bugs.
Changes:
State: closed