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. >> >Well, i am not sure i follow you completely here, but my interrest in >> >scaling is : >> > >> > o having one monitor display the same framebuffer area as the other, >> > but in another resolution. Like when your laptop's LCD screen can only >> > display 1024x768 but you have to do a presentation on a 800x600 video >> > projector. You sent the framebuffer to be 800x600 to have maximum >> > quality on the video projector, and scale it to 1024x768 on the >> > mirrored display of your LCD screen. >> > >> > o displaying lower video modes than what the LCD screen can display >> > (or bigger modes also). >> >> The type of "scaling" that comes for free is when your LCD displays >> 1024x768 and the video projector displays 800x600, but that 800x600 is >> just a 800x600 pixel subset of the full 1024x768 desktop. Other forms > >That is not scaling, you juts open a plain second viewport on the same >framebuffer. > >> 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. >I am speaking about hardware scaller in the video chip, and altough not >all video chips have those, i guess some have and more will have. Or >else you could just re-use the video overlay unit for it or whatever. > >> A lot of chipsets that drive LCD displays do transparent scaling where >> the user and XFree86 server see a "800x600" mode, and the graphic hardware >> scales that to the 1024x768 physical LCD screen. > >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). >> >These would be static scalings, and could be set by specifying for the >> >viewport, not only the x/y corner like it is done right now, but also >> >the source height and width, the scaling would then be set to the ratio >> >between the height/width of the destination over the source. >> > >> >Keep in mind LCD monitors can only do fixed resolution mostly and will >> >become more and more predominant. >> >> Most of the current LCD monitors that I've seen can do built-in scaling >> so that they can display non-native resolutions transparently to the user. > >Mmm, maybe my monitor can, but the documentation i have doesn't speak >about it, and anyway, it has quite limited frequency ranges. Also, this >precludes doing more advanced stuff like i say below, orupscaling >instead of downscaling. 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. >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. >> >Then there is dynamic viewports, similar to what matrox does for windows >> >zooming on their windows drivers (i have not seen this personnally >> >though). You could designate a window, and have it be used for the >> >viewport of a second head. The second viewport would follow the window >> >and scale it apropriatedly, including if the window is moved around or >> >resized. >> >> I don't know how the Matrox driver works specifically, but if it allows >> arbitrary scaling it may use hardware scaling for the second viewport >> (like XVideo usually uses) to achieve this efficiently. I don't know >> how it handles partially obscured or partialy off-screen windows. >> >> Tracking fully visible mode-line sized windows in a second viewport is >> the easiest subset of this whole problem to implement. This is the part >> that could easily be implemented in 4.x without a lot of work. > >Yes, altough if we could add a source w/h to the viewport option, we >could do arbitrary hardware scalling too. static scaling only though. > >And if the hardware can do it, why limit ourself. Agreed. >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. 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. >> >And we would do dual head, not like now with splitting the framebuffer >> >into two zones, one for each head, but by sharing the same framebuffer >> >between both screens, this would give free dual head DRI also, if the 3D >> >engine supports such big displays. Overlay and cursor still would need >> >to be done separatedly. >> >> Right. >> >> >> >BTW, is it normal that SDL games requesting 640x480 try to set it even >> >> >if i did only specify 1024x768 in the monitor modes, and thus give blank >> >> >screens ? I observed this both in my being worked on driver and in the >> >> >vesa driver (using frozen-bubbles and solarwolf in fullscreen mode). >> >> >> >> I've seen games that just put a 640x480 window in one corner of the >> >> 1024x768 screen when there's no 640x480 monitor mode available. >> > >> >Well, apparently SDL will default to the next higher supported mode, but >> >apparently something is broken there. But still, X should not try >> >setting a mode not declared in the XF86Config file, whatever the app >> >asks. >> >> 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. >> 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. Anyway, just pointing out at least two cases where seeing modes not specified in the config file is not broken behaviour. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
