alexdeucher at gmail.com
Mon Feb 21 13:11:50 PST 2005
On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Mon, 2005-02-21 at 14:08 -0500, Jon Smirl wrote:
> > On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt
> > <benh at kernel.crashing.org> wrote:
> > > That leads to one missing piece to ultimately merge the fb layer
> > > (mode setting) and the kernel DRM (command processing), which is a video
> > > memory manager that is independant from the client (X server).
> > Now you know why I have been making all those posts about merging
> > DRM/fbdev for the last year while everyone was calling me crazy.
> > mesa-solo has to join DRM/fbdev together to get the foundation that it
> > needs.
> Heh, well, I at least knew it all along ;)
> > Another part of the goal is that the XGL server does not need to run
> > as root. I've recently posted code to fb-devel list that allows modes
> > to be set without being root. I'm also trying to sort out reseting of
> > secondary cards using fbdev. Other areas that need work is hardware
> > cursor and fixing radeonfb to support two heads and merged fb.
> For non-root, that is fine as long as there is some console ownership
> management, and proper arbitration with engine users when a mode switch
> is triggered. But we already discussed all of this a while ago ;) I'm
> sorry I didn't have time at all on my side to work on those things.
> Hardware support, radeonfb multihead, etc... is all trivial to do once
> we have proper infrastructure. fbdev need a bit of overhaul in it's
> current state (at least proper mecanism for picking where to allocate
> the second head and ways for userland to know which framebuffers are
> "tied" together).
If we are going to start "fresh" so to speak, why even mess with
mergedfb in the new fb/drm driver? it would make more sense to just
update the 2d and 3d engine offsets to point to whichever framebuffer
is "active." for dualhead the offset would just be updated along with
the other 3d state just like with multiple 3d apps. We could also use
separate tiled surfaces for each frambuffer so we wouldn't be limited
to 2kx2k. Then we wouldn't have any of the limitations of mergedfb.
More information about the xorg