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 ? > >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 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. > >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. 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. > >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. 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 ? > >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. > 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 ... Sven Luther _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
