On Sun, Mar 02, 2003 at 11:28:24PM -0500, David Dawes wrote:
> On Sat, Mar 01, 2003 at 10:34:20AM +0100, Sven Luther wrote:
> >On Fri, Feb 28, 2003 at 04:19:37PM -0500, David Dawes wrote:
> >> >Are you speaking about the current 4.3.0 or the stuff you are working on ?
> >>
> >> What I was working on.
> >
> >Ok, ...
> >
> >I take it, there will be a 4.4.0 before 5.0 ?
>
> Most likely.
:))
> >> of scaling are either handled by a hardware scaler (that may or may not
> >> be visible to the XFree86 server and user), or by having something in
> >> XFree86 that keeps a second copy of the image that is scaled in software.
> >
> >Mmm, you are speaking of a hardware scaller in the LCD monitor ?
>
> I'm talking about a scaler anywhere between where the resolution is
> programmed and the physical display. For laptop-type displays it's easy
> -- it's in the video hardware. For digital connections to LCD displays
> I'm not sure which side of the DVI connector it's normally located. I
> just know that I've seen it work in that case without needing to do
> anything special as a user or as a driver writer. I don't know whether
> the cases I've seen are common or unusual. I haven't played with enough
> of these HW combinations to know.
Mmm, it may be something special in the bios of those laptops, or even
some hardwired functionality, but in my case i need to program it by
hand, and i guess other chips will need this too, so we may as well
think of it.
> >Well, from my experience (i have a Sony SDM-X52, with both a DVI
> >connector and a standard VGA connector) this doesn't seem to happen. If
> >i request a mode lower than what the LCD can display, i get only
> >garbage, at least on the DVI channel. I believe the VGA channel can do
> >more advanced things, but didn't sucessfully use them. On the other
> >hand, my graphic hardware can do arbitrary scaling of the framebuffer
> >before passing it to the monitor, but i have to program it explicitly. I
> >guess that this is used by the bios at startup to convert the 640x480
> >text mode to something my monitor supports, since the fonts appear a bit
> >blurry.
>
> It sounds like that in current cases the driver should handle this type
> of scaling transparently. The only extension that might be relevant is
> to allow the viewport to be set to a range of sizes rather than discrete
> mode sizes (as happens now).
Well, i have to calculate the scaling factor from the source
(framebuffer) width/height and the destination (mode resolution)
width/height, that is why i ask for a more granular handling of this.
Currently, you can do :
Section "Screen"
...
SubSection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 15
Modes "1024x768" "800x600" "640x480"
EndSubSection
...
EndSection
(Well, actually, i have only 1024x768, since that is what the monitor
supports.)
What would be nice, would be if :
1) you could have only one line for all the depth/bpp, or a possibility
to have multiple depth/bpp per display section.
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
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.
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.
I strongly advocate that you take in account such separation of the
outgoing resolution and the framebuffer size in any future configuration
scheme.
> Right. I've only seen downscaling, and it's possible that I'm wrong
> about it it happening in the monitor rather than in the video hardware.
I think it is happening in the video hardware, at least for DVI
connections.
> >BTW, do you know any doc on DVI and LCD monitors ? my monitor refuse to
> >go to sleep when i am using the DVI channel, while it works fine with
> >the VGA channel.
>
> I haven't seen any docs on those. If there are related VESA specs, I
> should have them somewhere.
Mmm, i will be also looking.
> >That said, another thing that would be nice, would be the possibility to
> >specify one display section for every depth, instead of just copying it
> >for each supported depth. Do many people in these times of 64+Mo of
> >onboard memory specify different resolutions for different depths ?
>
> I think it'd be useful to be able to specify paramters that apply to
> all depths, but still allow a depth-specific subsection to override.
> That'd be a useful extension of the current Display section format.
Yes, ...
> I still find the depth-specific parameters useful when testing, and
> there are still a lot of HW configs that have more modest amounts
> of video memory. But, this is probably the less common case these
> days.
The per depth parameters should be kept, no doubt about that. I would go
for a display section without dept info being common, and which can then
be overriden for specific depth.
> >> I haven't seen that happen, but if the VidMode extension is working
> >> correctly, it should be possible for an application to specify new video
> >> modes. They're supposed to be validated though, and the driver gets
> >> the opportunity to reject them. I haven't looked at SDL's internals in
> >> a long time, so I don't really know what it does now.
> >
> >Well, my driver is only half written, but the vesa driver also don't
> >works correctly here.
>
> You really need to trace was SDL is doing and find where the problem is.
Yes, will do that once i get time.
> >> BTW, there are cases where vmware will do VBE calls of its own to provide
> >> good full-screen operation, and doesn't necessarily rely on modes provided
> >> in the config file. But that's a different story...
> >
> >I don't use wmware anyway, so ...
>
> 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 ?
> Anyway, just pointing out at least two cases where seeing modes not
> specified in the config file is not broken behaviour.
I am not sure i agree to that. If i specify that i want my monitor in
one specific mode, and something changes it to show only garbage, then
something is broken (the app i guess), but then i guess you can also
configure it in wmware so that they don't try unreasonable depths.
Friendly,
Sven Luther
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
