On Fri, Feb 28, 2003 at 09:04:06PM +0100, Sven Luther wrote: >On Fri, Feb 28, 2003 at 02:06:35PM -0500, David Dawes wrote: >> On Fri, Feb 28, 2003 at 06:27:20PM +0100, Sven Luther wrote: >> >On Fri, Feb 28, 2003 at 11:59:48AM -0500, David Dawes wrote: >> >> On Thu, Feb 27, 2003 at 10:11:34AM +0100, Sven Luther wrote: >> >> >> >> >BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of >> >> >thing would most assuredly go into the thinking about 5.x, but some of >> >> >the stuff here, and about the dual-head/one FB (which would allow DRI on >> >> >dual head cards) could also be implemented in the current setting. >> >> >> >> We definitely want to discuss the dual-seat possibilities in the context >> >> of 5.0. >> >> >> >> I agree that dual-head/one FB (single seat) can be handled in the current >> >> 4.x environment. Several 3rd party drivers already handle this in one >> >> way or another. I did some configuration and infrastructure related >> >> work on this for a project that got cut. One of the things this handled >> >> was the configuration for mutiple monitor viewports being attached to >> >> a single screen. Now that 4.3.0 is out, I'd like to go back and finish >> >> that off, and modify one of the existing dual CRTC drivers to make use >> >> of it. >> > >> >There was some discution about this in the DRI mailing list, and i am >> >also currently writing a driver which would need this kind of thing. >> > >> >I guess that you can tell the driver via the device section that it is >> >to share the Framebuffer between monitors and that you can then use the >> >viewport on the display subsection to set the viewport to wherever you >> >want. >> >> The static configuration handles associating multiple monitors, sets of >> modes, initial viewport positioning, etc with a single Device/Screen. > >Are you speaking about the current 4.3.0 or the stuff you are working on ?
What I was working on. >> >Now, if you want one of the viewports to do some scaling too, either >> >because your LCD monitor is fixed size, and a program want to run in >> >another size, or for having one viewport displaying a zoomed part of the >> >other or whatever. I think this is not currently possible, but i may be >> >wrong. Also it would be nice if we could follow a window with a >> >viewport, and adjust the zoom factor accordyingly. >> >> Mode switching would work for multiple monitors, and they could be made >> to switch independently. Handling this switching, and providing useful >> run-time control over the origin of the viewports is the next step after >> the static configuration. It could be handled with some combination of >> hot keys, pointer scrolling, and/or a control client. >> >> Are you also interested in doing scaling other than what you get for >> free by having one monitor display at a lower resolution? > >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 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. 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. >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. >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. >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. 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... David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
