[BRLTTY] My experience with Humanware Monarch

Fri May 30 21:43:37 UTC 2025

I should mention I sent your feedback on to our developers. I work at APH.

-----Original Message-----
From: BRLTTY <brltty-bounces at brltty.app> On Behalf Of Aura Kelloniemi
Sent: Friday, May 30, 2025 5:07 PM
To: brltty at brltty.app
Subject: [BRLTTY] My experience with Humanware Monarch

Hello list,

Humanware/APH Monarch braille display has been mentioned a few times on this list lately. I had a chance to try it out just a few days ago and I think it would be worthwhile to report my experiences here.

So the device is intended to display both text and graphics using braille dots. It is not separated to distinct lines. Its resolution is 96x40 braille dots. In computer braille mode it can show 8 lines and 32 columns of text (assuming empty dot between character cells—both vertically and horizontally).

There are two very important downsides in this device if one plans to use it as a braille display for accessing text terminals. First of all, the display renders itself very slowly. Every refresh takes about two seconds (or more).
This includes adding or removing single characters. I did not try it in a terminal (of course, because there is no driver available), but I suspect that a two seconds delay is a major issue when trying to navigate a terminal screen.

The second problem is that the dots that are being rendered must not be touched during refresh, or the rendering process will be just partial. If the display is being touched during rendering, the dots being touched may not be raised/lowered and the user needs to trigger a refresh (there is a button for that in the display).

Rendering the dots makes considerably more noise than what is usual to braille displays. Also the dot panel is under a plastic membrane which feels a bit sticky, especially if one's hands are not very dry. The touch recognition feature in Monarch works very differently from how it is implemented in some HandyTech displays. I was told there are some light sensors which detect the position of the user's finger on the display, and routing/button activation needs to be triggered b pressing a button with the other hand. Lighting conditions can affect how touch recognition works. For me it worked about 90% of cases.

I suppose all the "defects" related to display refreshing are due to the technology used in the display. I don't know how the display works internally, but certainly the braille dots are controlled in a different way compared to traditional displays.

What is good in this display? First of all, it is big. Reading long passages of text with a multi-line display is (for me at least) much faster than with a single-line display. Also the graphics feature is very nice, although the resolution is low—but hey, now blind people have access to pixel art.

Considerations for BRLTTY: there are a few things that could be implemented in BRLTTY to help utilize multi-line displays in terminals. The most important of these is to split long terminal lines on multiple braille lines. For example, if the terminal width is 80 characters, BRLTTY could use three lines on Monarch braille display to display one terminal line. Of course BRLTTY could dynamically choose how many braille lines to use for representing one terminal line (trimming trailing whitespace).

Sometimes (when reading a table, or playing a grid-based game) it is useful to move the whole multi-line braille window horizontally. But when reading linear text (like in text editor, web browser, or output of `ls -l`) the user probably would like to avoid the horizontal shifts and instead read terminal contents linearly (even though line breaks in the visual terminal will be in different points than on the braille display).

This functionality of splitting screen lines on multiple braille lines would be especially useful for Monarch display, because of its long refresh time, but I guess it would be very helpful for anyone using a multi-line display.

Another thing that would help Monarch users would be audible notification before the display is redrawn. Because the display contents will get garbled if the user touches the display while it is refreshed, it would be nice to have BRLTTY beep before it refreshes the display so that the user has time to remove their fingers from the display.

Blinking: due to the long rendering time, all features that utilize blinking (like blinking cursor, blinking attributes, etc.) must be disabled when using Monarch.

Line height control: BRLTTY should be able to scale the line height and line spacing. The user should be able to control how many blank dot rows are left between lines of text.

One great feature that Monarch (and other similar displays) would allow us to implement is 10-dot braille. I at least have pushed computer braille to its limits long time ago and would love to have more dots in my braille cells. The extra dots could be used for representing terminal attributes or just to be able to differentiate more characters from each other. Actually, because there is always an empty vertical column of dots between each character cell, these dots could also be utilized, resulting in 15-dot braille (3x5 dot cells).
These could be useful in representing line graphics (for example).

Images support: many modern terminals can display images. BRLTTY could add support for these terminals and display the images on suitable braille displays.

Finally, I would have two questions for those who have used the other multi-line displays currently available (Canute 360 and Dotpad): do these displays have the same issues with refreshing that Monarch has (long refresh times, garbling of the display if touched during a redraw)? Do these displays have any way to point to a specific dot (e.g. to route cursor to a particular position)?

If you have questions regarding Monarch, I can try to answer them.

--
Aura
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty