After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 562944 - Make use of the randr 1.3 primary output
Make use of the randr 1.3 primary output
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: general
2.30.x
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 347815 567118 578058 (view as bug list)
Depends on:
Blocks: randr-tracker
 
 
Reported: 2008-12-02 08:26 UTC by Lionel Dricot
Modified: 2020-03-17 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Allow choosing of monitor for each panel to be on (13.10 KB, patch)
2009-01-26 02:33 UTC, Richard Eames
none Details | Review
Panel properties screenshot (22.13 KB, image/png)
2009-01-28 18:07 UTC, Richard Eames
  Details
gnome-panel-bgo562944-prefer-lvds-output.diff (9.22 KB, patch)
2009-03-06 02:28 UTC, Federico Mena Quintero
none Details | Review
xrandr -q result (1.03 KB, text/plain)
2009-04-03 05:59 UTC, Damien Cassou
  Details
xprop -root (3.52 KB, text/plain)
2009-04-03 06:01 UTC, Damien Cassou
  Details
gnome-panel-bgo562944-prefer-lvds-output.diff (10.67 KB, patch)
2009-04-06 17:57 UTC, Federico Mena Quintero
committed Details | Review
[panel] Make use of the primary output in randr 1.3 (3.42 KB, patch)
2009-08-11 22:40 UTC, Vincent Untz
none Details | Review
support of randr-1.3 features in gnome-panel (4.88 KB, patch)
2009-08-19 21:33 UTC, Vincent Untz
committed Details | Review

Description Lionel Dricot 2008-12-02 08:26:59 UTC
If you set a dualscreen setup with gnome-display-properties, gnome-panel will be only on one of those screens (the first display device listed by xrandr). Unfortunatly, it seems to be impossible to choose which one should be the "main" one.

And, guess what ? Every time, I want it on that *other* screen... 


Ubuntu bug about it : https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/192009
Comment 1 Skippy le Grand Gourou 2008-12-08 18:50:24 UTC
I can confirm this bug that have upset me the whole afternoon.
Comment 2 Richard Eames 2009-01-26 02:33:42 UTC
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 :))
Comment 3 Vincent Untz 2009-01-28 11:52:13 UTC
Richard: can you post a quick screenshot? Would help me :-)
Comment 4 Richard Eames 2009-01-28 18:07:24 UTC
Created attachment 127412 [details]
Panel properties screenshot
Comment 5 Matthias Clasen 2009-02-27 06:31:57 UTC
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.
Comment 6 Richard Eames 2009-02-27 06:51:30 UTC
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.

Comment 7 Jens Granseuer 2009-03-05 18:17:03 UTC
*** Bug 567118 has been marked as a duplicate of this bug. ***
Comment 8 Federico Mena Quintero 2009-03-06 01:12:55 UTC
See also bug #564713 about having a way in gnome-display-properties to pick the
monitors in which the panel appears.
Comment 9 Federico Mena Quintero 2009-03-06 02:12:41 UTC
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.
Comment 10 Federico Mena Quintero 2009-03-06 02:28:43 UTC
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 11 Sebastien Bacher 2009-04-01 08:13:24 UTC
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."
Comment 12 Sebastien Bacher 2009-04-01 08:14:26 UTC
I've asked for a stacktrace but the user comments make sense
Comment 13 Matthias Clasen 2009-04-01 13:09:28 UTC
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.
Comment 14 Sebastien Bacher 2009-04-02 10:34:54 UTC
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."
Comment 15 Sebastien Bacher 2009-04-02 10:35:17 UTC
the correct url is https://bugs.launchpad.net/bugs/353712
Comment 16 Federico Mena Quintero 2009-04-02 19:02:52 UTC
(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.
Comment 17 Damien Cassou 2009-04-03 05:59:44 UTC
Created attachment 131972 [details]
xrandr -q result
Comment 18 Damien Cassou 2009-04-03 06:01:26 UTC
Created attachment 131973 [details]
xprop -root
Comment 19 Damien Cassou 2009-04-03 06:27:00 UTC
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.
Comment 20 Jens Granseuer 2009-04-05 19:26:05 UTC
*** Bug 578058 has been marked as a duplicate of this bug. ***
Comment 21 roberth.sjonoy 2009-04-05 21:33:00 UTC
I can also confirm this even with the new xrandr gui which appeared in GNOME 2.26.
Comment 22 Marius Gedminas 2009-04-06 09:14:03 UTC
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).
Comment 23 Federico Mena Quintero 2009-04-06 17:57:18 UTC
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.
Comment 24 Guillaume Desmottes 2009-04-23 22:25:12 UTC
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!
Comment 25 Federico Mena Quintero 2009-05-15 03:11:42 UTC
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.]

Comment 26 Guillaume Desmottes 2009-05-17 13:53:32 UTC
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.
Comment 27 Matthias Clasen 2009-07-08 05:15:03 UTC
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). 
Comment 28 Vincent Untz 2009-08-11 22:11:56 UTC
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?
Comment 29 Vincent Untz 2009-08-11 22:12:59 UTC
(doh, bad status for the patch)
Comment 30 Vincent Untz 2009-08-11 22:40:40 UTC
Created attachment 140492 [details] [review]
[panel] Make use of the primary output in randr 1.3
Comment 31 Vincent Untz 2009-08-11 22:41:23 UTC
This is a completely untested patch which might be totally wrong. Federico, Matthias, care to look at it and try it? :-)
Comment 32 Vincent Untz 2009-08-12 13:44:43 UTC
*** Bug 347815 has been marked as a duplicate of this bug. ***
Comment 33 Marius Gedminas 2009-08-12 16:10:51 UTC
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.
Comment 34 Vincent Untz 2009-08-12 16:40:54 UTC
Marius: see patches in bug 589632. The panel should remember on which monitor it was, and the patches there (hopefully) implements that.
Comment 35 Vincent Untz 2009-08-19 21:33:30 UTC
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).
Comment 36 Federico Mena Quintero 2009-08-20 23:09:48 UTC
(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.
Comment 37 Vincent Untz 2009-08-25 13:12:26 UTC
I've committed the patch, without adding code to listen to the randr events for now.
Comment 38 Stephan Hermann 2009-09-03 09:21:35 UTC
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
Comment 39 Vincent Untz 2009-09-03 09:49:28 UTC
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.
Comment 40 Stephan Hermann 2009-09-03 09:55:57 UTC
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
Comment 41 Vincent Untz 2009-09-03 10:06:10 UTC
(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 ;-))
Comment 42 Federico Mena Quintero 2009-09-07 19:22:11 UTC
(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.
Comment 43 Cody Russell 2009-11-23 22:21:18 UTC
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
Comment 44 Jeremy Nickurak 2010-08-28 21:51:53 UTC
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.