Multihead, KDE, Xfree4, WM, desktop - question(s)
Hi Excuse the long post, but I have a hard time explaining stuff briefly...:-) I'm hoping someone can point me to some resource(s) on the inner workings of KDE/XF86 interoperation... The environment: SuSE 7.1 (2.2.18), XFree 4.0.2, KDE 2.1 The hardware: 1 Matrox 2164W, 1 Matrox 2064W graphics adaptors 1 Hansol 710P (17"), 1 Proview 1564 (15") monitors Physical setup: screen 0: mga2164W+Hansol rightof screen 1 screen 1: mga2064W+Proview leftof screen 0 I now have these configurations: Xinerama - which basically works fine, except for the unseen bottom left corner (on the smaller Proview monitor), the tendency of windows to open up on the left screen, and that the KDM login box (plus message boxes generally) open up across the division between the screens. These are minor annoyances that I live with and probably could correct if I could just find *where* these settings are defined. Traditional - Which behaves rather strange: Screen 0 works pretty much like in a singlehead-setup, but: Screen1 is *wierd*: It seems as if the WM isn't quite aware of this screen, or it doesn't know what to make of it/how to handle it. Desktop background loads fine, panel goes where I specify, but windows opened here lack borders/titlebar, cannot be moved/resized and don't get keyboard input. All the pointy-clicky stuff works though. Virtual desktops are bound to "the same" screen, so I have (at present) 4 virtual desks on screen 0, and 4 (other) desks on screen 1. I like the traditional setup, mainly because the window-resizing operations function normally. Maximize something, and it does so, within the confines of one screen. In contrast, maximizing windows on the Xinerama setup results in the window sprawling across both screens... (Not so nice) I would like to achieve the following: A "traditional" setup, with *both* screens being managed by the WM, with complete functionality. The virtual desktops should be set up, so that the virtual desk shown on screen 1 = (virtualdesk on screen0)-1 e.g. screen0=desk1 -> screen1=desk4 screen0=desk2 -> screen1=desk1 screen0=desk3 -> screen1=desk2 screen0=desk4 -> screen1=desk3 Up till now I have been using SaX2 to generate the configfiles, and basically it works nicely. I've experienced trouble when importing any multiheaded configfiles, though (SaX2 dies when I say "next"), but generally I am able to set everything up if I supply SaX2 with the information each time I run it. I suspect X might be broken, but I can't seem to locate the troublespot. Other than that I can't seem to find any documentation specifically on the 'virtual desktop' phenomenon at all? Currently I've symlinked /etc/X11/XF86Config -> /etc/X11/XF86Config.dualhed.xinerama.works so that (for testing purposes) I can switch between configurations by changing the symlink instead of renaming the different files all the time. This works fine, it's easy, and I don't *think* it causes any trouble. (Trouble/weirdness was present *before* I adopted this MO.) Generating a new XF86Config just requires I remove the symlink first, and then I don't risk losing my previous config-files ;-) All feedback welcome! I'm on the verge of purging my system of all things X and KDE, and starting from scratch... :-/ Sincerely Jon Clausen BTW since I installed 7.1 and KDE2.1 I now have the option to go directly to console from the GUI-Login-screen... I love it!
Jon Clausen wrote:
The environment: SuSE 7.1 (2.2.18), XFree 4.0.2, KDE 2.1
Xinerama - which basically works fine, except for the unseen bottom left corner (on the smaller Proview monitor), the tendency of windows to open up on the left screen, and that the KDM login box (plus message boxes generally) open up across the division between the screens. These are minor annoyances that I live with and probably could correct if I could just find *where* these settings are defined.
For the window sizing and placement to work correctly, your window manager has to be Xinerama aware. Otherwise, the wm just thinks you have a single screen. I don't think the KDE wm is xinerama aware. I do know that Enlightenment is (I use it). As for the KDM login box, go to the control panel and specify it's location.
Traditional - Which behaves rather strange: Screen 0 works pretty much like in a singlehead-setup, but: Screen1 is *wierd*: It seems as if the WM isn't quite aware of this screen, or it doesn't know what to make of it/how to handle it. Desktop background loads fine, panel goes where I specify, but windows opened here lack borders/titlebar, cannot be moved/resized and don't get keyboard input. All the pointy-clicky stuff works though.
In that mode you have two displays, yourhost:0.0 and yourhost:0.1. Is like having two computers, you have to juggle between the two by playing with the DISPLAY environment variable. You have to start a second window manager, too. This setting has never worked to my satisfaction, you cannot run the same window manager, cannot move windows across screens, etc. I don't use it.
I like the traditional setup, mainly because the window-resizing operations function normally. Maximize something, and it does so, within the confines of one screen. In contrast, maximizing windows on the Xinerama setup results in the window sprawling across both screens... (Not so nice)
Use a window manager that understands xinerama.
I would like to achieve the following:
A "traditional" setup, with *both* screens being managed by the WM, with complete functionality.
The virtual desktops should be set up, so that the virtual desk shown on screen 1 = (virtualdesk on screen0)-1
e.g. screen0=desk1 -> screen1=desk4 screen0=desk2 -> screen1=desk1 screen0=desk3 -> screen1=desk2 screen0=desk4 -> screen1=desk3
This all the job of the window manager, not the server. I don't think there is one that can do that. In any case, think of you screen in xinerama mode desk 1 as desk1 and desk2 of the traditional mode.
Up till now I have been using SaX2 to generate the configfiles, and basically it works nicely. I've experienced trouble when importing any multiheaded configfiles, though (SaX2 dies when I say "next"), but generally I am able to set everything up if I supply SaX2 with the information each time I run it.
I suspect X might be broken, but I can't seem to locate the troublespot.
Rather a sax problem, log a bug report in http://bugzilla.suse.de/ -- Rafael
participants (2)
-
Jon Clausen -
Rafael E. Herrera