Closed manateelazycat closed 4 years ago
Native wayland support or through xwayland?
Native wayland support or through xwayland?
native support
Native wayland support or through xwayland?
It looks like EAF forces qt to use the xcb backend on wayland displays: https://github.com/manateelazycat/emacs-application-framework/blob/df9da7b600ff21c69c2e6c7af66ddb94573207c6/eaf.el#L1143-L1144
Then QWindow::setParent
arranges the XEmbed connection under the hood using xcb: https://github.com/qt/qtbase/blob/7ee682a1ddc259225618b57ff00f4c36ff5e724c/src/plugins/platforms/xcb/qxcbwindow.cpp#L1239-L1253
So unless I'm misunderstanding something here, I think my point still stands that EAF doesn't work on wayland. Given what I've learned about wayland compositors when I toyed with creating a wlroots based exwm replacement, I'm not sure I see a clean way for EAF to work with wayland since it will have to rely on the compositor behaving well but that may be difficult given the differing behaviors across mutter, kwin, and wlroots based compositors. Of course its hard to know anything concrete without trying, so I'd be happy to be proven wrong!
It looks like EAF forces qt to use the xcb backend on wayland displays: https://github.com/manateelazycat/emacs-application-framework/blob/df9da7b600ff21c69c2e6c7af66ddb94573207c6/eaf.el#L1143-L1144
Then
QWindow::setParent
arranges the XEmbed connection under the hood using xcb: https://github.com/qt/qtbase/blob/7ee682a1ddc259225618b57ff00f4c36ff5e724c/src/plugins/platforms/xcb/qxcbwindow.cpp#L1239-L1253So unless I'm misunderstanding something here, I think my point still stands that EAF doesn't work on wayland. Given what I've learned about wayland compositors when I toyed with creating a wlroots based exwm replacement, I'm not sure I see a clean way for EAF to work with wayland since it will have to rely on the compositor behaving well but that may be difficult given the differing behaviors across mutter, kwin, and wlroots based compositors. Of course its hard to know anything concrete without trying, so I'd be happy to be proven wrong!
EAF can works well on Wayland, we have test it, have you try it?
Sorry I should have been more specific. Yes I've tried and found it works fine on wayland with the usual --with-x
but that means emacs itself is running under xwayland and hence eaf also is running under xwayland. To run emacs natively on wayland you need to compile emacs using the experimental --with-pgtk
. I tested eaf using that and it does not work, giving the error message
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.screen: QXcbConnection: Could not connect to display wayland-0
Could not connect to any X display.
If you don't like Qt or Python, I understand. ;)
I mean that the document should show that EAF can work in Wayland, avoid misunderstanding that EAF can not work under Wayland, regardless of what technology it uses.
@manateelazycat I think you've misunderstood - EAF does not and can not work on wayland without XWayland. While that means it can be used on most wayland compositors, it does not make it wayland native, and on any compositor that doesn't allow XWayland (quite possible!) EAF will fail to work.
I think "can not work on wayland" is perhaps a bit too strong. It may be possible for it to work and my guess is that it would have to be by using the wayland popup window protocol as that's all I could find with respect to wayland offering the concept of a parent window. Perhaps Qt might implement something like that behind the scenes for its QWindow::setParent
call on the wayland qpa platform but when I dug around there I couldn't find anything resembling that capability, although I didn't look too hard. If Qt did this EAF would work for free on pgtk emacs, but as I mentioned before I think this may still be pretty difficult since unlike xorg where you can rely on XEMBED functioning the same across window managers and compositors, it's up to each compositor to define its own implementation that may comply with the xdg spec to varying degrees or with varying quirks.
It's at least pretty clear to me that EAF does not currently run natively on wayland. That's perfectly fine since xwayland won't be going anywhere for awhile, but it does mean it won't be able to take advantage of the improvements in pgtk emacs.
I think "can not work on wayland" is perhaps a bit too strong. It may be possible for it to work and my guess is that it would have to be by using the wayland popup window protocol as that's all I could find with respect to wayland offering the concept of a parent window. Perhaps Qt might implement something like that behind the scenes for its
QWindow::setParent
call on the wayland qpa platform but when I dug around there I couldn't find anything resembling that capability, although I didn't look too hard. If Qt did this EAF would work for free on pgtk emacs, but as I mentioned before I think this may still be pretty difficult since unlike xorg where you can rely on XEMBED functioning the same across window managers and compositors, it's up to each compositor to define its own implementation that may comply with the xdg spec to varying degrees or with varying quirks.It's at least pretty clear to me that EAF does not currently run natively on wayland. That's perfectly fine since xwayland won't be going anywhere for awhile, but it does mean it won't be able to take advantage of the improvements in pgtk emacs.
EAF use Qt's QWindow::setParent instead XLib reparent function. I believe Qt has adapt Wayland and X11, at least in README document should say EAF depend on Qt's implement and not depend on XEmbed protocol directly, because EAF current version not use any XLib/XCB code.
See my first comment where I link to the implementation of QWindow::setParent
on the xcb qpa backend which you force Qt to use in eaf. Qt arranges the xlib reparent for you when you call setParent
which ultimately relies on the xembed protocol. I guess while I'm at it, I'll go ahead and let qt use the wayland backend for eaf and see how it behaves then report back here.
EAF use Qt's QWindow::setParent instead XLib reparent function.
@manateelazycat ,@akirakyle 想表达QWindow::setParent
的源码用了xcb,并且EAF也通过(unless (equal (getenv "WAYLAND_DISPLAY") "") (setenv "QT_QPA_PLATFORM" "xcb"))
来确保qt5用的是xcb。这代表Wayland里EAF是通过XWayland这个backward compatible的方式将x11与wayland强行连接起来了,也就是说如果使用纯native wayland(--with-pgtk
),EAF还是不能运行。
There're probably some confusion in the conversation, hopefully this clears them out.
EAF use Qt's QWindow::setParent instead XLib reparent function.
@manateelazycat ,@akirakyle 想表达
QWindow::setParent
的源码用了xcb,并且EAF也通过(unless (equal (getenv "WAYLAND_DISPLAY") "") (setenv "QT_QPA_PLATFORM" "xcb"))
来确保qt5用的是xcb。这代表Wayland里EAF是通过XWayland这个backward compatible的方式将x11与wayland强行连接起来了,也就是说如果使用纯native wayland(--with-pgtk
),EAF还是不能运行。There're probably some confusion in the conversation, hopefully this clears them out.
我知道,(setenv "QT_QPA_PLATFORM" "xcb") 这个是后面加上的补丁,加之前也是可以在Wayland下运行的。
加之前也是可以在Wayland下运行的
对,但是是通过xwayland运行的(因为QWindow::setParent
技术底层用了xcb)。xwayland让x11程序能在wayland成功运行,而 @akirakyle 的意思是这不是native wayland,所以pgtk emacs就有问题。
现在我们要不想办法绕过QWindow::setParent
支持native wayland,要不等待Qt团队更新这个api。
加之前也是可以在Wayland下运行的
对,但是是通过xwayland运行的(因为
QWindow::setParent
技术底层用了xcb)。xwayland让x11程序能在wayland成功运行,而 @akirakyle 的意思是这不是native wayland,所以pgtk emacs就有问题。现在我们要不想办法绕过
QWindow::setParent
支持native wayland,要不等待Qt团队更新这个api。
其实可以在Wayland下用Native的方法,其他平台用QWindow::setParent.
其实可以在Wayland下用Native的方法
现在需要寻找一个Native的办法 :)
Sorry I can't really follow this conversation effectively as I don't know Chinese (I tried using google translate though). I just tried using emacs --with-pgtk
and (setenv "QT_QPA_PLATFORM" "wayland")
. As I expected, I get that the EAF widget is created in its own window rather then embedded in an emacs buffer. Perhaps the Qt devs will figure out a way to implement QWindow::setParent
on wayland, but as I mentioned before, I don't think this will be easy, or necessarily even possible.
I just realized another issue that EAF would need to overcome to work on wayland, but I can't think of any way it can be solved as it seems to go against wayland's design. EAF currently uses the x11 XID that Emacs reports in the window-id
frame-parameter
. AFAIK there is no equivalent to an XID on wayland as applications shouldn't really be able to identify and tell the compositor to affect another app's windows (yay security?!). Thus emacs --with-pgtk
reports the pointer to the GtkWindow
in window-id
. I don't think there's anything useful Qt could do with this Gtk pointer. The recent bug I fixed (#12) was all about the different window-id
between x
and pgtk
window-systems, but thankfully I can convert an XID to a GtkWindow
pointer on x
, but on wayland the reverse isn't possible.
Sorry I can't really follow this conversation effectively as I don't know Chinese (I tried using google translate though).
No worries, I was just paraphrasing what you were saying to him in Chinese.
I've created a issue manateelazycat/emacs-application-framework#449 dedicated to the continuation discussion of this topic in the EAF repo, as this issue's conversation is becoming more on the specifics of EAF, instead of emacs-webkit itself.
@akirakyle EAF has support Wayland native https://github.com/emacs-eaf/emacs-application-framework/commit/8df41d0058a59affbec19f013b504259305109cc
Don't need XWayland anymore.
pgtk support by https://github.com/emacs-eaf/emacs-application-framework/commit/29a5e56e6e0fdad161bc83064f4f04dbda7d8d59
If you are using Wayland environment, you need update EAF to newest and execute the command cp -r emacs-application-framework/gnome-shell/eaf-wayland@emacs-eaf.org ~/.local/share/gnome-shell/extensions
and activate the Gnome-Shell plugin eaf-wayland@emacs-eaf.org
in Gnome3
Does this support only Gnome Wayland?
EAF has support wayland,I think doc need adjust