On Mon, Mar 03, 2003 at 10:31:56AM +0100, Sven Luther wrote: >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.
Yep. > 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. 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. 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. >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 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. >> 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 ? 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). >> 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 David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
