I'm using a multiscreen X configuration, when I log in, all the panels are started on screen 1
Could you attach the output of "PANEL_DEBUG=1 xfce4-panel"?
Just tried but it starts correctly on both screen. The problem seems to only manifest itself when logging in. I have to find a way to start xfce4-panel with PANEL_DEBUG=1 when the session starts. Any idea ?
If you start with startxfce4, you can export it in the console. If you use a login manager I think you can drop an export in $sysconfdir/xdg/xfce4/xinitrc.
Created attachment 3401 xsession-errors Here is my xsession-errors with PANEL_DEBUG=1 exported in xinitrc
Pushed a bunch of fixes for various screen issues on master, could you give it a shot? Or do you want a tarball to try it?
Created attachment 3409 updated xsession-errors
Created attachment 3410 xorg.conf
Created attachment 3411 xfce4-panel.xml
Tried the same config, but it all works fine here...
meh, is there any parallelization somewhere that could start xfce4-panel too early (running on a quad core here) ? Because it also seems to me that the text of the clock and application menu has no hinting applied (will file an other bug about that later).
I tried it on a quad too, but I'm not sure that could be the cause, because i think gtk takes care of window positioning and moving to the correct screen, not the window manager. Olivier? Anyway, git master has some improved debugging (yes, again...) so a new log could help.
(In reply to comment #11) > I tried it on a quad too, but I'm not sure that could be the cause, because i > think gtk takes care of window positioning and moving to the correct screen, > not the window manager. Olivier? No, the window manager always has the final word, it's its role, managing windows. Is the multi-monitor setup active already from gdm? What you describe looks a lot like a race condition between the panel and the xrandr settings being applied at startup, something like: 1. window manager starts, only one monitor is active or a different setup is applied 2. panel starts, forced onto one monitor 3. xrandr setup is applied, multiple monitors are added (but too late, panels are already positioned) Well, just an idea.
The panel *should* remember the output name, so if it comes available it moves to that screen and the window is hidden if the output is not available. Looking at the logs, the first call to the positioning of the window has a 2-screen setup, so I don't think that's is the problem. Only wondered if Xfwm4 would 'interfere' with positioning if it starts later then the panel.
Will check later whether I have multi-monitor setup active in gdm and report (but I think I haven't)
(In reply to comment #13) > Only wondered if Xfwm4 would 'interfere' with positioning if it starts later > then the panel. It won't interfere with panel positioning if the requested position is within the screen boundaries. (In reply to comment #14) > Will check later whether I have multi-monitor setup active in gdm and report > (but I think I haven't) I have been using xfce on multi-monitor layouts for years, no problem with the panel, that includes 4.6 and 4.8 as well, ie works for me.
(In reply to comment #15) > > I have been using xfce on multi-monitor layouts for years, no problem with the > panel, that includes 4.6 and 4.8 as well, ie works for me. 4.6 worked fine, the problem appeared in 4.8 and it seems I'm the only one who encounters it. Don't know what is so special about my configuration.
(In reply to comment #14) > Will check later whether I have multi-monitor setup active in gdm and report > (but I think I haven't) Multi-monitor is active in GDM with a black screen on the second monitor
I now think that the panel 1 is correctly set on the main screen but that screen is not "repainted" and thus I can't see it. Sometimes, after log in, the wallpaper on that screen is not painted either.
(In reply to comment #18) > I now think that the panel 1 is correctly set on the main screen but that > screen is not "repainted" and thus I can't see it. Sometimes, after log in, the > wallpaper on that screen is not painted either. "xwininfo -root -tree" will tell what windows are on the screen and at what position.
Created attachment 3426 xwininfo on display :0.0
Created attachment 3427 xwininfo on display :0.1
As you can see in the xwininfo output for display :0.0, the panel is started but I can't see it. The wallpaper is also not painted on display :0.0, I ran a killall -HUP xfdesktop that made it reappear but still no panel visible.
(In reply to comment #22) > As you can see in the xwininfo output for display :0.0, the panel is started > but I can't see it. The wallpaper is also not painted on display :0.0, I ran a > killall -HUP xfdesktop that made it reappear but still no panel visible. Is compositing enabled? Could it be the same as bug 7194 ?
(In reply to comment #23) > (In reply to comment #22) > > As you can see in the xwininfo output for display :0.0, the panel is started > > but I can't see it. The wallpaper is also not painted on display :0.0, I ran a > > killall -HUP xfdesktop that made it reappear but still no panel visible. > > Is compositing enabled? Could it be the same as bug 7194 ? Compositing is disabled (even in Xorg configuration)
Maybe it is just a coincidence but since I updated the NVidia drivers, the problem seems to have disappeared.
Well good to hear. I've also cleaned the code that caused Olivier's problem (hopefully), so that might help too, although it doubt they are related.
I spoke too quickly, same problem when logging in this morning. I'm going to install a master version of Xfce to test your latest commits.
I still have the problem with a fresh master install when logging in with GDM. I will test with logging in using startxfce4.
The panel crashes totally when enabling the composite extension, don't if I should fill an other bug or if it is related. DBG[xfce-sm-client.c:722] xfce_sm_client_parse_argv(): setting restart and clone commands (xfce4-panel, xfce4-panel) TRACE[xfce-sm-client.c:1254] xfce_sm_client_set_property_from_command(): entering (RestartCommand, 0x1f73aa0, APPEND) TRACE[xfce-sm-client.c:1254] xfce_sm_client_set_property_from_command(): entering (CloneCommand, 0x1f73b30, REMOVE) DBG[xfce-sm-client.c:751] xfce_sm_client_set_state(): state change: DISCONNECTED -> REGISTERING The program 'xfce4-panel' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 398 error_code 8 request_code 1 minor_code 0) (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.) xfce4-panel-wrapper-CRITICAL **: Wrapper systray-6: Could not get owner of name 'org.xfce.Panel': no such name. aborting...
I've just pushed a commit to print debug info about colormaps and visual, could you attach the output of the panel with PANEL_DEBUG=display-layout?
Created attachment 3473 xsession-errors with PANEL_DEBUG=display-layout
Created attachment 3483 xsession-errors of a correct positioning with PANEL_DEBUG=display-layout This is the content of .xsession-errors after a successful positioning of the panels at log in time.
Compared both files and there are no differences when it comes to colormaps, screen settings and positioning. Only strange thing is that composite-changed is triggered by Gtk even while compositing is disabled. I've added a change in master to skip the redraw part (which might confuse the system) unless it really changed and the colormap crash should also be fixed.
(In reply to comment #33) > Compared both files and there are no differences when it comes to colormaps, > screen settings and positioning. Only strange thing is that composite-changed > is triggered by Gtk even while compositing is disabled. I've added a change in > master to skip the redraw part (which might confuse the system) unless it > really changed and the colormap crash should also be fixed. Success report: I have similar setup (NVidia dual screen, not compositing) as the OP and similar problem. With stock 4.8.1, all panels started on screen 0 and trying to start on screen 1 or move a panel to screen 1 crashed xfce4-panel. Tried git-head and it fixed the problem. Seems like: http://git.xfce.org/xfce/xfce4-panel/commit/?id=7bd1028804d7f5ffa7dc7994d7104a02375a0bc2 might have been the solution.
Also updated to master HEAD and seems to have fixed the problem (at least for the last 2 log in)
Good, but lets wait a couple of more logins ;-).
(In reply to comment #36) > Good, but lets wait a couple of more logins ;-). And it failed with the login of this morning :-(
Created attachment 3617 idle showing window I'm thinking about committing a patch to idle showing the panel window to avoid flickering (seems to help here), maybe this influences this bug too.
Created attachment 3656 Wait for window manager Another attempt to fix this. I've added some code to wait until the window manager is initialized.
Master has some improvements regarding this.
I had the same problem on a 3 screen setup (no Xinerama/Twinview/or similar) and can confirm that the attached patch from Nick (comment #39) fixed it for me! :-) BTW: Is there a reason why the patch didn't make it into 4.8.5? (I'm currently running 4.8.5 and cherry picked commit 4e14f27) For the record, here's a debug run. Notice the new "No window manager registered on screen 0" message, indicating that the fix detects the problem: xfce4-panel(module-factory): reading /usr/share/xfce4/panel/plugins xfce4-panel(module-factory): reading /usr/share/xfce4/panel-plugins xfce4-panel: No window manager registered on screen 0. To start the panel without this check, run with --disable-wm-check. xfce4-panel(base-window): 0x7fa3338a4010: rgba colormap=0x7fa3338956b0, compositing=false xfce4-panel(base-window): 0x7fa3338a4010: rgba colormap=0x7fa3338956b0, compositing=false xfce4-panel(base-window): 0x7fa3338a4010: rgba colormap=0x7fa333895730, compositing=false xfce4-panel(display-layout): 0x7fa3338a4010: display=:0.0{comp=true}, screen-0[0x7fa333866be0]=[2560,1600] (monitor-0=[0,0;2560,1600]), screen-1[0x7fa33386e6e0]=[1200,1600] (monitor-0=[0,0;1200,1600]), screen-2[0x7fa33386fb40]=[1024,768] (monitor-0=[0,0;1024,768]) xfce4-panel(positioning): 0x7fa3338a4010: screen=0x7fa33386e6e0, monitors=1, output-name=screen-1, span-monitors=false, base=595,1584 xfce4-panel(positioning): 0x7fa3338a4010: working-area: screen=0x7fa33386e6e0, x=0, y=0, w=1200, h=1600 xfce4-panel(struts): 0x7fa3338a4010: bottom=31, start_x=0, end_x=1199 xfce4-panel(applicationsmenu): XDG_MENU_PREFIX is set to "xfce-" xfce4-panel(module): new item (type=object-type, name=applicationsmenu, id=7) xfce4-panel(module): new item (type=object-type, name=launcher, id=14) xfce4-panel(module): new item (type=object-type, name=launcher, id=15) xfce4-panel(module): new item (type=object-type, name=tasklist, id=10) xfce4-panel(module): new item (type=object-type, name=pager, id=17) xfce4-panel(module): new item (type=object-type, name=actions, id=9) xfce4-panel(external): register dbus path /org/xfce/Panel/Wrapper/12 xfce4-panel(module): new item (type=external-wrapper, name=datetime, id=12) xfce4-panel(external): datetime-12: child spawned; pid=19930, argc=8 xfce4-panel(external): register dbus path /org/xfce/Panel/Wrapper/11 xfce4-panel(module): new item (type=external-wrapper, name=systray, id=11) xfce4-panel(external): systray-11: child spawned; pid=19932, argc=8 xfce4-panel(base-window): 0x7fa3338a4280: rgba colormap=0x7fa3338956b0, compositing=false xfce4-panel(base-window): 0x7fa3338a4280: rgba colormap=0x7fa3338956b0, compositing=false xfce4-panel(display-layout): 0x7fa3338a4280: display=:0.0{comp=true}, screen-0[0x7fa333866be0]=[2560,1600] (monitor-0=[0,0;2560,1600]), screen-1[0x7fa33386e6e0]=[1200,1600] (monitor-0=[0,0;1200,1600]), screen-2[0x7fa33386fb40]=[1024,768] (monitor-0=[0,0;1024,768]) xfce4-panel(positioning): 0x7fa3338a4280: screen=0x7fa333866be0, monitors=1, output-name=screen-0, span-monitors=false, base=1158,1584 xfce4-panel(positioning): 0x7fa3338a4280: working-area: screen=0x7fa333866be0, x=0, y=0, w=2560, h=1600 xfce4-panel(struts): 0x7fa3338a4280: bottom=31, start_x=0, end_x=2559 xfce4-panel(applicationsmenu): XDG_MENU_PREFIX is set to "xfce-" xfce4-panel(module): new item (type=object-type, name=applicationsmenu, id=1) xfce4-panel(module): new item (type=object-type, name=directorymenu, id=2) xfce4-panel(module): new item (type=object-type, name=tasklist, id=5) xfce4-panel(module): new item (type=object-type, name=pager, id=6) xfce4-panel(module): new item (type=object-type, name=actions, id=4) xfce4-panel(external): datetime-12: child is embedded; 4 properties in queue xfce4-panel(systray): registered manager on screen 1 xfce4-panel(external): systray-11: child is embedded; 4 properties in queue xfce4-panel(main): terminate panel for session manager xfce4-panel(application): saving /panels/panel-0, save-plugins=true xfce4-panel(application): saving /panels/panel-1, save-plugins=true xfce4-panel(external): datetime-12: plugin unrealized; quiting child xfce4-panel(external): systray-11: plugin unrealized; quiting child xfce4-panel(application): finalized
Did you also picked e3e6be1c591c8e9cce625722866a1c7b129ecdfd that patch waits for another wm atom.
No, but it makes sense now that you say it. I've now checked out xfce4-panel-4.8.5, then cherry picked 4e14f27 and e3e6be1. Again, I can confirm it works fine and fixes the issue for me. :-) The later patch (e3e6be1) makes the panel appear much faster. Thanks!
Nick, a more complete patch to solve this problem follows. My previous answer was incorrect, the regression is back with e3e6be1. So I've looked a bit further and saw that you use the atom WM_S0 instead of _NET_WM_CM_S0. Funny enough: waiting for _NET_WM_CM_S0 worked all the time just because it takes so long ;-)
Created attachment 3748 Wait for window manager on all screens Wait for the window manager on all screens instead of only on screen 0. This patch applies on top of: xfce4-panel-4.8.5 + 4e14f27 + e3e6be1 (in that order)
_NET_WM_CM_S0 is not registered if compositing is disabled. I agree with your patch, however could you let me know how many times "wm_ready = FALSE;" is reached? So something like: wm_ready = FALSE; g_message ("Screen %d is not ready", i); break;
Using this: for (i = 0; i < wfwm->atom_count; i++) if (XGetSelectionOwner (wfwm->dpy, wfwm->atoms[i]) == None) { panel_debug (PANEL_DEBUG_APPLICATION, "screen %d is not ready", i); wm_ready = FALSE; //break; } else { panel_debug (PANEL_DEBUG_APPLICATION, "screen %d is ready", i); } ... I get the follwing output in 3 test runs. Notice that run 1 was with cold caches, i.e. after echo 3 > /proc/sys/vm/drop_caches. So this test shows what usually happens on first login (loading the panel is slow enough to give the window manager enough time, which is probably always the case in single head setups) [1] xfce4-panel(application): screen 0 is ready xfce4-panel(application): screen 1 is ready xfce4-panel(application): screen 2 is ready xfce4-panel(application): found window manager after 1 tries [2] xfce4-panel(application): screen 0 is not ready xfce4-panel(application): screen 1 is not ready xfce4-panel(application): screen 2 is not ready xfce4-panel(application): screen 0 is ready xfce4-panel(application): screen 1 is ready xfce4-panel(application): screen 2 is ready xfce4-panel(application): found window manager after 2 tries [3] xfce4-panel(application): screen 0 is not ready xfce4-panel(application): screen 1 is not ready xfce4-panel(application): screen 2 is not ready xfce4-panel(application): screen 0 is ready xfce4-panel(application): screen 1 is ready xfce4-panel(application): screen 2 is ready xfce4-panel(application): found window manager after 2 tries What is interesting here is that they are either all ready or not ready. I don't think you can rely on that (as it clearly did not work for me waiting for WM_S0 only). I guess the XGetSelectionOwner() query for the first screen is slow enough to give the others time to reach the same state. Another idea could be to just wait for the last screen, implying that X and the WM grab them sequentially, resulting in "all screens ready if the last one is". But I'm not sure this would not create a new door for race conditions...
Created attachment 3749 Wait for window manager on all screens v2 Updated patch matching the rest of your code (i.e. using g_malloc and g_free ...).
Created attachment 3750 Wait for window manager on all screens v3 You patch uses incorrect string allocation (the g_snprintf buffer is static, so all *atom_names are "WM_S3"). The g_messages leak, but that's just for testing.
Thanks. Here are the results: [1] (cold caches) xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 ready xfce4-panel-Message: WM_S2 ready xfce4-panel(application): found window manager after 14 tries [2] xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 ready xfce4-panel-Message: WM_S2 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 ready xfce4-panel-Message: WM_S2 ready xfce4-panel(application): found window manager after 2 tries [3] xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 ready xfce4-panel-Message: WM_S2 NOT ready xfce4-panel-Message: WM_S0 ready xfce4-panel-Message: WM_S1 ready xfce4-panel-Message: WM_S2 ready xfce4-panel(application): found window manager after 2 tries So now it starts to make sense :-)
Pushed in 9a2407b.
Created attachment 3751 Wait for wm on all screens for 4.8 branch JF, could your try the attached patch (against 4.8 or use master)? If it works for you as well, it can be applied in the 4.8 branch too.
I'm recompiling master, I'll try next time I log in.
Addressing JF is bit ambiguous here ;) But anyways, since Jean-François is testing master, I tested the patch again for the 4.8 branch: [1] (cold caches) xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): found window manager after 6 tries [2] xfce4-panel(application): window manager not ready on screen 1 xfce4-panel(application): window manager not ready on screen 2 xfce4-panel(application): found window manager after 3 tries [3] xfce4-panel(application): window manager not ready on screen 2 xfce4-panel(application): found window manager after 2 tries Looks good and still works fine here. Thanks again! BTW: During all these test runs, the desktop failed to load sometimes (background and icons) on random screens. As noted in #xfce-dev, this could be something simliar?
(In reply to comment #54) > BTW: During all these test runs, the desktop failed to load sometimes > (background and icons) on random screens. As noted in #xfce-dev, this could be > something simliar? I often experience that problem of the desktop not loading (I also have some troubles with the GTK theme that is not correctly loaded on one of my two monitors).
Jean-François, I've filed separate bugs for these problems: xfdesktop starts too fast in multi-screen setups (same as here): https://bugzilla.xfce.org/show_bug.cgi?id=7769 xfwm4 loses settings for random screens in multi screen setup: https://bugzilla.xfce.org/show_bug.cgi?id=7770 Perhaps you can add some info too. Thanks :)
(In reply to comment #53) > I'm recompiling master, I'll try next time I log in. Worked nicely this morning, there is no more wait time before seeing the panels appear on both screens.
(In reply to comment #57) > (In reply to comment #53) > > I'm recompiling master, I'll try next time I log in. > > Worked nicely this morning, there is no more wait time before seeing the panels > appear on both screens. Nice, but lets wait a week before making conclusions ;-).
And JF, any issues? Or does it still work as expected.
(In reply to comment #59) > And JF, any issues? Or does it still work as expected. None, as far as the panel is concerned it works like a charm. For the desktop I still experience some issues but that is the object of an other bug report. IMO you can close this one.
Ok thanks for testing (a long time). Applied in 4.8 in cabbdfd.