Framebuffer terminal emulators
Samuel Thibault <email@example.com> writes:
> Jason White, le Fri 28 Nov 2008 19:42:50 +1100, a écrit :
>> I'll gladly submit a bug report. Even if it's using framebuffer
>> console, BRLTTY should still work, right?
Jason, yes, BRLTTY works fine with kernel based framebuffer consoles. I am
actually using this at work since a few days with a 1024x768 screen resolution
(configured via fbset) and a 12x24 font (from console-terminus) to achieve a
85x32 terminal. This is useful since I happen to use a 88-cell braille display,
and now that BRLTTY has configurable status cell emulation, I suddenly was
able to conventiently add 5 more characters horizontally to my terminal setup.
> but a framebuffer running bogl-bterm doesn't, because in that case that's
> bogl-bterm that handles everything, and it doesn't expose the text to brltty.
This is a problem we know about since several years now. The ultimate root
cause of the issue is that the Linux kernel virtual terminal layer can only
handle 512 different glyphs in a terminal at once. With hacks (composite fonts)
this can be useful (to a limited extend) even with unicode characters, but to
achieve full unicode support, user space terminal emulators (bogl-term and
friends) had to be written. These terminal emulators do their own drawing on
top of the Linux framebuffer interface and therefore allow for support of the
full unicode range. Now we have a very typical accessibility problem that has
come up in various variations in the past. Since a program does its own drawing
and no longer uses the typical infrastructure for a given job, ATs fail. In
this case, we can't really blame the people that wrote these tools since the
Linux kernel is actually lacking a fundamental capability these programs provide.
> There is a long thread about it on debian-boot.
I didn't check into it, but I am sure the only real solution is for someone to
step up and implement BrlAPI support for the most popular framebuffer terminal
emulators. Sounds like a few days of work, depending on how good the internal
infrastructure of the project at hand already is. Someone just needs to want
to do this, allocate the timeslot and start doing it. Hey,
christmas holiday time is near!
P.S.: Actually, it could be a little bit easier to extend the existing "Screen"
screen driver in BRLTTY or implement a new screen driver for communicating with
bogl-term and friends. Its not like this hasn't already been done in the past.
The "Screen" screen driver has been the only way to work with BRLTTY on all BSDs
since there, the kernel totally lacks a way for user space to access the virtual
terminal content. On Linux, we're actually lucky to have /dev/vcs*. Its just
that it doesn't support full unicode. Take the chinese language for instance,
/dev/vcs* couldn't be used to represent it, while BRLTTY now actually has tables
for (all?) the chinese unicode characters. Users from that area would have to
use bogl-term or similar anyway to even be able to have all their various
characters representable, but BRLTTY currently can't speak to bogl-term yet.
There are even arguments and reasons for a typical console braille user from
a western country wanting to use a framebuffer terminal emulator to achieve full
unicode support. While you often can represent most of the characters you see
in your daily work with a 512-glyph font, there are situations (especially when
surfing the web or reading documents that make use of unicode characters in
general) where it would be desireable to be able to map a lot more than just 512
characters back to braille. Now that BRLTTY has full unicode support, we are in
the situation that we could define a lot of useful mappings, but most of them
are never going to be used because of this 512-glyph limitation.
So as crazy as it might sound, the ordinary blind braille user might want to use
a user-space framebuffer terminal emulator to get full unicode support in the
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger firstname.lastname@example.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>