Trouble with multiple screens and Nvidia drivers
Hi all,
(This is all with xmonad-0.5)
I've been wanting to try out xmonad (as a replacement for ion3), but I'm
having some trouble with the multi-screen support, but maybe I'm just
confused about how it's supposed to work...
My setup is as follows:
|----------------| |--------------|
| Screen 1 | | Screen 0 |
|----------------| |--------------|
This is what the nvidia control panel says. The nvidia control panel
also says that Xinerama is enabled (and so does my xorg.conf). Xdpyinfo
says:
default screen number: 0
number of screens: 1
and lists a screen size of 3200x1200 (my screens are both 1600x1200).
As far as I understand Xinerama this is all as it should be. Moving
stuff across the boundary between the two screens works as it should.
Now, the behavior that seems very disconcerting to me is this:
Let's say I use the Full layout exclusively and place a client (A) on
workspace 1, thus:
Workspace 1:
Screen 1 Screen 0
|--------------| |--------------|
| (empty) | | client A |
|--------------| |--------------|
Then I switch to workspace 4, place a client (B) which also ends up on
the physical screen 0:
Workspace 4:
Screen 1 Screen 0
|--------------| |--------------|
| (empty) | | client (B) |
|--------------| |--------------|
If I now switch to workspace 1 via Alt-1 and then go up through the
workspaces via Alt-2, Alt-3 and Alt-4 I get the following sequence of
physical layouts:
Alt-2 => Workspace 2:
Screen 1 Screen 0
|--------------| |--------------|
| (empty) | | (empty) |
|--------------| |--------------|
=> As it should be.
Alt-3 => Workspace 3:
Screen 1 Screen 0
|--------------| |--------------|
| Client A | | (empty) |
|--------------| |--------------|
=> What is client A now suddenly doing on workspace 3?
Alt-4 => Workspace 4:
Screen 1 Screen 0
|--------------| |--------------|
| (empty) | | client (B) |
|--------------| |--------------|
=> As it should be.
Things get really weird when I go back down through the workspaces:
Alt-3 => Workspace 3:
Screen 1 Screen 0
|--------------| |--------------|
| Client B | | (empty) |
|--------------| |--------------|
=> What is client B now doing on the left hand side of workspace 3?
Alt-2 => Workspace 2:
Screen 1 Screen 0
|--------------| |--------------|
| Client B | | (empty) |
|--------------| |--------------|
=> What is client B now doing on the left hand side of workspace 2?
Alt-1 => Workspace 1:
Screen 1 Screen 0
|--------------| |--------------|
| Client B | | Client A |
|--------------| |--------------|
I'm really baffled by this behavior. Am I missing something fundamental
about how xmonad+Xinerama is supposed to work?
(The exact order/screens which clients end up on doesn't seem to be
completely reproducible; the above is what happens most of the time though).
Any help in understanding this would be greatly appreciated.
Cheers,
--
Bardur Arantsson
On 2007-12-13 23:22:53 Bárður Árantsson wrote:
This is what the nvidia control panel says. The nvidia control panel also says that Xinerama is enabled (and so does my xorg.conf). Xdpyinfo says:
default screen number: 0 number of screens: 1
and lists a screen size of 3200x1200 (my screens are both 1600x1200).
That's correct.
As far as I understand Xinerama this is all as it should be. Moving stuff across the boundary between the two screens works as it should.
I'm not sure what stuff you'd be moving between screens under XMonad, other than the mouse pointer.
Now, the behavior that seems very disconcerting to me is this:
Let's say I use the Full layout exclusively and place a client (A) on workspace 1, thus:
Workspace 1:
Screen 1 Screen 0 |--------------| |--------------| | (empty) | | client A | |--------------| |--------------|
Nope. Screen 0 is showing workspace 1. Screen 1 is showing workspace 2. ...
I'm really baffled by this behavior. Am I missing something fundamental about how xmonad+Xinerama is supposed to work?
Yes. Each screen shows a different workspace and can switch between workspaces independently. When you type alt-1 etc., that workspace is pulled onto the currently focused screen. If the workspace you want to change to is already visible on the other screen, XMonad swaps it with your current workspace. /J
On Fri, 2007/12/14 00:41:22 +0000, Jamie Webb wrote:
Yes. Each screen shows a different workspace and can switch between workspaces independently. When you type alt-1 etc., that workspace is pulled onto the currently focused screen. If the workspace you want to change to is already visible on the other screen, XMonad swaps it with your current workspace.
Even though I’ve been using xmonad for a couple months, I’m still not completely comfortable with greedy workspace switching. It seems somehow wrong to me. Is it possible to configure xmonad to revert to the old style of switching (or what I think the old style is; I converted to xmonad after the 0.3 release with greedy switching) where pressing Mod+# for a visible workspace would be equivalent to Mod+[WER]? Or possibly have a different set of workspaces for each screen, so that Mod+7 on screen 0 would pull up a different workspace than Mod+7 on screen 1*? Both at work and at home, my two screens have different resolutions and workspace-swapping is sometimes unpleasant. * Displaying the current screen configuration in dzen or xmobar could be difficult, though. I known’t enough about how log hooks work in xmonad 0.5.
On Thursday 13 December 2007 20:47:04 lithis wrote:
Even though I’ve been using xmonad for a couple months, I’m still not completely comfortable with greedy workspace switching. It seems somehow wrong to me. Is it possible to configure xmonad to revert to the old style of switching
Yes, simply replace W.greedyView with W.view. Cheers, Spencer Janssen
xmonad:
On Fri, 2007/12/14 00:41:22 +0000, Jamie Webb wrote:
Yes. Each screen shows a different workspace and can switch between workspaces independently. When you type alt-1 etc., that workspace is pulled onto the currently focused screen. If the workspace you want to change to is already visible on the other screen, XMonad swaps it with your current workspace.
Even though I’ve been using xmonad for a couple months, I’m still not completely comfortable with greedy workspace switching. It seems somehow wrong to me. Is it possible to configure xmonad to revert to the old style of switching (or what I think the old style is; I converted to xmonad after the 0.3 release with greedy switching) where pressing Mod+# for a visible workspace would be equivalent to Mod+[WER]? Or possibly have a different set of workspaces for each screen, so that Mod+7 on screen 0 would pull up a different workspace than Mod+7 on screen 1*? Both at work and at home, my two screens have different resolutions and workspace-swapping is sometimes unpleasant.
* Displaying the current screen configuration in dzen or xmobar could be difficult, though. I known’t enough about how log hooks work in xmonad 0.5.
the dzen logHook stuff is already set up to show current, visible and hidden screens in the status bar, to make it really easy to see the current mapping from screens to workspaces. See Eric's config file and screenshot: http://haskell.org/sitewiki/images/3/3f/Glguy-config.jpg (note the visible and current marked screens) and a fairly fancy config file, http://haskell.org/haskellwiki/Xmonad/Config_archive/Eric_Mertens%27_xmonad.... the essence of whcih is, logHook = dynamicLogWithPP $ myPP din myPP h = defaultPP { ppCurrent = dzenColor "white" "#cd8b00" . pad , ppVisible = dzenColor "white" "#666666" . pad , ppHidden = dzenColor "black" "#cccccc" . pad so yep. dynamicLogWithPP with seperate colours for current, visible and hidden. We'll continue to improve and simplify the status bar mechanisms. -- don
Jamie Webb wrote:
On 2007-12-13 23:22:53 Bárður Árantsson wrote: [--snip--] ...
I'm really baffled by this behavior. Am I missing something fundamental about how xmonad+Xinerama is supposed to work?
Yes. Each screen shows a different workspace and can switch between workspaces independently. When you type alt-1 etc., that workspace is pulled onto the currently focused screen. If the workspace you want to change to is already visible on the other screen, XMonad swaps it with your current workspace.
Aha! I'm glad it's just me, because that should hopefully mean that it's
possible to configure one's way out of it :).
Is there a way to force "consistency" such that I'll always end up with
consistent pairs of workspaces on each of the screens? Say as in,
Alt-1:
Screen 1: Workspace 0
Screen 0: Workspace 1
Alt-2:
Screen 1: Workspace 2
Screen 0: Workspace 3
Alt-2:
Screen 1: Workspace 4
Screen 0: Workspace 5
(etc.)
?
Cheers,
--
Bardur Arantsson
On Fri, Dec 14, 2007 at 07:47:36AM +0100, =?ISO-8859-1?Q?B=E1r=F0ur_=C1rantsson_ wrote:
Is there a way to force "consistency" such that I'll always end up with consistent pairs of workspaces on each of the screens? Say as in,
Alt-1:
Screen 1: Workspace 0 Screen 0: Workspace 1
Alt-2:
Screen 1: Workspace 2 Screen 0: Workspace 3 ... ?
What you're descibing is the way other window managers work, in which you view just one workspace at a time, and each workspace includes the contents of both screens. I'm not sure why we do this differently. In a sense, it's a sort of crude "sticky window" approach that assumes you're actually only using one screen at a time. This wouldn't be to hard to create keybindings for. Alternatively, you could disable xinerama support in xmonad, and construct your layout algorithms using *|* so that windows wouldn't be placed on the boundary between the two screens. This might be more or less successful, depending what layouts you want to use, but would definitely be the easiest and most internally-consistent solution. (Yes, this is a hack, but that's what's required to construct a semantics not implemented in xmonad.) -- David Roundy Department of Physics Oregon State University
David Roundy wrote:
On Fri, Dec 14, 2007 at 07:47:36AM +0100, =?ISO-8859-1?Q?B=E1r=F0ur_=C1rantsson_ wrote:
Is there a way to force "consistency" such that I'll always end up with consistent pairs of workspaces on each of the screens? Say as in,
Alt-1:
Screen 1: Workspace 0 Screen 0: Workspace 1
Alt-2:
Screen 1: Workspace 2 Screen 0: Workspace 3 ... ?
What you're descibing is the way other window managers work, in which you view just one workspace at a time, and each workspace includes the contents of both screens. I'm not sure why we do this differently. In a sense, it's a sort of crude "sticky window" approach that assumes you're actually only using one screen at a time.
Yup, I'm used to Ion and the current behavior just feels really weird to me.
This wouldn't be to hard to create keybindings for. Alternatively, you could disable xinerama support in xmonad, and construct your layout algorithms using *|* so that windows wouldn't be placed on the boundary between the two screens. This might be more or less successful, depending what layouts you want to use, but would definitely be the easiest and most internally-consistent solution. (Yes, this is a hack, but that's what's required to construct a semantics not implemented in xmonad.)
As an xmonad hacker do you have any idea how difficult it would be to
implement this?
I'm not entirely foreign to Haskell, but I've never tried to modify the
xmonad code. If I could get any hints as to what bits of code need
tweaking, I'd happily have a whack at it. :)
Cheers,
--
Bardur Arantsson
Hi, I was like you ... I think I have the hack that you have need It's an expermental version ... Normaly it works for 2 screens In 2 or 3 months, I will finalize it and I will distribute it. Actually, it works with xmonad 0.4 For use this hacks : *In Config.hs import Hacks.SendWsToAllScreen --01 02 11 12 -- workspacesP = ["1","2","3","4"] workspacesP :: [WorkspaceId] workspacesP = map (\x -> "0"++(show x)) [1 .. nbWorkspacePerScreen :: Int] ++ map (\x -> "1"++(show x)) [1 .. nbWorkspacePerScreen :: Int] -- Le nombre de bureau par ecran nbWorkspacePerScreen :: Int nbWorkspacePerScreen = 9 In keys add: -- mod-[1..6] @@ Switch to workspace N and N+6 [((modMaskP, k),sendWsToAllScreen i) | (i,k) <- take (nbWorkspacePerScreen) (zip [1..] (take nbWorkspacePerScreen keyWorkspace))] *And add the module (SendWsToAllScreen.hs) in the sources path, I hope so that you will find your happiness... I can help you if you have some pb See you, Antoine Bárður Árantsson a écrit :
David Roundy wrote:
On Fri, Dec 14, 2007 at 07:47:36AM +0100, =?ISO-8859-1?Q?B=E1r=F0ur_=C1rantsson_ wrote:
Is there a way to force "consistency" such that I'll always end up with consistent pairs of workspaces on each of the screens? Say as in,
Alt-1:
Screen 1: Workspace 0 Screen 0: Workspace 1
Alt-2:
Screen 1: Workspace 2 Screen 0: Workspace 3
...
?
What you're descibing is the way other window managers work, in which you view just one workspace at a time, and each workspace includes the contents of both screens. I'm not sure why we do this differently. In a sense, it's a sort of crude "sticky window" approach that assumes you're actually only using one screen at a time.
Yup, I'm used to Ion and the current behavior just feels really weird to me.
This wouldn't be to hard to create keybindings for. Alternatively, you could disable xinerama support in xmonad, and construct your layout algorithms using *|* so that windows wouldn't be placed on the boundary between the two screens. This might be more or less successful, depending what layouts you want to use, but would definitely be the easiest and most internally-consistent solution. (Yes, this is a hack, but that's what's required to construct a semantics not implemented in xmonad.)
As an xmonad hacker do you have any idea how difficult it would be to implement this?
I'm not entirely foreign to Haskell, but I've never tried to modify the xmonad code. If I could get any hints as to what bits of code need tweaking, I'd happily have a whack at it. :)
Cheers,
participants (7)
-
Bárður Árantsson -
David Roundy -
Don Stewart -
Jamie Webb -
kg -
lithis -
Spencer Janssen