[Xorg-driver-geode] looking at wide mode support for GeodeLX (continued)

[Jordan Crouse]

On 08/02/08 12:05 -0500, Bart Trojanowski wrote:
> So I returned to looking into the missing modes on the GeodeLX.  This
> work is funded by symbio-technologies.com -- thanks.
> 
> At this time I don't have a patch because my code is still a mess with
> debug code, but it's eminent.  The changes will be restricted to the
> amd_lx_driver.c file in the -amd driver.
> 
> In order to get wide modes two things need to happen:
> 
> 1) LXValidMode() currently calls vg_get_display_mode_index() to find a
>     mode that X wants validated a CimarronDisplayModes[] table kept in
>     src/cim/cim_modes.c.  The problem here is that this table contains
>     nothing a wide LCD monitor would display natively.
> 
>     I fixed this by cutting out the check; that is removed the call to
>     vg_get_display_mode_index() and just return MODE_OK if it's non-PANEL
>     output.  I'll still call vg_get_display_mode_index(), but only report
>     if the check fails... and continue on.
> 
>     I have no idea what implications using non-Cimarron modes has.  I
>     don't even know what Cimarron modes are :) ... so I would like for
>     someone (Jordan, Martin-Eric) to comment before I make CRTs explode.

The problem is this - for the VESA modes that Cimarron knows about,
Cimarron will have optimized timings that work well with the Geode 
clock, which are better then the timings that are hard coded in X.

The problem here is with the timings that are not hard coded anywhere,
such as the DDC timings and user specified timings.  We blindly accept
the latter, but we have no good way to tell if the timing is from DDC
or not.  

The other problem with avoiding the check is making sure that 
simultaneous panel/CRT modes are correct.  The user can check this
themselves, but it is more user friendly if the code does it for them.
So if we do remove the timing check for CRT modes, we should still go
down that path for PANEL modes.

The implications of skipping the timing check all together are that in
the absense of DDC and user defined modes, the hard coded modes that 
X will ask us to use may not be 100% completely optimized for the
Geode.  That is of course, assuming that X will give us a completely 
qualified set of timings for arbitrary VESA modes, which I'm not 100%
sure is true.  To test, turn off DDC completely, get rid of user defined
modes, and then try to set a nominal mode in xorg.conf (say 1024x768).
If it works without going through Cimarron, then we can probably consider
removing the Cimarron mode check.  That said, I would far prefer
if we could figure out a way to tag the DDC modes with a flag, since
that would give us the best of all possible worlds.  Are we sure that
there isn't a USERDEF equivalent for DDC?  What is pMode->type for
a mode from DDC?

> 2) LXSetVideoMode() is called to switch to a new mode (either the
>     initial one, or later with xrandr or Ctrl-Alt-+/-).
> 
>     If the mode is specified from xorg.conf we get a flag indicating
>     that this is a M_T_USERDEF mode and call lx_set_custom_mode() and
>     everything works fine (almost, see below).
> 
>     If the mode is detected by X, then vg_set_display_mode() is called.
>     This code path checks for a valid mode in the CimarronDisplayModes[]
>     table and just fails.
> 
>     It so happens that while vg_set_display_mode() returns an error, we
>     never checked for it.  I have added this code:
> 
>         rc = vg_set_display_mode( ... );
>         if (rc)
>                 lx_set_custom_mode( ... );
>                 // I plan to report if this call fails :)
> 
>     and I can get X to display any mode upto 1600x1200.  It even thinks
>     that it can do 1920x1200.

Well - this is academic if we either get rid of the cimarron mode or figure
out a way to flag DDC modes.

> It's *almost* perfect...
> 
> The native mode on my new monitor is 1920x1200, which the DDC reports
> and the LX happily provides.  The screen is rendered, and at first I
> thought it was working.  However it seems that the display is actually
> rendering at 1600x1200, while the buffer is 1920x1200.  
> 
> If X was aware of this, it would pan when I moved the mouse to the edge,
> but the cursor just goes off screen.  Even xrandr reports that it's set
> to 1920x1200, and doesn't even list 1600x1200 as an alternative (BTW, I
> can have it display 1600x1200 if I set such a "Modes" line in xorg.conf).
> 
> I think it's the Geode that's doing this reduction.  Thoughts?

Possibly, though X can do things like that and not tell you.

You'll have to check in LXSetVideoMode to see what the active X and active Y
size is.  If we're setting whatever pMode-> tells us too, then its X,but
if pMode is asking for 1920x1200 and we're ignoring it, then thats our bad.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.