app_to_run not working in recent 1.4 server
I compiled the latest 1.4 servers on snow leopard since they contain some fixes over the apple installed server. The server starts fine by either double-clicking it or by executing an application that uses the X server. The only thing that doesn't work (in the apple48 and apple49 servers) is that the app listed in the app_to_run no longer runs. I have app_to_run set as an xterm so that I have a terminal when the server starts. In bundle-main.c: if(argc == 1 || (argc == 2 && !strncmp(argv[1], "-psn_", 5))) { /* Now, try to open a display, if so, run the launcher */ display = XOpenDisplay(NULL); if(display) { /* Could open the display, start the launcher */ XCloseDisplay(display); return execute(command_from_prefs("app_to_run", DEFAULT_CLIENT)); } } The XOpenDisplay call is returning a null display, so the app_to_run is never run. Is this the only place where the app_to_run is executed from? I don't know if this works with the latest 1.5 server because I haven't upgraded the necessary X11 protos to compile the server. I probably should just create a script in .xinitrd.d to run my default startup app anyway. Thanks, Martin
On Oct 2, 2009, at 08:53, Martin Otte wrote:
I compiled the latest 1.4 servers on snow leopard since they contain some fixes over the apple installed server. The server starts fine by either double-clicking it or by executing an application that uses the X server.
The only thing that doesn't work (in the apple48 and apple49 servers) is that the app listed in the app_to_run no longer runs. I have app_to_run set as an xterm so that I have a terminal when the server starts. In bundle-main.c:
if(argc == 1 || (argc == 2 && !strncmp(argv[1], "-psn_", 5))) { /* Now, try to open a display, if so, run the launcher */ display = XOpenDisplay(NULL); if(display) { /* Could open the display, start the launcher */ XCloseDisplay(display);
return execute(command_from_prefs("app_to_run", DEFAULT_CLIENT)); } }
The XOpenDisplay call is returning a null display,
If that's the case, then DISPLAY is not set to a value it expects. What happens when you just execute (from Terminal)? /Applications/Utilities/X11.app/Contents/MacOS/X11.bin There should be output that mentions why it's not working. Do you have 2.4.1_alpha1 installed on your system? If so, that would be why X11.app isn't using that path. XQuartz.app owns DISPLAY when both are installed.
so the app_to_run is never run. Is this the only place where the app_to_run is executed from?
The behavior is to only execute app_to_run if you're starting X11.app by double clicking and it owns the launchd socket...
I don't know if this works with the latest 1.5 server because I haven't upgraded the necessary X11 protos to compile the server.
It's working here on 1.4 through master... I'd recommend keeping /usr/X11 the way it's shipped from Apple unless you want to get possibly clobbered. That's why we're using /opt/X11 for the MacOSForge.org releases.
Hi, The problem was that I didn't update xinit along with the x server, so the DISPLAY variable that was being set in the LaunchAgent was wrong. Your most recent changes were not in the 1.1.1 xinit release that I was using. Now the app_to_run works again. Two other minor points: 1) In any app that starts from a script in ~/.xinitrc.d, the DISPLAY is set to :0.0. All other applications have the correct DISPLAY (/tmp/ launch-*:0) I can verify this behaviour with the 2.4.0 release too on a Leopard machine. Is xinit setting a custom DISPLAY for apps that it launches? 2) In 1.4.2-apple49, my custom .Xmodmap is not being used at startup (or probably it is being overwritten after it is read by xinit). This was working in the previous apple47 server that I was using. Thanks, Martin On Oct 2, 2009, at 2:03 PM, Jeremy Huddleston wrote:
On Oct 2, 2009, at 08:53, Martin Otte wrote:
I compiled the latest 1.4 servers on snow leopard since they contain some fixes over the apple installed server. The server starts fine by either double-clicking it or by executing an application that uses the X server.
The only thing that doesn't work (in the apple48 and apple49 servers) is that the app listed in the app_to_run no longer runs. I have app_to_run set as an xterm so that I have a terminal when the server starts. In bundle-main.c:
if(argc == 1 || (argc == 2 && !strncmp(argv[1], "-psn_", 5))) { /* Now, try to open a display, if so, run the launcher */ display = XOpenDisplay(NULL); if(display) { /* Could open the display, start the launcher */ XCloseDisplay(display);
return execute(command_from_prefs("app_to_run", DEFAULT_CLIENT)); } }
The XOpenDisplay call is returning a null display,
If that's the case, then DISPLAY is not set to a value it expects. What happens when you just execute (from Terminal)?
/Applications/Utilities/X11.app/Contents/MacOS/X11.bin
There should be output that mentions why it's not working.
Do you have 2.4.1_alpha1 installed on your system? If so, that would be why X11.app isn't using that path. XQuartz.app owns DISPLAY when both are installed.
so the app_to_run is never run. Is this the only place where the app_to_run is executed from?
The behavior is to only execute app_to_run if you're starting X11.app by double clicking and it owns the launchd socket...
I don't know if this works with the latest 1.5 server because I haven't upgraded the necessary X11 protos to compile the server.
It's working here on 1.4 through master...
I'd recommend keeping /usr/X11 the way it's shipped from Apple unless you want to get possibly clobbered. That's why we're using / opt/X11 for the MacOSForge.org releases.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Oct 2, 2009, at 14:45, Martin Otte wrote:
Hi,
The problem was that I didn't update xinit along with the x server, so the DISPLAY variable that was being set in the LaunchAgent was wrong. Your most recent changes were not in the 1.1.1 xinit release that I was using. Now the app_to_run works again.
But it should fall back on using ":0" if it doesn't get "org.x.X11:0" http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.4-apple&id=... I bet I'm unsetting DISPLAY in bundle_main.c if it doesn't match the BundleIdentifier ... I might need to add a case to accept just "/:0" as well... or just push out a new xinit release and depend on that...
Two other minor points:
1) In any app that starts from a script in ~/.xinitrc.d, the DISPLAY is set to :0.0. All other applications have the correct DISPLAY (/ tmp/launch-*:0) I can verify this behaviour with the 2.4.0 release too on a Leopard machine. Is xinit setting a custom DISPLAY for apps that it launches?
Yeah... that's by design. That's the easiest way to guarantee it will work for all startup paths of X11. There might be another option, but there's nothing inherently broken with this behavior. You're just following a different path into the server.
2) In 1.4.2-apple49, my custom .Xmodmap is not being used at startup (or probably it is being overwritten after it is read by xinit). This was working in the previous apple47 server that I was using.
Yeah... that's an old bug that is just now more prevalent. A bit about that... With the xkb config files in place (xkeyboard-config), our keymap gets trashed by XKB. We've skirted this issue by simply not including these files in our releases and deleting them when they are present (they snuck in during a 2.4.0 alpha I think). 1.7 now requires XKB... meaning that if they're not present, the server fails to start. The easiest solution was to put them in place, let XKB do its thing, then trash its mappings. As a side note, XKB is ugly, messy, and getting rewritten... hopefully things will be better in 1.8... We can probably execute xmodmap after updating the keymap to pull in custom updates. This has always been a bug, but nobody ever bothered to complain about it. If you had "Follow System Keymap" enabled and switched keymaps, your customizations would be nuked. Please open tickets about this one, so I don't forget. --Jeremy
participants (2)
-
Jeremy Huddleston
-
Martin Otte