[BRLTTY] BRLTTY in GRUB

[Dave Mielke]

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

Hi:

>I have an impression that we don't understand each other. 

Not at all. I can see from what you've written below that I've understood you 
very well. :-(

>Currently I take following files from brltty:
>  common = braille/brltty/Programs/parse.c;
>  common = braille/brltty/Programs/driver.c;
>  common = braille/brltty/Programs/brl.c;
>  common = braille/brltty/Programs/queue.c;
>  common = braille/brltty/Programs/ttb_translate.c;
>  common = braille/brltty/Programs/drivers.c;
>  common = braille/brltty/Programs/bluetooth_none.c;
>  common = braille/brltty/Programs/bluetooth.c;
>  common = braille/brltty/Programs/usb.c;
>  common = braille/brltty/Programs/usb_serial.c;

This isn't nearly enough. This, as I suspected, is barely enough to simply 
attempt to write braille. The user won't be able to use the controls on his 
braille device to do anything. No user will accept this. Well, if it's all he 
has, then he might, but he'll also silently curse the tremendous lack of 
support, and, yet again, be disappointed by those who don't truly understand 
his needs.

>Following files I implement right now:
>  common = braille/brltty_wrap/timing.c;
>This file seems to be platform-specific and uses select().

Only a very small part of it. Duplicating a whole file like that, just because 
part of it is a problem, isn't right. It's far better to use #if on 
HAVE_SELECT, and fill in how grub needs it done with, maybe, an #if for GRUB.

>  common = braille/brltty_wrap/log.c;
>GRUB has no file writing facilities

AGain, replacing a whole file just for that isn't good.

>  common = braille/brltty_wrap/charset.c;
>GRUB has Unicode but no iconv

Then let #if on HAVE_ICONV take care of it. No need to duplicate the whole 
file.

>  common = braille/brltty_wrap/usb.c;
>Should be renamed to usb_grub.c actually.

Yes, if (I'm hoping) I'm understanding this one correctly.

>  common = braille/brltty_wrap/serial.c;
>Platform-specific.

Parts of it, yes, but not all of it. Again, replacinb the whole file isn't 
right.

>  common = braille/brltty_wrap/async.c;
>Seems to use select() and requiring multi-threading.

No threads. The whole point of async is to let a single thread handle many 
events.

>  common = braille/brltty_wrap/ktb.c;
>Currently dummy for keys.

Totally bad idea.

>Which code handles autoloading? I haven't seen any library loading calls.

sys_shlib_*.c

>In GRUB renderer is separated from info. It's easier to have good
>Braille display by making braille another renderer rather than rendering
>in standard screen and then having a reader.

Why not render the screen content into a string array, and then let brltty's 
Grub screen driver inspect it and update the real screen from it. This is a 
classic example of what I'm trying to teach, here. Use some imagination to get 
it right for all cases, rather than keep grub nice and mess up brltty to get 
there. In this case, rather than Grub just going directly to the physical layer 
for updating the screen, it should introduce a logical layer in between which 
can be accessed by other applications.

>I've already tested it with serial console 40x1.

You shouldn't need braille access to depend on the physical screen dimensions.

Also, given the lack of core support, no user with a braille display smaller 
than 40 cells will be able to use it.

And also, as posted earlier to the list by a user, users also need to be able 
to inspect the rest of the screen, not just the current line, so that they, for 
example, can reveiw the list of special keys, etc.

>>> Also I've noticed that the function convertCharToWchar is unlikely to
>>> work with UTF-8.
>> That function is probably not used for braille.
>Hm, it was referenced in my tests.

I can look through the code for references to it. There likely aren't too many 
any more.

>GRUB has hotplug ability. Is it possible to somehow make brltty pick it up?

Perhaps. At the moment, brltty relies on the platform-specific part, in your 
case that'd be usb_grub.c, to know anythng about which devices exist. If grub 
already maintains a dynamic list of connected USB devices then I'd think that 
ought to be good enough. I'm open to ideas, though.

>> Knowing the properties of the brialle device shouldn't be something Grub needs 
>> to care about.
>With separate renderer rather than reader will produce better braille
>and it needs the screen size.

That'd be a half-baked solution. Introducing a logical rendering layer, as 
described above, would let brltty do its job properly. Grub shouldn't have to 
know how to render good braille.

>> 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.
>Renderer already handles this. Keys can be mapped to analogous scroll
>features.

You don't understand braille devices, do you. You're making an assumption ehre 
which is simply not true. Controls on the braille device don't show up as 
keyboard events. Also, the navigation needs of a braille user are entirely 
different from those of a sighted user. Grub shouldn't be involving itself with 
trying to get this right. Brltty already knows how to do it. Let it do its job 
and the users will be happy.

>>> Is it possible to somehow disambiguate this. In GRUB USB and serial devices 
>>> are in completely different namespaces. 
>> It's already disambiguated in brltty.
>Yes but the string itself is ambiguous as the same string may be USB
>serial number or serial device name. 

The string isn't ambiguous. If it begins with usb: then the rest of it is 
passed to usbFindChannel() for interpretation. If it begins with serial: then 
the rest of it is passed to serialOpenDevice() for interpretation. I'm not 
understanding why you keep claiming this is ambiguous.

>I'd prefer to avoid this in GRUB.

But it's already avoided.

>Information about unicode is available in GRUB but not through the same
>functions.

Hence the use of #if. We just need to have an #if for the Grub environment, and 
make that part do the right thing. No reason to completely replace a file.

I don't know how many times I'll need to keep saying this in order to make the 
point stick. We need the freedom to make changes without worrying that we've 
broken the Grub implemenation. You want to get the Grub implementation working 
without having to continually maintain it as we make changes which break it. 
There's only one way to get this right, and that's to let brltty be brltty, 
with Grub implemenations of low level pieces where necessary.

>The other function is setAlternative.

It selects the AltSetting of an interface.

>We had good results with automated importing using python scripts.
>In future it may be changed as to the direction of import but I'd first
>like to make it work at all.

Yes, I agree, it's not necessary to get this right at the outset. It's 
necessary, though, to eventually get it right because we don't want to 
continually be breaking your stuff.

-- 
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/