From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1L5J7r-00021A-In for mharc-grub-devel@gnu.org; Wed, 26 Nov 2008 07:04:11 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5J7p-000215-1t for grub-devel@gnu.org; Wed, 26 Nov 2008 07:04:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5J7l-0001xW-32 for grub-devel@gnu.org; Wed, 26 Nov 2008 07:04:07 -0500 Received: from [199.232.76.173] (port=51633 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5J7k-0001xK-U9 for grub-devel@gnu.org; Wed, 26 Nov 2008 07:04:05 -0500 Received: from mail2.webhost.ie ([83.138.8.79]:4196) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5J7k-0003UG-4e for grub-devel@gnu.org; Wed, 26 Nov 2008 07:04:04 -0500 Received: from 87-194-180-175.bethere.co.uk [87.194.180.175] by mail2.webhost.ie with SMTP; Wed, 26 Nov 2008 11:41:33 +0000 Message-ID: <492D35EA.2000404@ufomechanic.net> Date: Wed, 26 Nov 2008 11:41:30 +0000 From: Amin Azez User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: The development of GRUB 2 References: <20081102181132.GA24737@thorin> <200811221842.54928.okuji@enbug.org> <20081122195457.GA7779@thorin> <200811252223.53090.okuji@enbug.org> In-Reply-To: <200811252223.53090.okuji@enbug.org> Content-Type: multipart/alternative; boundary="------------050005020200030808050506" X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ X-Greylist: delayed 1329 seconds by postgrey-1.27 at monty-python; Wed, 26 Nov 2008 07:04:03 EST Subject: Re: SPAM-LOW: Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2008 12:04:09 -0000 This is a multi-part message in MIME format. --------------050005020200030808050506 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit * 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 --------------050005020200030808050506 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit * 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
--------------050005020200030808050506--