[PATCH] make xf86SetDesiredModes a bit more driver friendly

Jesse Barnes jbarnes at virtuousgeek.org
Wed Mar 12 11:29:14 PDT 2008


On Tuesday, March 11, 2008 7:20 am Alex Deucher wrote:
> On Mon, Mar 10, 2008 at 7:14 PM, Jesse Barnes <jbarnes at virtuousgeek.org> 
wrote:
> > Here's an updated intel half of the patchset.  This one takes advantage
> > of the earlier server patch to provide 0 flicker LVDS mode setting.
> >
> >  I'm not totally happy with it however, and I'm looking for suggestions
> > on the following points:
> >   - getting crtc mapping & output status
> >     Right now this is done in each output setup routine, which creates a
> > lot of duplication.  Maybe we should have a output function pointer
> > callback ->get_crtc() and move all that stuff into the server (output
> > status can already be done this way)?
>
> In radeon we just iterate through the outputs after we create them
> from the bios connector table and call detect.  We do this even
> through the server already does it to make some decisions about output
> fallbacks and such depending on what's connected.  How about a
> set_crtc() callback instead.  then the driver can force the crtc to
> avoid letting the server pick and it might also be useful on cards
> where, for example, crtc0 has to be active to use crtc1, etc.  this
> would also allow the driver to re-arrange crtcs if something changes
> that it would know how to handle best.

Right now if you set the output->crtc value in the driver I think the server 
will honor it?

> >  But ultimately, this is what needs to be dealt with.  If
> > xf86SetDesiredModes got the current configuration from each output &
> > crtc, we wouldn't need to turn everything off to get a known state (I
> > think).  Which means the above removals of RestoreHWState wouldn't be
> > necessary (aside from cleanliness).
> >
> >  Any ideas?  What works for radeon & nv?
>
> For radeon we call have general save/restore functions.  We save the
> console state at startup and then restore it in LeaveVT.  For EnterVT
> we just call xf86SetDesiredModes().

Yeah, we do the same.  What I'm worried about is what happens between LeaveVT 
& EnterVT.  If the configuration changes (maybe due to output switching or 
something when we're in text mode), xf86SetDesiredModes may have the wrong 
crtc<->output mappings or crtc & output enable bits.  So xf86SetDesiredModes 
should really be calling back into the drivers to get output & crtc status 
before it does its thing.  The server side of this patch removes the "get the 
hardware into a known state by DPMS offing everything", but we'll still need 
something like that, preferably without any flashing.

An output specific get_crtc callback should be enough for that specific 
problem...  But I have no problem with adding a set_crtc too if you think 
that would help.

Jesse



More information about the xorg mailing list