[BRLTTY] BRLTTY under real Dos

[Samuel Thibault]

Hi,

Nicolas Pitre, le Wed 03 May 2006 15:06:08 -0400, a écrit :
> But my point is that it's up to BRLTTY to cope with the Grub 
> environment, not the other way around.  Grub should not emulate an OS.

Ok, but brltty was developped in a way that supposed a lot of things
which grub lacks.  BTW, grub people are adding more and more features
which makes it look more and more like an OS ;)

> If you can do it in 32-bit mode I'd say just try it.  Otherwise I don't 
> think it is worth the implied costs.

You can't know the real cost before beginning trying :)

On this issue, I really feel that adapting brltty to grub will probably
be more invasive than adapting it to DOS. (yes, the potential benefit
would be much broader though, so it would be worth the effort).

Well, anyway, this is just chatting, and makes us loose time instead of
actually trying DOS port, discovering issues, probably realizing that
they are too hard, and hence giving up (but at least it would have been
tried).

> > > And that would be less useful and rather backward to me.  DOS is 
> > > nevertheless a practically dead environment for which dosemu is 
> > > certainly a good substitute in 99% of the cases.
> > 
> > Well. I'm still using dos for booting my server. Why? Because even if it
> > has a lot of features, grub will never be as feature-full as DOS is for
> > editing parameters etc. And if some day grub becomes so feature-full,
> > then why developping it at all, instead of just taking a small linux
> > distro as boot loader?
> 
> What operation can you do with DOS for booting Linux that you cannot do 
> with Grub?

Having more powerful editing power than the simple grub editor.
Saving parameters, copying files from a floppy/cdrom/whatever, ... The
list is really long.

> And yes, some projects are already using Linux to boot Linux.

Then we should rather focus on just running brltty in them... (should be
fairly easy).

> > I repeat: grub1 will _never_ accept any new feature, be it BRLTTY or
> > plugins capabilities (I tried to have an "echo" command added, and it
> > was refused).
> > 
> > On the contrary, grub2 already integrates a notion of modules (and a lot
> > of people are currently implementing a lot of crazy things), so it would
> > probably work this way of course.
> 
> Why bothering about Grub1 then?

Because grub2 will not be released before quite some time.

> > I'm _not_ talking about BRLTTY code.  Only really _basic_ driver /
> > screen reading stuff.  Mere up/down/left/right browsing would just be
> > sufficient for instance.  Just the little bit that you've always dreamed
> > to have for just being able to change parameters in your BIOS.
> 
> And what driver do you support?

Any driver that people would contribute to.  Spending a little time
for providing a basic driver is not much, compared to the potential
accessibility benefit (see below).

> And what about my Brailliant display for which my PC bought last year 
> couldn't have support for since it wasn't available?

It won't work of course (unless the vendor provides ROM upgrades). Just
like buying big hard drives for an old board is a bit risky.

> And what about BIOS bugs (because of course we know that PC BIOSes are 
> known for their high quality and never have bugs)?

There will be some indeed.

These are issues of course.  But isn't a bad support in vendor BIOSes
better than _no_ support?

Have you listened to the BIOS/bootloader/kernel session of the FSG
a11y.org conference in Honolulu last year?  Such issues have been
discussed at that time...
http://accessibility.freestandards.org/conference/session10a.ogg

> Yet today's PCs are plain commodities which tag price has to be as low 
> as possible.  Therefore I doubt BIOS vendors might be convinced into 
> spending any resources for integrating such a feature that only 0.0001% 
> of the total customer base might use.
> <snip>
> believing that can be achieved with vendor BIOSes is a peep dream
> IMHO.

You find me quite optimistic about this, but IIRC, Janina told us
at some time on a11y.org that she (or FSG, I can't remember) was
contacted by some BIOS vendor about how they could make their BIOS
accessible. For isntance, there's the Tiano project from Intel which can
be an opportunity to take.

I don't know if it can apply here, but remember that some US law enforce
accessibility.

> Especially with modern PCs where the BIOS output is graphical _only_
> that means adding back the text menus etc.  This is not even a
> technical issue before being a business issue.

Ah.  All the PCs I have seen (except a very old 486-based one) had
text-only BIOSes...  In such case vendors would most probably not make
effort on accessibility.  But are BIOSes really heading to this?

> I'd hope for serial support from BIOSes before anything resembling 
> native braille display support,

BIOSes _do_ already have serial support, since this is one of the
services it provides to operating systems through interrupt 0x14.
They do have USB support too for keyboards, BTW.

> and yet this is a feature that doesn't work well even in the Grub
> version installed with FC4!

Agreed.  Grub's built-in support for serial is quite poor, maybe because
it doesn't use the uart IRQ.

> Sorry to rain on your parade,

I'm a bit voiceless on this.  I don't even know how I should understand
it...

> > Do you really think LinuxBIOS will ever be usable on all PCs you can
> > shop?
> 
> Certainly.  Motherboard manufacturers are using more and more "standard" 
> chipsets increasing the likelihood for your PC to be supported by 
> LinuxBIOS.

Agreed.  But will flashing your motherboard often be possible?  And how
will you be able to do this by yourself if you don't have accessibility
in the vendor BIOS?

> I truly think there is better hope with BIOS accessibility in the
> LinuxBIOS project than vendor BIOSes.

Of course accessibility in LinuxBIOS will surely be _way_ better than
accessibility in vendor BIOSes, and this needs to be worked on too.  But
I doubt you will find LinuxBIOS in freshly-bought PCs, so some effort
would be useful in helping vendors BIOSes.  And by implementing basic
drivers with a BSD licence, we may work only once and then embed them
into all of LinuxBIOS, vendor BIOSes, grub, Linux, BSD, ... Yes, you
already said in a previous post that you doubt such code could be shared
between all these, but I think a really basic implementation can.

Samuel