* 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
|