! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Support for RandR's "primary monitor"
Status:
RESOLVED: FIXED
Severity:
enhancement
Product:
Xfce4-panel

Comments

Description Simon Steinbeiss editbugs 2012-09-28 10:53:10 CEST
In the course of improving the display dialog to support extended desktop mode, I realized that the panel currently doesn't support RandR's "primary monitor" setting. Instead, the panel always sits on the left-most monitor (i.e. the one that has x:0,y:0).

I think this would be a nice feature to implement along the display-dialog improvements, then it'd make sense to add a "make primary" checkbox to the dialog to move the panel.
Comment 1 mr.lahorde 2015-12-10 11:14:24 CET
A workaround consist in adding a udev rule triggered on monitor connection / disconnection and modifying xfce4-panel monitor using 

xfconf-query -c xfce4-panel -p /panels/panel-0/output-name -s LVDS1

You can find complete solution here :
https://bbs.archlinux.org/viewtopic.php?pid=1584974#p1584974

But I would prefer this issue be solved using "primary monitor settings" described by Simon Steinbeiss.

lah
Comment 2 RichTea 2016-02-16 16:01:31 CET
here is a primitive patch to chose the "Primary" monitor if "Automatic" is selected as the output.



diff --git a/panel/panel-window.c b/panel/panel-window.c
index c21aac3..1d371ca 100644
--- a/panel/panel-window.c
+++ b/panel/panel-window.c
@@ -2013,9 +2013,10 @@ panel_window_screen_layout_changed (GdkScreen   *screen,
         {
           normal_monitor_positioning:
 
+          /* get the primary monitor */
+          monitor_num = gdk_screen_get_primary_monitor (screen);
+
           /* get the monitor geometry based on the panel position */
-          monitor_num = gdk_screen_get_monitor_at_point (screen, window->base_x,
-                                                         window->base_y);
           gdk_screen_get_monitor_geometry (screen, monitor_num, &a);
           panel_return_if_fail (a.width > 0 && a.height > 0);
         }
diff --git a/panel/panel-window.h b/panel/panel-window.h
index f5aa603..e1de633 100644
--- a/panel/panel-window.h
+++ b/panel/panel-window.h
@@ -33,6 +33,11 @@ typedef struct _PanelWindow      PanelWindow;
 #define PANEL_IS_WINDOW(obj)         (G_TYPE_CHECK_INSTANCE_TYPE ((obj), PANEL_TYPE_WINDOW))
 #define PANEL_IS_WINDOW_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), PANEL_TYPE_WINDOW))
 #define PANEL_WINDOW_GET_CLASS(obj)  (G_TYPE_INSTANCE_GET_CLASS ((obj), PANEL_TYPE_WINDOW, PanelWindowClass))
+/* workaround to get "primary" monitor on gtk versions older than 2.20.0 */
+#if !GTK_CHECK_VERSION (2, 20, 0)
+#define gdk_screen_get_primary_monitor(screen) (gdk_screen_get_monitor_at_point (screen, window->base_x, window->base_y))
+#endif
+
 
 GType      panel_window_get_type                  (void) G_GNUC_CONST;
Comment 3 Simon Steinbeiss editbugs 2016-02-17 13:39:04 CET
I've done a quick test of this and it works well, definitely better than what we have now. I'd second merging this.
Comment 4 Simon Steinbeiss editbugs 2016-02-17 13:40:01 CET
*** Bug 8936 has been marked as a duplicate of this bug. ***
Comment 5 RichTea 2016-02-17 13:57:59 CET
I have noted a possible bug, my panel is being stretched out of the current screen when I remove the external monitor, not sure why yet. I hope to dig through and see if the "old" code is being used elsewhere. Some where that works out the screen length?
Comment 6 Simon Steinbeiss editbugs 2016-02-22 22:30:59 CET
(In reply to RichTea from comment #5)
> I have noted a possible bug, my panel is being stretched out of the current
> screen when I remove the external monitor, not sure why yet. I hope to dig
> through and see if the "old" code is being used elsewhere. Some where that
> works out the screen length?

So you're sure this is a regression?
Seems a bit odd to me because if you disconnect the secondary monitor the result from both gdk_screen_get_primary_monitor and gdk_screen_get_monitor_at_point should be 0.

Maybe add some debug output to that portion of the code to see what happens when you disconnect the monitor.
Comment 7 RichTea 2016-03-11 16:19:08 CET
Sorry for the delay, I blieave what is happing is "our" value for the screen geometry is not being updated when the extra monitors are being removed, so the bar ends up to long.

Just trying to understand where that is!
Comment 8 RichTea 2016-03-12 01:15:55 CET
OK after a little digging it seems its a bug with my X session not with Panel or this update. 

So the Diff Stands as it was... 
https://paste.debian.net/391711
Comment 9 wolf 2016-11-21 06:28:06 CET
Is there something holding up this patch?

I came here with the same issue. Ended up figuring out the GUI panel move myself via https://forum.xfce.org/viewtopic.php?pid=35746#p35746
Comment 10 jkroll 2017-02-11 15:50:40 CET
This problem has been bugging people for years [1,2,3,4]. RichTea provided a patch which apparently fixes the issue, at least for the panel. Can you please merge it?

[1] https://forum.xfce.org/viewtopic.php?id=6440
[2] https://bugzilla.xfce.org/show_bug.cgi?id=8936
[3] https://bugs.launchpad.net/ubuntu/+source/xfce4-panel/+bug/1596751
[4] https://unix.stackexchange.com/questions/149388/setting-primary-monitor-in-xfce
Comment 11 Simon Steinbeiss editbugs 2017-02-12 23:33:31 CET
What's holding me (or I guess anyone else with push-rights) back is that the panel's target is now Gtk3, there are no more feature-releases planned for the current Gtk2 panel.

So this patch would have to be ported on top of Gtk3 so we could merge it: https://git.xfce.org/users/andrzejr/xfce4-panel/log/?h=gtk3
Comment 12 jkroll 2017-02-13 15:39:12 CET
+(In reply to Simon Steinbeiss from comment #11)
> What's holding me (or I guess anyone else with push-rights) back is that the
> panel's target is now Gtk3, there are no more feature-releases planned for
> the current Gtk2 panel.
> 
> So this patch would have to be ported on top of Gtk3 so we could merge it:
> https://git.xfce.org/users/andrzejr/xfce4-panel/log/?h=gtk3

Porting to GTK3 would involve using gdk_display_get_primary_monitor[1] as gdk_screen_get_primary_monitor is deprecated[2]. It should still be trivial to do if one has a development environment and dependencies for the GTK3 branch of the panel set up (which I don't). There's also a "nick/gtk3" branch in the official repo[3], not sure what the difference is to the andrzejr one.

Also, this should be considered a bug fix, not a feature. Even the GDK documentation clearly states,
> While normal application windows typically allow the window manager to place the windows, specialized desktop applications such as panels should place themselves on the primary monitor.

So this should be merged into the GTK2 version now, and in the GTK3 version too whenever that's released. Unless there's a reason to stay with the old behaviour, which many users (and the GDK docs) consider broken.


[1] https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-get-primary-monitor
[2] https://developer.gnome.org/gdk3/stable/GdkScreen.html#gdk-screen-get-primary-monitor
[3] https://git.xfce.org/xfce/xfce4-panel/tree/?h=nick%2Fgtk3
Comment 13 RichTea 2017-02-13 17:23:36 CET
Created attachment 6996 
xfce4-panel-primary-monitor.patch
Comment 14 RichTea 2017-02-13 17:31:48 CET
I agree, this is a bug in the code not an enhancement, I have attached a patch file with a workaround for any one running older versions of GTK (<2.20) maybe a similar a workaround to this can be used for GTK3!.
The work around is a little icky, maybe instead there should be an xfce function created "xcfe_get_primary_monitor" that could chose the appropriate backed gtk function depending on the gtk version being used.
Comment 15 Simon Steinbeiss editbugs 2017-02-28 00:07:12 CET
Created attachment 7033 
Add option for supporting primary monitor

I have reworked the original patch a little and made "Primary" an additional option. I'm not sure I like changing the "Automatic" behavior or dropping it in favor of the "Primary" option.

This means that we can later also add a check - if necessary - to check for older versions of XRandR which don't support the "primary" feature.

Finally, I've rebased the patch on top of git master, which is now the Gtk3 port of the panel.

Please give it some testing.
Comment 16 LukeLR 2017-03-05 00:52:05 CET
I'd love to see this feature in release soon. I am really surprised  that xfce-panel ignores the primary-flag in xrandr. My three-monitor-setup includes my primary display as the center monitor now, but my panel stays on the leftmost monitor. This is not expected behaviour, at least for me.
Comment 17 Simon Steinbeiss editbugs 2017-03-16 00:13:17 CET
Pushed to master: https://git.xfce.org/xfce/xfce4-panel/commit/?id=a24b0214c9218ab39581d0e40b1b441913d631f7

This means the feature will be part of the 4.13 (development) and 4.14 (stable) releases.

I will evaluate whether we can backport this easily in a regression-free manner to 4.12.
Comment 18 jkroll 2017-03-16 00:24:11 CET
Sounds great, thanks!
Comment 19 FadyEk 2017-04-05 05:38:23 CEST
Thanks Simon and RichTea for this fix. I really would like to get it in my environment. I had to switch to another desktop environment until this issue is fixed. Is there a way to build 4.13 myself, or at least build 4.12 and apply the patch myself? I'm using xubuntu with XFCE 4.12.
Comment 20 Simon Steinbeiss editbugs 2017-04-08 00:03:22 CEST
I have finally found the time to backport this to 4.12. Please test from my branch:
https://git.xfce.org/users/ochosi/xfce4-panel/log/?h=primary_for_4_12
Comment 21 haarp 2017-04-13 22:34:55 CEST
(In reply to Simon Steinbeiss from comment #20)
> I have finally found the time to backport this to 4.12. Please test from my
> branch:
> https://git.xfce.org/users/ochosi/xfce4-panel/log/?h=primary_for_4_12

I applied 18df47092db and everything seems to be working.

However, I am seeing the same bug I've had with the previous patch by RichTea. If only 2 of 3 defined monitors are active, part of the third panel will be sitting at the top of the screen (i.e. a 1 or 2 pixels high line is visible). It might be related to the authide function, which is enabled for this panel.
Comment 22 Simon Steinbeiss editbugs 2017-04-13 22:59:50 CEST
(In reply to haarp from comment #21)
> However, I am seeing the same bug I've had with the previous patch by
> RichTea. If only 2 of 3 defined monitors are active, part of the third panel
> will be sitting at the top of the screen (i.e. a 1 or 2 pixels high line is
> visible). It might be related to the authide function, which is enabled for
> this panel.

Could you please either share your panel setup via xfpanel-switch or describe the setup in detail so I can try to reproduce?
Thanks!
Comment 23 haarp 2017-04-13 23:21:53 CEST
(In reply to Simon Steinbeiss from comment #22)
> Could you please either share your panel setup via xfpanel-switch or
> describe the setup in detail so I can try to reproduce?
> Thanks!

Sure!

All panels are horizontal and at the bottom.
Panel 1: full length, always visible, on Primary output
Panel 2: 75% length, autohide enabled, Monitor 1
Panel 3: 75% length, autohide enabled, Monitor 2

I have three monitor setups (it's a laptop)
Mobile: laptop screen
Home: laptop screen left, primary monitor right
Work: laptop screen left, primary monitor middle, 2nd monitor right

Observations:
At work things work as expected.

On mobile, I can see panel 2 hiding behind panel 1 (they're partially transparent) - but I understand why. panel 2 is set to monitor 1 after all :) It seems it always counts them from left to right.

At home things get weird. on the laptop screen, I can partially see one of the 75% panels the *top* of the laptop screen (a 1 or 2 pixels wide bar is sticking out). This happens even if both monitors are set to mirror, but not if the monitor is unplugged.

I can provide the xfconf config if necessary.


Thanks!
Comment 24 haarp 2017-09-01 18:03:54 CEST
I think the bug I'm seeing is unrelated to this patch and is a general issue with xfce4-panel's output handling. Therefore I've made a new report at bug 13831.

Primary output is working as intended (tested in 4.13.1) and I think this can be closed. Thanks!
Comment 25 Simon Steinbeiss editbugs 2017-09-06 00:50:55 CEST
Ok, thanks for testing again. Closing this report then.
Comment 26 Git Bot editbugs 2017-10-09 21:32:58 CEST
Simon Steinbeiss referenced this bugreport in commit cc453ea2402167d48ddff8da75fd026e3c2dc26e

Add support for XRandR's primary monitor feature (Bug #9338)

https://git.xfce.org/xfce/xfce4-panel/commit?id=cc453ea2402167d48ddff8da75fd026e3c2dc26e
Comment 27 Simon Steinbeiss editbugs 2017-10-09 21:33:56 CEST
I'm preparing a new release for 4.12 with the primary feature now (since the translations are fixed now). Waiting for translations to trickle in and then there'll be a maintenance release.
Comment 28 Christian Hesse 2017-10-27 22:24:59 CEST
Created attachment 7392 
make 'Primary' the default output

I think the implementation is incomplete. Please consider applying the attached patch on top.
Comment 29 Christian Hesse 2017-10-27 23:21:46 CEST
Created attachment 7393 
make 'Automitic' the default selection for output

... or the other way round.
Comment 30 Simon Steinbeiss editbugs 2017-10-29 00:38:35 CEST
I amended your second patch a little (panel_str_is_empty does not exist on the 4.12 branch) and pushed it. Thanks for catching that!

Bug #9338

Reported by:
Simon Steinbeiss
Reported on: 2012-09-28
Last modified on: 2017-10-29
Duplicates (1):
  • 8936 Monitor ordering in multi-screen setup

People

Assignee:
Simon Steinbeiss
CC List:
14 users

Version

Version:
4.12.0

Attachments

Additional information