Bug 165898 - background changes only on one screen when using multiple screens and nVidia twinview
Summary: background changes only on one screen when using multiple screens and nVidia ...
Status: RESOLVED DUPLICATE of bug 167558
Alias: None
Product: plasma4
Classification: Unmaintained
Component: multiscreen (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-06 23:46 UTC by Pete Snider
Modified: 2008-11-18 21:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pete Snider 2008-07-06 23:46:57 UTC
Version:           4.0.84 (using Devel)
Installed from:    Compiled sources
Compiler:          precompile from kde-redhat.com version 4.0.84 
OS:                Linux

Setting the background with Twinview or Xinerama should apply to the whole logical screen and not one physical screen.  Currently different backgrounds can be set for each physical screen even if multiple screens are configured as one logical screen.

One background should be allowed per screen no matter if it's a logical or physical screen.  The positioning tiled, centered, center and streach, or other configuration should be user controled.
Comment 1 Mark Philpot 2008-07-22 07:22:38 UTC
4.1 Update -- Can now no longer set background for right (second) monitor.  Right click on the right desktop does not produce a context menu.  The background is a grey-white checkerboard pattern.

(Kubuntu packaging)
Comment 2 Christopher Rasch-Olsen Raa 2008-09-13 20:50:36 UTC
Same bug on Fedora 9 using Kde 4.1.0-1 and xorg server 1.4.99.
Comment 3 Tom G. 2008-11-10 03:03:10 UTC
The backgrounds are set in the ~/.kde/share/config/plasma-appletsrc file.

All you have to do is manually edit this file and set the wallpaper to point the correct file for screen1.  

then
killall plasma && plasma

will reload.   Hopefully KDE 4.2 won't have this oversight in the desktop settings dialog.

--Tom G.
here is an excerpt
<code>
[Containments][12]
formfactor=0      
geometry=1686,0,1280,1024
immutability=1           
location=0               
plugin=desktop           
screen=1                 
wallpaper=/home/tom/Pictures/89896-dorren.jpg
zvalue=0         

[Containments][1]                           
backgroundmode=0                            
formfactor=0                                
geometry=0,0,1680,1050                      
immutability=1                              
location=0                                  
plugin=desktop                              
screen=0
wallpaper=/home/tom/Pictures/78212-2006.jpg 
wallpapercolor=224,223,222                  
wallpaperposition=2                         
zvalue=0   


</code>
Comment 4 Pete Snider 2008-11-10 05:01:29 UTC
Please correct me if I'm wrong, but comment #3 looks as if it's a method to set the background for screen 1.  But in the problem configuration, Twinview or Xinerama is being used which means there is no screen 0, only a one logical screen 0.  No application or X operation should be able to access screen 1 as in :0.1 only as :0.0.  Does setting the background with KDE involve OpenGL?  Could the problem actually be an OpenGL not operating on a logical screen?

thanks,
-pete
Comment 5 Nick Shaforostoff 2008-11-10 13:56:29 UTC
btw. some time ago a local kde user approached me and asked a thing about automatic background image switch (slide-show): he wanted to be able to select different set of images for every virtual desktop.
Comment 6 Tom G. 2008-11-11 12:45:53 UTC
X sees only one logical screen with a size of both screens combined.  Xinemara  partitions this into two logical screens.  Thanks to that, we are able to have have two or more seperate yet interoperable screens.

Not sure why the KDE 4.1 desktop-settings (right click on desktop) dialog does not detect screens.  Perhaps they wanted a complete rewrite as with the KDE kicker.

The screens in the plasma-appletsrc are virtual / logical, they don't pertain to Screen 0:0 /  Screen 1:0 as far as X is concerned.

FYI, I am using Fedora 9.93, KDE 4.1.2 with plasma, Xgl, compiz...  This is most definitely a deficiency with the settings dialog, as it is the default KDE 4.1.2 dialog.  Compiz / XGL do not change it whatsoever (same as before I enabled Xgl / compiz; thus, OpenGL is not to be blamed.  


Please let me know if you have any questions.


(In reply to comment #4)
> Please correct me if I'm wrong, but comment #3 looks as if it's a method to set
> the background for screen 1.  But in the problem configuration, Twinview or
> Xinerama is being used which means there is no screen 0, only a one logical
> screen 0.  No application or X operation should be able to access screen 1 as
> in :0.1 only as :0.0.  Does setting the background with KDE involve OpenGL? 
> Could the problem actually be an OpenGL not operating on a logical screen?
> 
> thanks,
> -pete
> 

Comment 7 Gael Beaudoin 2008-11-18 20:37:58 UTC
I'm using 4.1.3 and I can for each of my screens setup a different background, choose, centered, tiled, etc.

What doesn't work  correctly ?
Can you try  with a  more recent kde, aither trunk or 4.1.3 ?
Comment 8 Gael Beaudoin 2008-11-18 21:18:05 UTC
Additional comment from the reporter:

Gael,

The point is having 2 different backgrounds in Twinview or Xinerama is
broken. Both Twinview and Xinerama multiple physical screens are one
and only one virtual screen.  Addressing the screens as 0:0.0 and
0:0.1 is wrong.  In Twinview or Xinerama setting the background should
spread across the virtual screen.  Setting the background should not
know or even be capable of displaying one physical screen or another.
The background should go across the virtual screen according to the
mode of centered, tiled, stretch, etc.  I'm using the latest in Fedora
9.

-pete

So this is duplicate of 167558.

*** This bug has been marked as a duplicate of bug 167558 ***