Right now it seems, that the primary display (the one which has the panel in auto mode, which gets notification, which is monitor 1 in the desktop settings dialog and so on) is always the one which defines the 0xX-border of the virtual screen in a multimonitor setup. The --primary/--noprimary option of xrandr isn't honored.
I fail to understand what this have to do with the window manager, can you please provide the reproducing steps, expected result and actual result?
O.k., it seems I don't have the right terminology to express in a simple way, so I hope you excuse, that this will be a long post. (You may also want to have at this forum post: http://forum.xfce.org/viewtopic.php?id=6440 ). It was only a guess, that xfwm manages this sort of stuff. Let's start with single monitor setup: I have my notebook monitor with the panel, some opened windows, conky and so on. Now I plugin an external monitor, which is physically located right of my notebooks display. I extend my desktop via 'xrandr --output <external monitor> --auto --right-of <notebook monitor>', get empty desktop space on the external monitor and can push some windows to it, while my notebooks monitor show me the same as before: the panel, previously opened windows, conky, notifications ... In the desktop settings/wallpaper dialog my notebooks monitor is called 'monitor 1' the external 'monitor 2'. So, this is exactly, how I want it to be. Now we change the setup: the external monitor is physically located left of my notebook screen. I extend my desktop to the left via 'xrandr --output <external monitor> --auto --left-of <notebook monitor>'. Now the content of my notebook monitor shows up on the external monitor (panel, conky notifications ...) and leaves it an empty desktop space. The desktop settings/wallpaper dialog shows me the external as 'monitor 1' and the notebook display as 'monitor 2'. This is not, how I want it to be. I want my notebooks monitor content remain the same and extend it with an empty desktop space to the left (like it worked when extending to the right). I'm not sure, but I thought the '--primary/--noprimary' option of xrandr is meant for this case: to specify which physical display in the virtual display of a multimonitor setup remains the 'original' and which becomes the 'extension'. From my testing it seems, that xfce chooses always the physical display which is the leftmost display in the virtual display as it's 'monitor 1'. Summarized, I would like to be able to define which physical display in a multimonitor setup remains the main display and which display(s) is(are) just the extension.
The problem is that you cannot specify the primary display in a dual head setup. Normally you would use the xrandr command: xrandr --output CRT1 --primary to set the external screen as primary, so it gets the XFCE panel. And you use xrandr --output CRT1 --right-of LVDS to position the external monitor to match your physical setup. The problem is that the panel only wants to be on the display that is on the left as defined by xrandr. In my case the laptop display (LVDS). The --primary option does work in other desktop environments such as gnome2.3..
Oh and Olivier, you have to excuse us for not knowing to which tracker we have to submit this bug. We are simple users (at least I am) and have no idea which part of the code is responsible for this behaviour. Feel free to move it to another more suited tracker. :)
This bug should go to Product Xfce4-settings instead of Xfwm4. Reason: Code for handling with libxrandr is in that other Product.
Hi Raphael, Can we easily move this to there? Of should we start a new thread in xfce4-settings?
(In reply to comment #6) > Hi Raphael, > > Can we easily move this to there? Of should we start a new thread in > xfce4-settings? I created a clone of this bug with the suggested Product selection. See # 8328. Maybe you can close this bug.
(In reply to comment #7) https://bugzilla.xfce.org/show_bug.cgi?id=8328
It's not so simple, many components are affected... - The xfce4-panel, - The settings manager and its UI - xfwm4 as well, as it would have to move the windows depending on which display is declared primary
Does that mean you're trying to reimplement the logic of xrandr CLI? Why not call that executable then directly from code instead of using the libxrandr API?
(In reply to comment #10) > Does that mean you're trying to reimplement the logic of xrandr CLI? Why not > call that executable then directly from code instead of using the libxrandr > API? No, that means that feature needs code to be added. Try to set the primary display withe CLI, that has absolutely no effect at all. As a side note (off topic here), yes, it's more efficient to use the API rather than trying to build a command line and spawn a process that will parse that command line...
*** This bug has been marked as a duplicate of bug 8328 ***