Mark Knecht posted on Fri, 24 Jun 2011 09:08:15 -0700 as excerpted: > I've been using an xorg.conf built around NVidia TwinView which > combines two monitors into a single screen. This has worked very well > for me. Two effects I appreciate quite a lot are > > 1) Ctrl-F8 showing me all 6 desktops I have setup > > 2) Drag my mouse to upper left corner which shows all running apps in a > single desktop allowing me to choose one > > To use that setup I have to disable the xinerama USE flag on the Gentoo > ebuilds. > > Yesterday I decide to create a more standard, non-TwinView > xorg.conf file. I got that working with the xinerama USE flag enabled > and found that neither of the two feature above seemed to work at all. > > Questions: > > 1) Should these features have stopped working? (I believe not...)
They should still work, but the config and hotkeys may be different, now. This assumes that opengl is still working across the whole desktop, of course. > 2) Does someone have a working xorg.conf file for a 2+ head system using > NVidia that supports these features? Note that two-headed, AFAIK, refers to fully separate gpu chips/cores (traditionally on separate cards, tho that isn't necessarily the case in today's multi-core technology environment, AFAIK), each of which drives its own display(s). From X's perspective that's rather more complicated than two displays driven by the same graphics chip/core. In the separate graphics cores case, modern X works with a kernel option called graphics arbitration to route graphics requests to the correct core. That's about all I know about it as I've not used it for well over half a decade, now, tho I routinely use and indeed depend on multi-output/single-card/core, in what can be called pseudo-xinerama mode, since the kernel command routing issue doesn't appear as it would in the true multi-head, full xinerama mode, case. Back in the day when I /used/ to run true multi-head, opengl would only work on a single head, tho it would work across all displays run by the same core. I don't know if that's still the case today, or not, but even if it's not, there may be additional config options needing set to get it to work across all of them. I simply don't know. Thus, the first thing to do is to test opengl. A quick (but rather basic, for today's systems) way to do that is to run glxgears from a konsole window. It will likely open on one monitor. See that it works there, move it to the other one, see that it works there (checking the framerate reported in the konsole window to ensure they're comparable), and then test it when the window's half on each monitor as well. If it continues displaying the gears on both monitors and when split across both, with about the same framerate, you're good. If framerate drops more than temporarily as your moving the window, or if it only draws the gears on one monitor (or not at all) when you have the window split across both, that's the first thing to address, as kde's opengl simply isn't going to work well if at all in that case. If desired, you can maximize the window to one monitor, and then across both, to see how well the system keeps up as the draw area increases. If it can keep about the same framerate when running full desktop across both, you have good opengl support. It can be noted that on a modern system frame-rates tend to be locked to the refresh-rate of the monitors, typically 60 fps on LCD-based displays, and decent opengl should do 60 fps at full double-HD resolution without issue. If you're not seeing refresh-rate-locked framerates, then they'll be far higher, perhaps 500 fps or more with a small window, dropping down as the window size increases, but they should still not drop below the refresh-rate of the monitors except possibly temporarily as you move/resize the window, as glxgears simply isn't the stress-test on modern opengl that it was back in the day. If the glxgears test comes out OK, then kde should be able to work with it. You should recall the multiple monitors kcontrol (umm,.. systemsettings, except they aren't systemsettings!) applet from previous threads, and a quick check of the size and orientation (resize and rotate aka randr) applet will hopefully reveal the expected layout, resolution choices, etc. Those are both under hardware, display and monitor. Desktop effects is the next stop. That's under workspace appearance and behavior. WARNING! If your opengl isn't working properly the desktop effects applet can trigger crashes. Thus, best to save any open work you don't want to lose, before opening it, and DEFINITELY before fiddling with specific effects or switching between XRender and OpenGL on the advanced tab, at least until you know the thing is stable on your system. If the glxgears tests above went well, opengl should be working, but as I mentioned, that's testing extremely basic functionality for a modern system and many kwin effects make use of rather more advanced opengl functionality on systems that have it. It has blacklists for hardware/ driver combinations known to be unstable, but they aren't necessarily complete, and there's an override option to force it to try anyway, so it'd definitely best to play with caution at least until you know how stable things are on your system. If you have any extra partitions mounted, etc, it's worth unmounting them, too, and then doing a couple syncs (using either the command line sync command, or the kernel magic-srq sync sequence, alt-sysrequest-s, if the option for that is enabled in your kernel), just to be sure. On the advanced tab, compositing type should be OpenGL. If it's set to XRender, most of the effects won't work, tho a few will. The disable functionality checks checkbox is the override I mentioned above. If it's not letting you switch and you believe it should work, you can check that box and it should allow you to try it, but again, be *SURE* you're prepared for a crash in that case, because those functionality checks are there for a reason. Moving to the all effects tab, I believe the desktop grid effect is what you were referring to above. That and present-windows. Those are both near the bottom of the effects list (second and fourth from the bottom), in the window management section. There's a number of options that can be configured for each if you click the config (spanner/wrench icon) button, including the hotkey (ctrl-f8 being the default for desktop grid, as you mentioned, but I've reassigned window functions to what else, the windows key, here, win-g being my mapping for it -- I only use present- windows as part of desktop-grid, so don't have any way assigned to trigger it, either via hotkey or hot-corners, see below). Once those are setup, the hot-corners config for the present windows effect is elsewhere, under workspace appearance and behavior, workspace behavior, screen edges. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
