[BRLTTY] My experience with Humanware Monarch

Devin Prater r.d.t.prater at gmail.com
Sat May 31 07:09:14 UTC 2025


I have seen the Cadence Braille display. This one has a much, much 
faster refresh rate, about as fast as regular displays. I think it still 
has the issue of you can't touch the area of the display while it 
refreshes, but it handles it much better. When you move your finger from 
that exact cell, it refreshes. Now, it has four units that can be 
conjoined into a larger display. You can even connect just two together, 
in landscape or portrait configurations. The singleton is about 40 
cells, about ten cells across four lines.

On 5/30/2025 4:06 PM, Aura Kelloniemi wrote:
> 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.
>


More information about the BRLTTY mailing list