[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. >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'm not sure what the problem is. If your goal is to replace the core and just load brltty drivers, that won't work. The drivers rely on code within the core. We can't guarantee that any changes we make to any driver will ever remain compatible with your replacement of the core. Brltty contains drivers of various ages. Older ones do things older ways, unless they've been upgraded. In spite of this mixture, they all work properly because they work in conjunction with a core that knows how to support the differences. Upgrading them all would be nice, except that it's extremely unrealistic due to the sheer cost of acquiring the hardware for testing. 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. >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). Brltty doesn't require multi-treading. Configure it with speech and the API disabled. Grub should do what brltty's main() function does. Removing all the unecessary stuff, this means: Call brlttyConstruct(argc, argv). Then, from some strategic place within Grub's loop, call brlttyUpdate(). 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. >Also I've noticed that the function convertCharToWchar is unlikely to >work with UTF-8. That function is probably not used for braille. 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. Going down a path where things are sufficiently different in Grub is, in my opinion, not good. We must recognize that ensuring that brltty works in Grub isn't easy. We need to know with certainty, on an on-going basis, that it'll still work in Grub after we've tested it on Linux. This can only be done if we don't start modifying things at higher levels, and if we only change for Grub that which is absolutely necessary. >int brltty_get_brl_width (void); Knowing the properties of the brialle device shouldn't be something Grub needs to care about. >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. Also, a number of braille devices have keyboards on them. Their users like to use them. The core knows how to interpret these keyboards, and then enqueues the character as keyboard input. This is another job for the screen driver to handle. Again, therefore, you really do need to provide a Grub screen driver. The core already knows how to do all of these things properly. It'd be wrong to reimplement all of that. >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) As mentioned above, a simple Grub screen driver which returns Unicode will do the job. >I meant "serial number". Okay. It's too bad that the word "serial" is used for two such different things. >Is it possible to somehow disambiguate this. In GRUB USB and serial devices >are in completely different namespaces. It's already disambiguated in brltty. serial: means to use serial I/O, and usb: means to use USB I/O. For completeness, there's also bluetooth:, which, of course, means to use Bluetooth I/O. >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 ? Sure. >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. 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. >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. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
