[plasmashell] [Bug 460413] plasma shell crashes when searching for something
https://bugs.kde.org/show_bug.cgi?id=460413 C. Leu changed: What|Removed |Added CC||k...@bluewin.ch --- Comment #10 from C. Leu --- Hi folks! It should be added here that the effective solution in this topic is to switch to OpenGL ES compositing in KWin. The OP is using a really really old Intel 3th gen 945G iGPU which even don't supports OpenGL 2.0 fully. However, the awesome Mesa drivers offers stable OpenGL ES 2.0 support even for that old vintage hardware. ;-) To get there, open the following file: sudo nano /etc/profile.d/kwin.sh And then add: export KWIN_COMPOSE=O2ES Save and reboot. By the way, it was confirmed by the OP "johnathan" that this works. More information can be found at the corresponding Mesa bug report: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7499 @Nate Graham I really don't understand why the OpenGL ES renderer is not present as an official option in the UI. It is absolutely useful especially on older and weaker hardware like we have here. The only drawback is that some more complex themes / global designs may show artifacts. But that's acceptable as long as the standard Breeze theme is fully working. I can confirm this for latest Kubuntu 22.04 running at a dual-GPU based iMac 12,2 computer. Absolutely no issues there even with the enforced OpenGL ES compositing backend. :D -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 456490] Add an option in the UI to disable the "USB auto suspend feature" of the Bluetooth controller
https://bugs.kde.org/show_bug.cgi?id=456490 --- Comment #1 from C. Leu --- A short addition, I can confirm that this USB auto suspend tweak also works for an Acer Aspire One 721 Netbook which was upgraded with an Intel 7260 AC BT 4.0 WiFi card. The used mouse model was a Logitech MX Anywhere 3. The original behavior on this system was that the reaction of the mouse became reproducible laggy. Usually that happened after a short time of inactivity so when the mouse was not used for a moment. But in contrast to the first scenario the BT controller was in that case not always automatically disabled. In short, - the above mentioned USB auto suspend feature disable tweak also fixed the laggy symptom of an Logitech MX Anywhere 3 mouse in conjunction with an Intel 7260 BT 4.0 controller. So it would really make sense to have somewhere in the UI an option to disable the USB auto suspend feature on the BT controller. ;-) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 456490] New: Add an option in the UI to disable the "USB auto suspend feature" of the Bluetooth controller
https://bugs.kde.org/show_bug.cgi?id=456490
Bug ID: 456490
Summary: Add an option in the UI to disable the "USB auto
suspend feature" of the Bluetooth controller
Product: systemsettings
Version: unspecified
Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: kcm_bluetooth
Assignee: now...@gmail.com
Reporter: k...@bluewin.ch
CC: plasma-b...@kde.org
Target Milestone: ---
SUMMARY
***
Right at the beginning it should be noted that this is not a typical bug
report. However, the resulting consequences of the here described faulty "USB
auto suspend functionally" can be significant.
So what's the problem? In short, it looks that on certain systems the "USB auto
suspend functionality" is triggered too aggressively with the result that all
Bluetooth devices became non-functional.
I have noticed this first at a BT 4.0 upgraded iMac computer. The Apple Magic
Mouse was working normally under Mac OS and Windows but it stopped the
operation from time to time under Linux (Kubuntu 18.04 and 20.04). Regardless
which BT setting was tried, nothing helped. The whole situation became then
even more annoying when I bought an Apple Magic Mouse 2 which uses BT LE 4.0.
And finally, after a new switch to an even newer Logitech MX Master 3 mouse the
situation became totally unbearable. The mouse always became reproducible
inactive after the automatic screen-locker was enabled and on the same time the
Bluetooth controller was out of unknown reasons disabled. I have tried again to
alter several Bluetooth related settings (like mentioned in Bug 440493) but
nothing helped.
Finally I was able thanks to askUbuntu and a very helpful ArchLinux user to
identify the underlying problem which was in the end not Bluetooth but USB
related. It looks that the "USB auto suspend feature" doesn't work as expected
with certain BT LE devices. More Information can be found at the following
askUbuntu link:
https://askubuntu.com/questions/1303731/how-to-change-bluetooth-timeout-settings-for-bluetooth-mouse
The summarized solution:
Check the USB BT controller information and look for the ID:
lsusb -vt
Mine is:
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/3p, 12M
ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046
Bluetooth)
Edit the following file:
sudo nano /etc/udev/rules.d/50-usb_power_save.rules
Add the following content:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="4500",
ATTR{idProduct}=="0a5c", ATTR{power/autosuspend}="-1"
Reboot and enjoy a perfect working BT environment! ;-)
***
STEPS TO REPRODUCE
1. Buy a Logitech MX Master 3 mouse
2. Connect it under a Kubuntu version like 20.04 (Note, newer releases have an
additional MX Master 3 mouse related problem with the BlueZ stack)
3. The mouse is too aggressively triggering the BT controller into USB
autosuspend mode
OBSERVED RESULT
The mouse stopped responding after the automatic screen-locker non-responsive
became active. The BT controller is automatically disabled when this happens.
EXPECTED RESULT
The BT controller must not be switched off every time when a BT LE devices
triggers the "USB auto suspend functionality".
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.13.0-52-generic
(available in About System)
KDE Plasma Version: 5.18.8
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
ADDITIONAL INFORMATION
This problem also occurs in conjunction with the Logitech MX Master 3 mouse
under Windows. It can be fixed there by disabling the corresponding USB
autosuspend feature (of the BT controller) in the device manager.
--
You are receiving this mail because:
You are watching all bug changes.
[kaffeine] [Bug 445197] New: Kaffeine does not respect additional entries in its "Settings" -> "libVLC arguments"
https://bugs.kde.org/show_bug.cgi?id=445197 Bug ID: 445197 Summary: Kaffeine does not respect additional entries in its "Settings" -> "libVLC arguments" Product: kaffeine Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mchehab+hua...@kernel.org Reporter: k...@bluewin.ch Target Milestone: --- SUMMARY Hi all! Here follows a bug report in conjunction with Kaffeine 2.0.18. Unfortunately Kaffeine does NOT respect additional entries in its "Settings" -> "libVLC arguments". In my case, VLC only works properly with the arguments --vout=gles2 and --avcodec-hw=vaapi. Therefore Kaffeine should also use this settings. STEPS TO REPRODUCE 1. Start up Kaffeine 2. Go to "Settings" and then "libVLC arguments" 3. The additional arguments shows no effect OBSERVED RESULT Kaffeine permanently ignores and additional libVLC arguments, it always falls back to VDPAU with message: "Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding" EXPECTED RESULT The --vout=gles2 and --avcodec-hw=vaapi vlc parameters should be accepted. Kaffeine should start up and use the OpenGL ES 2.0 video output and the VA-API hardware decoder. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu / Ubuntu 20.04.3 LTS (Focal Fossa), kernel 5.11.0-40-generic x86_64 bits KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Used drivers: Mesa 21.0.3, Mesa 22.0.0 devel Note, the mpv Media Player starts right out of the box without any additional settings and performs awesome reliable. So maybe it would make sense to chose that on instead of the libVLC library. ;-) A similar bug was filled in 2019 at the Gentoo Bugzilla: https://bugs.gentoo.org/686646 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442386] Prefer EGL to GLX for GL support also on X11
https://bugs.kde.org/show_bug.cgi?id=442386 --- Comment #4 from C. Leu --- Again a short update. During the last few weeks it has been shown that the best way to enforce EGL in kwin is through the "KWIN_OPENGL_INTERFACE=EGL" and not the "KWIN_COMPOSE=O2ES" variable. This will effectively keep the OpenGL 2.0 or OpenGL 3.1 "function feature set" and just force EGL over GLX. sudo nano /etc/profile.d/kwin.sh export KWIN_OPENGL_INTERFACE=EGL The first mentioned "KWIN_COMPOSE=O2ES" environment variable is also applicable but it will additionally switch the compositing to OpenGL ES 2.0. Just to be clear, this is perfect for weaker hardware like single core Netbooks, AIO computers, or older systems with limited GPU functionality. Such lower-end systems may benefit significantly from the OpenGL ES 2.0 mode, like the previously mentioned Apple iMac5,1 from 2006. However, the OpenGL ES 2.0 compositing may limit in certain situations some enhanced graphical effects of a theme. I can confirm this now for the "Se7en Aero" global design which shows partially missing elements. For example, all frames in dolphin are becoming "transparent". This is not the case regarding the regular OpenGL backend in conjunction with EGL. It should also be noted that this is not the case for the standard (more basic) KDE designs "Breeze" and "Breeze-Dark", - they work fine even with only OpenGL ES 2.0 feature set. Whatever, maybe there will be in the future beside a Vulkan additionally also an OpenGL ES 3.0 rendering backend, - it would allow more effects on weaker hardware. ;-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442386] Prefer EGL to GLX for GL support also on X11
https://bugs.kde.org/show_bug.cgi?id=442386 --- Comment #3 from C. Leu --- Here follows a short status update. Just for reference, - until now I was NOT able to reproduce any sort of a "stuttering effect" with the EGL backend. In the meantime I switched at a further iMac computer running Kubuntu 20.04 LTS (and containing a Radeon 6770M GPU) to the OpenGL ES / EGL backend. Also here, no negative side-effect, just a benefit in the KDE Plasma GUI behavior: iMac12,2 (16GB RAM, native EFI, R600 Mesa 21.0.3) I searched at the web regarding this EGL/GLXÂ matter and found the information that Firefox 94 will make EGL to its default: https://www.itsfoss.net/firefox-94-will-change-the-output-for-x11-to-use-egl-by-default/ However, this is true only if Mesa 21.x driver version (or higher) is present. Fortunately that's the case for an up-to-date Kubuntu 20.04 LTS installation. ;-) I also found some information which indicates that the mentioned EGL "stuttering effect" may be more an issue of the proprietary Nvidia Linux driver. Regarding the Radeon side I can confirm for Mesa 21.0.3 that the OpenGL ES / EGL backend runs great on several quite different older Radeon GPUs. The most impressive benefit I noticed at my oldest and weakest iMac5,1 computer. The usability jumped from "not really usable" to almost "perfectly usable" in near any office-work related scenario. So out of my perspective as a Linux user I simply don't understand why there exist no "user-friendly way" to enable the OpenGL ES / EGL option in the compositor. It doesn't have to be the default setting. Just an option to play with it. ;-) Whatever, I know this will all change with Wayland but I assume that this bigger "switchover" will then probably also exclude some older hardware. My conclusion is therefore, it's time to change to EGL also on X11! Well, - at least for systems with the awesome Mesa drivers... ;-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442386] Prefer EGL to GLX for GL support also on X11
https://bugs.kde.org/show_bug.cgi?id=442386 --- Comment #2 from C. Leu --- Thanks Vlad Zahorodnii for your replay. I have now switched in kwin the compositing of all my Kubuntu 20.04 LTS installations to OpenGL ES / EGL and noticed so far no issues regarding any sort of stuttering. Maybe I will see a "buffer swap" problem sometimes in the future... ;-) How can I provoke it? Furthermore I enabled the X11 EGL option even in Firefox, - also here no issues so far just a benefit in the overall behavior. However, it could be possible that this problem described here is not only a "GLX" problem but also one of the "notification system". As mentioned, the message "kworker blocked for more than 120 seconds" has not occurred so far with EGL backend enabled. But when the RAM memory is quite full, then I have sometimes still some "hangers" for example in Dolphin. So I decided to disable the notifications completely, only the critical ones are allowed. After this setting there were no more hangers present, - strange but interesting. Whatever, it should be noted that this problem may be primary relevant for systems with low RAM memory. My iMac 5,2 has just 4GB physical RAM installed, but Apple enables in legacy CSM Bios mode only around 3GB which is effectively too less for Kubuntu 20.04 LTS. Apple furthermore also screws down the speed of the SATA controller to UDMA133, which is just ridiculous because it limits totally my Crucial MX200 SSD. These points can be only resolved thorough a installation of Kubuntu in native (mixed-mode) EFI. Whatever, back to the original matter. As for now I have switched to the EGL backend at the following Apple computer models. I noticed an improvement in the KDE GUI behavior at all of them. iMac5,1 (4GB RAM, only 3GB usable, R300 Mesa 21.0.3) iMac8.1 (6GB RAM, native EFI, R600 Mesa 21.0.3) iMac9,1 (8GB RAM, native EFI, R600 Mesa 21.0.3) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442386] New: Prefer EGL to GLX for GL support also on X11
https://bugs.kde.org/show_bug.cgi?id=442386 Bug ID: 442386 Summary: Prefer EGL to GLX for GL support also on X11 Product: kwin Version: 5.18.7 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: glx Assignee: kwin-bugs-n...@kde.org Reporter: k...@bluewin.ch Target Milestone: --- Hi to all Okay, this is more a "feature request" than a bug report. After intensive testing, especially on older Apple Intel iMac computers, I must say that a switch to the EGL backend would make absolutely sense. This will improve in some cases dramatically the entire user experience of the GUI on older hardware. I can confirm this for the old Apple iMac 5,1 series were Kubuntu 20.04 LTS has to be installed via CSM Bios emulation. When the normal GLX backend is used for compositing, the GUI hangs reproducible after login. This happens always right after the "notification message" regarding the WiFi status is displayed. When I start then the terminal via alt + F2 I can see in dmesg the message "kworker blocked for more than 120 seconds". This "GLX hanging problem" is also present when a copy action is started from a network share. However, a switch to the EGL backend fixed the problem. It furthermore also improves noticeable the overall response of the KDE GUI: export KWIN_COMPOSE=O2ES sudo nano /etc/profile.d/kwin.sh So for me it looks that as for 2021 the EGL implementation is superior to the GLX one. And this is now true also for the X11 window system! STEPS TO REPRODUCE 1. Install Kubuntu 20.04 LTS at an iMac 5,1 computer* 2. After the first start-up X is "hanging around" when notifications are displayed *Currently an install is only possible via CSM Bios emulation. A native EFI installation is not supported because of a "32bit EFI vs. 64bit CPU mismatch". However, there were some changes in later Linux kernel versions (since 5.7) which added a flag called "LOAD_X64_ON_IA32_ENABLE". This would theoretically make a mixed-mode EFI installation possible. But so far I know the Kubuntu devs didn't set that flag on their kernels. As of 2021 only Archlinux seems to have it enabled. OBSERVED RESULT X is under more system-load reproducible hanging (for around 2 minutes) when GLX is used X is not hanging when EGL is used, also not under higher system-load EXPECTED RESULT X should run fine also with GLX SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.11.0-34-generic KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 GPU Hardware: Radeon X1600 series (Mesa 21.0.3, R300 Gallium3D driver used) ADDITIONAL INFORMATION It should be noted that also Gnome is "defaulting" X (since four months) to EGL: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540 -- You are receiving this mail because: You are watching all bug changes.
