grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub & accessibility


From: Samuel Thibault
Subject: Re: Grub & accessibility
Date: Fri, 10 Jul 2009 20:13:46 +0200
User-agent: Mutt/1.5.12-2006-07-14

(sorry phcoder for the duplication)

Robert Millan, le Fri 10 Jul 2009 19:22:48 +0200, a écrit :
> We've made some exceptions, but in general, we'd like to keep the GRUB
> codebase made entirely of FSF-copyrighted code, or at least code we
> have disclaimers for.
> 
> OTOH, we don't want to discard valuable work that wasn't written specifically
> for GRUB.  Perhaps Marco or Okuji will allow an exception for this case.

The thing is that it would be sad to re-implement these drivers, as
getting hardware to make sure they work is hard.

> Another possibility is integrating those drivers in the grub-extras
> repository.  grub-extras is a collection of 3rd party add-ons for GRUB.
> It's not officially part of GRUB, but distributions (e.g. debian) can
> integrate it into their builds.

That seems like a good way. The core of screen reading can be
implemented in GRUB and drivers be modules.

> > diff -urN grub-debian-patched/configure.ac 
> > grub-0.95+cvs20040624/configure.ac
> > --- grub-debian-patched/configure.ac        2005-09-05 03:57:02.000000000 
> > +0200
> > +++ grub-0.95+cvs20040624/configure.ac      2005-09-05 03:56:54.000000000 
> > +0200
> 
> Only GRUB 2 is in development.  New features won't be added to GRUB Legacy
> anymore.

I know.  I didn't send the patch for inclusion, but for hpcoder to have
a look.  The story is that I met him at lsm and found he was interested
in implementing something so since I had already done some stuff it
could be a good thing for him to have a look at it.

> > +static unsigned char latin1_2_dots_vs[256] = {
> > +0X00, 0X81, 0X83, 0X89, 0X99, 0X91, 0X8B, 0X9B,
> > +[...]
> 
> This needs some clarification.  Opaque blobs are not acceptable, but arrays
> whose content is documented/understandable should be ok.

Same reason: that wasn't code meant for inclusion, it wouldn't be
implemented this way, though for this precise driver there would be such
array, converting from the ISO 11548-1 encoding of braille dots into
VisioBraille's own encoding of braille dots.

Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]