Robert Millan wrote:
On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote:
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
On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote:
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
* 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,
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
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.
On Thu, Nov 06, 2008 at 06:05:21PM +0100, Yoshinori K. Okuji wrote:
On Tuesday 04 November 2008 18:14:17 Robert Millan wrote:
On Tue, Nov 04, 2008 at 04:52:20PM +0100, Yoshinori K. Okuji wrote:
No ChangeLog?
Here. I ommitted it because I wanted to see if it would need big
adjustments
On Tue, Nov 04, 2008 at 08:12:56PM +0100, Robert Millan wrote:
- Turn the grub_cur_term_{input,output} pointers into lists, so that
multiple terminals can be current at the same time.
- Implement a magic input (or output) terminal that can be attached to
other terminals and
On Tuesday 04 November 2008 18:14:17 Robert Millan wrote:
On Tue, Nov 04, 2008 at 04:52:20PM +0100, Yoshinori K. Okuji wrote:
No ChangeLog?
Here. I ommitted it because I wanted to see if it would need big
adjustments first.
OK. The patch looks perfect for me.
BTW, I would like to obtain
On Sunday 02 November 2008 19:11:32 Robert Millan wrote:
Hi,
This patch splits terminal handling in input and output. While at it, it
resolves/removes some of the kludges we had to work around this limitation.
For example, gfxterm/vga no longer need to assume the input is bios
console,
On Tue, Nov 04, 2008 at 04:52:20PM +0100, Yoshinori K. Okuji wrote:
No ChangeLog?
Here. I ommitted it because I wanted to see if it would need big
adjustments first.
BTW, I would like to obtain the capability of handling pipes, so that we can,
say, help | more. I guess you have the same
Yoshinori K. Okuji wrote:
BTW, I would like to obtain the capability of handling pipes, so that we can,
say, help | more. I guess you have the same idea in your mind. This should
be trivial, once the input and output are separate, right?
I think this would need separated streams design in
Robert Millan wrote:
Hi,
This patch splits terminal handling in input and output. While at it, it
resolves/removes some of the kludges we had to work around this limitation.
For example, gfxterm/vga no longer need to assume the input is bios console,
at_keyboard can be used in
On Tue, Nov 04, 2008 at 08:53:22PM +0200, Vesa Jääskeläinen wrote:
I think multipath would be nice feature. Eg. you can have serial/other
remote connected and then have local terminal at same time.
In fact we need that if we ever want to support reading from AT keyboards
and USB keyboards at
On Tue, 4 Nov 2008 20:12:56 +0100
Robert Millan [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 08:53:22PM +0200, Vesa Jääskeläinen wrote:
I think multipath would be nice feature. Eg. you can have
serial/other remote connected and then have local terminal at same
time.
In fact we
Hi,
This patch splits terminal handling in input and output. While at it, it
resolves/removes some of the kludges we had to work around this limitation.
For example, gfxterm/vga no longer need to assume the input is bios console,
at_keyboard can be used in combination with any output terminal,
15 matches
Mail list logo
