ATI Drivers report bogus dot_clock to xvidtune

[Egbert Eich]

Alex Deucher writes:
 > On 3/29/06, Egbert Eich <eich at suse.de> wrote:
 > > Alex Deucher writes:
 > >  >
 > >  > How would you propose we handle having 2 heads with different timings
 > >  > be handled by one screen in a reasonable fashion?  Unfortunately,
 > >  > mergedfb is a hack.  The X driver infrastructure was not built to
 > >  > handle multiple crtcs with one instance of the driver.  If you have
 > >  > one head at 1024x768 at 60 and the other at 1280x1024 at 85 what should we
 > >  > set the "meta" clock to?  Also we want to allow you to have another
 > >  > metamode of 1024x768 at 60 and 1280x1024 at 75 and not have the mode parser
 > >  > throw it out. Then throw in crtc orientations (left, right, clone).
 > >  >
 > >
 > > Do you mean the mode validator? I haven't investigated why it doesn't
 > > throw out modes with the clock values that the radeon driver supplies.
 > >
 > 
 > yeah, that's what I meant.  Sorry.
 > 
 > > I'm aware that a clock value for a meta mode is pretty meaningless.
 > > However one could try to pick sane clocks (ie. such that they are in
 > > a range so that the refresh values are in a range the user expects).
 > >
 > 
 > I should look into a better approach.

I was briefly doing this too just the other day.
I had to give up as I was given more urgent tasks :-/

 > 
 > > Yes, it is true that the X driver infrastructure is particularly broken
 > > when it comes to multiple heads per driver. All this was designed for was
 > > to get the G400 going.
 > 
 > any ideas? ;)  Is it worth fixing the driver infrastructure or should

Yeah, I do. I've been thinking about this on and off - especially
whenever I stumble over the poor multi screen design that we currently
have. 

 > we just wait and do it right with egl or some such?  Perhaps we can
 > base the drivers on Entities rather than Screens, then store a list of
 > associated screen pointers with each driver instance.
 > 

The biggest problem is that the DIX notion of a screen is exposed thru
the DDX all the way down to the drivers. What's more each piece of silicon
is attached to one screen (everything else is a klude).

We really have 3 entities: drivers, DDX-screens (or framebuffers) and 
heads (or viewports). (note that DDX-screens are not the same as the
DIX notion of screens - I'm unable to think of a better term right now).

These are the three degrees of freedom you have. You can have n DDX-screens
per driver and m heads. Obviously you can attach 0..m heads per DDX screen.
In my opinion these three need to be represented in separate structures.

There is one driver structure per logical hardware entity. Initializing
the driver means generating this structure including the initial probing
of the heads (what is connected where;  what are the constraints). 
The probing code should be entirely separate from the driver init code,
though to allow for hotplug.
Mode initialization takes place on top of this at any time of the driver
livetime.

DDX-Screens are really just areas in the framebuffer. Setting them up is
a task of the memory manager and of the accel layer (as this may have
some constraints).

Somewhere in the upper layers of DDX we map the DDX-screens to 
DIX-screens. (This way we may be able to do away with a lot of
the ugly Xinerama kludes). 

I assume that most of this will still be relevant regardless of
what GL solution we finally adopt. The driver layer does not have 
to be a part of the Xserver at all any more.
Thus I think it is still worthwhile to explore this area.
 
The only required link between the Xserver and the drivers would
be the DDX-screen. 
Information about the heads can optionally be exposed to X 
- if we want to support viewport changes thru cursor movements 
  (panning)
- or want to be able to provide Xapps information about the desktop
  geometry of the user 
- or we want to experiment with configuration interfaces that are 
  routed thru the X protocol. 

This is of course just the zeroeth approximation - there are definitely
things I have missed and were to hook up the hardware cursor or 2D
accel (I assume we still need those two for a while) has not been
addressed at all, yet.

Cheers,
	Egbert.