[BRLTTY] BRLTTY in GRUB

[Dave Mielke]

[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/15 at 17:22 +0100]

>Particular driver at one side allowed me to pull in something we, for
>sure will need, 

The drivers have been written such that they can depend on core functionality. 
Any changes which involve modifying individual drivers will be destined for 
failure. Even chganges to higher level core functionality are a very bad idea.

Changes to the code are made on an on-going basis. If we can't rely on common 
functionality working as it does, we'll always have to be worried abouty 
breaking the Grub implementation every single time we do anything. That's 
simply unacceptable.

It's essential that anything which is platform-specific be isolated such that 
it ideally need never be touched again. This can only ever be ensured if it 
only touches the lowest level of system interfacing.

>and on the other hand in GRUB it's largely preferred to be able to load 
>drivers individually. In brltty it seems that you can load only the large 
>block.

I'm not sure what the problem is. If your goal is to replace the core and just 
load brltty drivers, that won't work. The drivers rely on code within the core. 
We can't guarantee that any changes we make to any driver will ever remain 
compatible with your replacement of the core.

Brltty contains drivers of various ages. Older ones do things older ways, 
unless they've been upgraded. In spite of this mixture, they all work properly 
because they work in conjunction with a core that knows how to support the 
differences. Upgrading them all would be nice, except that it's extremely 
unrealistic due to the sheer cost of acquiring the hardware for testing.

Brltty already loads the needed driver. Although it can be built with all of 
the drivers linked in, that's not the default way it works. The default way is 
for the core to have no drivers linked in, and for it to load the driver which 
the user needs.

>I'd rather avoid pulling in parts we don't need. If you can give me a
>set of functions that are easy to integrate with GRUB but won't result
>in the need for large wrapping layer (in particular anything needing
>multithreading is a no-go since GRUB is single threaded).

Brltty doesn't require multi-treading. Configure it with speech and the API 
disabled.

Grub should do what brltty's main() function does. Removing all the unecessary 
stuff, this means:

Call brlttyConstruct(argc, argv). Then, from some strategic place within Grub's 
loop, call brlttyUpdate().

Implement a simple screen driver for Grub which returns whatever should be on 
the braille display. This screen driver can present a one-line screen with the 
current line on it. That should be good enough. This approach assumes that 
there's a function in Grub for finding out what's on the current line.

>Also I've noticed that the function convertCharToWchar is unlikely to
>work with UTF-8.

That function is probably not used for braille. Braille now works with wchar_t, 
i.e. it works with Unicode. The screen driver returns the screen content in 
Unicode, and that's the way it continues to be handled until it's eventually 
converted into the correct braille representation.

>Ideally for GRUB I'd like a set of functions something along:
>void brltty_usb_device_attached (UsbDevice *);
>void brltty_usb_device_detached (UsbDevice *);

If we're going to go down a path which allows us some sort of safety in terms 
of making changes to brltty in the future, then changing the USB paradigm is, 
in my opinion, unacceptable. All we should need to do is correctly implement 
usb_grub.c. Then, USB will simply work.

Going down a path where things are sufficiently different in Grub is, in my 
opinion, not good. We must recognize that ensuring that brltty works in Grub 
isn't easy. We need to know with certainty, on an on-going basis, that it'll 
still work in Grub after we've tested it on Linux. This can only be done if we 
don't start modifying things at higher levels, and if we only change for Grub 
that which is absolutely necessary.

>int brltty_get_brl_width (void);

Knowing the properties of the brialle device shouldn't be something Grub needs 
to care about.

>void brltty_set_displayed_text (uint32_t *ucs4_string);

As mentioned above, this is the wrong paradigm. Write a Grub screen driver.

Maybe you're imagining that braille support is as simple as "put the right text 
on the display". It's not that simple. There are features, like cursor routing, 
which need to work properly. These features especially need to work when, for 
example, the user is editing the kernel boot command. The user also needs 
correct control over his device when, for example, the current line is longer 
than his display is.

Also, a number of braille devices have keyboards on them. Their users like to 
use them. The core knows how to interpret these keyboards, and then enqueues 
the character as keyboard input. This is another job for the screen driver to 
handle. Again, therefore, you really do need to provide a Grub screen driver.

The core already knows how to do all of these things properly. It'd be wrong to 
reimplement all of that.

>As for the input of set_displayed_text I can propose either of:
>- Groups of unicode character with attached combining characters (preferred)
>- UTF-32 in native endian
>- UTF-8
>- UTF-8 with bidi reordering
>- ASCII (last resort)

As mentioned above, a simple Grub screen driver which returns Unicode will do 
the job.

>I meant "serial number". 

Okay. It's too bad that the word "serial" is used for two such different 
things.

>Is it possible to somehow disambiguate this. In GRUB USB and serial devices 
>are in completely different namespaces. 

It's already disambiguated in brltty. serial: means to use serial I/O, and usb: 
means to use USB I/O. For completeness, there's also bluetooth:, which, of 
course, means to use Bluetooth I/O.

>Right now it seems that none of the functions in question are used in any of 
>the code I've imported, only declared >and/or implemented. Could we have a 
>define like HAVE_FLOAT ?

Sure.

>Some of the files I've replaced with my implementations have lots of #if's in 
>them. Perhaps it would be better to declare them as platform-dependent. E.g. 
>charset.c and unicode.c

The #ifs in unicode.c are for available features, like libicu. That has nothing 
to do with platform dependence.

The three worst cases I can think of in terms of #ifs for platform-dependent 
code within portable code are mount.c, serial.c, and, yes, charset.c. It may 
well be time to revisit those.

>I have already implemented usb_grub.c except the two functions I don't 
>understand.

I've forgotten which ones they are. They're probably the ones for managing an 
interrupt input endpoint. There are three: start an asynchronous request, 
cancel it, and check for arrived input. While it's nice to have them 
implemented, brltty does fall back to using bulk transfers if they aren't.

>I'd prefer the GRUB build system to 
>pick up brltty rather than the other way round. It simplifies version and 
>module dependency management.

It also complicates things whenever we change things as you undoubtedly, for 
one example, then have to maintain your own set of which files to build.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | 2011 May 21 is the End of Salvation.
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://Mielke.cc/now.html
http://FamilyRadio.com/                   | http://Mielke.cc/bible/