[BRLTTY] BRLTTY in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 15.03.2012 15:35, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/15 at 15:09 +0100]
>
>> I've pulled as much core as needed cutting at the lines where it was
>> the easiest to implement a glue layer
> In my opinion, if it's involving looking at individual drivers, rather than 
> just at doing what's necessary to make the core work within Grub, then it's 
> being done in an unsafe way. I'll be glad to help have a crack at it if you can 
> tell me how to set up the right build environment.
>
Particular driver at one side allowed me to pull in something we, for
sure will need, and on the other hand in GRUB it's largely preferred to
be able to load drivers individually. In brltty it seems that you can
load only the large block.
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).
Also I've noticed that the function convertCharToWchar is unlikely to
work with UTF-8.
Ideally for GRUB I'd like a set of functions something along:
void brltty_usb_device_attached (UsbDevice *);
void brltty_usb_device_detached (UsbDevice *);
int brltty_get_brl_width (void);
void brltty_set_displayed_text (uint32_t *ucs4_string);

As for the input of set_displayed_text I can propose either of:
- Groups of unicode character with attached combining characters (preferred)
- UTF-32 in native endian
- UTF-8
- UTF-8 with bidi reordering
- ASCII (last resort)
>> Then I don't understand following part:
>> static int
>> openUsbPort (const char *device) {
>> ...
>>  if ((usbChannel = usbFindChannel(definitions, (void *)device))) {
>>    return 1;
>>  }
>>
>> and usbFindChannel apparently searches by serial number.
> I think I must've misunderstood you, then. Maybe you just said "serial" instead 
> of "serial number". If you mean what follows usb: in the device identifier, 
> then, yes, it's an optional serial number. I thought you were asking if brltty 
> treated the device as a virtual serial device.
I meant "serial number". Is it possible to somehow disambiguate this. In
GRUB USB and serial devices are in completely different namespaces.
>> I'll also need to #if-out some part, like anything using float/double
>> since GRUB doesn't have those.
> Well ... I'd rather have a look at such code (there can't be much) to find if 
> there are other ways to implement it.
Right now it seems that none of the functions in question are used in
any of the code I've imported, only declared and/or implemented. Could
we have a define like HAVE_FLOAT ?
>
> Basically, I hate hacking. I'd rather use projects like this one to find ways 
> to make the code more and more portable. It may be the tougher toad to travel, 
> but it's always invariably the one which yields the most fruit. This approach 
> has kept brltty's code rather clean in spite of the fact that it's grown to 
> support multiple platforms, multiple I/O methods, lots of new features, etc.
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
>> We don't implement libusb
> But there'll be some way to do USB operations. They just need to be impemented 
> in the correct set of low level functions.
I have already implemented usb_grub.c except the two functions I don't
understand.
>  As long as autoconf can have a way 
> to know that the environment is Grub, then it can select the Grub set of low 
> level USB functions and the core will just work.
I'd prefer the GRUB build system to pick up brltty rather than the other
way round. It simplifies version and module dependency management.


-- 
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/50af3ad7/attachment.sig>