On Thu, Mar 06, 2003 at 10:34:44PM -0500, David Dawes wrote: > >> 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.
Well sure, ... I think the important part here is that what we are handling is separating the viewports input size (the actual pixels in the framebuffer) from the viewports output size (the video mode). Scaling can be done automatically once you have these two informations. > >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. I need to look into RandR, i believe it could easily be extended to RRandS (for Scaling). > 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). Yes, ... I believe that we already have all the needed info to do scaling, we only need to extend the viewport parameters so they also consider the viewports input size. I really don't see how you will specify this otherwise, ... mmm, maybe i see, ... > > 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). Do you mean that you have plans for using the "[EMAIL PROTECTED]" mode in the display section to set the viewport input size (800x600) and then define that mode to something larger in the monitor's modeline section ? The multimonitor thingy can easily be emulated by using a "Shared" option to the devices, and using a virtual size being enough for both heads. > 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. Mmm, yes, for 4.4.0, 5.0 could well warrant a rewrite or at least a rethinking of the configuration file anyway, right ? So we can have a framebuffer section and multiple viewports looking into them. > 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. I don't really agree here, modes are for the outgoing resolution, not the input viewport. it would be far simpler to keep this simple acceptation, and add a new keyword for defining the input viewport. Reusing the viewport keyword is one way, adding a new resolution keyword is another. After all this would be a transparent modification from what we have now, and will just give additional info that helps calculate the scalling factor and set the source of the viewport. I believe this is nothing new, and older chips already had this kind of view, altough you could not do much scaling (unless pixel doubling counts), you still had to program the outgoing mode and the framebuffer parameters separatedly. > >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. You are speaking viewport source size here or outgoing mode ? My first intention was that we don't, the user can specify an outgoing mode (or the monitor can tell what he supports), and a viewport input size. The driver then checks (in validatemode) if it can support this scaling, either choosing to reject it or to fall back to the next bigger supported input viewport and blank the margins or whatever. Then, there is no need to specify a range in the configuration file, the driver would handle that, more dynamic things could be done by expanding RandR to support scaling (and dynamic multi-head configurations). Now, if you want smooth zooming (going from one resolution to the another), then clearly, you don't haveto modify the outgoing mode, just the input viewport. And again, the driver is best placed to know about this, and anyway you would not handle this in the configuration file but in some dynamic change (or in RandR(andS)). But then, maybe i did not understand you well ? Friendly, Sven Luther _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
