[kdeconnect] [Bug 468400] Layout change in 1.24.0 makes button inaccessible in widescreen and squishes permissions list to 3 lines of text in portrait
https://bugs.kde.org/show_bug.cgi?id=468400 Thomas Baag changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #2 from Thomas Baag --- Sorry. Scrolling works fine. Seems like I messed this up. Sorry again for the inconvenience. Closing the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 468400] New: Layout change in 1.24.0 makes button inaccessible in widescreen and squishes permissions list to 3 lines of text in portrait
https://bugs.kde.org/show_bug.cgi?id=468400 Bug ID: 468400 Summary: Layout change in 1.24.0 makes button inaccessible in widescreen and squishes permissions list to 3 lines of text in portrait Classification: Applications Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: tho...@b2ag.de CC: andrew.g.r.hol...@gmail.com Target Milestone: --- SUMMARY A recent layout change in 1.24.0 makes button inaccessible in widescreen and squishes permissions list to three lines of text in portrait from which one line can be scrolled. Seems like someone overlooked that there can be more than four buttons when testing and those buttons can't be scrolled. STEPS TO REPRODUCE 1. Configure remote commands 2. Rotate phone to wide screen 3. Try to execute remote command OBSERVED RESULT Fail. EXPECTED RESULT Success. SOFTWARE/OS VERSIONS Android app from F-droid 1.24.0 ADDITIONAL INFORMATION Downgrading to 1.23.0 works for me. Please try to value function over form in future development and stop what keeps on happening to KDE. Some devs seem to like making changes so that things look better and break/remove/obstruct things they didn't use in the first place (and seemingly also are totally unaware of). I guess that's why KDE3.5/Trinity is a thing. So please stop breaking things for shiny new looks. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 441487] New: kcm_kscreen sometimes doesn't allow me to move screens
https://bugs.kde.org/show_bug.cgi?id=441487 Bug ID: 441487 Summary: kcm_kscreen sometimes doesn't allow me to move screens Product: KScreen Version: 5.22.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: tho...@b2ag.de Target Milestone: --- SUMMARY Sometimes (I don't know how to reproduce) I'm unable to place screens in kcm_kscreen. STEPS TO REPRODUCE 1. Try to place a screen in a multi-head setup. OBSERVED RESULT Trying to move the screen moves the whole kcm-window. EXPECTED RESULT It should only move the screen box. SOFTWARE/OS VERSIONS Linux: 5.13.12-arch1-1 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 441486] Snapping of screen boxes in kcm_kscreen works different with more than two screens
https://bugs.kde.org/show_bug.cgi?id=441486 --- Comment #1 from Thomas Baag --- Created attachment 141014 --> https://bugs.kde.org/attachment.cgi?id=141014=edit This is what snapping forces me to do when I try to place left screen last -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 441486] New: Snapping of screen boxes in kcm_kscreen works different with more than two screens
https://bugs.kde.org/show_bug.cgi?id=441486 Bug ID: 441486 Summary: Snapping of screen boxes in kcm_kscreen works different with more than two screens Product: KScreen Version: 5.22.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: tho...@b2ag.de Target Milestone: --- Created attachment 141013 --> https://bugs.kde.org/attachment.cgi?id=141013=edit This is the desired configuration (I have to create from left to right still with some struggle) SUMMARY Snapping of screen boxes in kcm_kscreen works agains me when having more than two screens active. STEPS TO REPRODUCE 1. Have more than two screens arranged next to each other but one has a different height. In my case one has 1080 pixel height and two have 1200 pixels. 2. Try to align the one with less height to 0 pixels top. 3. Fail. OBSERVED RESULT I have to place the 1080 height screen first and than place all others after that one. It's especially tricky with a forth screen 90 degrees rotated. EXPECTED RESULT Let my place the screen at top 0 pixels without snapping to the vertical centered position (at 60 pixel). SOFTWARE/OS VERSIONS Linux: 5.13.12-arch1-1 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The problem is somewhat old but did annoy me enough today to create this report. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381000] [Regression] High CPU when background is set to slideshow
https://bugs.kde.org/show_bug.cgi?id=381000 --- Comment #80 from Thomas Baag <tho...@b2ag.de> --- Created attachment 106803 --> https://bugs.kde.org/attachment.cgi?id=106803=edit plasmashell output with qt5-declarative 5.9.1-3 patched with 106799 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381000] [Regression] High CPU when background is set to slideshow
https://bugs.kde.org/show_bug.cgi?id=381000 --- Comment #79 from Thomas Baag <tho...@b2ag.de> --- As this bug report made me aware of high (single thread) CPU usage of plasmashell I now can confirm this part of the bug. CPU usage is substantially higher with desktop slideshow enabled (~30%) than normal (1%-5%) when this bug happens. It's harder to trigger than the memory leak bug. I had to have both screens set to slideshow. Setting picture to change every second helps a lot with triggering it. Still looks like some race condition. With help of GALLIUM_HUD I found redraws go up a lot when the bug strikes. Climbing up to 330 redraws per second as shown here http://imgur.com/a/Y45SQ. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381000] [Regression] High CPU when background is set to slideshow
https://bugs.kde.org/show_bug.cgi?id=381000 --- Comment #77 from Thomas Baag <tho...@b2ag.de> --- Comment 60 fixed the memory leak problem I described in bug 382602. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382602] Video memory leak with desktop configured to slideshow
https://bugs.kde.org/show_bug.cgi?id=382602 --- Comment #3 from Thomas Baag <tho...@b2ag.de> --- qt5-declarative package from Antonio Rojas linked in bug 381000 seems to have fixed the issue for me. Thanks a lot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382602] Video memory leak with desktop configured to slideshow
https://bugs.kde.org/show_bug.cgi?id=382602 Thomas Baag <tho...@b2ag.de> changed: What|Removed |Added Platform|Other |Archlinux Packages --- Comment #1 from Thomas Baag <tho...@b2ag.de> --- broulik.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382602] New: Video memory leak with desktop configured to slideshow
https://bugs.kde.org/show_bug.cgi?id=382602 Bug ID: 382602 Summary: Video memory leak with desktop configured to slideshow Product: plasmashell Version: 5.10.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Desktop Containment Assignee: se...@kde.org Reporter: tho...@b2ag.de CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 106788 --> https://bugs.kde.org/attachment.cgi?id=106788=edit GTT and VRAM usage shown by GALLIUM_HUD VRAM and GTT usage steady increases when using desktop in wallpaper slideshow mode. It doesn't happen directly after starting plasmashell, but I can trigger it in under 60 seconds. What I do: 1. Reset my plasma config mv ~/.config/plasma-org.kde.plasma.desktop-appletsrc ~ 2. Run plasmashell (in my case with GALLIUM_HUD to see VRAM and GTT info) GALLIUM_HUD="requested-VRAM,requested-GTT,VRAM-usage,GTT-usage" plasmashell 3. Set desktop to slideshow, configure a folder with tons of images and keep change interval at 1 second. (4. Bring up some other plasma surfaces which maybe triggers a race condition.) What I see: VRAM usage is increasing with every image up to a point where radeon driver says "no" with "radeon :23:00.0: va above limit (0x00200407 >= 0x0020)". My system: Linux stan 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.5 -- You are receiving this mail because: You are watching all bug changes.
