Re: redesigning the DRM internal logic..

[Dave A. <ai...@li...>]

> 
> Any idea if we can wrap legacy DRI users in a separate 'rendering
> context' so that you can run old and new X servers/DRI clients in
> different sessions? I'm thinking the exclusive nature will make some
> application compatibility 
harder (app 'Q' runs only on old DRI, app 'R'
> runs only on new DRI. Pain).

to quote ajax: http://people.freedesktop.org/~ajax/fennec-fox.jpg

or this isn't about choice. or no.

If you can clarify exactly what you mean by DRI clients (i.e. mesa itself 
or GL apps on top of Mesa), old X server (i.e. what we have now.. or 
modesetting or TTM etc..), we might be able to find a point of usefulness, 
like we can run old X servers on cards that don't support this stuff hence 
the legacy node will always be there..

> 
> Also, it seems like we can support legacy fbdev clients by creating
> suitable controls that create and modify fbdev devices, and potentially
> even have the system create a default fbdev device at boot time to stick
> the console in.
> 

fbdev will probably look like it does now in the modesetting tree mainly, 
hopefully someone does a userspace console at some point... but fbdev 
would have a BO for its front buffer and one per set of outputs would 
exist, so the control node splitting out crtcs and outputs would give you 
an fbdev per crtc.. otherwise cloned fbdev..

Dave.