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