On Mon, Mar 03, 2003 at 09:46:40PM -0500, David Dawes wrote:
> > 2) a way to tell the framebuffer/viewport sizes for each supported
> > resolution, something like :
> >
> > SubSection "Display"
> > Mode "1024x768"
> > Viewport 0 0 1024 768
> > Viewport 0 0 800 600
> > Viewport 0 0 640 480
> > EndSubSection
> >
> >or maybe
> >
> > SubSection "Display"
> > Framebuffer 1024 768
> > Modes "1024x768" "800x600" "640x480"
> > EndSubSection
Erm, this is the other way around, the Modes give the Framebuffer size,
and not the other way around, so, this one woudln't work.
> >Which would tell the driver that we only support outgoing resolution of
> >1024x768, but that framebuffer resolution of 1024x768, 800x600, and
> >640x480 are ok, and that we should scale from them to the 1024x768 one.
> >Maybe the syntax is not the best, but you get the idea.
>
> Actually, I don't understand what you're trying to do that can't be done
> already. The user shouldn't care that the panel is 1024x768 (other than
> that it's the max available mode resolution). The driver should figure
> that out and take care of scaling the user's "800x600" mode request to
> the physical output size of 1024x768. As a user, when I specify 800x600,
> I just want the physical screen to display an 800x600 pixel area on the
> full screen. I don't care of it's an 800x600 physical output mode or
> if the 800x600 is scaled to some other physical output resolution.
Yes, but we need to change the way we calculate output mode, and use the
fixed resolution, autodetected or with a monitor option like you propose
below.
> The only new feature I see is that arbitrary scaling allows a potentially
> much finer set of "mode" sizes than we're currently used to, and this
> would be very useful for allowing real-time zooming and tracking windows
> (including resizes). That can be done with most modern CRTs too (with
> some horizontal granularity limits), but I imagine that zooming would
> be more seemless with the scaler method though than implementing it with
> CRT resolution changes.
Yes.
> >I could do this by using an outgoing resolution size in the device specific
> >section, but this would not work best, since all the logic doing the
> >mode setting now is done for the resolution in the display setting.
>
> Can the driver query the panel's size? If it can't, then it needs to
> be supplied somewhere. It could be a new Option in the Monitor section
> that the driver checks for. It would be best if the driver can auto-detect
> it though.
I guess it can, DDC should be able to provide that, but i haven't got to
there, and anyway, some monitor may have broken DDC, so better think of
a Option for it, in the monitor section would be the best place for it.
> >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
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.
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.
> >> Some of the users of your driver probably will, so it's worth testing
> >> with it.
> >
> >Sure, but, err, its proprietary software i have no access too, right ?
>
> It never hurts to ask for a copy as a driver developer. The worst they
> can say is "no". I find vmware very useful personally as well as for
> XFree86-related stuff (especially multi-platform build testing).
Ok, Will be asking them.
Friendly,
Sven Luther
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
