Hi, I recently found that Xephyr 1.6.3 will fail to embed to other window (-parent) if a -screen XxY resolution is specified at the same time. This was working in 1.4.2 but was broken after upgrade to 1.6.3. The following GTK simple program can be used to reproduce the issue. After you run this program, use the following command line to embed will fail: $ Xephyr :1 -parent <window-id> -screen 640x480 However, this still works: $ Xephyr :1 -parent <window-id> Since I need to specify the resolution in my application, this breaks the application's functionality entirely after upgrade to 1.6.3. /************ testxephyr.c *****************/ #include <gtk/gtk.h> #include <stdio.h> static GtkWidget *window, *socket; int main (int argc, char *argv[]) { gtk_init (&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_set_default_size (GTK_WINDOW (window), 640, 480); socket = gtk_socket_new (); gtk_widget_show (socket); gtk_container_add (GTK_CONTAINER (window), socket); gtk_widget_show (window); g_print ("socket id:%i\n", gtk_socket_get_id (GTK_SOCKET (socket))); gtk_main (); return 0; }
Verified with 1.7.
Sorry, hit submit too early. With 1.7, Xephyr seems to hang when trying to displaying xterm. The command doesn't fail directly though. And the normal Xephyr window still opens (is it supposed to?)
Yes. when I said it failed, I actually mean Xephyr failed to embed to the parent window. The Xephyr command does not crash actually, but it creates a new window and start acting very weird; things look messy and after a while it could freeze. Sorry for the confusion, I didn't describe the exact behavior in the first post. Vic
Hi, I think I found the root cause of the issue. In case of -parent and -screen arguments are provided at the same time, Xephyr actually creates two screens, one embed into the existing window, the other creates a new window (which is incorrect and causing other issues like hanging). I also found the bug is probably in a function ddxProcessArgument in ephyrinit.c. It will call processScreenArg() twice, one for -parent and the other for -screen, which results in two screens. Can these two parameters combined into a single processScreenArg() call? int ddxProcessArgument (int argc, char **argv, int i) { .......... if (!strcmp (argv[i], "-parent")) { if(i+1 < argc) { processScreenArg ("100x100", argv[i+1]); return 2; } UseMsg(); exit(1); } else if (!strcmp (argv[i], "-screen")) { if ((i+1) < argc) { processScreenArg (argv[i+1], NULL); return 2; } UseMsg(); exit(1); } .........
The screen argument seems superfluous as Xephyr will scale to the size of the embedding window. Any particular reason you're specifying it?
Yes, I understand I can resize to root window without -screen argument to workaround the problem, and Xephyr knows to scale itself. But then I lost an important feature, to assign the color depth. Because as far as I know the -screen argument is the only way to assign color depth. Besides that, in my real GTK+ application the situation is far more complex. It's a GtkSocket inside a scrolled window, which is inside a tabbed notebook, then a GtkWindow. When I was with Xephyr 1.4, I don't have to take care of that, because once Xephyr get embed, the GtkSocket will reallocate its size, then user can scroll the window if the application window is smaller.
Created attachment 29916 [details] [review] 0001-ephyr-if-parent-is-given-check-for-a-trailing-screen.patch How does this one look like? It allows multiple -screen arguments and multiple -parent arguments as well, provided -screen always follows -parent.
I tried to apply this patch on 1.6.4, compile Xephyr myself and test with my application. It works fine! Really appreciate your quick action on this bug. Any chance getting this patch into both 1.6 and 1.7 branches?
Pushed as 19be992d9dc542b61fa3f4fd32a09071c9e64880, nominated for 1.7 and 1.6. Thanks for testing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.