Multiple Monitors
Hi Guys, I am in the process of creating an X mod and would like some pointers on where to start (i wont have a problem writing the code, i am just not sure where to start). I am wanting to create the following: Y Y1Y2 Where Y, Y1 Y2 are monitors. I always want the cursor to be located on Y, but the screens to the right left of me are visible on other monitors. Firstly is this possible? Secondly is this an X mod or a window manager's mod? Actually having thought about it further, I assume it would be a process of setting up X with multiple monitors and then moding the window manager?? Any pointers would be tops. Thanks Jono ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
I will assume that you do not want Xinerama mode. So, three display heads is not a problem, hand tweak the xf86config file for 3 displays. Assign each display a number :0.0 == Y :0.1 == Y1 :0.2 == Y2 Use CursorLimits command to constrain the cursor done JC Jonathon Bates wrote: Hi Guys, I am in the process of creating an X mod and would like some pointers on where to start (i wont have a problem writing the code, i am just not sure where to start). I am wanting to create the following: Y Y1Y2 Where Y, Y1 Y2 are monitors. I always want the cursor to be located on Y, but the screens to the right left of me are visible on other monitors. Firstly is this possible? Secondly is this an X mod or a window manager's mod? Actually having thought about it further, I assume it would be a process of setting up X with multiple monitors and then moding the window manager?? Any pointers would be tops. Thanks Jono ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Jay Cotton [EMAIL PROTECTED] 408 635 0621 x11621 Sun Microsystems Inc. 2515 North First Street, MS USJC07-201 San Jose, CA 95131 Sun Microsystems Inc. - X11 Server Group User Experience Engineering ~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Thu, 18 Mar 2004, Jonathon Bates wrote: Hi Guys, I am in the process of creating an X mod and would like some pointers on where to start (i wont have a problem writing the code, i am just not sure where to start). I am wanting to create the following: Y Y1Y2 Where Y, Y1 Y2 are monitors. I always want the cursor to be located on Y, but the screens to the right left of me are visible on other monitors. Firstly is this possible? Secondly is this an X mod or a window manager's mod? Actually having thought about it further, I assume it would be a process of setting up X with multiple monitors and then moding the window manager?? If you want these to be 3 separate root windows with the cursor confined to one of them, XFree86 can probably already do that. A ServerLayout like the following: Section ServerLayout Identifier DualHead Screen 0 ScreenY 0 0 Screen 1 ScreenY1 0 0 Screen 2 ScreenY2 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection probably does that already since there are no LeftOf etc... to tell the server how to route the cursor when it goes offscreen, so it ends up getting stuck on screen 0. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
Alan Hourihane wrote: I prefer option 2 because of its fewer levels of SubSections. What's the replacement for the metamodes option/concept? Will this survive? No. Hm. In that case, I don't think this is a real step forward. It requires more configuration data instead of less: Only for simple configurations... read on. The current implementation (at least in the SiS driver, can't really speak for the others), the Modes in the Display subsection are the pool from which the meta modes are composed. All modes in that (yet single) Display subsection are checked against the specs of *both* output devices (which are the Monitor section for device 1, and specific options in the Device section for the second; in both cases unless we have DDC data). If they pass this check, they can be part of a meta mode. Your modification forces the user, more or less, to enter the same data twice. I don't really see the advantage, except that it's maybe more intuitive to read the config file but that is assumingly not the goal. The fact is, more and more video cards are getting multiple heads. Even the Matrox Parhelia can drive 3 monitors. I know of others than can drive 4 monitors and it's just not user friendly/scalable with the current setup. No question. Agreed. As all the drivers seem to have their own implementation (albeit similar) AFAIK only 3 open source drivers support mergedfb yet: Matrox, SiS and radeon (in the DRI trunk). Radeon's code is nearly if not entirely identical with the SiS code as Alex Deucher took my SiS code and inserted it into the radeon driver. As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. The options (and their names) of all three drivers supporting mergedfb are identical; they are, conceptwise, mostly even identical to the binary NVidia driver (except that the open source drivers don't support panning domains - however useful that is anyway). (Hm, reading this might make one think that there already is something like a standard) it clutters up drivers with very very similar code too. Agreed. Yes, there might be more config to do in the config file, but the tools to setup these up hide a lot of that already. Hell, I'll even make the -configure option do the right thing too. OK In case you mean that the resolution changes in the same order the modes are given in these two Monitor sections, I find this far less easy to configure (one has to count the Modes to see which ones are being combined, etc.) And how are clone/zoom modes being configured? I'm open to suggestions on how to deal with all this, and that's why I brought it up. The current situation of 'let the driver deal with it' is just ripe for getting out of control. I am not against your idea at all, in case I made this impression. I just wanted to point out that just monitor configuration is by far not sufficient. The following is meant to give a short overview and as a basis for comments for a new configuration implementation: Summarized, the criteria for configuring mergedfb mode are - monitors and their specs; that is what your proposal so far took care of, - relative position = orientation (mon A left/right of/above/below mon B; that can be extended to 3 or 4 or whatever number of monitors easily: mon c above mon b, mon d above mon a etc) and clone/zoom (=both/all show the same image, possibly with a zoom facility) - mode selection for each monitor (read: output device); there the problem starts. As I said, right now, the drivers use the (only) Modes list as the pool, and the MetaModes statement for combining these modes. What I would find highly unpractical is leaving this out entirely and use the Modes given in the new Monitor Subsections as the modes the driver should use - in that order. From my experience, users think more in a whole when configuring mergedfb mode. Meaning that the emphasis is on the respective modes used on each output device _at_the_same_time_ = metamode. A plain list of modes for each monitor (of which assumingly many will be skipped when they exceed the specs) makes server behavior highly uncomprehendable from a user's point of view: If one or the other mode is deleted from the list, the whole list is shifted, and hence the result is an entirely different one. I find the MetaModes concept, even if perhaps not the most intuitive, but a very useful one. This, of course, cries for comments. (From anyone, that is. Alex? Mark?) - virtual screen dimension: The user should not be forced to calculate anything. Hence, this must be done automcatically. - DPI: Big problem, inherent to all multi-monitor implementations. - automatic configuration (in case the user does not give all the above with options; such as
Re: Multiple Monitors
On Tue, 2 Mar 2004, Alan Hourihane wrote: I mentioned in a reply to Alex, that maybe the ScreenLayout section should use Monitor's rather than Screens. I think that should fix the orientation issues, as the ScreenLayout is really describing the monitor positions. I didn't spot this the first time around. At present there is no need for two monitor sections when you have two identical monitors, as each Screen can use the same Monitor. Don't know whether that change is important. So you'd only use the modes for the second monitor that is described for the primary monitor ? I'm not keen on that. Some people will have two very different monitors, and many of the Matrox cards support more modes (RAMdac bandwidth limits) on one head than the other. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
--- Thomas Winischhofer [EMAIL PROTECTED] wrote: Alan Hourihane wrote: I prefer option 2 because of its fewer levels of SubSections. What's the replacement for the metamodes option/concept? Will this survive? No. Hm. In that case, I don't think this is a real step forward. It requires more configuration data instead of less: Only for simple configurations... read on. The current implementation (at least in the SiS driver, can't really speak for the others), the Modes in the Display subsection are the pool from which the meta modes are composed. All modes in that (yet single) Display subsection are checked against the specs of *both* output devices (which are the Monitor section for device 1, and specific options in the Device section for the second; in both cases unless we have DDC data). If they pass this check, they can be part of a meta mode. Your modification forces the user, more or less, to enter the same data twice. I don't really see the advantage, except that it's maybe more intuitive to read the config file but that is assumingly not the goal. The fact is, more and more video cards are getting multiple heads. Even the Matrox Parhelia can drive 3 monitors. I know of others than can drive 4 monitors and it's just not user friendly/scalable with the current setup. No question. Agreed. As all the drivers seem to have their own implementation (albeit similar) AFAIK only 3 open source drivers support mergedfb yet: Matrox, SiS and radeon (in the DRI trunk). Radeon's code is nearly if not entirely identical with the SiS code as Alex Deucher took my SiS code and inserted it into the radeon driver. As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. Yup, I ported pseudo-xinerama over to radeon as well. I also plan to bring the mga driver up to speed with the other drivers as time allows, pending ryan's re-work of the dualhead/dvi stuff. The options (and their names) of all three drivers supporting mergedfb are identical; they are, conceptwise, mostly even identical to the binary NVidia driver (except that the open source drivers don't support panning domains - however useful that is anyway). (Hm, reading this might make one think that there already is something like a standard) it clutters up drivers with very very similar code too. Agreed. Yes, there might be more config to do in the config file, but the tools to setup these up hide a lot of that already. Hell, I'll even make the -configure option do the right thing too. OK In case you mean that the resolution changes in the same order the modes are given in these two Monitor sections, I find this far less easy to configure (one has to count the Modes to see which ones are being combined, etc.) And how are clone/zoom modes being configured? I'm open to suggestions on how to deal with all this, and that's why I brought it up. The current situation of 'let the driver deal with it' is just ripe for getting out of control. I am not against your idea at all, in case I made this impression. I just wanted to point out that just monitor configuration is by far not sufficient. The following is meant to give a short overview and as a basis for comments for a new configuration implementation: Summarized, the criteria for configuring mergedfb mode are - monitors and their specs; that is what your proposal so far took care of, - relative position = orientation (mon A left/right of/above/below mon B; that can be extended to 3 or 4 or whatever number of monitors easily: mon c above mon b, mon d above mon a etc) and clone/zoom (=both/all show the same image, possibly with a zoom facility) - mode selection for each monitor (read: output device); there the problem starts. As I said, right now, the drivers use the (only) Modes list as the pool, and the MetaModes statement for combining these modes. What I would find highly unpractical is leaving this out entirely and use the Modes given in the new Monitor Subsections as the modes the driver should use - in that order. From my experience, users think more in a whole when configuring mergedfb mode. Meaning that the emphasis is on the respective modes used on each output device _at_the_same_time_ = metamode. A plain list of modes for each monitor (of which assumingly many will be skipped when they exceed the specs) makes server behavior highly uncomprehendable from a user's point of view: If one or the other mode is deleted from the list, the whole list is shifted, and hence the result is an entirely different one. I find the MetaModes concept, even if
Re: Multiple Monitors
Alex Deucher wrote: I agree. I think metamodes are kind of klunky, but I don't know what a better solution would be off hand. Another thing about the proposed solution is that in many drivers certain configurations are assumed, which can be confusing in the screen setup. For instance in the radeon driver, the DVI/lvds port is always primary. What's the primary? Since I can put the devices left-right or right-left, primary is IMHO only relevant for Xinerama and/or applications drawing fixed conclusions. (And for the record: The SiS driver needs to treat CRT2 as some sort of primary as well, due to order-of-init reasons required by the hardware. CRT2 can be TV, LCD=DVI-D or VGA2=DVI-A. CRT1 can only be VGA. I also need to know all about the configuration for CRT2 before I can eg. calculate the maximum pixel clocks for CRT1, etc etc etc) It might almost be a better idea to work the other way around. standardize the mergedfb backend stuff (pseudo-xinerama, metamode parsing, pointermoded(), etc.) and then just standardize on options for the drivers. Maybe instead of messing with the monitors in the screen section, allow the user to specify them in the device section like Alan mentioned earlier, something like: option crt2monitor Monitor1 That is an alternative, indeed. And it would be much easier to implement since there is no old version-style and new-version-style XF86Config then (which I wouldn't know how to distinguish between). The disadvantage is that you blast the chain of / Monitor Screen ---x \-Device by directly linking the Device and Monitor section. Dogmatically that isn't really beautiful. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 05:56:01AM -0800, Alex Deucher wrote: As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. Yup, I ported pseudo-xinerama over to radeon as well. I also plan to bring the mga driver up to speed with the other drivers as time allows, pending ryan's re-work of the dualhead/dvi stuff. Yeah, I need to get back to that. I got sidetracked with studies and the last weekend was eaten trying to beat some sense into the rendition driver. Did you ever get your G550? I have two systems now, one with DH G400 and one with SH G400 + a millenium II. So hopefully I can at least verify that me stuff is working on at least one DH card and at least one multi-mga configuration. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 10:10:40PM +, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. The approach I was following up a while ago but never finished was something like this: Section Screen Identifier Screen0 Device Videocard0 Monitor 0 Monitor0 Monitor 1 Monitor1 RightOf Monitor0 DefaultDepth 24 SubSection Display Depth 16 Virtual 0 1600 1200 Virtual 1 1024 768 Modes 0 1600x1200 1280x1024 1024x768 Modes 1 1024x768 800x600 640x480 EndSubSetion SubSection Display Depth 24 Virtual 0 1600 1200 Virtual 1 1024 768 Modes 0 1600x1200 1280x1024 1024x768 Modes 1 1024x768 800x600 640x480 EndSubSetion EndSection Explicitly tying numbers to the monitor entries would be optional, as would supplying per-monitor parameters in the Display subsections. The idea of MetaModes (i.e., mode combinations) that I think Andy Ritger mentioned a while back would be useful too. Figuring out how the configuration information is represented will be useful in working out how to represent the information internally for the drivers. As much as possible should be auto-configured by default though. I got the parser changes, and the data structure changes done, and had made a start on the other pieces. Allowing a high level of flexibility in the configuration syntax was complicating the implementation though. It might be that a different method would simplify that, which would definitely be a good thing. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection I'd prefer option 2 out of these because of the reduced redundancy. If we want to handle meta modes, perhaps they could be handled via a regular Display subsection. You then need a method for specifying the monitor layout. I chose an approach analogous to how we specify the layout of multiple screens, and that should work here too. Additional things come up, like how the monitor view port moves within the logical screen, how the mode switching hot keys work, etc. I'd suggest we come up with something that can cope with the types of things we expect to need, get the basics implemented first, then get into the nitty gritty details of some of the fancier stuff. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 11:09:23PM +, Alan Hourihane wrote: On Mon, Mar 01, 2004 at 02:57:50PM -0800, Alex Deucher wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Indeed. So I'd let to get this first step of modifying the config file out of the way so all the other pieces can drop into place. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Actually, you bring up a good point with orientation, and it's making me rethink a little. Maybe we need to be a little more radical with the changes and change the ServerLayout to accept Monitor configurations instead of Screen sections as essentially that's how it's really tied down. You don't have the same freedom with placement of monitors as you do with screens. For example, you can't have the screen of a second card placed in between two monitors of the first card. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 04:11:02PM -0800, Mark Vojkovich wrote: On Mon, 1 Mar 2004, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 01:18:20AM +0100, Thomas Winischhofer wrote: Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. I think the goal here is provide a simpler and more regular method of handling this stuff, but with a basis that is flexible enough to handle expected needs without going through this again in the near future. Clone and zoom are all special cases of a more general monitor layout mechanism, which is really all about how you postion the multiple view ports into the single screen and how you handle mode switching. Allowing these things to be changed/configured on the fly makes it even more interesting, and will go some way to simplifying real-world configuration. Open question: does the newly (or nearly?) standardised Xinerama extension allow for the physical screen layout to be changed at runtime? It needs to for a least this pseudo Xinerama case. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 12:32:08PM +, Dr Andrew C Aitchison wrote: On Tue, 2 Mar 2004, Alan Hourihane wrote: I mentioned in a reply to Alex, that maybe the ScreenLayout section should use Monitor's rather than Screens. I think that should fix the orientation issues, as the ScreenLayout is really describing the monitor positions. I didn't spot this the first time around. At present there is no need for two monitor sections when you have two identical monitors, as each Screen can use the same Monitor. Don't know whether that change is important. That is an important point. Now that you mention it, I ran into the same issue in handling the monitor layout with the method I was looking at. It makes referring to monitors by Id alone ambiguous. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 12:59:52PM -0500, David Dawes wrote: Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. BTW, while we are at it, please let's add support for depth independent modelines. Something like : SubSection Display Depth 16 24 Modes1024x768 800x600 640x480 EndSubSection Or even : SubSection Display Modes1024x768 800x600 640x480 EndSubSection Which would use the modes for all depth. I doubt newer cards have per depth modes limitations anymore. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 07:18:37PM +0100, Sven Luther wrote: On Tue, Mar 02, 2004 at 12:59:52PM -0500, David Dawes wrote: Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. BTW, while we are at it, please let's add support for depth independent modelines. Something like : SubSection Display Depth 16 24 Modes1024x768 800x600 640x480 EndSubSection Or even : SubSection Display Modes1024x768 800x600 640x480 EndSubSection Which would use the modes for all depth. I doubt newer cards have per depth modes limitations anymore. I already did the latter for 4.4.0 as part of the auto-configuration work. The Display subsection and Monitor sections are entirely optional too. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
David Dawes wrote: On Tue, Mar 02, 2004 at 01:18:20AM +0100, Thomas Winischhofer wrote: Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. I think the goal here is provide a simpler and more regular method of handling this stuff, but with a basis that is flexible enough to handle expected needs without going through this again in the near future. Clone and zoom are all special cases of a more general monitor layout mechanism, which is really all about how you postion the multiple view ports into the single screen and how you handle mode switching. Allowing these things to be changed/configured on the fly makes it even more interesting, and will go some way to simplifying real-world configuration. Open question: does the newly (or nearly?) standardised Xinerama extension allow for the physical screen layout to be changed at runtime? It needs to for a least this pseudo Xinerama case. Exactly. However, since I found that changing it run-time either has no effect (so with kde) or seriously confuses apps (many examples) I don't do it now. I just calculate a basic setup (based on the orientation and the meta modes) and use this through out the session. It's no problem with Xinerama, it's a problem with the apps. (Or, well, perhaps Xinerama, too, in case it lacks a facility to notify clients of changes which I don't remember) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Multiple Monitors
I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection Comments ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 10:10:40PM +, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. To add to this, we'd probably need to add a keyword 'Monitor' into the Device Section, and be able to do something like this Section Device Identifier Videocard0 VendorName Vendor BoardName RADEON 8500 Monitor Monitor0,Monitor1 Driver radeon EndSection Then the driver can see that Monitor0 is primary and Monitor1 is secondary and so on. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
--- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Alex Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection Comments ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 02:57:50PM -0800, Alex Deucher wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Indeed. So I'd let to get this first step of modifying the config file out of the way so all the other pieces can drop into place. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Actually, you bring up a good point with orientation, and it's making me rethink a little. Maybe we need to be a little more radical with the changes and change the ServerLayout to accept Monitor configurations instead of Screen sections as essentially that's how it's really tied down. I'm gonna ponder on this some more, but I'd love to hear any furthur comments. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, 1 Mar 2004, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 04:11:02PM -0800, Mark Vojkovich wrote: And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. Absolutely, that is a main priority, as is allowing the new XFree86 server to still parse older XF86Config files. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Multiple monitors
I have five monitors on a system and one keyboard/mouse. Can I configure the system that the mouse/keyboard will not apply for two of those monitors. And thus will go one monitor further while dragging the mouse ? Best regards, Marcel Stegehuis ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple monitors
you can configure that heads however you want. if you don't want to use two of the heads, don't include them in your config. then set up the arrangemet of the other heads as you like. Alex --- [EMAIL PROTECTED] wrote: I have five monitors on a system and one keyboard/mouse. Can I configure the system that the mouse/keyboard will not apply for two of those monitors. And thus will go one monitor further while dragging the mouse ? Best regards, Marcel Stegehuis __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Betr: Re: Multiple monitors
I do want to see the graphics on the monitor but I would like the mouse to step over it. Marcel -- Oorspronkelijk bericht -- From: Alex Deucher [EMAIL PROTECTED] Subject: Re: Multiple monitors To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 7 Oct 2003 06:46:34 -0700 (PDT) you can configure that heads however you want. if you don't want to use two of the heads, don't include them in your config. then set up the arrangemet of the other heads as you like. Alex --- [EMAIL PROTECTED] wrote: I have five onitors on a system and one keyboard/mouse. Can I configure the system that the mouse/keyboard will not apply for two of those monitors. And thus will go one monitor further while dragging the mouse ? Best regards, Marc l Stegehuis __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://X ree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Betr: Re: Multiple monitors
well, in the config you can arrange the mointors such that the two you want to skip are above, below, or to the side of the ones you want together. Alex --- [EMAIL PROTECTED] wrote: I do want to see the graphics on the monitor but I would like the mouse to step over it. Marcel -- Oorspronkelijk bericht -- From: Alex Deucher [EMAIL PROTECTED] Subject: Re: Multiple monitors To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 7 Oct 2003 06:46:34 -0700 (PDT) you can configure that heads however you want. if you don't want to use two of the heads, don't include them in your config. then set up the arrangemet of the other heads as you like. Alex --- [EMAIL PROTECTED] wrote: I have five onitors on a system and one keyboard/mouse. Can I configure the system that the mouse/keyboard will not apply for two of those monitors. And thus will go one monitor further while dragging the mouse ? Best regards, Marc l Stegehuis __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://X ree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
