On Thu, Mar 06, 2003 at 12:27:41PM -0500, David Dawes wrote:
> On Tue, Mar 04, 2003 at 10:41:50AM +0100, Sven Luther wrote:
>
> >> >I strongly advocate that you take in account such separation of the
> >> >outgoing resolution and the framebuffer size in any future configuration
> >> >scheme.
> >>
> >> We already have the "Virtual" size, which is the framebuffer size, and
> >> allows it to be separated from the viewport (mode) sizes. I don't think
> >> the outgoing resolution belongs in the Screen/Display sections. It
> >> should be between the Monitor data and the driver, with the driver using
> >> this information to determine the maximum viewport (mode) size allowable.
> >
> >Yes, but consider how the current display section works.
> >
> >You use the mode to specify outgoing resolution, but apart from the
>
> That's one way to look at it. Another way to look at it is that you
> use the mode to specify the viewport size and you don't really care
> about how that gets implemented. In the CRT case, both the viewport
> and outgoing resolution happen to be the same, so there is currently no
> distinction between these two. I think that the latter interpretation
> more closely matches what the user would expect when moving from a CRT
> display to an LCD display, and that's how things appear to be handled
> with most video BIOS and Windows drivers at present.
But the mode contains more information than what is needed (the exact
timings), which will not be used. And this may be confusing.
> It's imaginable that there might be displays that one day support multiple
> outgoing resolutions as well as using a scaler. It's also imaginable
> that displays will get "smarter", and automatically take care of whatever
> resolution data the video card sends to it (as most CRT screens do
> today). I'd suspect the latter given how things have developed in the
> past.
I don't know, i have the impression that this technology will more
probably be part of the video card, and not the monitor, but that may be
only me. I believe that the video card used in laptops also do the
scaling if needed, from a comment i read on the linux-fbdev mailing list
it seems that the fbdevs also do the scaling part themselves.
> But rather than speculating too much, it would be useful to do some
> research into current and developing standards/technology in this area.
That would be usefull, yes.
> >builtin mode, there is no guarantee that the string used for the modes
> >even correspond to said resolution, the user are used to this, but if we
> >are going to do scaling, it really don't make sense to use "800x600" as
> >mode, when what you really want to say is that you want a resolution of
> >800x600.
>
> The parameters of the mode determine the resolution, not the name.
Exactly, and the mode has much more info than what is needed for setting
a viewport.
> However, a useful extension would be to place a special interpretation
> on mode names that fit a regular format (e.g., <xres>x<yres>@<refresh>).
Yes, and these are what the monitors tell the card trough ddc anyway.
> For CRT output, the VESA GTF can be used to construct matching timings.
> For DVI output, the driver uses the resolution parameters to calculate
> the scaling.
You see, again, you are speaking in video modes, but we want a
framebuffer size. What does the refresh have in common with the
framebuffer size ? It can evidently not be used to refer to the outgoing
mode, which will have different timing parameters than what your
<xres>x<yres>@<refresh> suggest.
> >Also, if you still want to use a virtual screen bigger than the actual
> >one, you still would need to specify the viewport.
> >
> > SubSection "Display"
> > Virtual 1600 1200
> > Mode "1024x768" (outgoing mode).
> > Resolution 1280 1024
> > Resolution 1024 768
> > Resolution 800 600
> > Resolution 640 480
> > EndSubSection
> >
> >This way, we would have a 1600x1200 virtual screen, an outgoing
> >resolution of "1024x768", which could be specified in the monitor
> >section, and resolutions of 640x480 upto 1280x1024.
> >
> >Sure, you could also use the modes, but you would give to much info,
> >after all you would only need the size of the mode, and not the rest of
> >it.
>
> For built-in modes, you only need to give the size now. With an extended
> interpretation for mode names as I suggested above, that would be the case
> for any mode size.
For the outgoing monitor timings, yes i agree.
I don't know, i still think that it would be best if we could separate
the information as follows :
1) Information on the Framebuffer : virtual size and viewport size and
position. If we have a shared framebuffer, then the virtual size is
common to each head. Depth and Bpp information also goes here.
2) Information on the outgoing modes. This is taken from a list of
builtin modes, or better yet from the data that the monitor sends
back trough the DDC channel.
And further, we would separate the information on the chips (the device
section) and the screens, as in modern chips, a part of the
configuration for both heads is common (like a shared framebuffer
setting, but also other information, like the chip being able to use
parts of one head for the other and other common configuration). This
would also have an influence on the configuration file.
> I think that a more important thing would be handling the specification
> of a range of mode/viewport sizes so that smoother zooming could be
> implemented.
I am not sure i follow you here.
Friendly,
Sven Luther
>
> David
> --
> David Dawes
> Release Engineer/Architect The XFree86 Project
> www.XFree86.org/~dawes
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
