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 580103 - Terminal starts on Display :0.0 when started on :0.1 in Dual screen conf
Terminal starts on Display :0.0 when started on :0.1 in Dual screen conf
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 579387 581502 585846 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-24 11:03 UTC by Vincent Gerris
Modified: 2009-09-30 16:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Fix to glib is_env() function. (591 bytes, patch)
2009-05-29 19:49 UTC, Greg
none Details | Review

Description Vincent Gerris 2009-04-24 11:03:01 UTC
Please describe the problem:
The Gnome Terminal and several other programs start on the wrong screen.
When creating a link to it on screen 1, that also appears on screen 0.
It seems to be cause by a bug in gnome-panel.

Steps to reproduce:
1. configure dual screen X (nvidia seperate X screens)
2. start Terminal from the second screen
3. voila, it will start on the first screen (for my setup)


Actual results:
The Terminal opens on the wrong screen

Expected results:
see it on screen where it was started

Does this happen every time?
yes

Other information:
seems to be related to gnome-panel bug.
When I type export DISPLAY=:0.1 in a started terminal and then type gnome-terminal , it will start on the second screen.
Comment 2 Christian Persch 2009-04-24 11:08:53 UTC
Since this does work if DISPLAY is set correctly, it is not a gnome-terminal bug.
You already recognised this ("It seems to be cause by a bug in gnome-panel.") so why did you file this against gnome-terminal ?

Possibly the panel launchers aren't setting the DISPLAY variable correctly.

Please specify the exact version of gnome-panel you use.

Moving -> gnome-panel for further triage.

Comment 3 Vincent Gerris 2009-04-24 11:19:43 UTC
Using gnome-panel:

GNOME gnome-panel 2.26.0

It also happens when a link is on the desktop, so not sure if it is only in the panel.
If you need any more info, please ask.
Using Ubuntu 9.04 by the way.
Comment 4 Gavin Robertson 2009-04-30 19:23:16 UTC
I can confirm this, additionally,

It is not limited to gnome-terminal but all panel items:

menu items and panel launchers, exceptions see below

some notification area items, e.g. volume control: left click on icon - slider on wrong screen, right click on icon and select open volume control - opens on correct screen.

some panel applets, although some behave correctly e.g. system monitor applet will open the system monitor application on the correct screen when using its menu.

The run application dialogue sets the DISPLAY variable correctly so applications launched from it open on the correct screen.

Menu Items/Panel Launchers that use a script to launch i.e. a shell is invoked first have the DISPLAY variable set correctly so open on the correct screen.

Another oddity which might help in tracking down this problem:

on the second screen (DISPLAY=:0.1) right click on a panel launcher,
select properties,
- properties dialogue opens on wrong screen (DISPLAY=:0.0)
leave properties dialogue open on wrong screen,
right click on the same panel launcher, select properties again,
- dialogue closes on wrong screen and opens on correct screen (DISPLAY=:0.1)
((much weirdness))

You do not need to export DISPLAY=:0.1 in gnome-terminal as the original reporter suggested, if you have gnome-terminal (via run dialogue) open on any screen the DISPLAY variable is correct.

Ubuntu 9.04 - gnome-panel 2.26.0

This did not happen with the previous versions of gnome-panel
Comment 5 Davidux 2009-05-06 07:29:55 UTC
I confirm this as well, happened to me with a new install of Ubuntu 9.04; 8.04 and 8.10 were working fine.

I have a thread as well on the Ubuntu forum:
http://ubuntuforums.org/showthread.php?t=1137206

Notice that some applications like Firefox and Open Office open on the correct screen.
Comment 6 Hagen Moelle 2009-05-06 07:57:01 UTC
I confirm the errors reported by Gavin and Davidux. I updated my system from Ubuntu 8.10 to Ubuntu 9.04 (gnome-panel 2.26.0).

But the problem is not limited to the gnome-panel. When I right-click on the desktop of screen1 and create a new directory/document the object will be put on screen1. So far so good, but if you right-click on the desktop of screen1 and create a new "starter" the object will be put on screen0.
Comment 7 Frédéric Delanoy 2009-05-06 16:53:43 UTC
I have exactly the same issue: everything opened on screen 1 displays on screen 0 (but firefox and openoffice, maybe others) in jaunty (gnome 2.26.1).
Alt-F2 + <command> displays it in the right place, though.

I had the same problem (but *only* for nautilus file manager) in intrepid (gnome 2.24.sthg), so this is definitely a regression IMHO
Comment 8 Frédéric Delanoy 2009-05-06 16:57:46 UTC
(In reply to comment #7)
> I have exactly the same issue: everything opened on screen 1 displays on screen
> 0 (but firefox and openoffice, maybe others) in jaunty (gnome 2.26.1).
> Alt-F2 + <command> displays it in the right place, though.
> 
> I had the same problem (but *only* for nautilus file manager) in intrepid
> (gnome 2.24.sthg), so this is definitely a regression IMHO
> 

And, BTW, I use no desktop effects at all. I'm also using NVIDIA driver v180.
Comment 9 L Johnson 2009-05-06 18:34:50 UTC
This is happening on amd64 upgrade from 8.10 to 9.04.

Comment 10 L Johnson 2009-05-07 15:43:25 UTC
Is there any work-around for this, it really hampers my work?
Comment 11 Hagen Moelle 2009-05-07 15:50:13 UTC
You can use the run application dialog "Alt+F2" to start an application on screen1. It is annoying but works.
Comment 12 Greg 2009-05-07 16:22:05 UTC
Just a thought: This could also be a gnome-session-manager bug.  It all depends on where gnome applications get their display information from when launched from the gnome panel.

Someone (I'm not volunteering (yet)) can probably produce a hacked version of gnome-terminal that would dump some debug information to a file about exactly which GTK call this bad terminal information is coming from.  However, I'm unwilling up upgrade to Ubuntu 9.04 on my main machine to do the test run because this bug is a show-stopper, so someone else would have to run the code to get the real debug output.
Comment 13 L Johnson 2009-05-07 16:25:04 UTC
Thanks for the suggestion Hagen but it doesn't work...

http://bugzilla.gnome.org/show_bug.cgi?id=581765
Comment 14 Brian J. Murrell 2009-05-07 17:17:39 UTC
I wonder why this bug seems to be full of "me too"s and whatnot and no real analysis by any gnome developers.

Is this happening on all gnome 2.26 based distros or is it isloated to Ubuntu?
Comment 15 Davidux 2009-05-07 18:30:40 UTC
(In reply to comment #10)
> Is there any work-around for this, it really hampers my work?
> 

From fooman on Ubuntu forums:

------

if you cannot get to a terminal on that screen, try installing "nautilus-open-terminal"...that will give you the ability to right-click on the secondary screen's desktop (or anywhere in nautilus) and choose "open in terminal" from the context menu.

to install it....open a terminal on the main screen and run this command:

Code:

sudo apt-get install nautilus-open-terminal

after it installs, log-out and back in again. when you get back to the desktops, you should be able to right-click on screen 2, choose "open in terminal" and open the app from there...it should then open on screen 2.

hope that helps.

-------

I tested it and it works...
Comment 16 L Johnson 2009-05-07 18:40:55 UTC
Davidux

Works!

Thanx--

 
Comment 17 Frédéric Delanoy 2009-05-08 09:18:05 UTC
(In reply to comment #15)
> (In reply to comment #10)
<...>
> 
> if you cannot get to a terminal on that screen, try installing
> "nautilus-open-terminal"...that will give you the ability to right-click on the
> secondary screen's desktop (or anywhere in nautilus) and choose "open in
> terminal" from the context menu.
> 
> to install it....open a terminal on the main screen and run this command:
> 
> Code:
> 
> sudo apt-get install nautilus-open-terminal
> 
> after it installs, log-out and back in again. when you get back to the
> desktops, you should be able to right-click on screen 2, choose "open in
> terminal" and open the app from there...it should then open on screen 2.
> 
The problem of course is that nautilus opens on screen 1... so...
Comment 18 Davidux 2009-05-08 09:21:40 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #10)
> <...>
> > 
> > if you cannot get to a terminal on that screen, try installing
> > "nautilus-open-terminal"...that will give you the ability to right-click on the
> > secondary screen's desktop (or anywhere in nautilus) and choose "open in
> > terminal" from the context menu.
> > 
> > to install it....open a terminal on the main screen and run this command:
> > 
> > Code:
> > 
> > sudo apt-get install nautilus-open-terminal
> > 
> > after it installs, log-out and back in again. when you get back to the
> > desktops, you should be able to right-click on screen 2, choose "open in
> > terminal" and open the app from there...it should then open on screen 2.
> > 
> The problem of course is that nautilus opens on screen 1... so...
> 

of course, but you can still right click on the second screen desktop and open there a terminal to launch the other programs; in any case this is only a quick fix, i hope that the gnome people will correct this bug soon
Comment 19 paul c 2009-05-08 17:50:23 UTC
(In reply to comment #14)
> I wonder why this bug seems to be full of "me too"s and whatnot and no real
> analysis by any gnome developers.
> 
I hope this bug is looked at.  Just another note that may help pin point the issue in gnome panel or session mgmt:  When I open a remote desktop connection to ":0.1", it displays a cascading loop of my desktop on ":0.0".  I really need this working since I use VNC to access my second screen which is in a remote location.

Comment 20 L Johnson 2009-05-19 19:40:04 UTC
Possible duplicate http://bugzilla.gnome.org/show_bug.cgi?id=581502
Comment 21 L Johnson 2009-05-21 12:58:53 UTC
Is anything going to be done about this?
Comment 22 Greg 2009-05-28 15:03:28 UTC
In Ubuntu, I got someone to get me info on the actual call made from gnome-panel.  This looks like a glib2.0 bug.  I have appended my comment to the Ubuntu board below:


Actually, this helps a lot.

What this tells us is that this is actually a bug in glib2.0 function g_app_info_launch_uris().

The bug occurs when this is launched with a context including a screen with gdk_screen_make_display_name(screen)=":0.1" but the parent process has DISPLAY=":0.0"

Here is a snippet of the relevent code sequence in gnome-panel:

...
        gdk_app_launch_context_set_screen (context, screen);
        gdk_app_launch_context_set_timestamp (context, timestamp);

        local_error = NULL;
        retval = g_app_info_launch_uris (appinfo, uris,
                                         (GAppLaunchContext *) context,
...
Comment 23 Greg 2009-05-29 19:49:18 UTC
Created attachment 135573 [details] [review]
Fix to glib is_env() function.

The problem is that the DISPLAY environment variable is not getting replaced correctly.  This fixes the compare function that is not finding the old value.
Comment 24 Greg 2009-05-29 20:06:45 UTC
Someone please change the product to glib, as the problem is not in gnome-panel.  See my attached patch.

Thank you.
Comment 25 Greg 2009-06-08 17:25:58 UTC
Just thought I'd note that 3 individuals on the Ubuntu defect that feeds this have noted that the patch fixes their problem.

I'd sure love to help move things along, but I don't know how beyond providing a working patch.

Thanks!



It might help to change the title to something that looks like glib, such as:

g_app_info_launch_uris() fails to replace the DISPLAY environment variable correctly.
Comment 26 Matthias Clasen 2009-06-08 18:07:01 UTC
You will have to explain your patch a little better than 'naughty equals usage'
What are the strings that are passed into is_env that cause this to fails ?
Comment 27 Greg 2009-06-08 19:59:23 UTC
I'd be happy to explain the patch.  The comment is just on why I added an equals checker where one wasn't really needed.

is_env is supposed to compare two strings, looking for a match.  Here is how it is used:

The first string (a) is a line in an environment, such as:
DISPLAY=:0

The second string (b) is a name for an environment variable, such as:
DISPLAY

The original patch would loop and return true if all of the characters *including* a trailing equals matched.  This would work if (b) was of the format: "DISPLAY=" but that didn't match the usage.  I decided to let usage win, as the changes required to other code would be more ugly.

Here is a detailed analysis of the changes.  All of my newer comments are enclosed in /*:...*/

   while (*a == *b)
   {
/*: Return false if string b has an '=' in it.  If string b contains an equals then the format of string b (based on usage) is bad.  Returning FALSE seems safer.  However this change could be removed, see below.*/
-    if (*a == 0 || *b == 0)
+    if (*a == 0 || *b == 0 || *b == '=') /* cover naughty equals usage. */
       return FALSE;
/*: The existing code returns TRUE if the first '=' character in string b matches the '=' in string a.  The correct trailing character in string b based on usage is 0.  It might be safe to leave this as-is and remove the change above, but the function is not used that way.*/
-
-    if (*a == '=')
-      return TRUE;

     a++;
     b++;
   }
/*: THIS IS THE IMPORTANT CHANGE: The correct final state based on usage is for the '=' in string a to match the 0 at the end of string b.  This will fall-thru and return FALSE if string b and the variable name portion of string a are of different lengths.*/
+  if (*a == '=' && *b == 0)
+    return TRUE;
+


I hope this explains the reason for each of the changes.

Thanks!
Comment 28 Vincent Gerris 2009-06-09 06:39:44 UTC
How can I check if this patch works?
I cannot derive from this information what code to patch where.
Is there a simple howto anywhere?
I'd be happy to test this.

Thanks for your efforts and especially Greg, thanks for the patch.
I hope it will be put upstream soon.
Comment 29 Frédéric Delanoy 2009-06-09 16:25:24 UTC
I tested the patch in Jaunty i386, and it worked for me.
Comment 30 Frédéric Delanoy 2009-06-09 16:32:57 UTC
(In reply to comment #28)
> How can I check if this patch works?
> I cannot derive from this information what code to patch where.
> Is there a simple howto anywhere?
> I'd be happy to test this.
> 
> Thanks for your efforts and especially Greg, thanks for the patch.
> I hope it will be put upstream soon.
> 

I don't know which distribution you're using, but to test it, you've basically to
download the source codeof glib2 (+ potential dependencies), apply the patch, recompile, create a package and update the system with the new package.

You could also compile the glib2.0 and replace the system's libgio shared lib with the newly compiled one (of course, take backups before...).


Comment 31 Charlie Brej 2009-06-10 14:36:45 UTC
Definitely is a problem in Fedora 11. The patch does fix the issue.

In Fedora to apply the patch run the following as root:

yum install rpmdevtools gamin-devel
yumdownloader --source glib2
rpm -Uvh glib2-2.20.1-1.fc11.src.rpm
rpmbuild -bi rpmbuild/SPECS/glib2.spec
cd ~/rpmbuild/BUILD/glib-2.20.1
patch -i /path/to/the_patch.patch          # enter "gio/gdesktopappinfo.c"
make install
Comment 32 L Johnson 2009-06-10 16:31:09 UTC
I got mixed results with this patch, some app opened in the correct screen and some did not.

Ubuntu 8.10 amd64.
Comment 33 Matthias Clasen 2009-06-11 01:57:06 UTC
Fixed differently in git master.
Comment 34 L Johnson 2009-06-11 14:11:04 UTC
(In reply to comment #32)
> I got mixed results with this patch, some app opened in the correct screen and
> some did not.
> 
> Ubuntu 8.10 amd64.
> 

Should be 9.04 amd64
Comment 35 Greg 2009-06-11 16:18:29 UTC
(In reply to comment #33)
> Fixed differently in git master.

I looked at the fix.

While I generally agree with your new methodology, I think your "unsetenv" calls in child_setup should be removed.  If the calling program calls with a context not including a screen, we should fail gracefully and display on whatever the DISPLAY environment variable was already set to.  As written the launched app will crash because DISPLAY environment variable is not set.

Here are my recommended changes:

static void
child_setup (gpointer user_data)
{
  ChildSetupData *data = user_data;

  if (data->display)
    g_setenv ("DISPLAY", data->display, TRUE);
-  else
-    g_unsetenv ("DISPLAY");

  if (data->sn_id)
    g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
-  else
-    g_unsetenv ("DESKTOP_STARTUP_ID");
}

For a final result of:
static void
child_setup (gpointer user_data)
{
  ChildSetupData *data = user_data;

  if (data->display)
    g_setenv ("DISPLAY", data->display, TRUE);

  if (data->sn_id)
    g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
}


NOTE: I'm less sure about DESKTOP_STARTUP_ID, but DISPLAY definitely should not be cleared in the environment if not set in the calling context.
Comment 36 Matthias Clasen 2009-06-11 16:40:44 UTC
I was just trying to keep the existing behaviour of replace_env_var (ie clearing it if NULL is passed as the value). 

But now that you mention it, I missed the fact that replace_env_var was not even called for NULL...
Comment 37 Vincent Untz 2009-06-15 21:39:02 UTC
*** Bug 581502 has been marked as a duplicate of this bug. ***
Comment 38 Vincent Untz 2009-06-20 17:44:34 UTC
*** Bug 585846 has been marked as a duplicate of this bug. ***
Comment 39 Vincent Untz 2009-06-20 17:46:03 UTC
*** Bug 579387 has been marked as a duplicate of this bug. ***
Comment 40 Vincent Gerris 2009-08-14 07:23:22 UTC
Thanks to midnightflash and keepitsimpleengr, here are some pretty nice instructions to get it fixed for Ubuntu 9.04/

Thanks TJ for patching and anyone who helped.

https://answers.launchpad.net/ubuntu/+source/glib2.0/+question/77380

It worked for me, thank you all for your support!
Comment 41 Brian J. Murrell 2009-08-20 00:19:58 UTC
(In reply to comment #35)
> 
> I looked at the fix.
> 
> While I generally agree with your new methodology, I think your "unsetenv"
> calls in child_setup should be removed.  If the calling program calls with a
> context not including a screen, we should fail gracefully and display on
> whatever the DISPLAY environment variable was already set to.  As written the
> launched app will crash because DISPLAY environment variable is not set.

I think this is what is making evolution fail to open attachments in X apps.

> Here are my recommended changes:
> 
> static void
> child_setup (gpointer user_data)
> {
>   ChildSetupData *data = user_data;
> 
>   if (data->display)
>     g_setenv ("DISPLAY", data->display, TRUE);
> -  else
> -    g_unsetenv ("DISPLAY");
> 
>   if (data->sn_id)
>     g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
> -  else
> -    g_unsetenv ("DESKTOP_STARTUP_ID");
> }

Did this ever land in glib or will the next release of many distros now be broken where evolution wants to spawn other applications that require a $DISPLAY set?
Comment 42 Brian J. Murrell 2009-08-20 00:26:09 UTC
(In reply to comment #41)
> 
> Did this ever land in glib or will the next release of many distros now be
> broken where evolution wants to spawn other applications that require a
> $DISPLAY set?

To answer my own question, it seems it did according to http://git.gnome.org./cgit/glib/tree/gio/gdesktopappinfo.c#n851

I wish I knew how to find the specific commit from the above reference.  Oh well.
Comment 43 Dindon 2009-09-30 16:04:05 UTC
I confirm that the update worked for me.

I find that after the update occurs the following behavior:

Applications like Chromium, Opera and others (NOT Firefox) appears that use "gnome-open" to open the downloaded files and launch links as "mailto:".
Failure occurs and the files and applications are not opened by the system.

Case 1:
1.- Launch Opera or Chromium.
2.- Download a file.
3.- Try open the file with the download manager.
3.- Nothing happens.

Case 2:
1.- Launch Opera or Chromium.
2.- Click on a link with "mailto:"
3.- Nothing happens.

If I run the applications (Chromium or Opera) in a terminal I can view the following error when I try to open a pdf file:
 (acroread:5958): Gtk-WARNING **: " cannot open display:    "

It is the same error as if I launch in a terminal "gnome-open":

 user@computer :~$ gnome-open anyfile.pdf
 user@computer :~$ (acroread:5958): Gtk-WARNING **: cannot open display:

Could be confirmed if the same applies to you.