[BRLTTY] BRLTTY under real Dos

[Samuel Thibault]

Nicolas Pitre, le Wed 03 May 2006 13:43:33 -0400, a écrit :
> On Wed, 3 May 2006, Samuel Thibault wrote:
> 
> > Nicolas Pitre, le Wed 03 May 2006 12:28:58 -0400, a écrit :
> > > Well... for such a use I'd probably investigate linking BRLTTY directly 
> > > with grub instead.
> > 
> > That's quite another story, since grub doesn't provide all the features
> > that an OS provides.  It doesn't handle interrupts, for instance.
> 
> Indeed, but BRLTTY shouldn't need much.  It needs a time abstraction for 
> delays, plus some read() and write() replacements to communicate over 
> the serial port, plus a memory allocator, and a grub specific screen 
> driver.  Anything else can be stubbed out with dummy functions in 
> sys_grub.c.

Not so easy. There is no generic memory allocator, and time is a bit odd
in grub: it busy loops waiting for keypresses... This needs to be turned
into polling both keyboard and serial port.

> > Porting brltty to DOS would probably be much easier.
> 
> Are you sure?

On the TSR-able problem, not necessarily, but from the programming
environment point of view, definitely yes (except the "int" issue). And
I really think TSR problems are less tricky than getting grub implement
all the things that brltty needs.

> I'm not, and I doubt there will be many users as well.

This needs to be tried: in case it reveals to be easy, why not doing it?

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

> > I already did some work on grub1: I added the VisioBraille driver
> > to grub and added basic grub reading, and this already works quite
> > fine.  But grub people don't accept any new features in grub1.  Such
> > development would have to wait for grub2.
> 
> Of course I wouldn't envision adding BRLTTY to grub source base that 
> would be insane and unmaintainable.  Instead there should be a way to 
> add some kind of "plugins" capabilities to grub so BRLTTY configured for 
> grub would only compile to a single grub_brltty.o file that the grub 
> build process would be instructed to link with, and instanciated somehow 
> at run time in a standard (non BRLTTY specific) way.

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.

> > More than that, it would be useful that brltty (and/or other screen
> > readers) be able to provide basic drivers + basic screen reading engine
> > as small independant objects.  That would even permit integration in
> > BIOSes (even in proprietary BIOSes if the object licence permits it (BSD
> > for instance, not GPL/LGPL))
> 
> I'm sorry to not be that inclined towards BSD licensing with BRLTTY 
> code.

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.

> Better encourage projects like LinuxBIOS

Do you really think LinuxBIOS will ever be usable on all PCs you can
shop?

On the contrary, if only really _BASIC_ drivers were to be available as
BSD code, I doubt any proprietary products would make money with it, and
on the other hand usual BIOS manufacturers would be able to make their
BIOSes accessible! The benefit (computers that are accessible from BIOS
start) would be really _huge_.

Samuel