[Top][All Lists]

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

Re: some console code checked in

From: Marcus Brinkmann
Subject: Re: some console code checked in
Date: Mon, 18 Mar 2002 13:29:35 +0100
User-agent: Mutt/1.3.27i

On Mon, Mar 18, 2002 at 03:12:54AM -0500, Roland McGrath wrote:
> I checked in some build nit fixes, and started a ChangeLog file.


> I think all the terminal emulation stuff belongs in the common layer and
> not in the vga code.  All that stuff would be the same for a different sort
> of output device.  Each output device can just have a few calls for move
> cursor, scroll, clear space, write chars, etc.

I have considered it, that is how it was done in colortext.  It is a nice idea,
but I think it is based on wrong assumptiond about the display drivers/
It assumes that all display drivers basically have the same features, and
work roughly the same way.  But if you look what there is outside of
framebuffer and VGA text hardware, there is lots of stuff that works quite
differently (Braille terminals, Text-to-Speech, "intelligent" terminals
doing their own escape sequences handling).  For some of these, things like
scrolling a part of the screen might be emulated anyway, but it would be
slower.  For others, there is not even a screen to scroll.

However, what I think can be done is to isolate that code, and have it in a
seperate file with it's own small abstraction layer.  Then drivers like the
VGA display driver can include that and make use of it.  What do you think?

> About LEDs: in the PC keyboard hardware they are part of the same hardware,
> so it needs to be the same driver as handles the keyboard input.
> but it would be good to
> factor it into the vc switching code and so on from the start anyway.

No problem.  The underlying input devices will be informed about the switch
and get a chance to diddle their state specifically to the console switched
to.  This is necessary anyway for them to adopt to the expected encoding for
the terminal.
> About the bell, you can see the oskit code for how it's handled in the PC
> hardware (pc_speaker).  It's just io ports that you use to set the
> frequency and turn the tone on, then you wait, then you turn it off.

Oh, that's easy.

> I don't think anything else uses those particular io ports (0x61 turns the
> speaker on, 0x48 controls the timer that drives the tone frequency), so
> console could just diddle them directly as it does for VGA (though there is
> the timing question--it would suck to have your speaker keep beeping while
> something gets paged in before console runs again to turn it off).  

Yes, this is a serious problem.  It is also not easy to solve this in the
kernel. What you can get easily is a beep that blocks the system, but I am
not sure how hard it is to get a non-blocking beep at the kernel level
(seems to require some interrupt stuff to switch it off at the right time?).

> What makes you think that trivfs won't work and you need netfs?

Neal told me that doing multiple nodes like we want to is a pain in trivfs. 
He did it this way in his procfs implementation (so I know it can be done),
and he said it was a mistake.  Do you think trivfs would be better?


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

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