On Fri, Mar 07, 2003 at 12:31:18PM +0000, Dr Andrew C Aitchison wrote:
> On Fri, 7 Mar 2003, Sven Luther wrote:
>
> > 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.
>
> Have you looked at the "Stretch" option on say the NeoMagic driver ?
> I have a 1024x768 laptop display, and by default (ie unless I use
> option "noStretch") all modes are stretched to fill the screen.
> Thus the modes (and modelines) describe the viewport size, not the
> output resolution.
Interesting, i suppose the scaling is also done in the driver then, i will
have a look at how it works when i get some free time.
I wonder how the driver knows what the laptop display size is ? do you
specify or does the monitor tell the driver about it with ddc ?
> So I don't agree with your description of what the words currently mean.
> Using "viewport" to describe the visible pixels of the
> framebuffer and "modes" to describe the pixels of the monitor would be
> logical and consistent, but it does mean a change from the way "modes"
> is considered now.
Well, if you consider that the size given for the modes and the size of
the framebuffer are mostly exactly the same, you can hardly argue that
using modes for the framebuffer size is what most people think of when
they hear of modes.
Also, you have to consider how things work out from the driver
internals.
There is the DisplayModePtr mode, which as its name says is for the
outgoing mode, and has all the monitor timings. On the other hand, the
viewport source position and size is given by pScrn->frame{XY}{01},
which i suppose are calculated from the viewport (usually 0,0) and the
size of the current mode. Other framebuffer info include the
displaywidth (given by the virtual size, i guess) and the pixel depth.
So, we can do it in two ways :
1) As i said, we simply add the size to the viewport keywords, which
would be used to generate pScrn->frame{XY}{01}. No further driver
changes are needed, apart from setting the appropriate scaling factor,
or reject scaled modes if scalling is not allowed.
2) We do it the other way, we use the mode info to mean the viewport
source size. There is no way to set the real outgoing mode, so you can
only hope that the monitor provides you the real data (unless you add
a supported resolutions option to the monitor entry). And even such,
you have to calculate the new outgoing mode, and there is no practical
way for the user to specify the exact timing of the outgoing mode. No,
there is, i suppose you would be able to use a "Supported" line in the
monitor section and have there the lists of supported modes.
Both solution have advantages and disadvantages, i personnally think
that 1) is better, especially if you want to do more advanced stuff
later on, like zooming on windows (you would just call adjustframe each
time the window is moved) or such, it is also the one that needs least
overall changes.
Friendly,
Sven Luther
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
