Request for help implementing HID protocol in BrailleTouch project #14829
Replies: 23 comments 16 replies
-
Have you read our documentation on braille HID? |
Beta Was this translation helpful? Give feedback.
-
CC @LeonarddeR I'm not sure, but it is possible you might have some knowledge
that would guide this effort in some better direction.
|
Beta Was this translation helpful? Give feedback.
-
This has been the problem we've been facing, and I've been searching for programmers, but none have been able to help because it seems that no one has seen code for HID braille on the braille display (firmware). Would it be necessary to reverse engineer a braille display? Apparently, the part that goes on the screen reader's side (the driver) is known, but no one knows how to do the firmware or the HID part that goes from the braille display side. There is no starting example. It would be a great advancement to have a sample HID braille display code in C that can display braille content on the console and have at least two buttons to navigate through the content. With this code, we could show how to pass buttons and receive and display content on the console. It would be a perfect example for developing anything, but unfortunately, it doesn't exist. I even tried using artificial intelligence to generate code, but it also failed because everyone only works on the code that goes to a controller for making a controller, and AI does the same. |
Beta Was this translation helpful? Give feedback.
-
cc: @FalkoBabbage @discapacidad5 which HID library did you use on your platine? Maybe these sources could help in how to design the class and the internal library on the platine to comunicate with the HiD driver in NVDA or with Windows independently. I guess you need these enhanced libraries for your platine to comunicate via HID efficiently: and this is also very useful since you can specify your own HID classes with your own enums: Does your braille display work already without any screen reader? Or is a screen reader required to use it? This treat might help further in finding some hints for functions required to be written to your HID device in order to comunicate with Windows. |
Beta Was this translation helpful? Give feedback.
-
It seems Helptech from Germany they claim at least some of their braille devices are pure HID devices: |
Beta Was this translation helpful? Give feedback.
-
I guess you already used the HID conventions in this HID usage table right? |
Beta Was this translation helpful? Give feedback.
-
Hi, Hi, I'm sure you may have read through NVDA's own source code, but have you tried looking at HID braille standard file (source/brailleDisplayDrivers/hidBrailleStandard.py) to get a sense of how NVDA understands HID protocol? Thanks. |
Beta Was this translation helpful? Give feedback.
-
The big problem lies in the fact that those who provide explanations and the manufacturers never explain how to send the HiD report. They explain how to interpret it and there are instructions on how to interpret the HiD report to use it on a screen reader to create a driver, but there is no information on how to create or generate the HiD report itself, only its interpretation and structure. Sometimes I think there is a great interest in preventing anyone from understanding this, so that no one can develop a screen that can be compatible with all screen readers. I have always believed that Braille screens end up being a business. They are so expensive and there are ways to make Braille screens so affordable, but if there is no way to communicate with the screen reader, what is the point of manufacturing a screen if it cannot be functional with screen readers or if I have to wait a long time for a custom driver for a screen reader. And of course, if I want to try to bring it to paid readers like Jaws or iPhone or even Android, how long do I have to wait to see if my device driver can be recognized in their device list? The advantage of HiD is precisely that it would give that freedom to play with all this and start designing, testing and evaluating Braille screens that work without waiting for a custom driver for a screen reader. Having a working sample code would open the doors to many projects that could use HiD to offer more accessible devices to people with disabilities. Today, people with disabilities are not using Braille precisely because of the cost of the devices and only first-world countries that have the capacity or whose governments donate the devices have the ability to have a Braille screen. The rest of the people in the world do not have that possibility, and that is the vast majority. |
Beta Was this translation helpful? Give feedback.
-
Sorry if I am being dummy...
The HID protocol is not only for USB devices?
If you say that
ESP32 only supports Bluetooth, you should not devellop a specific driver for your Braille display?
Rui Fontes
Às 21:16 de 15/04/2023, discapacidad5 escreveu:
… "In the case of the projects you mentioned, such as the Android HID project and USBD-Human-Interface, they provide HID support only for USB devices and do not work with Bluetooth devices. In my case, I am facing a problem with the ESP32, which does not have native USB support for HID Braille. I can only work with it through Bluetooth.
However, as I mentioned before, the problem is not that the computer does not recognize the device as HID. The problem is that NVDA, or more specifically HID Braille, has a specific structure to define the cells and many other things, which is not the same as the structures for a keyboard or a mouse. These libraries that convert HID do not have a structure for HID Braille. Therefore, even if I manually change the descriptor and add the HID and Braille descriptor, the computer recognizes it but the screen reader does not, because there are many things that are not properly structured.
That's why it is necessary to create a specific library for HID Braille or add HID Braille support to the existing library."
|
Beta Was this translation helpful? Give feedback.
-
@discapacidad5 I am totally with you, sometimes big players announce a lot of things such as standards but often they are not being thought to the end. Especially when it comes to guidance on how to achieve them. I am not total expert, but it seems you have found some how a way to design your in report and now you need an out report for the report descriptor. Is this correct? So can you already send key presses to an application in Windows without any screen reader? Anyway, I found a good tutorial on how to create a USB report descriptor, it defines in general how to create it for some usual examples like gamepads and mouse. Now we have to find examples for some code that describes a report descriptor for bluetooth devices and then for a HID braille device. And here is a tutorial which shows how to create custom HID devices with custom report descriptors in circuitpython. I could find an usage file that has been approved from Microsoft for the HID standard, I guess this is the filtered information from the table that I have already posted above. It could make it easier to find here all the relevant info without having to scroll through the whole HID conventions: @discapacidad5 did you already try the win-hid-dump tool to extract the propper HID report descriptor for the custom device? I guess this will give you an in report rather than an out report but might be worthy to try. Then you could use a report descriptor decoder such as this one to create C structures: |
Beta Was this translation helpful? Give feedback.
-
I found on stack overflow a code example for sending and receiving data on a custom HID device, but not sure if it works:
A couple of things to note: Source: https://stackoverflow.com/questions/21606991/custom-hid-device-hid-report-descriptor |
Beta Was this translation helpful? Give feedback.
-
@discapacidad5 did you raise your questions on this forum ast well? I have the impression there could be some really good experts that can help further in this regard. |
Beta Was this translation helpful? Give feedback.
-
For anyone's reference, here is an example of a bluetooth device that uses the Gatt profile to comunicate with the host: It also describes how a report descriptor for a bluetooth device could look like. |
Beta Was this translation helpful? Give feedback.
-
And here is a complete report descriptor for a smart remote which might also help. |
Beta Was this translation helpful? Give feedback.
-
Finally, here is some more Info on how HID input and output can works between HID device and host, here is a dualshock game controller as an example:. |
Beta Was this translation helpful? Give feedback.
-
"Thank you for all the information you've sent, I will look into it to see if I can achieve something. However, I have seen many examples and have actually been able to make a HID device work. There are many examples of how a HID device works and there are libraries that do the job. But what I have noticed is that even if you have a HID device configured, it does not work with the screen reader. In fact, key presses on the HID Braille device do not go directly to the operating system like on a normal keyboard. The key presses are captured by the screen reader. Currently, the operating system does not recognize the HID Braille to work with it directly. That is the big problem. That's why I mentioned that it's not about just passing examples. There are many examples, but it's about making an example that works with HID Braille. When you start working on it, you realize that existing examples do not work with HID Braille because it's not enough to be recognized by the computer. It has to carry certain structures that the screen reader must recognize. All key presses have to go to the screen reader, and the screen reader looks for the desktop in a specific location. Therefore, both the input and output go to the screen reader, and the screen reader processes it. I will analyze all the examples you sent, but even those that claim to provide an example of a descriptor do so theoretically. No one has done it in practice. The theory is not enough when thinking about how HID works. Braille input is a bit different and requires certain different operating parameters. I encourage you to try to make a functional code that can receive the content of Braille and can be recognized by the screen reader, not just recognized by the operating system, as that can already be done. There are already libraries that help with that, and you simply need to load the library to be automatically recognized. But it's not enough to be recognized by the operating system. The goal is to make the screen reader recognize the HID Braille, and that's where we are falling short. There is a part of the code that is missing, something needs to be done, and there are some parameters that are not being set. Therefore, the screen reader is not recognizing it, and that's the unclear part. Everyone explains it theoretically, but no one provides a practical example. Sometimes, a practical example is necessary to understand." |
Beta Was this translation helpful? Give feedback.
-
Hi, Hmmm, even after reading NVDA's own source code? If yes, then we might as well discuss how we (NVDA folks) can make our source code better so others can understand what's going on, because when discussing HID and screen readers, NVDA's own HID standard implementation is the closest we have to seeing the protocol in action. As long as a screen reader (or some assistive tech software) is running, the screen reader will process input before anyone can do so, and that also involves understanding input coming from a braille display as communicated by its driver. In case of HID, HID input is first processed by the screen reader, therefore the screen reader's job is to parse protocol messages from the braille device and translate it into actual input mechanism the operating system supports. As for actually writing support for a braille display, yes, it involves looking at or asking for basic protocol documentation, and lots of debugging to get it right (more so if one wishes to support multiple models). The last time I did something with braille input and output, I have added support for specific models of HumanWare BrailleNote family, involving different models and input styles. This work involved printing protocol messages sent by the braille display, mapping messages into a form that could be understood by NVDA (key mappings, for example), and getting NVDA to recognize specific input and perform commands and/or send the equivalent command to the operating system. As for braille and HID, what makes it a bit difficult is that the input side is not seen as a typical keyboard - it ic akin to a controller or a specialized input device. If we're dealing with a computer keyboard, then it is better to get the OS/keyboard driver to recognize the input and do whatever it needs to do. But we're talking about an input style that cannot be readily translated into scan codes and virtual key codes (that's how Windows knows about keyboard input), thus the screen reader is involved in:
In other words, the way the term "human interface device" is understood, interpreted, and implemented differs based on who you ask:
As a repository for screen reader development, we fall under the last category, with some folks wearing different hats. Hope all of this makes sense. Thanks. |
Beta Was this translation helpful? Give feedback.
-
Unless there could be a Standard Windows driver that translates the commands from the braille display into windows standard Input, without having a screen reader. I was hoping USB-IF would have thought about this before shouding out such a standard promising that HID braille displays would work without a screen reader. I think still the example that comes nearest to a Braille input / output interpretation is a dualshock game controler as a HID device. Those have input mapings that need to match some how to keyboard and mouse, and they have output mappings such as vibrations to indicate something which has been sent from the HID host to the HID device.
This could be done via a custom hid miniport driver. Here are all the classes supported so far, but I think Microsoft didn't think of Braille driver API as an own class, so it could be a good start to also talk with them about how to create a custom HID Miniport Driver for Braille Input and Output. |
Beta Was this translation helpful? Give feedback.
-
Hi, A completely different direction, but have you looked at BRLTTY and see how it can serve as a bridge between different braille displays and screen readers? Yes, different braille displays implement different protocols, and some have standardized around a common set of messages (protocols) i.e. Baum protocol (talking about braille display protocols will require looking at a history of braille display development for the last twenty years or so). Thanks. |
Beta Was this translation helpful? Give feedback.
-
BRLTTY causes many conflicts between screen readers, for example when Narator and braille displays are added via BRLTTY, some of the braille displays are totally overtaken by Narator ynd you cannot find them in NVDA's menu anymore. I had this problem with an user here in Germany and the solution was to remove BRLTTY and all the Braille drivers from Narator. After that the Braille displays appeared again in NVDA's menu and they have been recognized automatically again. |
Beta Was this translation helpful? Give feedback.
-
Hello, I've also been wanting to do something similar. I have used RP2040 and programmed it using Micropython. Even I have been facing issue in implementing it as Braille HID device. @discapacidad5 It would be great to know if you found out a way on how it's done. I'm very new to this HID thing and it's quiet honestly getting very complicated for me to understand. |
Beta Was this translation helpful? Give feedback.
-
I have looked at implementing a hid braille display with a RP2040 as well last week since I was tagged in this discussion and I am relatively interested in HID devices in general. I'll see if I can make some time this week to see if I can make a minimal example and put it online. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Hello,
I hope this message finds you well. I am reaching out to you because I am working on an open-source project called BrailleTouch. Our goal is to create affordable Braille displays for blind and deaf-blind individuals.
We are currently stuck and unable to get the HID Braille to receive information from the screen reader and continue programming. As someone with experience in this area, your expertise could be of great help to our project.
I believe that an open-source Braille display could be incredibly useful and have many benefits for those who are blind and deaf-blind. Your knowledge of the HID protocol could be particularly helpful in implementing the protocol in our Braille display.
Please take a moment to review our project on GitHub at https://github.com/brailletouch. If you're interested in helping, please let me know.
Thank you for your time and consideration. I look forward to hearing back from you.
Best regards,
Cergio Monasterio
Beta Was this translation helpful? Give feedback.
All reactions