[BRLTTY] BRLTTY in GRUB

[Dave Mielke]

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

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

As I've already said, I'd be glad to do the work of making brltty compile if 
you'd be so kind as to tell me how to set up a build environment for Grub. I 
think it's the better approach, and I'm not just compliaining - I'm offering to 
help.

>If you think that it's better to have nothing at all rather than something to 
>start with then I'm at wrong address.

That's your judgement call. If you aren't interested in my thoughts, opinions, 
and suggestions, then perhaps you are.

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

You've been speaking as though this is your permanent goal. If my understanding 
has been incorrect on this point then I stand corrected.

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

I've already said that I know serial.c to be one of the three biggest offenders 
in this area. One of the problems with splitting it up, though, is the fact 
that platform-dependent type definitions are used internally so that things 
like attribute caching can be all done in common, portable code.

>>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).

As I said, async doesn't rely on threads. It allows the single main program 
thread to handle multiple tasks.

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

>It makes the whole compile.

It also renders the controls on the braille devices entirely useless.

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

A braille user needs to be able to see the whole screen, just like you like to 
see the whole screen. Do you really think it's somehow better to have two 
completely different renders, both of which, independently, know what should be 
on the whole screen? Isn't it better for the screen to be rendered logically 
once, and then to have various presenation layers to turn that logical 
representation into physical ones?

It's not good, by the way, to go down a path which would allow the braille 
screen to have different content than what's shown on the monitor. If a braille 
user and a sighted person are working together, it's critical that they're both 
seeing exactly the same data in exactly the same layout. The importance of this 
cannot be understated.

Given the above, can you now see the sense in first rendering the screen into a 
logical representation? It doesn't need to be something hard-coded like 80x24. 
I think a list of arbitrarily long lines would be good enough. The real screen 
renderer could then wrap each line as needed to fit the actual screen width.

>It seems that my efforts about this aren't appreciated.

No one has said that. The fact is that I myself do appreciate your efforts. I 
really and truly would lvoe to see good braille support in Grub. My goal here 
isn't to discourage the work. It is, rather, to emphasize the needs of a 
braille user, and to try to ensure that this project doesn't go down what I 
believe to be a wrong path. If you're going to assume that anything I suggest 
that differs from your own already-formed opinions is garbage, then I guess 
we're at an impass.

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

I still maintain that Grub shouldn't need to care about the properties of the 
braille device. Rendering good braille isn't as simple as putting text on the 
display.

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

I don't understand. The user said he'd like to be able to look at the whole 
screen with his braille device so that he can remind himself what the special 
keyboard keys are within the Grub environment. This is a valid and good 
request. It simply highlights the need for a braille user to be able to see the 
whole screen rather than just the current line.

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

This is probably a result of you having disabled async. It really would be a 
good idea to find a way to get the timer part of async working. I don't mind 
helping with this, but I can't until I know how to set up a Grub build 
environment.

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

Please! I haven't called you an idiot. You can't possibly be an idiot if you're 
undertaking this kind of project.

There's nothing wrong with admitting ones ignorance on a topic, though. I, for 
example, am entirely ignorant when it comes to Grub internals. I don't mind 
admitting this. Likewise, you're unfamiliar with the use of braille when it 
comes to handling a computer screen. There's nothing at all wrong with you 
admitting this, either. We both have complementary skills, here. I know about 
braille use and you know about Grub.

Also, I haven't been just trashing your ideas. I believe I have, each and every 
time, attempted to explain the reasons behind what I'm saying. If there 
actually has been an instance where I've simply said that you're wrong, without 
explaining why, then I'm sorry.

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

A braille user has come to expect the various controls on his device to work in 
the ways that they do. It'd be nearly impossible for you to redefine all of 
tjis in some brand new set of tables outside of brltty. Even if you somehow 
could, it'd go out-of-date the moment we make some change in that area.

Braille device controls aren't simple things. In many cases, key combinations, 
rather than just single keys, are used to define screen navigation operations.

There's also a very rich set of screen navigation operations which braille 
users have available to them. Reducing this to a simple left/right scroll would 
be extremely limiting.

Try to imagine how you would feel if you were suddenly handed a keyboard where 
all of the keys were in different places, and a monitor which only let you see 
part of the one line that someone else thought would be the only line on the 
whole screen you should ever be able to look at. Would you be a very efficient 
user of your computer if this were done to you?

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

It will work. I ahve no doubt about that. It boils down to do we want the 
deception of something far less than adequate working faster, or are we willing 
to put in the effort and patience to make it work right.

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

That's one of my concerns. Doing this work in a way which doesn't lend itself 
to on-going, easy maintenance will make the work eventually become irrelevant. 
You'll be happy with a version that works, but a user with a new device which 
ssn't supported by your old version won't be happy.

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