I can confirm this bug that have upset me the whole afternoon.

Created attachment 127229 [details] [review]
Allow choosing of monitor for each panel to be on

I ran into this today. Usually you can just drag the panel to the other monitor, but that seems to be broken. So I wrote a patch today that implements the the poster's desired functionality. It adds a section to the preferences dialog so you can choose which monitor the panel should be displayed on. (This is my first time writing a patch for gnome, be nice :))

Richard: can you post a quick screenshot? Would help me :-)

Created attachment 127412 [details]
Panel properties screenshot

xrandr 1.3 introduces a concept of 'primary' output, which can be set by clients.
I think that is what we want to use here. Make the display capplet set the primary output, and make the panel always appear on the primary output.

The original design for the display capplet had this:
http://www.gnome.org/~clarkbw/designs/monitor-resolution-settings/multiple-monitor-resolution-settings-2.png

Note the gray bands on the LCD (which are supposed to represent the panel, and the "Include Panel" checkbox.

Good! I was thinking there should be something on that display capplet for setting some kind of primary display. But, in my experience so far, it doesn't always detect I have two monitors, it sometimes says I have one huge one; unless xrandr 1.3 fixes that..

I disagree with the "always appear on the primary output": I used to have a top panel on one monitor, and a bottom panel on the other, so not allowing me to configure that way would be annoying (I'm sure there'd be others that agree). One reason I wrote that patch the way I did was for consistency: You can drag the panel round one screen, and can drag it across monitors. But, in the properties dialog, you can only move it around the screen that it's on - this I find inconsistent.

*** Bug 567118 has been marked as a duplicate of this bug. ***

See also bug #564713 about having a way in gnome-display-properties to pick the
monitors in which the panel appears.

This bug is actually a combination of several issues:

* First, some drivers put other outputs (like VGA) before LVDS in the list of outputs returned by the RANDR API.  Since gnome-panel defaults to preferring the first output it finds, people see this as "I plug in an external monitor and my gnome-panel switches to it, instead of staying in the LCD".

* Second, there really is no way to select where the panel should be while you are configuring other monitors.  The panel does *something*, but it evidently can't make everyone happy :)

I'll attach a work-in-progress patch for the first problem.  It works fine with RANDR 1.2.

Created attachment 130174 [details] [review]
gnome-panel-bgo562944-prefer-lvds-output.diff

This is a patch for the first problem described above.  It should make things a lot better for most laptop users.

comment about the change from ubuntu users

"This patch breaks gnome-panel on NX:

The program 'gnome-panel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 112 error_code 1 request_code 150 minor_code 8)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Maybe because nxagent don't support XRRGetScreenResources."

I've asked for a stacktrace but the user comments make sense

Note that gtk 2.16 does use xrandr 1.3, and does provide output names for the monitors, so there should be no need to use xrandr yourself to get that.

user comment about the change on https://bugs.launchpad.net/bugs/192009

"Since the update of April 1st, the dual screen support is buggy (it worked fine yesterday morning and the days before).

- The Gnome panel is now on the laptop screen but it was on the main screen before (which I prefered).

- Clicking on the maximize button of a window in the main screen does not maximize it as expected (in fact, it does maximize vertically but not horizontally): see attached screenshot."

the correct url is https://bugs.launchpad.net/bugs/353712

(In reply to comment #14)
> - Clicking on the maximize button of a window in the main screen does not
> maximize it as expected (in fact, it does maximize vertically but not
> horizontally): see attached screenshot."

To diagnose this we need the output of "xrandr -q" and "xprop -root".  I wonder if the WM struts are wrong.(In reply to comment #11)


> "This patch breaks gnome-panel on NX:

Oops, we don't actually check if RANDR is supported.  I'll fix this.

Created attachment 131972 [details]
xrandr -q result

Created attachment 131973 [details]
xprop -root

In reply to comment #16, I've attached the result of 'xprop -root' and 'xrandr -q'. Please also have a look at the video: http://damien.cassou.free.fr/gnome-panel-bug.ogv.

The video shows that there are some invisible lines on which a window attaches automatically. The video shows my main working area with the gnome-panel in the middle (on top of my bottom screen which is not what I want). The icons you see in the video on the left of Firefox can't be seen on my screen. The gnome-panel correctly spans my whole screen width. 

I'm *not* using Compiz.

*** Bug 578058 has been marked as a duplicate of this bug. ***

I can also confirm this even with the new xrandr gui which appeared in GNOME 2.26.

Another Ubuntu user here: while I love the patch that makes GNOME panel stay on my internal laptop screen, there's a little bug (http://launchpad.net/bugs/355848).  If I do this sequence of xrandr commands

  1. xrandr --output VGA --auto --rotate left --right-of LVDS
  2. xrandr --output LVDS --auto --pos 0x480
  3. xrandr --output LVDS --auto --output VGA --off

My bottom GNOME panel jumps to the top of the LVDS screen, just below the top panel, in step 3.

VGA is 1280x800, LVDS is 1280x1024 (and, rotated, becomes 1024x1280).

Created attachment 132207 [details] [review]
gnome-panel-bgo562944-prefer-lvds-output.diff

Updated to detect the RANDR extension at runtime, so that we don't get a BadRequest on nx servers.

Frederico: I'd like to test your patch but wasn't able to apply it on top of current master. Could you publish your branch somewhere please now that we all live in the brave git world? Thanks!

My patch was done against a patch for bug #530969; sorry for not noting that here :)

I've pushed the patch for #530969 to git://gitorious.org/gnome-panel/gnome-panel.git --- look for the bgo530969-sanitize-overlapped-monitors branch.  If you catch this before I look into it tomorrow, can you please see if the patch for *this* bug applies trivially on top of that one?

[One thing to consider is that these days GTK+ can use RANDR 1.3.  In my gnome-panel patch, I'm not using GTK+ to get the RANDR info anymore because GTK+ had switched to using Xinerama instead of RANDR for performance reasons, and thus it wasn't returning any names for outputs.  My patch needs the output names to see if one of them is "LVDS".  Now that GTK+ can use RANDR 1.3 (and thus performance is fixed), we can either keep my patch mostly intact, or use GTK+'s info *iff* it indeed gives us output names as expected.]

I applied the attached patch on top of your bgo530969-sanitize-overlapped-monitors branch, fixed conflicts and pushed it to:
http://git.collabora.co.uk/?p=user/cassidy/gnome-panel;a=shortlog;h=refs/heads/bgo562944-prefer-lvds-output

I also added a trivial patch as you can see.

I'll test this branch tomorrow at the office where I have an external monitor to test with.

I've put patches for gnome-desktop and the display capplet to make use of the xrandr 'primary output' notion at bug 588040 and bug 588041. Now we just need a patch to make the panel appear on the primary output, if there is one (and do what federicos patch does otherwise). 

I committed Federico's patch. Keeping the bug opened so that we also use the primary output stuff.

As for the original issue: I don't quite understand; you can drag and drop the panel to the monitor you want to put it on, can't you?

(doh, bad status for the patch)

Created attachment 140492 [details] [review]
[panel] Make use of the primary output in randr 1.3

This is a completely untested patch which might be totally wrong. Federico, Matthias, care to look at it and try it? :-)

*** Bug 347815 has been marked as a duplicate of this bug. ***

Vincent: if you carry your laptop from home to work, and use dual-head only at work, dragging both panels back to the correct screen every time you enable an external monitor gets old really fast.

Marius: see patches in bug 589632. The panel should remember on which monitor it was, and the patches there (hopefully) implements that.

Created attachment 141190 [details] [review]
support of randr-1.3 features in gnome-panel

I rewrote my patch. It seems to work fine here.

Federico, Matthias: feel free to take a look.

Matthias: should gtk+ emit a signal when the primary monitor is changed? Right now, if I change it, then the panel won't notice it until restart (or another randr event happens).

(In reply to comment #35)

I mailed this to Vincent about his patch:

* You have

  if (have_randr_1_3) {
      blah = XRRGetOutputProperty (..., "ConnectorType");
      if (blah == "Panel")
          return TRUE;
  }

It's not necessary to test for have_randr_1_3.  XRRGetOutputProperty()
*is* present in RANDR 1.2.  If that property doesn't exist, then that
function's returned actual_type will be None.

* About the g_str_has_prefix (name, "LVDS") fallback, I think I've
seen shitty drivers use "Lvds" instead.  We could definitely use a
case-insensitive comparison there.

* You have

        if (have_randr_1_3)
                primary = XRRGetOutputPrimary (xdisplay, xroot);

Again, you only need to check with the preprocessor whether
RANDR_MAJOR/RANDR_MINOR are for 1.3; you don't need to check
have_randr_1_3.  libXrandr's implementation of XRRGetOutputPrimary()
will return None if the X server doesn't do RANDR 1.3.

* Since we are doing RANDR 1.3 stuff... you may want to use
XRRGetScreenResourcesCurrent() if possible, falling back to
XRRGetScreenResources() if only 1.2 is available, to avoid actually probing the
outputs when the panel starts (this should save about 0.5 seconds or so).

> Matthias: should gtk+ emit a signal when the primary monitor is changed? Right
> now, if I change it, then the panel won't notice it until restart (or another
> randr event happens).

If GTK+ adds a gdk_screen_get_primary_monitor() API, then it would need to emit a signal if the primary monitor changes.

For now you can:

1. XRRSelectInput() for RROutputChangeNotifyMask.

2. Get RRNotify events with RRNotify_OutputChange subevents.

3. See if the primary output changed.

X also sends the most general RRScreenChangeNotify event whenever the primary output changes, so you can also do the check for the primary output for that generic event.  Unfortunately, _gdk_x11_screen_size_changed() will not emit the "size-changed" signal if the new size is the same as the old size, so the RRScreenChangeNotify that caused _gdk_x11_screen_size_changed() to be called, will not also result in you getting a signal from GdkScreen.

I've committed the patch, without adding code to listen to the randr events for now.

I just read about this issue, and I wonder how do you determine the primary display.

E.g.

shermann@wz-pc-010:~$ xrandr -q
Screen 0: minimum 320 x 200, current 2680 x 1050, maximum 2680 x 1050
DVI-1 connected 1400x1050+1280+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1400x1050      60.0*+   59.9  
   1280x1024      60.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   832x624        74.6  
   800x600        75.0     60.3  
   640x480        75.0     72.8     59.9  
   720x400        70.1  
DVI-0 connected 1280x1024+0+26 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0 +   75.0* 
   1280x960       75.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     59.9  
   720x400        70.1  

Does not give me any hint about that.
In the past, it was that DVI-0 was the first display which was taken for the panels etc. Now it's DVI-1, but only for panels. Desktop directory content is still on DVI-0.

Regards,

\sh

The primary output is a property that has to be explicitly set. You can use "xrandr --output DVI-0 --primary", eg. There are patches to make the resolution capplet able to set this property.

Note that in your specific case, without the primary property, there's no way to determine which output should be the first, so the panel takes the first one in the list, which is DVI-1.

Hi Vincent,

ok, understood, so my next question will be:

How do we save this information? 

I'm a switching user, means, depending on the day, I'm using GNOME or KDE, and both desktop system do this xrandr stuff independently. Wouldn't it be a good idea (also regarding those issues as described in this bug), to have an XDG compatible storage place for a config file for xrandr and friends, so that both desktop environments can use the same xrandr configuration? 

Thinking about the last paragraph, I think this needs to be addressed to freedesktop.org...

Regards,

\sh

(In reply to comment #40)
> Hi Vincent,
> 
> ok, understood, so my next question will be:
> 
> How do we save this information? 

This is the job of the resolution capplet.

> I'm a switching user, means, depending on the day, I'm using GNOME or KDE, and
> both desktop system do this xrandr stuff independently. Wouldn't it be a good
> idea (also regarding those issues as described in this bug), to have an XDG
> compatible storage place for a config file for xrandr and friends, so that both
> desktop environments can use the same xrandr configuration? 

I believe Federico was talking with KDE people at some point to have them look at our stuff and adopt it. He might know about this.

(but we're getting off-topic for this bug ;-))

(In reply to comment #41)
> 
> I believe Federico was talking with KDE people at some point to have them look
> at our stuff and adopt it. He might know about this.

Yeah, this was the intention of having ~/.config/monitors.xml as opposed to ~/.gnome2/monitors.xml (the configuration file lived under the gnome namespace for a while).

I contacted Aaron Seigo at the beginning of last year's Summer of Code, as he would be mentoring someone for krandrtray (if I remember correctly).  However, we lost touch after that... I don't know what KDE does these days.

If it's useful, I wrote a patch for gtk+ that supports querying the primary monitor from xrandr, so gnome-panel could just use this gtk+ function for that if it goes in.

https://bugzilla.gnome.org/show_bug.cgi?id=601712

Very inconvienient that all the panels go to an arbitrary screen. This comes up all the time in our institution.

Especially bad when one display is markedly smaller, lower resolution or otherwise of lower quality than the other, and they can't just be reconnected.

For example, in the case of a notebook with an builtin and one external display, one of these displays is arbitrarilly the primary display, and there's no way to change that.