About displays and screens

[Tomas Carnecky]

On Saturday, I had a discussion with Adam Jackson (ajax) on irc about 
EGL. I immediately checked out the mesa cvs code to see the code, 
because I like the idea of being able to use opengl without the xserver.

I first thought that EGL is just a library for creating contexts and 
surfaces. But it's more. I went through the code and saw that there's a 
eglDisplay, which is a collection of eglScreen(s). I don't think it's 
right to put the logic of Displays and Screens into this low level 
library. The Xserver should manage the screens and put them together to 
  displays.
Adam said out that it would be hard to implement the locking to make 
sure two applications that use the same card (but possibly different 
screens) don't get into each other. It doesn't matter how many 
applications are using the same card. Event today there must be some 
sort of locking. For example if I start two instances of glxgears that 
do direct rendering, someone must make sure they don't access the card 
at the same time, even if it's the Xserver.
Someone said I should write my own code. I did that, I was working on it 
during the last months. It's nothing more than a library that allows you 
to open a device (a device is what would be called a screen in X), 
create opengl contexts and surfaces, and share the surfaces between 
processes, and copy from one surface to another (if the drivers support 
that).
I don't like the idea that the Xserver owns the backbuffers of a clients 
window [1]. I thought about being able to say 'hey xserver, I have a 
backbuffer here, put it somewhere on the screen' instead of 'hey 
xserver, allocate a backbuffer for me'. That's why it's possible to 
share the surfaces. There's no distinction between on-screen and 
off-screen surfaces. You can convert a off-screen surface into a 
on-screen surface and vice versa. Now it's important to say that only on 
on-screen surface is allowed, so basically the application 'takes over' 
the screen (frontbuffer).
The library is small (90K shared object), and the drivers can be very 
flexible. Right now I have a fb driver (10K, used only to provide 
surfaces) and a mesa driver (2.2M, stataically linked, to create 
contexts). There also is a sdl (using libSDL, provides surfaces) and a 
shm (shared memory, also provides surfaces) driver. It would be very 
easy to make a X11 driver (surface == X window, context == glXContext), 
or even a network driver that translates the gl*() calls into packets, 
much like the GLX protocol.
Now what's the difference to EGL, Mesa? This library is only a 
abstraction layer, there is no logic whatsoever (I consider putting 
screens together to displays as logic).
Why is it better than EGL (don't kill me pls :) ? It does only what it's 
supposed to be. Hmm.. I guess EGL also does what it's supposed to be, 
but this library is more flexible. As a graphics card user, I don't want 
to know about the screens/displays. I want to be able to use the GPU to 
draw some nice images [2], but also to be able to display them on the 
screen.


tom


[1]: We're in the open source world, we don't like if other own our 
work, right?

[2] It doesn't have to be images, you also can use the GPU as a solver 
for equations, which can be _many_ times faster than doing that on the CPU.