[BRLTTY] BRLTTY in GRUB

Thu Mar 15 15:07:50 EDT 2012

On 15.03.2012 19:22, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/15 at 17:22 +0100]
>
>> Particular driver at one side allowed me to pull in something we, for
>> sure will need, 
> The drivers have been written such that they can depend on core functionality. 
> Any changes which involve modifying individual drivers will be destined for 
> failure. Even chganges to higher level core functionality are a very bad idea.
>
> Changes to the code are made on an on-going basis. If we can't rely on common 
> functionality working as it does, we'll always have to be worried abouty 
> breaking the Grub implementation every single time we do anything. That's 
> simply unacceptable.
>
> It's essential that anything which is platform-specific be isolated such that 
> it ideally need never be touched again. This can only ever be ensured if it 
> only touches the lowest level of system interfacing.
I have an impression that we don't understand each other. Currently I
take following files from brltty:
  common = braille/brltty/Programs/parse.c;
  common = braille/brltty/Programs/driver.c;
  common = braille/brltty/Programs/brl.c;
  common = braille/brltty/Programs/queue.c;
  common = braille/brltty/Programs/ttb_translate.c;
  common = braille/brltty/Programs/drivers.c;
  common = braille/brltty/Programs/bluetooth_none.c;
  common = braille/brltty/Programs/bluetooth.c;
  common = braille/brltty/Programs/usb.c;
  common = braille/brltty/Programs/usb_serial.c;

Following files I implement right now:
  common = braille/brltty_wrap/timing.c;
This file seems to be platform-specific and uses select().
  common = braille/brltty_wrap/log.c;
GRUB has no file writing facilities
  common = braille/brltty_wrap/charset.c;
GRUB has Unicode but no iconv
  common = braille/brltty_wrap/usb.c;
Should be renamed to usb_grub.c actually.
  common = braille/brltty_wrap/serial.c;
Platform-specific.
  common = braille/brltty_wrap/async.c;
Seems to use select() and requiring multi-threading.
  common = braille/brltty_wrap/ktb.c;
Currently dummy for keys.
>> and on the other hand in GRUB it's largely preferred to 
> Brltty already loads the needed driver. Although it can be built > with all of 
> the drivers linked in, that's not the default way it works. The default way is 
> for the core to have no drivers linked in, and for it to load the driver which 
> the user needs.

Which code handles autoloading? I haven't seen any library loading calls.

>> I'd rather avoid pulling in parts we don't need. If you can give me a
>> set of functions that are easy to integrate with GRUB but won't result
>> in the need for large wrapping layer (in particular anything needing
>> multithreading is a no-go since GRUB is single threaded).
>
> Call brlttyConstruct(argc, argv). Then, from some strategic place within Grub's 
> loop, call brlttyUpdate().
Easy enough.
> Implement a simple screen driver for Grub which returns whatever should be on 
> the braille display. This screen driver can present a one-line screen with the 
> current line on it. That should be good enough. This approach assumes that 
> there's a function in Grub for finding out what's on the current line.
In GRUB renderer is separated from info. It's easier to have good
Braille display by making braille another renderer rather than rendering
in standard screen and then having a reader.
I've already tested it with serial console 40x1.
>> Also I've noticed that the function convertCharToWchar is unlikely to
>> work with UTF-8.
> That function is probably not used for braille.
Hm, it was referenced in my tests.
>  Braille now works with wchar_t, 
> i.e. it works with Unicode. The screen driver returns the screen content in 
> Unicode, and that's the way it continues to be handled until it's eventually 
> converted into the correct braille representation.
>
>> Ideally for GRUB I'd like a set of functions something along:
>> void brltty_usb_device_attached (UsbDevice *);
>> void brltty_usb_device_detached (UsbDevice *);
> If we're going to go down a path which allows us some sort of safety in terms 
> of making changes to brltty in the future, then changing the USB paradigm is, 
> in my opinion, unacceptable. All we should need to do is correctly implement 
> usb_grub.c. Then, USB will simply work.
GRUB has hotplug ability. Is it possible to somehow make brltty pick it up?
>> int brltty_get_brl_width (void);
> Knowing the properties of the brialle device shouldn't be something Grub needs 
> to care about.
With separate renderer rather than reader will produce better braille
and it needs the screen size.
>> void brltty_set_displayed_text (uint32_t *ucs4_string);
> As mentioned above, this is the wrong paradigm. Write a Grub screen driver.
>
> Maybe you're imagining that braille support is as simple as "put the right text 
> on the display". It's not that simple. There are features, like cursor routing, 
> which need to work properly. These features especially need to work when, for 
> example, the user is editing the kernel boot command. The user also needs 
> correct control over his device when, for example, the current line is longer 
> than his display is.
Renderer already handles this. Keys can be mapped to analogous scroll
features.
>> Is it possible to somehow disambiguate this. In GRUB USB and serial devices 
>> are in completely different namespaces. 
> It's already disambiguated in brltty.
Yes but the string itself is ambiguous as the same string may be USB
serial number or serial device name. I'd prefer to avoid this in GRUB.
>> Some of the files I've replaced with my implementations have lots of #if's in 
>> them. Perhaps it would be better to declare them as platform-dependent. E.g. 
>> charset.c and unicode.c
> The #ifs in unicode.c are for available features, like libicu. That has nothing 
> to do with platform dependence.
Information about unicode is available in GRUB but not through the same
functions.
> The three worst cases I can think of in terms of #ifs for platform-dependent 
> code within portable code are mount.c, serial.c, and, yes, charset.c. It may 
> well be time to revisit those.
>
>> I have already implemented usb_grub.c except the two functions I don't 
>> understand.
> I've forgotten which ones they are. They're probably the ones for managing an 
> interrupt input endpoint. There are three: start an asynchronous request, 
> cancel it, and check for arrived input. While it's nice to have them 
> implemented, brltty does fall back to using bulk transfers if they aren't.
GRUB implements background transfers, very similar to what you describe.
Just it wasn't completely clear from prototype name.
The other function is setAlternative.
>
>> I'd prefer the GRUB build system to 
>> pick up brltty rather than the other way round. It simplifies version and 
>> module dependency management.
> It also complicates things whenever we change things as you undoubtedly, for 
> one example, then have to maintain your own set of which files to build.
We had good results with automated importing using python scripts.
In future it may be changed as to the direction of import but I'd first
like to make it work at all.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://mielke.cc/pipermail/brltty/attachments/20120315/87c1de3c/attachment.sig>