| Summary: | xwayland displays no output | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | deron <xinzhou208> |
| Component: | weston | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | darxus, xinzhou208 |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
the weston and xorg running log
Re-enable assigning output for surface of type none |
||
I think I'm seeing the same thing. Are you by any chance using nouveau drivers? That's what I'm using. A possible explanation: http://lists.freedesktop.org/archives/wayland-devel/2012-March/002770.html "I'd guess this is related to a change in shell to not map surfaces with type none. A quick grep shows that nothing calls wl_shell_surface_set_toplevel() in xwayland or the X window manager in weston." I thinks so; when i set the surface of x client as the top-level, the client can be show; but there are still a lot of work need to do when using the rootless Xorg; deron: Patch? Please? Created attachment 59183 [details] [review] Re-enable assigning output for surface of type none It's possible you can temporarily get xwayland to work by reverting weston commit de56c311d94e6df37537b9e05ec72863906902ff . Patch to do this attached. 21:45 < Darxus> Sounds like it could be fixed with one wl_shell_surface_set_toplevel() line somewhere? 21:49 < krh> yea, but we want the X wm to handle that 21:57 < krh> the X wm is in src/xserver-launcher,c in weston 21:57 < krh> that needs to talk to wl_shell 21:57 < krh> but they're both inside weston, so we need a little bit of glue to make the talk 2012-03-31: 07:57 < timon37> krh: hello, i'm trying to make a radeon driver for xwayland, and the radeon portion went reasonably well, now i'm trying to update xwayland to do wl_shell_get_shell_surface etc. 07:58 < timon37> and i'm wondering if i'm not duplicating something you've already done but didn't publish 08:00 < timon37> or if you could help me a bit, i'm getting a crash with a fairly useless backtrace and have very few ideas how to find what's missing 08:05 < timon37> heh it's probably breaking in the backtrace printer itself, so the stack is probably corrupted:/ 09:38 < krh> timon37: cool 09:39 < krh> timon37: the idea is that won want the X server to know about ewmh and icccm protocols 09:39 < krh> but have an X wm that can talk to X and read out ewmh properties like window type, title, icon etc and convert that to the corresponding wayland window types 09:40 < krh> for weston, that wm is actually in process, in xserver-launcher.c 09:40 < krh> and the trick is to get that to call into shell.c to get the shell surface and set the properties on it Tiago: Thanks for the link, I mostly came here to add it. This is apparently working again: http://lists.freedesktop.org/archives/wayland-devel/2012-April/003092.html There's still a fair amount of breakage in XWayland, but this bug - no output at all, is fixed. More info posted to the same thread I linked to in the previous comment. Tested commits: xserver * xwayland-1.12 801b0e4 xwayland: Disable screensaver extension under xwayland xf86-video-wlshm (requires s/hosted.h/xwayland.h/) * master 036c6cf wlshm: fix pixmap issues in rooted mode xf86-video-ati/ * master 3dec9f9 whateva Not tested because I don't have the hardware: xf86-video-intel * xwayland-1.12 9b93914 Add xwayland support I still get no output but it's possibly a problem on my end since it seems to work for everyone else. Still investigating. |
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.
Created attachment 57786 [details] the weston and xorg running log my steps: 1, run the weston ./weston 2, run the rootless Xorg ./Xorg -rootless -wayland :2 3, run the xterm export DISPLAY=:2 xterm the Xorg can run, but the xterm or other x client can not display in the weston; and the error occurs when i update the weston and wayland protocol last week; the attachment files have the log;