bug-hurd
[Top][All Lists]
Advanced

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

Re: Screensavers for the console


From: Marcus Brinkmann
Subject: Re: Screensavers for the console
Date: Sun, 11 May 2003 00:28:12 +0200
User-agent: Mutt/1.5.3i

On Sat, May 10, 2003 at 11:50:08PM +0200, M. Gerards wrote:
> Screensavers are still missing on the console although it is easy to write 
> some,
> even for people new to the Hurd. I've been thinking about what should be done 
> to
> make it possible to write screensavers.
> 
> IMO all display plugins for the console-client should support an option to 
> load
> screensavers (as plugins). These screensavers should be very general, for
> example if a screensaver only requires textmode it should work for all display
> drivers.
> 
> To support fancy screensavers with color graphics, etc. the VGA driver should 
> be
> extended a little to support a few graphic modes.

I think that's a bit off.  I don't say that it is unreasonable, but it
doesn't match what drove the console.

First, the console itself is independent of mode, and it doesn't support
graphics per se.  That means that any driver independent code should not
know about implementation details like graphic modes etc.  For the generic
interface, the console is a two dimensional array of cells.  Each cells
holds one unicode character and one attribute struct.  The existing
attributes are colors, bold, underlined etc.  If you want to add one or two
attributes bits, then we can talk about that, but graphic mode is a totally
different concept.  If you want to go in that direction, you should turn it
upside down, and write a console client which doesn't have the two
dimensional text cells as underlying assumption, but a framebuffer.  For
optimization, the framebuffer drivers might still support something like a
hardware cursor and fast glyph display from a font (by loading the font to
the video memory, for example), but it would be conceptionally totally
different.

The other question is how screensavers fit into the console.  There are
basically two models.  One is driver independent screensavers.  Those would
be something like: "Clear all screen cells" on sleep, and "Rewrite text
cells" on wakeup.  Inbetween, you could display fortune cookies, scrollling
text, unicode animations.  Alternatively, instead clearing the screen, you
could make the unicode characters drop from the screen, and such things. 
All this could be implemented without any driver specific code, or changing
the driver interface, but with the generic functions that exist today.

The other thing is something that really saves something, rather than burn
CPU cycles.  That would be a driver specific screen saver.  In fact,
screensavers could be drivers themselves, and some could use the generic
interface and some hardware specific interfaces (and in some cases a display
driver would come with its own screensaver drivers because of special
synchronisation needs, whatever).  For those screenservers, in particular
blanking and power save mode are worthy.  Only screensavers that ship with a
display driver could do funky stuff like graphic mode.  If you want a
generic graphic interface, you are talking about framebuffer support, and
my opinion on that is above.

Third, the main issue with screensaver support is synchronization.  There
should be a generic timer in the device independent code and the
blanking/power off etc times can be set at the command line. When the timer
expires, updating the screen will be disabled, and the screensaver callbacks
are invoked.  When a wakeup events happens (configurable, for example a
keypress), the screensaver is stopped and a refresh has to occur.
This is not hard to implement, and only needs two (three) new device driver
interfaces for sleep/(poweroff)/wakeup and one new callback into the generic
code (wakeup) when wakeup events occur.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

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