Re: SPAM-LOW: Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)

[Amin Azez <azez@ufomechanic.net>]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

* 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

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]