[Top][All Lists]
[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