Re: Multhead epiphany

[Filip S. <fs...@st...>]

On Sat, 3 Aug 2002, Nicolas Souchu wrote:

> On Tue, Jul 30, 2002 at 11:06:05AM -0400, Filip Spacek wrote:
> >
> > I was sitting in front of my computer, thinking how should multihead be
> > done, I was considering sharing the io structure and creating separate
> > mode structure and a separate meta language with different function for
> > setting of a mode on the second head and then registering the resulting
> > display with KGI.
> >
> > And then Paul came along and said: "Why don't you make it a separate
> > image?"
> [...]
>
> Hmm, this is not my understanding of kgi/doc/kgi.sgml. I consider images
> as filters describing how to process applicative buffers to produce
> final output.
>
> Why not simply consider the second head as a second display?


I realize that registering the second head as a second display seems like
the most appropriate thing. That was indeed what I started with. But as
soon as I started actually implementing this concept an incredible amount
of details started popping up that just made this idea not worth while.

So for example: each driver is composed of a meta, io and mode structure.
Since the hardware for each head is the same (from the system's point of
view) the io structure should definitely be shared. The mode structure
contains all the mode state so it seems logical that they should be
distinct. As for the meta structure, it contains all the actual callbacks.
It would be nice if they could be identical, but they can't because the
mode checking needs to be different for each head. Not the actual checking
part, but the last section where device dependent state is initialized
each head needs different info. So now the second head has a new meta
language, but obviously this one wouldn't contain any initialization or
denitialization code because that is all taken care of by the first
display. But what happens when the first display is deinitialized? It's
done method will restore the chipset to the state it found it in, but the
second head is still running.

There's plenty more problems with registering the second head as a second
display. Displays are meant to be independent things and everything is
designed around this. But two heads on the same card are not independent.
They share functionality and limitations of the card. So when text is
displayed through the vga-text functionality the whole card needs to be
put into vga mode which often makes the second head unavailable. Making
two displays interact like this is just way too hard and messy.

Now let's look at the option of using images. The only change required to
the drivers is extending the mode check callback to check both images and
extending the mode structure to include register states for the second
crtc. As I mentioned in the second email, ever other abstraction just
falls in place. General facilities provided by the card are shared as mode
resources, there's only one framebuffer and one accelerator. Other
features such as a pointer and luts are per head facilities which is
already nicely abstracted in the concept of per image resources. We
maintain the 3 structures for the driver so all the complicated
interaction between features and limitations shared by the two heads can
be easily managed inside modechecking (if the user requests text mode on
the first head/image and the card needs to be put into vga mode which
makes the second head unavailable a request for the second image simply
fails because in that case there cannot be a mode on the second head).

The only thing that worries me is the userland portion. Suddenly we don't
have a display per monitor which will complicate things. But KGI's job
is to cleanly expose video hardware functionality to the userspace. And I
don't see a reason why should KGI go to any great lengths to hide the fact
that the two heads are not independent. They aren't independent and that's
exactly what the user gets through two images on the same display.


-Filip