[kde-linux] Re: KDE multiple desktop effects vs NVidia TwinView/normal 2-head xorg.conf

[Duncan]

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