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
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
