While running Mageia Control Center(mcc) over ssh, the mcc menu on the right hand side is always empty, similar to bug 30332. This is true for up to date Mageia 8 and Cauldron systems. However, this is not happening on Mageia 8 with webkit2 versions less than 2.40. Steps to reproduce: 1. # ssh $USER@IP Connect with ssh to a system("ssh 127.0.0.1" will do too) with ssh-server and FowardX11 enabled. 2. # su - i.e. once connected, become root. 3. # mcc Observe the empty right hand side of mcc window. Note: Using "sudo mcc" over ssh will not bring up the graphical interface, but the terminal instance of mcc. Terminal output: " (mcc:64562): dbind-WARNING **: 16:27:02.121: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Ignore the following Glib::Object::Introspection & Gtk3 warnings (drakconf:64563): dbind-WARNING **: 16:27:02.527: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal libEGL warning: DRI3: failed to query the version libEGL warning: DRI2: failed to authenticate (WebKitWebProcess:64597): Gdk-WARNING **: 16:27:03.513: The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 185 error_code 1 request_code 155 (unknown) minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) " Regards, A.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30332
Did some digging and found this bug report originating from Fedora for yelp, which fails in the same manner as mcc over ssh in Cauldron: https://bugs.webkit.org/show_bug.cgi?id=259320 The bug report points to an issue with the mesa llvmpipe driver, the driver that is used for rendering over ssh. # inxi -Gx # over ssh Graphics: Device-1: AMD Navi 23 [Radeon RX 6600/6600 XT/6600M] vendor: Sapphire driver: amdgpu v: kernel arch: RDNA-2 bus-ID: 0d:00.0 Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: amdgpu,v4l dri: swrast gpu: amdgpu s-res: 3840x1200 resolution: 1: 1920x1200 2: 1920x1200 API: OpenGL v: 4.5 Mesa 23.1.5 renderer: llvmpipe (LLVM 15.0.6 256 bits) direct-render: Yes
Thank you for the report, and that Fedora link which does indeed look similar. "REGRESSION(2.41.6): [GTK] Yelp help viewer and Epiphany browser do not show content on a virtual machine (llvmpipe?) with WebKitGTK 2.41.6" It is very recnt: 2023-07-18 - 2023-07-21 It points to webkit: https://commits.webkit.org/266201@main The patch is shown here: https://github.com/WebKit/WebKit/commit/ad44d7bf323c78bd79f184859afb65d107efb103 No one person nurses webkit2, so assigning this globally; CC'ing NicolasS & DavidG who have most recently committed it.
URL: (none) => https://bugs.webkit.org/show_bug.cgi?id=259320Assignee: bugsquad => pkg-bugsCC: (none) => geiger.david68210, nicolas.salguero
Bug 30332 is also about drakconf missing display elements after an earlier update to webkit2 (>=2.36); this bug applies to >=2.41.6. Upping the importance because of its multiple occurrence; do not think it is a duplicate.
Severity: normal => major
CC: (none) => richardwest
https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools also see todays note in Bug 30332
Keywords: (none) => IN_ERRATA9CC: (none) => fri
Not only over ssh. See me in Bug 30332#c42 and https://forums.mageia.org/en/viewtopic.php?f=7&t=15031 and I think I also saw it in a mail list.
Summary: webkit2: drakconf (mcc) over ssh fails to display its menu options on the right hand side. => webkit2: drakconf (mcc) local and over ssh fails to display its icons on the right hand side.
Hello, I'm seeing the bug on a RASPBERRY PI 4B using modesetting as graphical driver, thus on aarch64. All tabs of MCC are blank and inactive.
CC: (none) => yvesbrungard
I have found that while it most often works OK, it may fail several times in a try repeatedly. If i then close other application (s) such as firefox, MCC then works OK. So: Something about resources?
(In reply to Morgan Leijström from comment #7) > I have found that while it most often works OK, it may fail several times in > a try repeatedly. If i then close other application (s) such as firefox, > MCC then works OK. So: Something about resources? I have not seen the behavior you mentioned on my system. However, as you mentioned resources, I tried IceWM with the same results as in the initial report, but, for my surprise, under Plasma - XWayland everything looks peachy. BTW, my initial report was carried out in Plasma - X11, sorry, it does look like I missed to mention it. Regards.
Someone reported another case of missing icons, though with a different log, on dev mailing list: https://ml.mageia.org/l/arc/dev/2023-10/msg00072.html
CC: (none) => animtim
I have a similar issue: I have a freshly installed M9 upgraded to Cauldron based machine - and recently, when I tried to start the MCC, I get the interface but without icons (just the menu on the side) - I tried to de-install and re-install, but that didn't help - looking at the console where I started it - I see some errors related to GBM-Drv - Maybe something to do with the proprietary NVidia drivers? [rfox@FoxLT5 ~]$ sudo mcc perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_DE:de", LC_ALL = (unset), LC_ADDRESS = "de_DE.UTF-8", LC_NAME = "de_DE.UTF-8", LC_MONETARY = "de_DE.UTF-8", LC_PAPER = "de_DE.UTF-8", LC_IDENTIFICATION = "de_DE.UTF-8", LC_TELEPHONE = "de_DE.UTF-8", LC_SOURCED = "1", LC_MEASUREMENT = "de_DE.UTF-8", LC_TIME = "de_DE.UTF-8", LC_NUMERIC = "de_DE.UTF-8", LANG = "en_DE" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. (process:50513): Gtk-WARNING **: 09:58:00.799: Locale not supported by C library. Using the fallback 'C' locale. perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_DE:de", LC_ALL = (unset), LC_MONETARY = "de_DE.UTF-8", LC_NUMERIC = "de_DE.UTF-8", LC_TIME = "de_DE.UTF-8", LANG = "en_DE" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Ignore the following Glib::Object::Introspection & Gtk3 warnings (process:50514): Gtk-WARNING **: 09:58:00.956: Locale not supported by C library. Using the fallback 'C' locale. Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833. (process:50555): Gtk-WARNING **: 09:58:01.483: Locale not supported by C library. Using the fallback 'C' locale. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) Failed to create GBM buffer of size 1513x1201: Invalid argument src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) Failed to create GBM buffer of size 1513x1201: Invalid argument src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) Failed to create GBM buffer of size 1513x1201: Invalid argument Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1
CC: (none) => rfox
Created attachment 14068 [details] screenshot of mcc
Hi, I've got a similar issue. serveur = PC running mageia9, using xfce as Desktop gui and intel (Intel 810 and later) driver. local = PC running mageia9, using Plasma as Desktop gui and nvidia (NVIDIA GeForce 635 to GeForce 920) driver. From my local PC , I connect with ssh to the server one. # ssh serveur # su -l root # mcc& Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. (mcc:332412): dbind-WARNING **: 18:43:28.155: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Ignore the following Glib::Object::Introspection & Gtk3 warnings (drakconf:332418): dbind-WARNING **: 18:43:28.515: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal libEGL warning: DRI2: failed to authenticate (WebKitWebProcess:332456): Gdk-WARNING **: 18:43:29.279: The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 169 error_code 1 request_code 154 (unknown) minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I do not have any icons on the right hand-side of the mcc window (see the above attachment of Robert Fox). Server : # rpm -qa | grep webkit2 webkit2-driver-2.40.3-1.mga9 lib64webkit2gtk4.1_0-2.40.3-1.mga9 webkit2gtk4.1-2.40.3-1.mga9 lib64webkit2gtk4.0_37-2.40.3-1.mga9 webkit2gtk4.0-2.40.3-1.mga9 lib64webkit2gtk-gir4.1-2.40.3-1.mga9 lib64webkit2gtk-gir4.0-2.40.3-1.mga9 local : # rpm -qa | grep webkit2 webkit2-driver-2.40.3-1.mga9 webkit2gtk4.1-2.40.3-1.mga9 lib64webkit2gtk4.1_0-2.40.3-1.mga9 lib64webkit2gtk-gir4.1-2.40.3-1.mga9 I didn't try to downgrade the webkit2 packages (too risky to me :)). Do you have any new ideas to fix this issue ? Regards. Xuo.
CC: (none) => xuoy
Hi, Closing all other local applications (local mcc, Firefox, Thunderbird, ... except the Konsole terminal) didn't improve anything. Regards. Xuo.
Today, I got a similar but different behaviour. I started mcc from a root console. All was fine. But starting again, right panel is blank AND tabs are inactive. Until now, the tabs were active. Starting again with no success, from console or from menu with polkit dialogue. Intel graphic card.
Missing icons in MCC on M9 with nVidea graphics issue - my fix: https://bugs.mageia.org/show_bug.cgi?id=30332#c47
CC: (none) => playthatbeat
This issue with icons being invisibe sometimes hit here. I can usually click the white space where they should be and the intended tool do launch. But today for me this new experience nothing can be clicked at, mouse pointer is always an arrow any place in the white area and nothing happens when i click. Fully updated Mageia 9 incl testing, nvidia535 on GTX750, but booted elder kernel-desktop-6.4.16-3.mga9.x86_64, Plasma.
Continuation of Comment 16: Starting it as root in konsole, no icon visible nor clickable: [root@svarten ~]# mcc Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal EGLDisplay Initialization failed: EGL_BAD_ACCESS Cannot create EGL sharing context: invalid display (last error: EGL_SUCCESS) (WebKitWebProcess:1428332): Gdk-WARNING **: 12:24:18.036: The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 207 error_code 2 request_code 152 (GLX) minor_code 34) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32840
*** Bug 32882 has been marked as a duplicate of this bug. ***
CC: (none) => pascal
We need to get this squashed! This system had this problem there in mga8, Bug 30332 Comment 27. I also now tested it after full mga8 update, problem is there unless packages downdated per description. (and put in skip list) Now upgraded the system to mga9: (fully, nothing in skip.list), Bug 32985#c45 And the problem is visible when launching MCC but icons appear immediately when i resize the window. And sometime I only have to let mouse pointer move over it.
Whiteboard: (none) => MGA9TOOPriority: Normal => High
Please note that in mga9 (not Cauldron), on this date and when fully updated, when using a GTX 750 Ti, this problem occurs when the NVidia New Feature driver is used (driver 545.*) and goes away when the NVidia Production driver (x11-driver-video-nvidia-current-550.54.14-2.mga9.nonfree). In this instance, there is no need to down-grade webkit.
CC: (none) => kbulgrien
I had this problem randomly even on successive launches in same session, i.e: 1) Launch MCC: no icons - keep the first MCC up and directly: 2) Launch another another MCC: OK ! So it varies even with no system change, and in this case obviously no problem of missing resources as it worked better launching the second instance... Maybe something is randomly executed in wrong order, some kind of sequence interlock need be added? Anyway, now we have recently released new X11, mesa, kernels, and nvidia-current, and I see a new webkit in updates_testing. Is it by chance any better?
Created attachment 14513 [details] spec file for waypipe Mageia 9( with up to date "update-testing" repos ) and Cauldron, they both show some regression as the mcc window closes almost immediately now with almost identical error message. This is happening under Plasma X11 while under Plasma XWayland/Wayland everything is fine. BTW, the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 doesn't help. As a workaround, avoiding X11 and using Wayland only, one can use "waypipe" which is not yet packaged for Mageia, but can be easily done(attached is a spec file for it). waypipe: https://gitlab.freedesktop.org/mstoeckl/waypipe/ redhat docs: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment
The problem seen when running over ssh is most likely not the same as the problem seen when running locally. I can reliably reproduce the problem over ssh, but have never managed to reproduce the problem running locally. When testing workarounds that set environment variables, it is important to know that /usr/bin/mcc is a soft link to /usr/bin/drakconf, which in turn is a wrapper script that runs /usr/libexec/drakconf via pkexec, and that pkexec unsets all but a handful of essential environment variables. So test like this (as root): WEBKIT_DISABLE_COMPOSITING_MODE=1 /usr/libexec/drakconf This fixes the problem when running over ssh for me. For people experiencing the problem when running locally, you could also try WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf
CC: (none) => mageia
Only trying locally, with the updated webkit, drakconf aborts with: WARNING **: Failed to load shared library 'libwebkit2gtk-4.1.so.0' referenced by the typelib: /lib64/libwebkit2gtk-4.1.so.0: undefined symbol: _ZN3JSC14JSGlobalObject14deletePropertyEPNS_6JSCellEPS0_NS_12PropertyNameERNS_18DeletePropertySlotE at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 110.
Doh, I had forgot the lib64javascriptcore packages! Prior to the webkit update, I launched five instances of mcc with no problem; icons visible. But after the update, several tries never the icons visible... Looking in launching terminal: $ LC_ALL=C sudo /usr/libexec/drakconf Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 890x776: Permission denied * and icons are invisible (but works to click where they should be) But using the suggestion from Martin: $ LC_ALL=C sudo WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf -give same output as above minus the two last lines *and icons are visible* (note that drakconf need be launched as root / using sudo)
(In reply to Martin Whitaker from comment #23) Never run into this kind of issues locally. I can only reproduce this bug over ssh with X11 only. WEBKIT_DISABLE_DMABUF_RENDERER=1 it never did any good with ssh for my tests, but it did help with mcc when running in a VirtualBox.
(In reply to Morgan Leijström from comment #25) > Doh, I had forgot the lib64javascriptcore packages! > > Prior to the webkit update, I launched five instances of mcc with no > problem; icons visible. > > But after the update, several tries never the icons visible... > > Looking in launching terminal: > > $ LC_ALL=C sudo /usr/libexec/drakconf > Ignore the following Glib::Object::Introspection & Gtk3 warnings > Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line > 539. > GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion > 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line > 223. > GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion > 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line > 223. > GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion > 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line > 223. > GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion > 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line > 223. > Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want > WebKit to use a different signal > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 890x776: Permission denied > * and icons are invisible (but works to click where they should be) > > > But using the suggestion from Martin: > $ LC_ALL=C sudo WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf > -give same output as above minus the two last lines > *and icons are visible* > > > (note that drakconf need be launched as root / using sudo) I suggest add this to erratas (if not already in) until devs make a fix
Please test drakconf-13.29-1.1.mga9 from core/updates_testing when it reaches the mirrors. This sets the two environment variables for you.
That fix works here :) Local use (not tried ssh) After updating to new webkit in testing, drakconf always came up without icons for a bout twenty tries. Now after drakconf update, drakconf always shows icons. --- Updated https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools --- In retrospect, the issue is not bound to webkit alone; webkit is just one of many ingredients of the cause. We need one bug to be set against drakconf to handle this update. (file list, advisory) Open a new bug or convert this one?
I will open a new bug for QA.
(In reply to Martin Whitaker from comment #28) > Please test drakconf-13.29-1.1.mga9 from core/updates_testing when it > reaches the mirrors. This sets the two environment variables for you. drakconf-13.29-1.1.mga9 didn't help with running mcc/drakconf over ssh in my case but it does work better locally, without ssh, in a VirtualBox and I haven't noticed any regressions.
Hi everyone. I ran into this issue almost immediately after installing the latest updates. I'm glad this bug report was here already. In my case (locally on X11 with nouveau) either of Martin's two environment variables from Comment 23 seem to work equally well. Wondering what the difference between them is, I did a bit of searching on the 'Net and soon came across the blog of WebKit developer Carlos Garcia Campos. From his entry dated a year ago this month, it appears (at least to me) that the DMABUF switch is meant to supersede/replace the COMPOSITING one such that applying both shouldn't be necessary (?). Specifically he hints that the DMABUF one should alleviate the need to account for the myriad factors brought on by users' disparate setups. Full blog post is here: https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/ Quoting the relevant section: === CARLOS GARCIA CAMPOS on 2023-04-03 === Reducing all the combinations to (almost) one: DMABUF All these combinations to support the different platforms made it quite difficult to maintain, every time we get a bug report about something not working in accelerated compositing mode we have to figure out the combination actually used by the reporter, GTK3 or GTK4? X11 or Wayland? using EGL or GLX? custom Wayland compositor or libwpe? driver? version? etc. We are already using DMABUF in WebKit for different things like WebGL and media rendering, so we thought that we could also use it for sharing the rendered buffer between the web and UI processes. That would be a more efficient solution but it would also drastically reduce the amount of combinations to maintain. The web process always uses the surfaceless platform, so it doesn’t matter if it’s under Wayland or X11. Then we create a surfaceless context as the render target and use EGL and GBM APIs to export the contents as a DMABUF buffer. The UI process imports the DMABUF buffer using EGL and GBM too, to be passed to GTK as a texture that is painted in the web view. This theoretically recudes all the previous combinations to just one (note that we removed GLX support entirely, making EGL a requirement for accelerated compositing), but there’s a problem under X11: GTK3 doesn’t support EGL on X11 and GTK4 defaults to EGL but falls back to GLX if it doesn’t find an EGL config that perfectly matches the screen visual. In my system it never finds that EGL config because mesa doesn’t expose any 32 bit depth config. So, in the case of GTK3 we have to manually download the buffer to CPU and paint normally using Cairo, but in the case of GTK4 + GLX, GTK uploads the buffer again to be painted using GLX. I don’t think it’s possible to force GTK to use EGL from the API, but at least you can use GDK_DEBUG=gl-egl. === END QUOTE === So, yeah, I'm not sure including both variables makes any difference. I hope the above info helps in some way.
CC: (none) => johnltw
MGA9-64 Plasma, i5-7500, Nvidia Quadro K620, using nvidia-current. I hit this bug this morning after receiving the latest webkit2 update. Prior to this, this system had been unaffected. Updating drakconf and drakconf-icons made the symptoms go away.
CC: (none) => andrewsfarm
(In reply to John L. ten Wolde from comment #32) > So, yeah, I'm not sure including both variables makes any difference. I > hope the above info helps in some way. For me, WEBKIT_DISABLE_COMPOSITING_MODE=1 fixes the bug when connecting over ssh, whereas WEBKIT_DISABLE_DMABUF_RENDERER=1 does not.
Over ssh, none of the 2 settings, by themselves or together, works for me, but I only have a discrete AMD and some dated integrated Intel graphics cards(i915) to test on. This is happening on up to date Mageia 9 and Cauldron and only, as I mentioned before, while running X11.
On two of four tested systems, the problem of missing icons in drakconf showed up firmly (same several tries) after the today released webkit update. Graphics divers in use are nvidia470 and Xorg modesetting. The drakconf in testing fixes the problem firmly. It seems we need to get this drakconf as is out ASAP to aid users Eventual optimised solution later
Packages in 9/core/updates_testing ######################################## drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm SRPM: drakconf-13.29-1.1.mga9.src.rpm
Assignee: pkg-bugs => qa-bugsWhiteboard: MGA9TOO => (none)Version: Cauldron => 9
Status comment: (none) => Packages in comment#37
Based on the different experiences everyone's describing, so much for Carlos' one-size-fits-all solution... I still have two more systems to upgrade myself. Both are AMD. One is an ancient 32-bit machine, the other a newish 64-bit. I'll comment back later with how they react to either one or both variables. Like I said earlier though, this 64-bit machine, on X11 with nouveau, works fine locally using either. I'm not in a position to need ssh. (In reply to Morgan Leijström from comment #36) > It seems we need to get this drakconf as is out ASAP to aid users > Eventual optimised solution later I have yet to find a clear definition that satisfies my curiosity about the actual differences between the two variables, except that (obviously) DISABLE_COMPOSITING_MODE should do what it says by using a sledge hammer. But continuing my search, I did end up back on Carlos' blog again, so regarding a more long-term optimised solution... quite an old entry, but perhaps this? === CARLOS GARCIA CAMPOS on 2017-03-20 === The WebKitGTK+ API is quite complete now, but there’s always new things required by our users. HARDWARE ACCELERATION POLICY Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16. === END QUOTE === Complete blog entry: https://blogs.igalia.com/carlosgc/2017/03/20/webkitgtk-2-16/ The embedded link to the API he provides has gone 404, but I think I found it now hosted on Valadoc.org. I'm guessing his link led to one or the other of these two: https://valadoc.org/webkit2gtk-4.0/WebKit.HardwareAccelerationPolicy.html https://valadoc.org/webkit2gtk-4.0/WebKit.Settings.hardware_acceleration_policy.html For additional giggles on this topic, it seems Michael Catanzaro saw trouble brewing on the horizon as far back as January 2019 when he filed an upstream bug report suggesting WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER be made the default going forward. Carlos quickly put the kybosh on this idea. See: https://bugs.webkit.org/show_bug.cgi?id=193972
RH mageia 9 x86_64 LC_ALL=C urpmi --auto --auto-update medium "QA Testing (32-bit)" is up-to-date medium "QA Testing (64-bit)" is up-to-date medium "Core Release (distrib1)" is up-to-date medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Release (distrib11)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Release (distrib21)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date medium "Core 32bit Release (distrib31)" is up-to-date medium "Core 32bit Updates (distrib32)" is up-to-date medium "Nonfree 32bit Release (distrib36)" is up-to-date medium "Tainted 32bit Release (distrib41)" is up-to-date installing drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/2: drakconf-icons ################################################################################################## 2/2: drakconf ################################################################################################## 1/2: removing drakconf-13.29-1.mga9.noarch ################################################################################################## 2/2: removing drakconf-icons-13.29-1.mga9.noarch ################################################################################################## mcc star without issues from root terminal and icon in panel
RH mageia 9 i586 LC_ALL=C urpmi --auto --auto-update medium "QA Testing (32-bit)" is up-to-date medium "Core Release (distrib1)" is up-to-date medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Release (distrib11)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Release (distrib21)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date installing drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm from //home/katnatek/qa-testing/i586 Preparing... ################################################################ 1/2: drakconf-icons ################################################################ 2/2: drakconf ################################################################ 1/2: removing drakconf-13.29-1.mga9.noarch ################################################################ 2/2: removing drakconf-icons-13.29-1.mga9.noarch ################################################################ mcc start without issues fro root terminal and icon in panel
About the origina issue I can't say if is fixed or not I cant start mcc from a ssh connection in any of my systems This is wat I see conecting from x86_64 system to i586 mcc Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. (mcc:14452): dbind-WARNING **: 19:30:49.920: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Ignore the following Glib::Object::Introspection & Gtk3 warnings (drakconf:14454): dbind-WARNING **: 19:30:51.000: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 841. libEGL warning: DRI3: failed to query the version libEGL warning: DRI2: failed to authenticate libEGL warning: DRI3: failed to query the version Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal error: XDG_RUNTIME_DIR is invalid or not set in the environment. MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen (drakconf:14454): Gdk-WARNING **: 19:30:55.197: The program 'drakconf' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 618 error_code 1 request_code 155 (unknown) minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) This was tested before and after the update, could be a configuration issue or something else but is not for this bug
(In reply to katnatek from comment #41) > About the origina issue I can't say if is fixed or not > I cant start mcc from a ssh connection in any of my systems It looks like this bug, try "drakrpm" over ssh and, if it works, most likely you hit this bug. Also try wayland environment as I never run into any issues if the local host is running under wayland. Testing steps: grep -r "FowardX11" /etc/ssh/ssh_config* ## to check if set to yes ssh -X 127.0.0.1 su - mcc or drakrpm OTOH, this bug can be reproduced with Fedora Rawhide running in a VirtualBox under Plasma X11 environment, under wayland this doesn't happen. I cannot reproduce the bug if local host is running under Wayland, maybe someone can say otherwise but it looks like it is confined to X11 environment.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=33149
I have opened a new bug for QA. This bug shouldn't be closed until the original problem (running remotely over ssh) is fixed. As I commented earlier, we are almost certainly dealing with multiple issues here. With the latest updates I can now reproduce the bug when running locally in VirtualBox (using the vmware DDX driver and vmwgfx kernel driver). I note that the icons are displayed the first time you run drakconf after booting the machine, but not when switching tabs or when rerunning drakconf. Restarting the X server doesn't help, rebooting the machine does. I see exactly the same error messages as Aurelian and katnatek report when connecting via ssh, so don't know why the workaround works for me and not for them.
Assignee: qa-bugs => mageiatools
Further note: after installing the webkit2gtk4.1-2.44.2-1.mga9 update, I again see the bug when running over ssh (even with WEBKIT_DISABLE_COMPOSITING_MODE=1). Downgrading to the previous version of webkit2gtk4.1 restores the fix.
Hi The blank windows of MCC reappeared suddenly for me after a bunch of last updates (kernel nvidia webkit) I could correct it with : drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm from core-updates-testing repo This update is efficient and necessary MGA9 86-64 OK for me
CC: (none) => philippedidier
applied update that included: lib64webkit2gtk-gir4.1 2.44.1 1.mga9 x86_64 lib64webkit2gtk4.1_0 2.44.1 1.mga9 x86_64 lib64webkitgtk6.0_4 2.44.1 1.mga9 x86_64 webkit2-driver 2.44.1 1.mga9 x86_64 webkit2gtk4.1 2.44.1 1.mga9 x86_64 webkitgtk6.0 2.44.1 1.mga9 x86_64 unusual final comment, never had this before.... 15/21: removing webkit2-driver-2.40.3-1.mga9.x86_64 ############# 16/21: removing lib64javascriptcoregtk4.1_0-2.40.3-1.mga9.x86_64 ############# 17/21: removing thunderbird-0:115.9.0-1.mga9.x86_64 ############# 18/21: removing lib64jasper6-3.0.6-1.mga9.x86_64 ############# 19/21: removing lib64editorconfig0-0.12.6-1.mga9.x86_64 ############# 20/21: removing nscd-6:2.36-52.mga9.x86_64 ############# 21/21: removing timezone-6:2023c-1.mga9.x86_64 ############# Segmentation fault (core dumped) Checking mcc via CLI from root - ok, ok from menu and panel launchers. Graphics: Device-1: AMD RV710/M92 [Mobility Radeon HD 4530/4570/5145/530v/540v/545v] vendor: Toshiba driver: radeon v: kernel arch: TeraScale pcie: Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X: loaded: radeon,v4l dri: r600 gpu: radeon display-ID: :0 screens: 1 System: Kernel: 6.6.22-desktop-1.mga9 arch: x86_64 bits: 64 compiler: gcc v: 12.3.0 Console: pty pts/0 wm: kwin_x11 DM: 1: LightDM note: stopped 2: LXDM note: stopped 3: SDDM Distro: Mageia 9
CC: (none) => westel
Alright, I've checked on the two AMD boxes, and within the local context neither are affected by this issue. The 20-year-old 32-bit machine uses the old ati driver and the newer 64-bit uses radeon. So yeah, only my old Nvidia (NV96 GeForce) machine running on nouveau needs the environment workaround. Sorry I can't help at all with testing over ssh.
(In reply to Philippe Didier from comment #45) > Hi > The blank windows of MCC reappeared suddenly for me after a bunch of last > updates (kernel nvidia webkit) > I could correct it with : > drakconf-13.29-1.1.mga9.noarch.rpm > drakconf-icons-13.29-1.1.mga9.noarch.rpm > > from core-updates-testing repo > > This update is efficient and necessary > MGA9 86-64 OK for me Thank you very much this has worked for me.
CC: (none) => ricardalfe
drakconf update Bug 33149 is shipped :) I have updated errata 9.
The failure over SSH is already reported upstream: https://bugs.webkit.org/show_bug.cgi?id=267261 I have added my two pennyworth there.
Thank you Martin. For that and all your other work! :)
I never had a problem opening drakconf locally, even after the recent update it doesn't work over ssh. Ony now instead of no icons, the window is drawn very briefly then crashes (still no icons in the window). Here is the console output: [root@watson bascule]# mcc Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings (drakconf:2500): dbind-WARNING **: 09:38:17.149: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus_0: No such file or directory Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/mgaapplet-config" since it is not installed [Updates Configuration] at /usr/libexec/drakconf line 841. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 841. "cannot run /usr/sbin/msecgui" since it is not installed [Security Level] at /usr/libexec/drakconf line 841. "cannot run /usr/sbin/drakguard" since it is not installed [Parental Controls] at /usr/libexec/drakconf line 841. libEGL warning: DRI3: failed to query the version libEGL warning: DRI2: failed to authenticate libEGL warning: DRI3: failed to query the version Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal error: XDG_RUNTIME_DIR is invalid or not set in the environment. MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen (drakconf:2500): Gdk-WARNING **: 09:38:17.744: The program 'drakconf' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 676 error_code 1 request_code 155 (unknown) minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [root@watson bascule]# I saw the reference about 'accessibilty bus', not knowing what that means I did a reboot just in case and that output is from after the reboot. bascule
CC: (none) => asura
__Status summary__ § The update of drakconf Bug 33149 seem to have solved the problem when MCC is launched locally. - If not, please tell! § There are still problems running MCC over SSH. Upstream bugs Comment 1 -> https://bugs.webkit.org/show_bug.cgi?id=259320 Comment 50 -> https://bugs.webkit.org/show_bug.cgi?id=267261
Status comment: Packages in comment#37 => Status in c53. #33149 fixed local use.Summary: webkit2: drakconf (mcc) local and over ssh fails to display its icons on the right hand side. => webkit2: drakconf (MCC) over SSH fails to display its icons on the right hand side.
commit 6e1902789812a5b8fb9d3a2e4d5f3dba1d99b2bd Author: Martin Whitaker <mageia@...> Date: Sat Sep 21 20:30:40 2024 +0100 Work around WebKit2 bugs that stop right hand pane icons being displayed. Since WebKit2 2.36, the icons in the right hand pane are not displayed on numerous (but not all) combinations of graphics hardware and drivers. This seems to be due to bugs in the WebKit2 accelerated compositing mode. The workaround is to disable WebKit2 accelerated compositing. This workaround was already released as a temporary fix for mga9, but still appears to be needed. See mga#30332, mga#32185, and mga#33573. --- Commit Link: https://gitweb.mageia.org/software/control-center/commit/?id=6e1902789812a5b8fb9d3a2e4d5f3dba1d99b2bd Bug links: Mageia https://bugs.mageia.org/30332 https://bugs.mageia.org/32185 https://bugs.mageia.org/33573