[BRLTTY] BRLTTY in GRUB

Thu Mar 15 17:27:03 EDT 2012

On 15.03.2012 21:21, Dave Mielke wrote:
> [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.
Samuel already said it: I just want to have something that works at 
least minimally to begin with. To make whole brltty at least compile 
would mean twice as much work. If you think that it's better to have 
nothing at all rather than something to start with then I'm at wrong 
address.
>   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.
Again, putting a dummy there to get something working at all for the 
first stage is more important than to get tiny bits right and the whole 
not compiling at all.
>
>>   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.
Most of this file should be split the same way as usb.c is.
>>   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.
GRUB works completely differently from POSIX-compliant OSes. GRUB is at 
most similar to msdos in some aspects (like being single-thread) but 
offers full features in others (like Unicode).
>>   common = braille/brltty_wrap/ktb.c;
>> Currently dummy for keys.
> Totally bad idea.
It makes the whole compile.
>> Which code handles autoloading? I haven't seen any library loading calls.
> sys_shlib_*.c
Ok, I'll have a look.
>
>> 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,
It's possible to make a virtual 80x24 terminal. However special 
structure of GRUB and its small code size has already allowed us to find 
better solutions to problems than what is applicable to a big OS where 
you can't change all components to improve input to your command. In 
this case I thought that having the complete model would allow better 
braille rendering. The solution of rendering into 80x24 and then 
attempting to parse seems to me as a kludge. It seems that my efforts 
about this aren't appreciated.
>   and then let brltty's
>
>> 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.
40 is a parameter
> 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.
So is it better to support keys without braille display?
>> 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.
I've already made usb_grub.c. But it seems that if I do only that and 
brltty is started when a new device is plugged in, it won't be picked up.
>>> 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.
Then tell me. Nothing is more frustrating than hearing "your idea sucks, 
the only good code is ours, you're an idiot who doesn't understand 
anything and we won't tell you"
>   You're making an assumption ehre
> which is simply not true. Controls on the braille device don't show up as
> keyboard events.
We have unified event queue. It's not a problem to add new virtual key.
>
>>>> I
>
>
>> 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.
Gain time to the first somewhat working solution?
> I don't know how many times I'll need to keep saying this in order to make the
> point stick.
Again, I want something to work at all.
>   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.
I want the cooperation and future version importability to work.  But if 
it doesn't work for any reason I'll just import one version and be happy 
with it.
> There's only one way to get this right, and that's to let brltty be brltty,
I don't care about it being brltty.
> w
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko