GNOME Bugzilla – Bug 115704
Multi-screen support for notification area is broken
Last modified: 2007-09-23 16:48:58 UTC
I have a dual-head setup, not running Xinerama, so I have a "utility" panel (panels I add tools to) on the bottom of both screens (:0.0 and :0.1) and an "menu/launcher" panel on the top of the second screen (:0.1). If I add a notification area to the panel on screen :0.0 and run applications that use the notification area (xmms with the notification plugin, gaim 0.64) on screen :0.0, everything works fine. If I run a notification on both :0.0 and :0.1 nothing shows up in either notification area no matter which screen I start it on. If I run a notification area on screen :0.1 only, nothing uses it no matter which screen I run it on. In summary, the notification area only works on the panel on screen :0.0 and only for applications started on screen :0.0. Any other combination of use does not work.
*** Bug 118061 has been marked as a duplicate of this bug. ***
Does it work in 2.4 ?
With a notification area (NA) on :0.0 and :0.1, applications started on :0.0 use the NA on :0.0 fine. Applications started on :0.1 do not use the NA of either screen. With a NA on :0.1 only, applications started on either :0.0 or :0.1 do not use the NA. With a NA on :0.0 only, applications started on :0.0 use it fine, but applications started on :0.1 do not.
I've discovered about the same in 2.4 (see #124974). I get the following: 1. If I configure my system with notification area on only screen :0.0 everything works fine. 2. If I configure the system with notification area on only screen :0.1 it doesn't show any icons at all. Instead I get windows on :0.0 with the pictures that should have been in the notification area on :0.1 (attaching screendump on that). 3. It I configure the system with notification areas on both my screens I don't get any icons in any of them, but I get the windows from point 2 above. 4. Furthermore (and I don't know if this is related), if I configure with more than one area in :0.0 only one of them works. My guess is that this is two separate bugs: Firstly, only one area (maybe the first one initialized?) at a time works. Secondly, icons due to show on an area in some other display than :0.0 doesn't understand that, but instead try to show on :0.0, where they are instead shown in windows since their destinated notification area isn't present in that display. Does this make sense?
Created attachment 20820 [details] Dump of the windows I describe in the above comment
I don't use xinerama, but I do have a dual-head setup, so apps can only put windows on the head they are started on. I notice the same, except: If I first start a NA on :0.1 and then on :0.0, they both don't work. If I first start one on :0.0 and then one on :0.1, aps started on :0.0 use the NA on :0.0, but aps on :0.1 don't use any NA and show up on :0.1.
Re-assigning to gnome-panel-maint. Apologies for the spam.
Ouch, sounds terrrible. Upping priority/severity.
According to the comments there, the cause might be bug #125257
There's more than one problem here. The NA is a screen-specific resource. An app using it is responsible for finding the NA for the screen on which the app's icon is created. The app's icon must be on the same screen as the NA. Furthermore, an application must not map its icon's toplevel window. The NA is responsible for reparenting and mapping the toplevel window of an icon. For reparenting to be successful, that window must be on the same screen as the NA's parent window, and must not be under the purview of another application such as the WM. If the icon's toplevel window is mapped while it is still a child of the root window, the window manager will take it over. Thus the NA must map the window only after it has reparented it; i.e., it must have received a ReparentEvent with correct values. Reparenting does not work across screens. Icons appearing on the wrong screen may be caused by failure of either the app or the NA. Apps using GtkPlug shouldn't fail this way unless the programmer mucks with Gtk+ internals. The NA's failure is to map windows it hasn't reparented, such as those on other screens. Fixing the NA won't solve all the problems reported here. Once the NA is fixed, apps contacting the wrong NA will still fail, but at least they won't show free-floating or WM-framed icons - unless the programmer mucks with Gtk+ internals or those internals are broken. Bugs should be filed against those apps with icons which have failed to appear in the correct NA. If there's ever to be a public tray icon API (instead of what's in libegg), it should simplify these screen handling issues and also the icon life-cycle issues which have appeared in other bug reports. (E.g., bug #122391 )
This problem still exists in version 2.6.2
*** Bug 157091 has been marked as a duplicate of this bug. ***
*** Bug 154833 has been marked as a duplicate of this bug. ***
*** Bug 159054 has been marked as a duplicate of this bug. ***
Still a problem in Gnome 2.10.1, NA ver 2.10.1
still a problem in gnome 2.12, glad I found this bug though, system works much better after I removed the NA from the other head ;)
*** Bug 324747 has been marked as a duplicate of this bug. ***
Confirming for Gnome 2.14 under FC5. Any dev's thinking about looking into this? (I love you, if so!) p.s. Can any users experiencing this confirm Bug 321159? (Bug 324772 might also interest you).
In regards to 324747, I'm eager to assist in debugging in anyway you would like Vincent. What would be useful to you specifically?
*** Bug 346162 has been marked as a duplicate of this bug. ***
Created attachment 70519 [details] [review] Patch Can someone seeing this issue compile gnome-panel HEAD with this patch? I believe this should fix the problem, but I have no way to verify...
*** Bug 325328 has been marked as a duplicate of this bug. ***
I've committed the patch to HEAD. I'll mark this bug as NEEDINFO until someone can test the notification area from gnome-panel >= 2.15.92.
I closed the Ubuntu bug - nobody seemed to complain about it again.
Let's close the bug. If someone can reproduce with gnome-panel 2.16.x, please open a new bug.
I'm seeing this in Fedora Core 6 with gnome-panel-2.16.0-4.fc6. My xorg.conf file has Xinerama "off" and Clone "on" in the ServerLayout section. My experience is exactly as described in comment 3. Is it really necessary to open a new bug for this? Can't we just reopen this one?
What kind of graphics card are you using? I only saw this problem using two completely different ones (one nVidia, one SiS) and without Xinerama. This bug originated in FreeBSD (If I remember correctly, starting with 5.4).
I've been hit by this bug (since 2.4) with a non-Xinerama setup on one, dual-head matrox card, not two different video cards. I Can't test 2.16 yet, as it's not in Debian unstable yet.
Chipset: "mgag400" (G450)(In reply to comment #27) > What kind of graphics card are you using? > I only saw this problem using two completely different ones (one nVidia, one > SiS) and without Xinerama. This bug originated in FreeBSD (If I remember > correctly, starting with 5.4). > As seen in dmesg output: matrox_w1 0000:01:00.0: Matrox G400 GPIO transport layer for 1-wire. As seen in Xorg.0.log: Chipset: "mgag400" (G450)
To add to comment 29, lspci shows: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 82)
I've got this bug, too. Ubuntu 6.10 Edgy Eft Linux Kernel: 2.6.17.11-generic Video Card: ATI Radeon X1300 Using ATI Proprietary Drivers Gnome Panel: 2.16.1 Windows created on display 0.1 fail to register to the NA on display 0.1 Works on display 0.0, though.
I have got the same Problem, application launch in second screen do not register in notification area. If I lauch the apps in the First screen it register to the 1st screen notification area. Ubuntu 7.04 beta Feisty Fawn Linuk Kernel : 2.6.20-14-generic 2007 i686 GNU/Linux Video Card : Ati X700 Gnome version 2.18.0
The same problem still exists in 2.6.18. Any progress in this issue,... this takes now for so long.... can't be true that it isn't possible to fix this. Chris.
And still in 2.19 (btw: of course I meant 2.18 in comment # 33). Is anyone actually readin this report? Or even going to fix it?
(btw: this bug hast to be reopenend)
(In reply to comment #34) > And still in 2.19 (btw: of course I meant 2.18 in comment # 33). > Is anyone actually readin this report? Or even going to fix it? I'm reading all comments :-) It'll eventually get fixed, once I get some time. Btw, since you opened bug 346162, there's no need to reopen this bug.
Ok I see,... uhm if you require some help (especially testing) please contact me.