Re: Events in libcons

[Marcus Brinkmann]

At 03 Apr 2004 13:20:46 -0800,
thomas wrote:
> 
> 
> So I'm wondering why libcons is responsible for this kind of thing?  I
> would have expected the next level up (like X) to be responsible for
> when the cursor appears?

There is a lot of potential for confusion here.

We have actually a very modular design.  Each module has its own
responsibilities and interfaces.

In particular, you have two distinct "realms".  The first is required,
and involves the console server, term, getty, login, and eventually
the shell and console applications running in it.  The lower level
components here, the console and term, provide very abstract
functionalities.  The console server provides abstract output and
input text terminal capabilities.  (2D matrix of characters with
colors and attributes, plus text input).

You can access the console server via a mixed ipc/shared memory
interface to display the content of the console and provide input into
it.  Note that as far as the console _server_ is concerned, hardware
is irrelevant.  The console server does not know nor care about
graphic cards, keyboards, mice, etc.  On the "term" side it has an
input and output stream of characters in the local character set,
interleaved with escape sequences.  On the "console client" side it
has a virtual console display with history logs for incremental
updates, and an input stream of UTF-8 characters, again interleaved
with escape sequences (which are not interpreted, but passed through
to term).

However, the console _client_ must care about hardware access.  It
also implements a full console itself.  So, if that console should
support cut & paste (as is done by the Linux console via gpm, for
example), it must implement that support.  It must also display the
mouse pointer etc.  Now, how to do this depends of course on the
target you want to support.  Currently, the only targets supported are
a native PC console with VGA graphic card, keyboard, and mouse (the
mouse will generate escape sequences that can then be understood by
programs like midnight commander or emacs), and the ncurses target,
which allows to use the console client in any Unix terminal.

Now, you could imagine a native X target, where the console server
data is put into an X window directly, and the X input is put into the
console server.  In that case, the console client itself would not
need to display an extra mouse pointer, of course.  The X windows
system mouse pointer can be used instead.  But in the native PC VGA
driver, the driver itself must display the mouse pointer.  For
example, as in Linux+gpm, with an inverted block, or in a framebuffer
by graphic card manipulation (can be done in many ways), or however.

So, libcons is a convenience library for console clients, just like
libdiskfs is a convenience library for filesystems.  It works by
implementing callbacks.  However, beside giving easy access to the
console server, it also implements a lot of functionality that should
be the same across all display clients, irregardless of the target.

One example is the behaviour of scrollback buffer display.  Obviously,
that should be the same in a native driver, in ncurses, etc.  A
screensaver is not really useful in the context of an ncursesw driver
or a native X driver (as then you already run within a different
console which will do the screen saving).  Still, it is generic enough
that libcons can implement the options to set the blanking times etc,
and then callbacks implement the function in a driver specific way.

A mouse pointer is also not needed in all targets.  It would not be
explicitely implemented by a native X driver, but for a native console
driver or for an ncurses driver it is mandatory (as we can not rely on
an external mouse pointer).  In fact, even for a native X driver such
callbacks (called by libcons) can be implemented in a meaningful way:
The X native console driver can hide and show the cursor on events
such as Marco proposed.  This is actually what you see in a
gnome-terminal: If the mouse cursor hovers over the terminal window,
it is hidden when you press a key, and shown when you move the mouse.
This behaviour is exactly the same as gpm in the Linux text console.
Such functions ("show mouse cursor", "hide mouse cursor") can be
implemented as driver-specific callbacks, but the policy when to show
and hide it can be set generically in libcons (and implemented there).

Thanks,
Marcus