Summary: | "Xephyr -parent window-id -screen XxY" fails entirely | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Vic Lee <llyzs> | ||||
Component: | Server/DDX/Xephyr | Assignee: | Peter Hutterer <peter.hutterer> | ||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
Severity: | critical | ||||||
Priority: | medium | CC: | llyzs, peter.hutterer | ||||
Version: | git | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 23613 | ||||||
Attachments: |
|
Description
Vic Lee
2009-09-24 22:43:28 UTC
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.