Re: [Dri-devel] Re: MergedFB option for radeon driver

[Andy R. <AR...@nv...>]

On Wed, 14 May 2003, David Dawes wrote:

> On Wed, May 14, 2003 at 03:38:28PM +0200, Sven Luther wrote:
> >On Wed, May 14, 2003 at 08:23:48AM -0700, Alex Deucher wrote:
> >> 
> >> --- Sven Luther <sve...@wa...> wrote:
> >> > > 
> >> > > I have a feeling Clone and MergedFB could share even more code,
> >> > e.g. I
> >> > > don't see why they would need different mode validation functions
> >> > etc.
> >> > 
> >> > Even worse, many of the stuff in the radeon driver would warrant to
> >> > be
> >> > separated and moved to a higher level, in order to be also re-usable
> >> > by
> >> > other drivers. I think of all the DDC and stretched mode logic for
> >> > example. But MergedFB is also a candidate for this.
> >> > 
> >> > I am sure i will end duplicating even more of it that i did just now,
> >> > and many other driver seem to have similar code.
> >> 
> >> 
> >> I agree.  almost all of the MergedFB helper functions are generic. 
> >> However if we move to add generic interfaces for all of this we may
> >> want to think about re-structuring the XF86Config file so that all of
> >> these features do not have to be driver options, or maybe they are best
> >> as Driver options.  I dunno.
> >
> >They are best as driver options for now, re-structuring is 5.0 stuff.
> 
> It looks like it can be done by making some small extensions to the
> config file rather than changing it.  I think that the infrastucture
> code can be similarly extended too.
> 
> Something like these simple examples:
> 
>     Section "Screen"
>         Identifier "Screen 1"
>         Device "Device 1"
>         Monitor 0 "My Monitor 1"
>         Monitor 1 "My Monitor 2" RightOf 0
> 
>         SubSection "Display"
>            Depth 16
>            Modes 0 "1024x768"
>            Modes 1 "1024x768"
>            Virtual 2048 768
>         EndSubSection
>     EndSection
> 
> Clone mode would be like this:
> 
>     Section "Screen"
>         Identifier "Screen 1"
>         Device "Device 1"
>         Monitor 0 "My Monitor" 0 0  # Absolute position
>         Monitor 1 "My Monitor" 0 0  # Absolute position
> 
>         SubSection "Display"
>            Depth 16
>            Modes 0 "1024x768"
>            Modes 1 "1024x768"
>            Virtual 1024 768
>         EndSubSection
>     EndSection

What happens on a modeswitch?  Would the driver just be expected
to switch to the next mode for each monitor?

I've found the MetaMode syntax (which binds a mode from each monitor
together) that the NVIDIA driver uses offers a lot of flexibility
(for one thing: it allows the positioning of the monitors to be
handled on a per MetaMode-basis, where the above syntax would fix
the location of the monitor for the life of the X server).

If you're interested, you can check out the description of MetaModes
in the text README available here:

	ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4363/README.txt

See (app-i) APPENDIX I: CONFIGURING TWINVIEW

It would be nice to be able to include multiple Monitor sections
in the Screen section like in your example above.

> The (initial) monitor layout would be handled like the screen layouts in
> the ServerLayout section, as you can see from the similarity in syntax.
> 
> >> Another thing I was thinking about... I was looking at Thomas' sis and
> >> thinking about Xv attributes.  You can change visual settings of the
> >> overlay and even what head it displays on in the sis driver by
> >> adjusting the attributes.  So why not create Screen or entitiy
> >> attributes for the 2D driver.  that you allow change things on the fly
> >> instead of having to restart the X server.  You could make clone and
> >> mergedFB options, modes, framebuffer sizes, bit depth (although that
> >> might be an issue with some old toolkits), re-run DDC if you connect a
> >> new monitor, change OpenGL attributes, tv-out, etc.  Obviously this is
> >> something for 5.0.
> >
> >Personally i think this would be done in the same way randr
> >configuration is done now, and anyway, this is the same kind of
> >functionality as what randr is doing.
> 
> randr is supposed to handle the root window resizing and rotating.  That
> still leaves a lot of other parameters to configure/adjust.  The vidmode
> extension is probably a natural place for some of it, or maybe a new
> configuration extension (for 5.0).

One of the problems with randr, if I understand it correctly,
is that it fixes the list of possible root window sizes upfront.
Ideally, you'd like to be able to arbitrarily grow your root window
if you plugged in a second monitor (assuming X drivers were given
a chance to validate that there's enough video memory for the new
root window size, etc).  Hopefully in the 5.0 timeframe randr can be
extended to allow clients to add (and validate) new XRRScreenSizes.

- Andy


> David
> -- 
> David Dawes
> Founder/committer/developer                     The XFree86 Project
> www.XFree86.org/~dawes
> _______________________________________________
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>