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. 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. But rather than speculating too much, it would be useful to do some research into current and developing standards/technology in this area. >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. 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>). 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. >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. 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. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
