Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Wednesday 24 May 2006 04:08, Dave Airlie wrote:
> > I am currently looking for some information or help in making the
> > Framebuffer devices use DRM and setting up a userspace system that
> > interfaces with the DRM backed framebuffer device to provide full 2D and
> > 3D acceleration of all supported features and *userspace* emulation of
> > the unsupported stuff.
>
> The first step is to provide some sort of communication between the
> DRM and fb drivers so they know the other one exists,
>
> previous attempts at this by myself have come apart in the device
> model which just plainly cannot support this without adding a couple
> of dirty hacks,
>
> The two attempts I've done, were using a vgaclass device from Alan
> Cox, and also adding a lowlevel driver for the radeon, hotplug became
> my major issue each time, discussions last year at Kernel Summit were
> had, but the results however never surfaced, I'm intending to go to KS
> this year and actually try and get Greg-KH to fix the device model for
> what we need as opposed to hacking the crap out of it.
>
> All the other designs and stuff people have mentioned have all been
> discussed to death before, people seem to love discussing graphics,
> but no-one seems to care about fixing it properly, in nice incremental
> steps that doesn't break older systems. The current systems are very
> very fixable, however there always seem to be lots of people who want
> to re-write it because it is a) ugly in their opinion b) don't care
> about backwards compat.
>

I'd never advocate just killing a functioning system. What I've been talking 
about is building a new system that sits alongside the existing one in the 
tree, depends on EXPERIMENTAL and BROKEN in the Kconfig system and takes the 
place of the traditional framebuffer system if someone decides to use it.

I say have it depend on BROKEN because that should keep the masses away from 
it while it's being heavily tested, and I say it should sit alongside the 
existing code and be *new* for exactly the reason you've pointed out. 
Modifying the existing systems to integrate the new technology would require 
either changing the driver model or a lot fo dirty hacks. Neither seems that 
good of an option to me.

DRH