On Thu, Mar 06, 2003 at 07:01:35PM +0100, Sven Luther wrote: >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.
It doesn't matter what extra information is there. It only matters that you have enough, and that the user doesn't need to specify more than is needed. In 99% of cases the user only specifies mode names these days (in an <xres>x<yres> format), not all the parameters. >> 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 Only because that's how viewports are typically implemented with CRT devices. I don't see a good reason to treat things differently depending on whether the viewport is implemented with CRT modes or a scaler in the video chip. >framebuffer size. What does the refresh have in common with the >framebuffer size ? It can evidently not be used to refer to the outgoing Nothing, so ignore it. Supplying it would be optional anyway. >mode, which will have different timing parameters than what your ><xres>x<yres>@<refresh> suggest. It seems that it has fixed timing parameters, so there's really no reason for the user to need to know about them. If the outgoing mode's refresh rate is usefully variable, then the refresh parameter becomes useful again. Use the parameters that are useful, and ignore the others. As I've said, you only care that you have enough parameters for what you need, and that the user doesn't need to supply more parameters than you need. There are existing cases where only a subset of the available timing parameters are used. The driver for the Intel 830M and later uses the video BIOS to set the video modes, and the mode programmed is based solely on the X, Y and refresh values, and not on the detailed timing parameters. The vesa driver (for VBE < 3) uses only the X and Y parameters. Note also that the RandR extension deals with these three parameters also, with refresh being optional. And it's more concerned with root window size/orientation than outgoing mode details. >> >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. This is already in the Screen/Display Section. The formatting of this section can be improved without changing the underlying data (multi-monitor changes aside). > 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. This is already in the Monitor section (implicitly for builtin modes, and will be for DDC modes when they're implemented). With some minor extensions to the Screen/Display section format, and how mode names are interpreted, I think it's possible to achieve this without any significant structural changes. Maybe it's easier to pretend that "Modes" have some other name now, that the only essential two parameters of "Modes" are the X and Y resolutions, and that the interpretation of any optional additional parameters may be monitor-specific. Just because "Modes" have traditionally been closely associated with the outgoing modes doesn't mean that we need to rigidly keep that association in the face of hardware that wasn't envisioned when they were originally defined. >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. How to you say that you want to allow all viewport sizes between 640x480 and 1024x768 (i.e., any viewports XxY with X in [640,1024] and Y in [480,768]). Maybe the answer is that you don't, and that the driver determines what range the scaler can support. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
