[plasma-systemmonitor] [Bug 477976] system-monitor incorrectly reports CPU usage as 0% when it is close to 100%
https://bugs.kde.org/show_bug.cgi?id=477976 --- Comment #1 from Nick Korotysh --- fixed in 5.91, can be closed -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477976] doesn't show CPU usage when it is close to 100%
https://bugs.kde.org/show_bug.cgi?id=477976 Nick Korotysh changed: What|Removed |Added Platform|Other |Arch Linux -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477976] New: doesn't show CPU usage when it is close to 100%
https://bugs.kde.org/show_bug.cgi?id=477976 Bug ID: 477976 Summary: doesn't show CPU usage when it is close to 100% Classification: Applications Product: plasma-systemmonitor Version: 5.90.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: tevut...@mail.ru CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- Created attachment 163806 --> https://bugs.kde.org/attachment.cgi?id=163806=edit htop vs system-monitor SUMMARY *** when all core are under high load (close to 100%), system monitor displays 0% CPU usage (both for total and per core) *** STEPS TO REPRODUCE 1. open system monitor or add widget displaying CPU usage 2. run CPU-heavy task, for example compilation or 7z benchmark (7z b 10) 3. compare usage in system monitor and htop OBSERVED RESULT CPU usage is 0%, only sometimes reaches 100% for some core EXPECTED RESULT CPU usage is close to 100% for all cores SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux/KDE Plasma 6 Beta, Wayland KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION not 100% usage seems to be reported correctly, see attached screenshot -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 477975] do not link KF::DocTools, it is not used in the code
https://bugs.kde.org/show_bug.cgi?id=477975 Nick Korotysh changed: What|Removed |Added Latest Commit||6f76a3f16d9915543fe0e002602 ||f2f1e1c7a88a3 -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 472307] cursor does not disappear if switched to fullscreen using keyboard
https://bugs.kde.org/show_bug.cgi?id=472307 Nick Korotysh changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Nick Korotysh --- is not reproducible anymore, tested on master branch detected as version 0.12.3 -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 477975] New: do not link KF::DocTools, it is not used in the code
https://bugs.kde.org/show_bug.cgi?id=477975 Bug ID: 477975 Summary: do not link KF::DocTools, it is not used in the code Classification: Applications Product: Haruna Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: task Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: tevut...@mail.ru Target Milestone: --- Created attachment 163805 --> https://bugs.kde.org/attachment.cgi?id=163805=edit chnages to build with Qt6 and no KDocTools SUMMARY *** KF6::DocTools is listed in target_link_libraries() in src/CMakeLists.txt, but it is not required - it is not used in code, only some tools from kdoctools package are used for documentation generation. *** STEPS TO REPRODUCE 1. remove kdoctools package 2. run cmake, everything is ok 3. build OBSERVED RESULT build failed, KDocTools is required to link the application EXPECTED RESULT successful build, as KDocTools is optional package (according to root CMakeLists.txt) SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux/KDE Plasma 6 Beta, Wayland KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION doc/CMakeLists.txt also needs to be updated - it checks only for KF5DocTools -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 472344] bits view is painted improperly until window resized
https://bugs.kde.org/show_bug.cgi?id=472344 --- Comment #1 from Nick Korotysh --- Created attachment 160348 --> https://bugs.kde.org/attachment.cgi?id=160348=edit possible fix -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 472344] New: bits view is painted improperly until window resized
https://bugs.kde.org/show_bug.cgi?id=472344 Bug ID: 472344 Summary: bits view is painted improperly until window resized Classification: Applications Product: kcalc Version: 23.04.3 Platform: Archlinux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: ete...@alum.rit.edu Reporter: tevut...@mail.ru Target Milestone: --- Created attachment 160347 --> https://bugs.kde.org/attachment.cgi?id=160347=edit bits view is painted improperly SUMMARY content of bits view looks truncated on app startup (see attached screenshot), window resize fixes it STEPS TO REPRODUCE 1. open application in "Simple Mode" (default) 2. switch to "Numerical System Mode" 3. close the application 4. open application again OBSERVED RESULT content of bits view is truncated on the right side EXPECTED RESULT bits view should be painted correctly, as after switching modes SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux/X11 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION seems that problem in custom button implementation used in this view - it doesn't provide sizeHint() on which QLayout relies on. possible fix is attached. -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 472307] New: cursor does not disappear if switched to fullscreen using keyboard
https://bugs.kde.org/show_bug.cgi?id=472307 Bug ID: 472307 Summary: cursor does not disappear if switched to fullscreen using keyboard Classification: Applications Product: Haruna Version: 0.11.3 Platform: Archlinux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: tevut...@mail.ru Target Milestone: --- SUMMARY mouse pointer doesn't disappear when player is switched to fullscreen and mouse is not touched STEPS TO REPRODUCE 1. open video file (doesn't matter using double click or keyboard) 2. press "toggle fullscreen" shortcut (default "F" in my case) 3. wait few (3-5) seconds OBSERVED RESULT cursor is still here unless mouse touched EXPECTED RESULT cursor should disappear as it does after going to fullscreen using double click (or mouse move in fullscreen) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux/X11 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION very easy to reproduce if only keyboard is used for FS navigation (aka some "Commander" app is used) and file opening, just because this prevents any accidental mouse movement -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 470374] Playlist -> Repeat option has no effect
https://bugs.kde.org/show_bug.cgi?id=470374 --- Comment #1 from Nick Korotysh --- Created attachment 159300 --> https://bugs.kde.org/attachment.cgi?id=159300=edit settings window screenshot added settings window screenshot -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 470374] New: Playlist -> Repeat option has no effect
https://bugs.kde.org/show_bug.cgi?id=470374 Bug ID: 470374 Summary: Playlist -> Repeat option has no effect Classification: Applications Product: Haruna Version: 0.11.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: tevut...@mail.ru Target Milestone: --- Created attachment 159299 --> https://bugs.kde.org/attachment.cgi?id=159299=edit config files SUMMARY playlist content is repeated regardless of disabled "Repeat" option, doesn't matter how many files in the folder (all files are added to the playlist automatically) STEPS TO REPRODUCE 1. disable "Repeat" option in the settings 2. open any video file just clicking on it 3. pick the last item in playlist 4. watch it or just seek to the end OBSERVED RESULT the first item in the playlist is started EXPECTED RESULT player should stop, doesn't matter how, showing just black screen or first item in paused state SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux / KDE Plasma on Wayland KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION package from standard ArchLinux repository config files (~/.config/haruna folder) is attached very likely bug is appeared only with the latest (0.11.0) version -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #15 from Nick Korotysh --- Created attachment 150866 --> https://bugs.kde.org/attachment.cgi?id=150866=edit Haruna vaapi QT_XCB_GL_INTEGRATION="xcb_egl" log attached -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #12 from Nick Korotysh --- I got h/w decoding (vaapi in particular case) working on X11! but mentioned change seems to be vital in any case, "display" variable must be passed as one of mpv initialization parameters. all I did - just set environment variable `QT_XCB_GL_INTEGRATION` to "xcb_egl": ``` export QT_XCB_GL_INTEGRATION="xcb_egl" ``` this was based on comment on GitHub you pointed (it says that EGL context is required for mpv) and this particular piece of Qt code https://github.com/qt/qtbase/blob/231d3670981a33ec42b91ad1cb33c1fc50551066/src/plugins/platforms/xcb/qxcbconnection.cpp#L1079-L1104 first of all I viewed which GL libraries are loaded by application. I was surprised to see both 'libGLX.so' and 'libEGL.so'. but when looked closer (and analyzed 'SMPlayer'+'mpv') found the difference - Qt applications also load 'libGLX_mesa.so' (very likely real OpenGL implementation) and mpv loads 'libEGL_mesa.so' instead. I already knew that Qt on X11 uses so-called 'xcb' platform plugin and it has something called "GL integration", and 2 "backends" are provided for that (exactly GLX and EGL), which very likely can be switched on runtime somehow. I just went deep into Qt sources starting from `QQuickFramebufferObject::Renderer::createFramebufferObject()` found in your code. P.S> please don't think that I know OpenGL specific on Linux, Qt Open GL integration on something specific to mpv - I know neither of those! I just familiar with Qt sources and its build process/dependencies on Linux and just used information you provided. so, I think issue can be marked as solved :) waiting new release in Debian unstable repo :) -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #11 from Nick Korotysh --- confirmed, compiled from master branch - vaapi works on Wayland, behavior is the same as in SMPlayer on X11. thanks! but unfortunately, Wayland is not an option for me - some necessary apps have significant issues on it, also some parts (don't know exactly which) have issues (artifacts around "minimize/maximize/close" button hints, around some but not all context menus), and many icons are blurry when scaling (200%) is enabled even fonts in the same places look fine (in many cases the same icons are fine on X11). thank you for your work! -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #9 from Nick Korotysh --- as I understood from the last comment on GitHub, the problem somewhere in OpenGL context type which you get from Qt and pass to libmpv, very sad... from my experience, it looks like Qt even may use OpenGL ES 2.0 (like on mobiles!) even on desktop, but I can be wrong... I almost don't have experience with OpenGL, just "touched" it due to work. also tried to run Haruna on Wayland - situation the same: any option except auto seems to use software decoding (very high CPU usage), auto option very likely uses the same generic GL/shaders implementation (CPU load is pretty low, but more than twice higher comparing when vaapi is used, GPU load is also pretty high, about twice more comparing to vaapi). so it is also doesn't work on Wayland too... for the sake of experiment, tried already mentioned SMPlayer (Qt, mpv-based) and Celluloid (GTK3, libmpv-based) on Wayland. so, SMPlayer is unusable on Wayland - in most cases video plays in separate window or hardware decoding doesn't work (when I got video in the same window) or just no video at all. from other side, Celluloid works fine, even with exactly the same options what was set in X11 environment, and vaapi seems to work correctly (almost no CPU usage, and GPU usage is comparable to SMPlayer in X11 environment). looks like GTK has much better support/integration with Linux rather than Qt... so, as so this bug seems not related to application side (unfortunately Qt may be the reason of it), feel free to close it. -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #7 from Nick Korotysh --- small update: occasionally found another `libmpv`-based player called Celluloid and decided to try. and hardware decoding (using `vaapi`) works in it, no difference in CPU/GPU load comparing with SMPlayer using the same test video. sources of mentioned player can be found here https://github.com/celluloid-player/celluloid , it is GTK-based. its configuration dialog is very simple, but have very convenient field "Extra MPV options", where I supplied the most important options copied from SMPlayer mpv command line `hwdec=vaapi vo=gpu sub-auto=fuzzy icc-profile-auto audio-file-auto=fuzzy` (just removed '--' like it was in some example I found). regardless of this field, comparing to SMPlayer, this player doesn't run `mpv` executable (checked with `ps ax | grep mpv`) and it is definitely linked to `libmpv` (checked with `ldd /usr/bin/celluloid | grep mpv`). don't know how, but it passes given options to some `libmpv` internals... so, the problem with H/W decoding somewhere on application side... -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #6 from Nick Korotysh --- Created attachment 150483 --> https://bugs.kde.org/attachment.cgi?id=150483=edit mpv logs in 3 cases attached logs in archive: - mpv with no any options - mpv with vaapi h/w decoder - mpv log from smplayer (which uses vaapi) -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #4 from Nick Korotysh --- used the same video as for initial testing, video played ~30 seconds -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #3 from Nick Korotysh --- Created attachment 150482 --> https://bugs.kde.org/attachment.cgi?id=150482=edit using `vaapi` option added log when using `vaapi` option (known to work in other player) -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 --- Comment #2 from Nick Korotysh --- Created attachment 150481 --> https://bugs.kde.org/attachment.cgi?id=150481=edit using `auto` option added log when using `auto` option -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 456482] New: hardware decoding doesn't work
https://bugs.kde.org/show_bug.cgi?id=456482 Bug ID: 456482 Summary: hardware decoding doesn't work Product: Haruna Version: 0.8.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: tevut...@mail.ru Target Milestone: --- Created attachment 150480 --> https://bugs.kde.org/attachment.cgi?id=150480=edit 2 first screenshots - Haruna, 2nd two - SMPlayer SUMMARY hardware decoding seems not working. only `auto` option (default) seems to have some effect, but even in this case it seems some GL/shaders fallback is used (according to CPU/GPU load, details are below). any other options definitely falling back to software decoding, because CPU usage grows insanely. hardware decoding works fine in another mpv-based player (SMPlayer), but it directly uses `mpv` rather than `libmpv` and just somehow embeds its output into UI. using vaapi as h/w decoding engine in it. I don't think that this may be an issue, `libmpv` definitely must have the same capabilities. there are some comparisons between playing the same video in Haruna and SMPlayer. first 2 screenshots are taken when Haruna played the video, another 2 - SMPlayer played the same video (`vaapi` is used as h/w decoding backend). STEPS TO REPRODUCE 1. open settings, enable h/w decoding (doesn't matter which option, even default `auto` is fine) 2. open any pretty heavy h.264 or h.265 encoded video 3. observe CPU and GPU load 4. compare results with some other player (SMPlayer for example) with h/w decoding enabled OBSERVED RESULT any options expect `auto` have no effect at all (result is the same as for disabled h/w decoding), software decoding is used (very high CPU load and almost no GPU load). `auto` value seems to fallback to some generic GL/shaders implementation, because it causes significant CPU load decrease and pretty high GPU load (see attached screenshots, the first two) EXPECTED RESULT H/W decoding works, special modules on GPU used for it, no significant CPU load, not so big GPU load SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Unstable / KDE Plasma on X11 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION hardware used for testing: - laptop: RedmiBook Pro 14S - CPU: AMD Ryzen 5 5500U with Radeon Graphics - GPU: AMD Radeon Graphics (Lucienne), integrated into CPU, no discrete graphics available - RAM: 16GB DDR4 - Display: 14", 2560x1600, 100% sRGB (aka 72% NTSC) video used in testing - Sony Aquarium 4K Demo.mp4 : 3840x2160 (aka 4k), 60 FPS, h.265 (~80 Mb/s), 8bit `amdgpu` proprietary firmware required by GPU drivers is installed, user-space (mesa and so on) libraries required for H/W decoding (both `vaapi` and `vdpau`) are installed too, otherwise h/w decoding would be impossible. h/w decoding is known to work in several players (based on different libraries) and even in different ways (aka using `vaapi` and `vdpau` variations). SMPlayer was chosen for comparison because it is also based on `mpv`. -- You are receiving this mail because: You are watching all bug changes.
