GNOME Bugzilla – Bug 773629
Add support for using EGLDevice as an alternative to GBM, and EGLStream based wl_buffers
Last modified: 2021-07-05 13:47:50 UTC
This bug is about adding support for EGLDevice based rendering, as an alternative to GBM. This is currently needed to make Nvidia cards working when using the proprietary driver. The main patch adding support is 'MetaRendererNative: Add EGLDevice based rendering support'. GBM is always attempted first, and using EGLDevice second. This bug is also about adding support for EGLStream based Wayland clients. See the 'wayland: Add support for EGLStream client buffers' commit message for a short description about how it works, and the patch itself for details. Note that the EGLDevice/EGLStream based paths will eventually be replaced with the cross vendor allocator API <https://github.com/cubanismo/allocator/>, in combination with gbm or something else. Currently tested with Nvidia driver 367.35 and 370.28. It doesn't seem to work at all with 375.10 (both the patch weston and mutter with these patches). Currently known issues (with 367.35 and 370.28): * Exiting a client causes mutter to segfault somewhere in the nvidia driver lib (from the glDeleteTextures() call). * VT switching while a client is drawing is prone to a race condition resulting in it being impossible to VT switch back. This is because the V-Sync callbacks behaving differently from the KMS ones. The spec is a bit unclear, and I'm reaching out in order to figure out a non-hacky solution. * mutter segfaults also somewhere in the nvidia driver lib on exit To enable the EGLDevice code path, the to be attached initial patches require one to add --enable-egl-device to ./configure.
Created attachment 338683 [details] [review] MetaBackendNative: Initialize GError pointer Initialize the GError pointer used when creating the renderer. If an error occurs, the error is expected to be NULL, otherwise it'll misinterpreted as already set.
Created attachment 338684 [details] [review] Add EGL abstraction class MetaEgl Add a MetaEgl meant to deal with EGL. It is intended to be use by EGL based renderers and handle extension symbols loading, handle errors etc.
Created attachment 338685 [details] [review] MetaRendererNative: GLib:ify a few Cogl types In another step getting rid of the duplications introduced by Cogl, use the equivalent GLib types where Cogl types previously used. While CoglBool is not a typedef to gboolean, they are both typedefs to int, and we already use GLib's TRUE/FALSE to set them.
Created attachment 338686 [details] [review] MetaRendererNative: Get EGLDisplay on init Use MetaEgl to get the EGLDisplay on initialization; use that when constructing the Cogl renderer.
Created attachment 338687 [details] [review] MetaLauncher: Remember the KMS file path Not only keep the KMS fd around, also remember the file path used. This will later be used when initializing a EGLDevice based renderer.
Created attachment 338688 [details] [review] MetaEgl: Add EGL extensions support Add proc symbol loading and helper functions for calling them, dealing with errors etc. So far no extension symbols are loaded, only the infrastructure is there.
Created attachment 338689 [details] [review] MetaEgl: Add eglGetPlatformDisplayEXT helper Prepare a helper function for the more reliable way to get a platform display.
Created attachment 338690 [details] [review] MetaRendererNative: Put gbm related things in an anonymous struct In order to separate gbm related fields from generic ones, put them in anonymous structs.
Created attachment 338691 [details] [review] MetaRendererNative: Put gbm initialization in its own function Separate gbm initialization from general renderer initialization. Do this even though no other initialization is done for now; later there will will be other types of rendering mode, initialized in their own functions.
Created attachment 338692 [details] [review] MetaRendererNative: Use pbuffer surface as dummy surface Lets use a pbuffer surface as a dummy surface instead of a gbm based one, so that we don't need to rely on the availability of gbm to create a dummy surface when there is no need for it.
Created attachment 338693 [details] [review] backends/native: Pass KMS file path to renderer The KMS file path will later be used for EGLDevice based rendering.
Created attachment 338694 [details] [review] MetaRendererNative: Log error reason when failing to create gbm device
Created attachment 338695 [details] [review] MetaRendererNative: Always use eglGetPlatformDisplay Drivers may be bad at guessing what is passed to eglGetDisplay, ending up return non-functioning EGLDisplay's. Using eglGetPlatformDisplay avoids this issue.
Created attachment 338696 [details] [review] cogl: Make platforms set the EGL_SURFACE_TYPE Cogl has no way to know how to properly set the surface type, so lets outsource that to the platform layer.
Created attachment 338697 [details] [review] MetaCursorRendererNative: Fall back to texture when there is no gbm For when there is no gbm available, for example when using EGLDevice/EGLStream's, just fall back to the OpenGL texture based cursor rendering path.
Created attachment 338698 [details] [review] MetaOnscreenNative: Make flip waiting state more generic Use a boolean to keep track whether a flipped event is pending or not, and use that instead of looking at the framebuffer id field.
Created attachment 338699 [details] [review] MetaRendererNative: Warn instead of wait when swapping flip in progress A swap-buffers should never be issued when we are waiting for a flipped callback, so instead of trying to handle a situation that sholud never happen, warn instead.
Created attachment 338700 [details] [review] egl: Add eglInitialize helper
Created attachment 338701 [details] [review] MetaRendererNative: Add helper for getting the next framebuffer id
Created attachment 338702 [details] [review] MetaOnscreenNative: Allocate for real after cogl_framebuffer_allocate There is no way to pass any backend specific parameters to a CoglFramebuffer until after it has been allocated by cogl_framebuffer_allocate() (since this is where the winsys/platform fields are initialized). This can make it hard to actually allocate anything, if the platform depends on some backend specific data. A proper solution would be to refactor the onscreens and framebuffers to use a GObject based type system instead of the home baked Cogl one, but that'll be left for another day. For now, allocate in two steps, one to allocate the backend specific parts (MetaOnscreenNative), and one to allocate the actual onscreen framebuffer (via meta_onscreen_native_allocate()). So far there is nothing that forces this separation, but in the future there will, for example EGLDevice's need to know about the CRTC in order to create the EGLSurface.
Created attachment 338703 [details] [review] configure.ac: Add option to enable EGLDevice based rendering This does nothing so far.
Created attachment 338704 [details] [review] MetaEgl: Add EGL procs necessary for EGLDevice based rendering
Created attachment 338705 [details] [review] MetaRendererNative: Add EGLDevice based rendering support This commit adds support for using a EGLDevice and EGLStreams for rendering on top of KMS instead of gbm. It is disabled by default; to enable it pass --enable-egl-device to configure. By default gbm is first tried, and if it fails, the EGLDevice path is tried. If both fails, mutter will terminate just as before.
Created attachment 338706 [details] [review] egl: Allow passing NULL as error When calling an EGL function is expected to sometimes fail, we might not care about the error.
Created attachment 338707 [details] [review] cogl: Expose API for creating texture from EGLImage Later to be used by mutter to create EGLImage's from Wayland buffers.
Created attachment 338708 [details] [review] egl: Add helpers for importing Wayland buffers as EGLImage's
Created attachment 338709 [details] [review] wayland: Make MetaWaylandBuffer handle texture generation itself Don't rely on the Cogl layer having Wayland specific paths by determining the buffer type and creating the EGLImage ourself, while using the newly exposed CoglTexture from EGLImage API. This changes the API used by MetaWaylandSurface to make the MetaWaylandBuffer API be aware when the buffer is being attached. For SHM and EGL buffers, only the first time it is attached will result in a new texture being allocated, but later for EGLStream's, more logic on every attach is needed.
Created attachment 338710 [details] [review] wayland: Add support for EGL_WAYLAND_Y_INVERTED_WL Add support for inverted Y Wayland buffers. OpenGL textures are by default inverted, so adding support for EGL_WAYLAND_Y_INVERTED_WL effectively means adding support for non-inverted, which makes the MetaShapedTexture apply a transformation when drawing only when querying EGL_WAYLAND_Y_INVERTED_WL resulted in the response "EGL_FALSE".
Created attachment 338711 [details] [review] MetaSurfaceActorWayland: Remove API never used externally anymore
Created attachment 338712 [details] [review] MetaShapedTexture: Add support for setting a custom CoglSnippet To support special types of buffer types, add support for setting a CoglSnippet on the shaped texture which will then be added to the pipeline.
Created attachment 338713 [details] [review] cogl: Add support for creating custom EGL based textures Add API to enable the caller to have a custom method for allocating an external texture. This will enable the possibility for mutter to generate a texture from for example an EGLStream without having to add support for that in Cogl.
Created attachment 338714 [details] [review] egl: Add vfuncs needed for client EGLStream surfaces
Created attachment 338715 [details] [review] wayland: Add support for EGLStream client buffers This commit adds for a new type of buffer being attached to a Wayland surface: buffers from an EGLStream. These buffers behave very differently from regular Wayland buffers; instead of each buffer reperesenting an actual frame, the same buffer is attached over and over again, and EGL API is used to switch the content of the OpenGL texture associated with the buffer attached. It more or less side-tracks the Wayland buffer handling. It is implemented by creating a MetaWaylandEglStream object, dealing with the EGLStream state. The lifetime of the MetaWaylandEglStream is tied to the texture object (CoglTexture), which is referenced-counted and owned by both the actors and the MetaWaylandBuffer. When the buffer is reattached and committed, the EGLStream is triggered to switch the content of the associated texture to the new content. This means that one cannot keep old texture content around without copying, so any feature relying on that will effectively be broken.
Also available as a branch here: https://github.com/jadahl/mutter/commits/wip/egldevice
Review of attachment 338695 [details] [review]: ::: src/backends/native/meta-renderer-native.c @@ +1260,3 @@ + if (!meta_egl_has_extensions (egl, EGL_NO_DISPLAY, NULL, + "EGL_KHR_platform_gbm", This should be EGL_MESA_platform_gbm.
Review of attachment 338705 [details] [review]: ::: src/backends/native/meta-renderer-native.c @@ +1870,3 @@ + "EGL_EXT_device_query", + "EGL_EXT_device_enumeration", +#endif These are rather implicitly guaranteed by "EGL_EXT_device_base" (if I understand correctly), so this #if and comment is probably wrong.
I left some comments on github. Overall this is looking good, and I think you can start pushing to master even with the problems you mention and iron things out as more people get the chance to test this.
Pushed the current patches with some changes: Some review issues raised by rtcm were fixed, fixed an old bug where a discarded framebuffer was marked as current, changed the cogl API for allocating external EGL images. Leaving the bug open for now, there'll probably be more patches. The mentioned issues still exist, but will hopefully be resolved either in mutter or in the driver, depending on where the issue actually is. Note that due to how the driver uses wl_surface.attach and wl_surface.commit, some EGL clients using xdg_shell will not work due to the unsupported usage of wl_surface.attach and wl_surface.commit. See https://bugs.freedesktop.org/show_bug.cgi?id=98731 . To enable, pass --enable-egl-device to ./configure Attachment 338683 [details] pushed as 7fa3f41 - MetaBackendNative: Initialize GError pointer Attachment 338684 [details] pushed as 22f0198 - Add EGL abstraction class MetaEgl Attachment 338685 [details] pushed as 8b81019 - MetaRendererNative: GLib:ify a few Cogl types Attachment 338686 [details] pushed as cde622b - MetaRendererNative: Get EGLDisplay on init Attachment 338687 [details] pushed as 4547c6e - MetaLauncher: Remember the KMS file path Attachment 338688 [details] pushed as 80c61c4 - MetaEgl: Add EGL extensions support Attachment 338689 [details] pushed as 87d6e45 - MetaEgl: Add eglGetPlatformDisplayEXT helper Attachment 338690 [details] pushed as 678ebbb - MetaRendererNative: Put gbm related things in an anonymous struct Attachment 338691 [details] pushed as f7cd6af - MetaRendererNative: Put gbm initialization in its own function Attachment 338692 [details] pushed as da1c1d9 - MetaRendererNative: Use pbuffer surface as dummy surface Attachment 338693 [details] pushed as 77b7ecf - backends/native: Pass KMS file path to renderer Attachment 338694 [details] pushed as 4ce7d3a - MetaRendererNative: Log error reason when failing to create gbm device Attachment 338695 [details] pushed as da21f02 - MetaRendererNative: Always use eglGetPlatformDisplay Attachment 338696 [details] pushed as 8f71677 - cogl: Make platforms set the EGL_SURFACE_TYPE Attachment 338697 [details] pushed as 68d6902 - MetaCursorRendererNative: Fall back to texture when there is no gbm Attachment 338698 [details] pushed as 59b4b5e - MetaOnscreenNative: Make flip waiting state more generic Attachment 338699 [details] pushed as cb6adc4 - MetaRendererNative: Warn instead of wait when swapping flip in progress Attachment 338700 [details] pushed as 78c121e - egl: Add eglInitialize helper Attachment 338701 [details] pushed as faa9644 - MetaRendererNative: Add helper for getting the next framebuffer id Attachment 338702 [details] pushed as b1597b4 - MetaOnscreenNative: Allocate for real after cogl_framebuffer_allocate Attachment 338703 [details] pushed as f692eb3 - configure.ac: Add option to enable EGLDevice based rendering Attachment 338704 [details] pushed as b735bdc - MetaEgl: Add EGL procs necessary for EGLDevice based rendering Attachment 338705 [details] pushed as 934184e - MetaRendererNative: Add EGLDevice based rendering support Attachment 338706 [details] pushed as 18b9cf8 - egl: Allow passing NULL as error Attachment 338707 [details] pushed as ecc1f56 - cogl: Expose API for creating texture from EGLImage Attachment 338708 [details] pushed as 659c987 - egl: Add helpers for importing Wayland buffers as EGLImage's Attachment 338709 [details] pushed as 2345598 - wayland: Make MetaWaylandBuffer handle texture generation itself Attachment 338710 [details] pushed as 41c9692 - wayland: Add support for EGL_WAYLAND_Y_INVERTED_WL Attachment 338711 [details] pushed as 11783ff - MetaSurfaceActorWayland: Remove API never used externally anymore Attachment 338712 [details] pushed as 7c31fb2 - MetaShapedTexture: Add support for setting a custom CoglSnippet Attachment 338713 [details] pushed as 1f0ce80 - cogl: Add support for creating custom EGL based textures Attachment 338714 [details] pushed as f5bdf75 - egl: Add vfuncs needed for client EGLStream surfaces Attachment 338715 [details] pushed as eed4dab - wayland: Add support for EGLStream client buffers
I think wayland isn't working on driver 375.10 since it just falls back to Xorg (That or I don't know how to start wayland). Also everything in the X session is flipped now. http://i.imgur.com/RbWHG1n.jpg
Created attachment 340200 [details] [review] MetaShapedTexture: Default to y-inverted being true Normally textures in OpenGL are inverted on the Y axis, and we only apply our rotation transform when it is not. To make the common case work as normal, default to assuming textures are Y inverted. ---- (In reply to Hussam Al-Tayeb from comment #39) > I think wayland isn't working on driver 375.10 since it just falls back to > Xorg (That or I don't know how to start wayland). > I never managed to get it running with 375.10, but as far as I know, the next version of the driver will fix that particular issue. > > Also everything in the X session is flipped now. > http://i.imgur.com/RbWHG1n.jpg The patch attached should fix the issue.
(In reply to Jonas Ådahl from comment #40) > Created attachment 340200 [details] [review] [review] > MetaShapedTexture: Default to y-inverted being true > > Normally textures in OpenGL are inverted on the Y axis, and we only > apply our rotation transform when it is not. To make the common case > work as normal, default to assuming textures are Y inverted. > > The patch attached should fix the issue. It does. Things are in the correct direction now. Thank you :)
Comment on attachment 340200 [details] [review] MetaShapedTexture: Default to y-inverted being true Attachment 340200 [details] pushed as 5774fcd - MetaShapedTexture: Default to y-inverted being true
(In reply to Jonas Ådahl from comment #42) > Comment on attachment 340200 [details] [review] [review] > MetaShapedTexture: Default to y-inverted being true > > Attachment 340200 [details] pushed as 5774fcd - MetaShapedTexture: Default > to y-inverted being true That fixed the inverted issue, but I tried both on 375.10 (that you already confirmed it doesn't work) and with 370.28 that doesn't work either. It doesn't let you login on Wayland. There is actually another bug here. The first time on GDM screen, it allows you pick Wayland and login, but it actually logins on X. When you logout and try relog from GDM, Wayland menu wont let you login (which is the normal behavior) These patches are supposed to let us use Wayland with NVIDIA, right?
(In reply to Jonas Ådahl from comment #0) > This bug is about adding support for EGLDevice based rendering, as an > alternative to GBM. This is currently needed to make Nvidia cards working > when > using the proprietary driver. The main patch adding support is > 'MetaRendererNative: Add EGLDevice based rendering support'. GBM is always > attempted first, and using EGLDevice second. > > This bug is also about adding support for EGLStream based Wayland clients. > See > the 'wayland: Add support for EGLStream client buffers' commit message for a > short description about how it works, and the patch itself for details. > > Note that the EGLDevice/EGLStream based paths will eventually be replaced > with > the cross vendor allocator API <https://github.com/cubanismo/allocator/>, in > combination with gbm or something else. > > Currently tested with Nvidia driver 367.35 and 370.28. It doesn't seem to > work > at all with 375.10 (both the patch weston and mutter with these patches). > > Currently known issues (with 367.35 and 370.28): > > * Exiting a client causes mutter to segfault somewhere in the nvidia driver > lib > (from the glDeleteTextures() call). > * VT switching while a client is drawing is prone to a race condition > resulting > in it being impossible to VT switch back. This is because the V-Sync > callbacks behaving differently from the KMS ones. The spec is a bit > unclear, > and I'm reaching out in order to figure out a non-hacky solution. > * mutter segfaults also somewhere in the nvidia driver lib on exit > > > To enable the EGLDevice code path, the to be attached initial patches require > one to add --enable-egl-device to ./configure. Hi, I built the latest commit of mutter (5774fcdd8001b9e15b417b765472245345e934fb) with --enable-egl-device and I'm running the new 375.20 driver from NVIDIA on Arch Linux with the 4.8.8 Kernel (w/o CONFIG_HARDENED_USERCOPY, which was introduced in 4.8, because it stops Wayland from working with NVIDIA [1]). The only thing that keeps me from using this as my daily driver is that in the Wayland session I can't put my monitor into standby. When I press Ctrl+L to lock the session the screen goes dark, but the monitor never turns off and moving the mouse or pressing keys doesn't wake the system back up. When I inspect the system with ssh I can't find a coredump of mutter only a calltrace related to the nvidia driver in dmesg, but the messages are older than the moment when I tried to enter standby with my monitor. I'm not sure if that's related to one of the issues you already pointed out. [1] https://devtalk.nvidia.com/default/topic/974491/linux/gtx-580-375-10-weston-eglstream-produces-crash-in-kernel/
(In reply to t.jp from comment #44) > (In reply to Jonas Ådahl from comment #0) > > This bug is about adding support for EGLDevice based rendering, as an > > alternative to GBM. This is currently needed to make Nvidia cards working > > when > > using the proprietary driver. The main patch adding support is > > 'MetaRendererNative: Add EGLDevice based rendering support'. GBM is always > > attempted first, and using EGLDevice second. > > > > This bug is also about adding support for EGLStream based Wayland clients. > > See > > the 'wayland: Add support for EGLStream client buffers' commit message for a > > short description about how it works, and the patch itself for details. > > > > Note that the EGLDevice/EGLStream based paths will eventually be replaced > > with > > the cross vendor allocator API <https://github.com/cubanismo/allocator/>, in > > combination with gbm or something else. > > > > Currently tested with Nvidia driver 367.35 and 370.28. It doesn't seem to > > work > > at all with 375.10 (both the patch weston and mutter with these patches). > > > > Currently known issues (with 367.35 and 370.28): > > > > * Exiting a client causes mutter to segfault somewhere in the nvidia driver > > lib > > (from the glDeleteTextures() call). > > * VT switching while a client is drawing is prone to a race condition > > resulting > > in it being impossible to VT switch back. This is because the V-Sync > > callbacks behaving differently from the KMS ones. The spec is a bit > > unclear, > > and I'm reaching out in order to figure out a non-hacky solution. > > * mutter segfaults also somewhere in the nvidia driver lib on exit > > > > > > To enable the EGLDevice code path, the to be attached initial patches require > > one to add --enable-egl-device to ./configure. > > Hi, > > I built the latest commit of mutter > (5774fcdd8001b9e15b417b765472245345e934fb) with --enable-egl-device and I'm > running the new 375.20 driver from NVIDIA on Arch Linux with the 4.8.8 > Kernel (w/o CONFIG_HARDENED_USERCOPY, which was introduced in 4.8, because > it stops Wayland from working with NVIDIA [1]). > The only thing that keeps me from using this as my daily driver is that in > the Wayland session I can't put my monitor into standby. When I press Ctrl+L > to lock the session the screen goes dark, but the monitor never turns off > and moving the mouse or pressing keys doesn't wake the system back up. When > I inspect the system with ssh I can't find a coredump of mutter only a > calltrace related to the nvidia driver in dmesg, but the messages are older > than the moment when I tried to enter standby with my monitor. I'm not sure > if that's related to one of the issues you already pointed out. > > [1] > https://devtalk.nvidia.com/default/topic/974491/linux/gtx-580-375-10-weston- > eglstream-produces-crash-in-kernel/ Are you able to wake the system with the 375.20 driver when using X? I'm on Arch with Linux 4.9.2 (for some reason. I also tested 4.8) and cannot properly wake from suspend with the 375.20 drivers. It may not be Wayland related. Then again, who knows what else I've broken.
Sorry, that's Linux 4.9-rc2. I'm not a time traveler.
What I'm talking about is not putting the PC into suspended mode. I'm talking about the monitor entering standby mode. That works in X11, but not on Wayland. I haven't used suspend that often, but it looks like my PC can't wake from that regardless of session, too. This doesn't seem related, though. Try switching to nouveau and if that fixes it file a bug with NVIDIA.
Strange I thought that my PC didn't resume from suspend in both sessions, but in the Xorg session it works, while on the GNOME Wayland session it doesn't. Even more strange is that in the patched Weston version it works...kind of. So I'm not sure if the problem is in Mutter or the driver. I reported it here: https://devtalk.nvidia.com/default/topic/978289/linux/gtx-580-375-20-suspending-doesn-t-work-with-wayland-compositors/
Created attachment 341656 [details] [review] egl: Use correct proc to meta_egl_stream_consumer_aquire_attrib It should be eglStreamConsumerAcquireAttribNV and not eglStreamConsumerAcquireAttribEXT as the EXT variant is defined in any extension.
Created attachment 341657 [details] [review] MetaRendererNative: Remove unnecessary ifdef
Created attachment 341658 [details] [review] egl: Add EGL_WL_wayland_eglstream helpers Are to replace the file descriptor hack currently in use.
Created attachment 341659 [details] [review] wayland/buffer: Add 'realization' concept to buffers Instead of having a way to determine the type of a buffer, add a realization step that implicitly detects the buffer type. This makes it possible to both realize (i.e. creating needed objects from the buffer) and determine the type at the same time, which may be the only possible way (for example, the only way to know whether a buffer is a EGLStream is to create the EGLStream from it).
Created attachment 341660 [details] [review] wayland/buffer: Remove unnecessary break
Created attachment 341661 [details] [review] MetaWaylandEglStream: Use EGL_WL_wayland_eglstream instead of fd hack Use the proposed EGL_WL_wayland_eglstream EGL extension instead of the file descriptor hack that was used as a temporary solution. Note that this results in EGL clients will no longer work if they are running on a Nvidia driver with a version older than 370. ---- This patch makes changes what versions of the Nvidia driver mutter on Wayland will run on. Before this patch, it'd (probably) work on 364, 367 and 370. After this patch, it'll work on 370 and 375.
Review of attachment 341661 [details] [review]: ::: src/wayland/meta-wayland-egl-stream.c @@ -82,3 @@ } - egl_stream = meta_egl_create_stream_from_file_descriptor (egl, egl_display, stream_fd, This function is now unused, right?
Review of attachment 341656 [details] [review]: In the commit message: "as the EXT variant is (not?) defined..."
Review of attachment 341657 [details] [review]: ok
Review of attachment 341658 [details] [review]: commit message: "(These?) are to replace..." ?
Review of attachment 341659 [details] [review]: looks fine
Review of attachment 341660 [details] [review]: ok
The last series pushed after having the issues reported fixed and amended. Attachment 341656 [details] pushed as 778f92e - egl: Use correct proc to meta_egl_stream_consumer_aquire_attrib Attachment 341657 [details] pushed as 139bed7 - MetaRendererNative: Remove unnecessary ifdef Attachment 341658 [details] pushed as 0a826da - egl: Add EGL_WL_wayland_eglstream helpers Attachment 341659 [details] pushed as 405aa8f - wayland/buffer: Add 'realization' concept to buffers Attachment 341660 [details] pushed as f7fd018 - wayland/buffer: Remove unnecessary break Attachment 341661 [details] pushed as 2df35d6 - MetaWaylandEglStream: Use EGL_WL_wayland_eglstream instead of fd hack
Created attachment 343135 [details] Kernel warning and application crashes On Arch 64bit, 4.8.13 w/o hardened copy protection, nvidia 375.26 and mutter to commit g2df35d636, the kernel is spitting out a lot of warnings and applications like webkit (used to log on accounts in goa) crash. See the attached journal extract, please ask if you think more information would be useful.
Any kernel issues with the nvidia driver should be reported to nvidia. Although i'm not familiar how WebKit deals with multiple processes and texture sharing, it'd be interesting to see a WAYLAND_DEBUG=1 log of the WebKitWebProcess crash.
@jonas I now think it wasn't related to wayland / your patches, sorry for the false alert.
- With nvidia driver 378.09, the crashes on switching VT whilst using wayland are gone. I assume the kernel issues are gone too. - But still opengl applications using xwayland won't run. - Also gnome-shell is constantly using 35% to 38% CPU. Under Xorg session, it's like 3% when idle. - gnome-maps won't start (gnome-maps:2273): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found. - mpv says: [vo/opengl] GLX not found. [vo/opengl] GLX not found. So only two issues for now: 1) No GLX. 2) High CPU usage in gnome-shell.
Arch x86_64 with kernel 4.9.8-1 and the Nvidia driver 378.13 with Mutter 3.23.90-1 here. The wayland session simply won't start when the nvidia driver is installed. Gnome-logs shows the following: Unrecoverable failure in required component org.gnome.Shell.desktop Process 688 (gnome-shell) of user 1000 dumped core. (Log: http://pastebin.com/N6RPytp9 ) When the Nvidia driver is removed, the wayland session works as expected without problems.
@antoine did you build it yourself? if yes, did you rebuild gnome-shell after that?
No, I didn't build it myself, I downloaded it from a repository (https://softwareperonista.com.ar/) whose maintainer did rebuild gnome-shell afterwards seeing as it's on 3.23.90-1 too.
Is the package built with --enable-egl-device configure flag? It won't work if not.
GNOME 3.24 now has landed in Arch and the Wayland session starts fine with the NVIDIA driver. The performance is pretty bad however (see e.g. [1], seems related to EGL/glvnd?). Is this expected or is this a misconfiguration on Arch's part? [1] https://bugs.archlinux.org/task/53284
I found out --enable-egl-device causes this kernel warning a few times a day. NVRM: Xid (PCI:0000:01:00): 41, CCMDs 00000010 0000a0b5 Removing the configure option stopped the kernel warning. I haven't seen it in two days. This is all under a Xorg session.
With fully updated F26 and negativo17 nvidia-driver-381.22-6.fc26.x86_64, wayland fails with gnome-shell[1261]: Can’t initialize KMS backend: could not find drm kms device. If I add “nvidia-drm.modeset=1” to /usr/lib/modprobe.d/nvidia.conf, I will get "Disabling glamor and dri3, EGL setup failed, Failed to initialize glamor, falling back to sw". Wayland will start but in a software rendering mode. ( I am guessing.)
(In reply to askstack from comment #72) > With fully updated F26 and negativo17 nvidia-driver-381.22-6.fc26.x86_64, > wayland fails with gnome-shell[1261]: Can’t initialize KMS backend: could > not find drm kms device. > If I add “nvidia-drm.modeset=1” to /usr/lib/modprobe.d/nvidia.conf, I will > get "Disabling glamor and dri3, EGL setup failed, Failed to initialize > glamor, falling back to sw". Wayland will start but in a software rendering > mode. ( I am guessing.) Fedora hasn't enabled --enable-egl-device in mutter including rawhide and f26 http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/mutter.spec#n117
Thanks, leigh123linux@googlemail.com . Fail to get wayland to start has been bugging me since F26 alpha. Now I know what to look out for.
Hello, please has something changed with today's F26 release perhaps? Is there a way how to enable wayland for fedora with nvidia? thanks
I'm not sure if this is best place to comment but if we have EGLStream XOR GBM than initializing EGLStream might not be best option on laptops as it will probably succeed if external displays are connected but it might not work with internal displays. Ideally it should support both at the same time to work with internal and external displays.
@Jonas I notice that --enable-egl-device is not the default still. From your perspective are things mature enough that maybe it can be set as a default configure option now?
(In reply to Mario Limonciello from comment #77) > @Jonas > > I notice that --enable-egl-device is not the default still. From your > perspective are things mature enough that maybe it can be set as a default > configure option now? I wouldn't say so. The current missing things include monitor mirroring (same content on two monitors), hardware cursors, and there are reports that using multiple monitors causes bad frame rates. The first and third of those issues are not trivial to fix. Regarding hardware cursor support, I can't remember whether that is possible or not. The other issue, although not directly related to GNOME, is that Xwayland doesn't have support for EGLStreams yet (which is being worked on).
Fairly new here, but I found a procedure that fixed this for me: https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/ Not sure if it was because I upgraded drivers during this process, but I'm able to boot into latest kernels now. Sorry, I've forgotten what I was using precisely before, but I believe my Nvidia drivers were in the 384 series before, and now they're 387.34. Was unable to boot into any 4.14 kernels before, but booted into 4.13 just fine. First time I booted after the fix into 4.14, it did flip the screen upside down after a few minutes for s ome reason, but after a reboot, it's been fine.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.