* Yoshinori K. Okuji wrote, On 25/11/08 21:23: > On Saturday 22 November 2008 20:54:57 Robert Millan wrote: > >> On Sat, Nov 22, 2008 at 06:42:54PM +0100, Yoshinori K. Okuji wrote: >> >>> However, whenever you want to do more than that, you must control each >>> terminal differently. In particular, the menu code. The menu interface >>> may not be uniform with all terminals. A terminal might have the size >>> 80x25. Another might have 120x40. This is more complex with graphical >>> terminals. >>> >> This problem does only happen with output terminals, right? My primary >> concern are input terminals, because if we want to support USB keyboards >> we need to probe from both USB and AT ones at the same time. >> > > Yes. > > >>> I like the idea that GRUB displays the user interface simultaneously. But >>> this requires a lot of refactoring. Probably, the menu code will have to >>> iterate all terminals explicitly, and make actions differently for each >>> terminal, based on the capabilities. With the menu editor, how should the >>> cursor be managed? We need to think a lot. >>> >> I've been thinking... what if we make this generic? I.e. with an event >> loop, then terminals can register their poll functions to it, and write >> their stuff to a shared resource the rest of GRUB can read from. >> > > For inputs, this is trivial for me. But, for outputs, not simple. For > example, > although we don't support yet in GRUB 2, if we have a dumb terminal, the menu > interface must be very different from others. >
I just noticed this converation. I use 2x16 character 4 button serial terminals, and on "some" of them you have to poll for keypresses! (And ideally convert a bitmap into keycodes, and debounce). Sam
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
