Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/25/06, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> * Review Dave Airlie's posts, he's been pretty spot-on in this thread.
> There needs to be a lowlevel driver that handles PCI functionality, and
> registers itself with the fbdev and DRM layers.  The fbdev/DRM
> registrations need to be aware of each other.  Once that is done, work
> will proceed more rapidly.

Controlling which driver is bound to the hardware is an easy problem
that a low level driver handles nicely. But controlling binding
doesn't really fix anything. All of the drivers binding to it still
have to duplicate all of the code for things like VRAM allocation, GPU
start/stop, mode setting, etc. That's because the second level drivers
can't count on the other drivers being loaded. The giant mess of whose
state is loaded into the hardware still exists too. Just consider the
simple problem of who EOI's an interrupt.

I would instead start by making fbdev the low level driver. DRM could
then bind to it and redundant code in DRM could be removed. 90% of the
code in fbdev is always needed.  Hopefully X could be convinced to use
the services offered by the fbdev/DRM pair. New memory management code
would be added to this base driver since everyone needs it. Fbdev
would also pick up the ability to reset secondary cards at boot.

I concede that loading both drivers will increase RAM usage slightly.
At some point it will be worth the effort to split an API
compatibility layer off from the lowlevel fbdev driver. But this is a
lot of work to get back <40K of RAM.

A related issue to this is mode setting. Initially I would leave it
alone in the fbdev code. Later it would use a collection of apps like
this. Mode setting is at the core of why X has to run as root.

|A good first project would be to start building a set of user space
|apps for doing the mode setting on each card. All of the code for
|doing this exists in the X server but it is a pain to extract. X has
|1000s of internal APIs and typedefs. You would end up with a set of
|apps that would be able to list the valid modes on each head and then
|set them. The code for achieving this is all over the map, sometimes
|we know everything needed like for the Radeon, sometimes you need to
|make a VM86 call to the BIOS to get the info (Intel). Load an fbdev
|driver and check out the current support for this in sysfs.
|
|When you get done with a command it should be a tiny app statically
|linked to klibc and have no external dependencies. These apps should
|be 30K or less in size. You probably will end up with about ten apps
|since a lot of the uncommon cards only have a standard VBE BIOS and
|will all use the same command.

Mode setting has at least these requirements...
1) Ability to be done at boot from initramfs
2) Ability for a user to change their mode without being root
3) No ability for a normal user to change the mode on hardware that
they do not own
4) Some hardware requires modes to be set using vm/emu86.
5) Monitor hotplug event needs to ensure that the new monitor receives
a valid mode
6) An interlock needs to be in place to stop simultaneous attempts to
change the mode

A key design problem is not requiring root and making sure you can't
change the mode on hardware that you don't own. This introduces the
entire concept of video hardware belonging to the logged in user.
I've written up more thoughts on this in the Kernel section of
http://jonsmirl.googlepages.com/graphics.html

I'm certainly open to any solutions that can satisfy the requirements.
Every solution that I've come up with so far is fairly complex.

--
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/