[BRLTTY] BRLTTY under real Dos

Nicolas Pitre nico at cam.org
Wed May 3 15:06:08 EDT 2006


On Wed, 3 May 2006, Samuel Thibault wrote:

> Nicolas Pitre, le Wed 03 May 2006 13:43:33 -0400, a écrit :
> > On Wed, 3 May 2006, Samuel Thibault wrote:
> > 
> > > 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.

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.

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

Because you also must evaluate the consequential costs of doing it.  It 
would add more material to the BRLTTY source base that has to be 
maintained inevitably adding complexity to the project and making the 
barrier to entry for new contributors even higher.  And that for what 
benefits?

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.

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

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

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

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

And what driver do you support?

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

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

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

I'd hope for serial support from BIOSes before anything resembling 
native braille display support, and yet this is a feature that doesn't 
work well even in the Grub version installed with FC4!

Sorry to rain on your parade, but I truly think there is better hope 
with BIOS accessibility in the LinuxBIOS project than vendor BIOSes.

There might even be a way to get at the BIOS ROM code and run it 
straight into an emulation sandbox with proper accessibility hooks for 
example.  That might not be as good as if you didn't need to boot into 
something in the first place but still.

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

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

It would indeed.  But believing that can be achieved with vendor BIOSes 
is a peep dream IMHO.


Nicolas


More information about the BRLTTY mailing list