Thanks, I'll take a look at it. Alex
--- Thomas Winischhofer <[EMAIL PROTECTED]> wrote: > Sorry for replying to my own post: > > Alex, > > I just uploaded a new version (to my website), this time with RandR > support for the Pseudo-Xinerama stuff. > > This required quite a few changes, such as > > - recalculating the maxCRTx_xx fields in UpdateXineramaScreenInfo() > rather than doing this once during mode-linking; but only if the > virtual > size has changed; > - calling UpdateXineramaScreenInfo() in SwitchMode() > > etc. > > Unfortunately, KDM does not support RandR as it seems, so I have not > tested this in reality yet. > > Thomas > > Thomas Winischhofer wrote: > > Alex Deucher wrote: > > > >> I'd be interested in seeing your code once you have decided on a > route, > >> so that I can update the radeon mergedfb driver. > > > > > > Alex, the code is now available on my website (URL in sig). > > > > Look for everything surrounded by "#ifdef SISXINERAMA", and check > the > > additions to the CopyModeNLink() function (setup of maxCRTx_xx). > > > > I wrote a little description which can be found in the options > chapter > > about MergedFB mode on the mentioned website. Please read that > first. > > > > When reading and trying to understand the code (which is far from > being > > as trivial as I wrote in the original message of this thread), > think of > > the following special situations: > > > > - overlapping viewports (virtual desktop too small for largest > Metamode), > > - Virtual desktops larger than the largest Metamode > > - Clone modes whereas the CRT2Position is not "Clone" > > > > The SiS-Pseudo-Xinerama extension will be disabled if the user > selected > > "Clone" as the CRT2Position (whatever you call this in the radeon > > driver), and if only clone modes are given (that is, if the > metamodes > > list only contains modes without a "-" and a second mode > following). > > > > For a while I thought of updating the Xineramainfo with each mode > > switch, since the boundary between the two heads eventually changes > with > > every such event. But after having implemented this, I turned out > that, > > at least with KDE/KDM, that had no effect; seems that the KDE > system > > queries the Xinerama extension only once, at startup... So I went > for a > > static information, calculated based on all Metamodes given, trying > to > > find a somewhat usable common. > > > > Essentially, the Xineramainfo for each (pseudo-)"screen" is the > maximum > > scrolling area of each head, taken from all Metamodes given. So > far, > > this is the smartest solution I could come up with. > > > > KDM works well with this, even with overlapping pseudo-screens, as > does > > Xine and some other applications. I don't know about other window > > managers, though. > > > > Some Metamode-combinations are, of course, very inconvenient for my > > > current concept, such as the "1280x1024-1024x768 > 1024x768-1280x1024" > > example I already mentioned. But I think, manually disabling > Xinerama > > support in such cases this is the price one must pay... > > > > Comments appreciated, especially from folks using the NVidia binary > > > driver with its Xinerama support. > > > > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
