bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Forward: Re: Serial Line boot may not properly clear the screen


From: Yoshinori K. Okuji
Subject: Forward: Re: Serial Line boot may not properly clear the screen
Date: Tue, 22 Jan 2002 02:23:36 +0900
User-agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryoae) APEL/10.3 Emacs/20.7 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN)

--- Begin Message --- Subject: Re: Serial Line boot may not properly clear the screen Date: Mon, 21 Jan 2002 16:54:34 +0100 (MET)
>>>>> Yoshinori K Okuji <address@hidden> writes:

    > At Sat, 19 Jan 2002 22:40:19 +0100 (MET),
    > Klaus Reichl wrote:
    >> If we do a `grub_print_esc' instead of `grub_printf' for ESC
    >> sequences, assuming that the terminal will swallow the sequence, and
    >> bypassing auto_fill, the auto_fill logic stays intact.  Is this idea
    >> to simplistic? 

    > I considered a similar approach, but it is not the Right Thing. What's
    > wrong about that is that GRUB doesn't track the cursor position
    > correctly. I now believe AUTO_FILL is the evil. As GRUB controls the
    > terminal completely (except when a dumb terminal is in use), GRUB
    > should always be able to know where the cursor is thereotically.

    > Therefore, I'm going to rewrite the terminal code radically, so that
    > each terminal driver (console, hercules, and serial) deals with the
    > cursor position, and remove AUTO_FILL. Perhaps the new code will have
    > a filesystem-like structure, like this:

    > struct terminal
    > {
    >   /* The terminal name.  */
    >   const char *name;
    >   /* Put one character.  */
    >   void (*putchar) (int c);
    >   /* Check is any input is available.  */
    >   int (*checkkey) (void);
    >   /* Get one character.  */
    >   int (*getkey) (void);
    >   /* Get the cursor position.  */
    >   int (*getxy) (void);
    >   /* Go to the specified position.  */
    >   void (*gotoxy) (int x, int y);
    >   /* Clear the screen.  */
    >   void (*cls) (void);
    >   /* Set the attribution of characters.  */
    >   void (*set_attrib) (int attr);
    >   /* Forward the cursor by N characters.  */
    >   void (*forward) (int n);
    > };

    > And, higher-level functions (such as get_cmdline) won't print any
    > escape sequences explicitly. This change will simplify the
    > implementation.

Great.

Do you think it is possible than to code like:

   if (term->gotoxy /* or term->getxy */)
      algorithm for terminals with positioning
   else
      algorithm for DUMB like terminals

instead of term (terminal & TERMINAL_DUMB)?

    >> If the terminal is dumb:
    >> prompt only with PROMPT and not with the original line
    >> read in keys until RET (no line editing at all, handling of BS
    >> though is debatable)
    >> this could easily be achieved by turning off readline in case of
    >> dumb terminal and handling the output of the original line
    >> otherwise
    >> normal (positioning) `get_cmdline'

    > I like this approach.

Me too, however, maybe this behaviour should be on another switch to
terminal.

e.g. terminal --dumb            => no ANSI positioning
     terminal --no-line-edit    => not even line editing

    > Also, I think it would be helpful to display "The original line is
    > ..." before the prompt, if non-empty CMDLINE is passed.

    > Another thing I'm thinking of is echo-back. When the terminal echoes
    > back inputs itself, it is just annoying that GRUB echoes back inputs
    > again. This is good in the batch mode of the grub shell, as the user
    > can see what command is executed currently, but no good in the
    > interactive mode, since you know what you type already. So it might be
    > useful to disable echo-back in a dumb terminal, except for the case of
    > the batch mode.

like above:
     terminal --no-echo         => don't echo back

    > [Oh, how many problems!]

Well, you know ...

* I do think, that your proposed terminal ops would make the code much
  clearer. 

* The 2nd thing (no-line-edit, no-echo) should be rather simple (I'm
  on the road for some days but afterwards I will look at these).

    > Thanks,
    > Okuji

Thanks,
Klaus

PS: In my first mail (Sat, 19 Jan 2002 22:40:19 +0100 (MET)), I forgot
to CC bug-grub.  This was not on purpose.  Should we add this
discussion to bug-grub or make a proposal first?
-- 
Klaus Reichl                        voice: +43 (1) 27722 / 3884
Alcatel Austria AG/RTPT             fax:   +43 (1) 27722 / 3955
Scheydgasse 41                      inet:  address@hidden
A-1210 Wien, Austria/Europe



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]