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 ca
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.
>
> F
* 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 par
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 unifo
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 Friday 07 November 2008 20:26:32 Robert Millan wrote:
> 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 (o
On Friday 07 November 2008 20:07:07 Robert Millan wrote:
> On Thu, Nov 06, 2008 at 06:20:57PM +0100, Yoshinori K. Okuji wrote:
> > Also, a similar technique can be used to implement "getting an output as
> > a string". For example:
> >
> > # Use the same password as the super user.
> > set pass
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 terminal
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
> > a
On Thu, Nov 06, 2008 at 06:20:57PM +0100, Yoshinori K. Okuji wrote:
>
> Also, a similar technique can be used to implement "getting an output as a
> string". For example:
>
> # Use the same password as the super user.
> set password=$(sed -ne '/^root:/{s/root:\([^:]*\).*/\1/;p}' /etc/shadow)
On Tuesday 04 November 2008 19:31:09 Vesa Jääskeläinen wrote:
> 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
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
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.
>
> I
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 a
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 comb
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 i
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 s
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
> consol
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,
19 matches
Mail list logo
