--- 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 perhaps not the most intuitive, > > but a very useful one. This, of course, cries for comments. (From > anyone, that is. Alex? Mark?) 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. users might confuse this and expect their monitor orientation to be swapped. not that it's hard to re-configure, but it just adds to the confusion, not that the current drivers do it any differently, but since it's all in the man page, there a better chance they will notice it. Thinking about this more, perhaps when you run 'XFree86 -configure' it can build the config file based on the monitor attached/ddc data from from the driver, however, that would require the driver to make that info available to the server for each head. 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" > > - 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 automatic selection of virtual screen size, > DPI, > meta-modes, etc). The SiS driver gives very good results even if one > _only_ specifies Option "MergedFB". Takes the largest modes for each > output device which survived validity checks, calculates virtual > screen > size, calculates DPI, etc. Don't know if matrox or radeon have > similar > functionality. radeon does the same thing for the most part, although clone mode is the default. mga does not yet. > > For those who don't know: I have written a quite detailed > documentation > for MergedFB mode on my website > (http://www.winischhofer.net/linuxsisvga.shtml#mergedfbmode) which > covers all the configuration problems involved. Maybe this helps > forming > a new configuration concept. > > However, I don't think we can make it entirely without options in the > > Device section... I have thought about this for a long time but > haven't > been able to come up with a better solution yet. > > > (For the sake of completeness: From a driver programmer's point of > view, > there is quite much to take care of: > > - HW cursor (especially if the viewable areas overlap) > > - video (problem for hardware that only has one overlay; this is not > as > trivial as it sounds) > > - hardware limitations (eg. max X coordinate for 3D operations, IIRC > this was a huge problem for radeon hardware) > > The reason for mentioning this is that these can become issues for > configuration, too.) > > > Alex __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
