Re: questions about your project

[James S. <jsi...@su...>]

Sorry about the delay. The holidays and all. As you can see this list is
very quite.

> 1.
> 
> I have written a kernel patch which allows a process which has
> a virtual console open in read mode to call an ioctl() on it to
> inject a small string of characters into the keyboard input as
> if they had been typed on the keyboard.  It only accepts the
> string if it won't overflow the buffer.  I personally have a
> few uses for this, and even though I have not fully studied it
> for security concerns and best practices, I've already put it
> into use on my systems.  It comes with a small C program which
> lets scripts inject data, including converting \ and ^ notation
> (in the sample program, not the ioctl).  Although a number of
> people have suggested I use pty's to do the things I needed this
> for, I consider a pty and the program that has to stay keeping
> the pty side open as being overhead I don't want, considering
> that I only inject data rather infrequently.
> 
> Is this an area which would be considered to be part of the
> virtual console redevelopment effort?

I like to look at this patch. Could you post it to the list?
 
> 2.
> 
> I've been interested in frame buffer consoles, but I have found
> that for many uses, they remain to slow.  Further, some of the
> ways they were is causing difficulty with how I use them.

This is because the graphical console are usually drawn pixel by pixel :-( 
I plan to have the drivers moved over to start using the accel engine
more.

> In particular, I find myself frustrated with the lack of distinct
> console abstraction with frame buffers.  There is technically
> just one frame buffer, with limited access.  

I couldn't agree with you more. In fact this is one of the reasons for
this project.

> What I really would
> like to see is frame buffering where each virtual console has its
> entire screen cached (and yes, I understand this can be as much
> as 4 megabyte or more per console) so that when switching consoles,
> the original contents are always re-presented, and the processes
> owning that console can make changes while I'm "away" and I can
> see the results of those changes when I switch back.

We don't cache the framebuffer due to memory size and complexity. We do
have a text buffer that is video card independent which stores the screen
image as if it was in text mode. This allows for what you are suggesting. 

> I'd also like to see one other feature, which could help address
> the space requirement for fully cached frame buffers, as well as
> the slowness issues I see.  This would be to have each virtual
> console individually define what mode they are in, be that frame
> buffer, or text mode.  That way I could choose to have 2 consoles
> in frame buffer mode with 4 megs each, and 50 consoles with no
> more than 16K each (based on my SVGATextMode extended size of
> 120x58).

Hum. Yes you can have different video modes for different consoles. I'm
in the process of making this driver independent. For the new console
system their are 16 consoles for every VT. SO you could have vgacon on
the first 16 and the second 16 you could have fbcon running.

> I've never found out if X Windows _must_, or simply _may_, use its
> frame buffer driver when Linux is booted up in frame buffer console
> mode, since I didn't stay with frame buffers long enough to try it.
> If it _must_, I'd sure like to see it changed to _may_ (with the
> obvious other choice of accessing the raw video device as it does
> without frame buffers).

Option "UseFBDev" 

By default XFree86 doesn't use the fbdev layer. You have to tell it to.

> 3.
> 
> Also, an idea I had a couple years ago, which I never followed up on
> with anyone, might be applicable here.  The idea was to have a screen
> saver device.  

/dev/vcsaX

> This device would work much like a virtual console
> (and in the case of frame buffers, should work like that, too).  But
> what it would be used for is to be the replacement content for when
> the screen saver timer pops.  It would initially have a blank content
> but a program could place content there to be seen in place of blank
> content when the timer pops.  There would also need to be a means for
> the program which has it open to know (without polling) when that
> screen is being displayed, and when it is not.  One thought is to
> call an ioctl() to enable signals USR1 and USR2 as indications.
> A program like Seti@Home could use that to start working only when
> its display is brought up by the screen saver.  Many other things
> could be possible.

You could do this rather easy in userland :-) You just have to turn off
the normal screen blanker in the kernel. Their is a simple ioctl call for
this. Set up your timer and poll for keyboard input. When no keyboard
input for X time then run blah program.