[frameworks-kidletime] [Bug 328987] Power saving should not trigger if joystick/controller/gamepad is in use
https://bugs.kde.org/show_bug.cgi?id=328987 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468346] Invalid .desktop files can crash plasmashell when trying to edit them from kickoff.
https://bugs.kde.org/show_bug.cgi?id=468346 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468346] New: Invalid .desktop files can crash plasmashell when trying to edit them from kickoff.
https://bugs.kde.org/show_bug.cgi?id=468346
Bug ID: 468346
Summary: Invalid .desktop files can crash plasmashell when
trying to edit them from kickoff.
Classification: Plasma
Product: plasmashell
Version: 5.27.4
Platform: Archlinux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: generic-crash
Assignee: plasma-b...@kde.org
Reporter: david.alejandro.ru...@gmail.com
Target Milestone: 1.0
Created attachment 157985
--> https://bugs.kde.org/attachment.cgi?id=157985=edit
use this to reproduce issue
SUMMARY
Pretty much the title. If the Exec= file of a .desktop file contains ' at the
start and end, AND the application contains switches (--example), plasmashell
will segfault when trying to edit them (right click, "edit application") from
the kickoff menu.
I haven't been able to get debug logs yet, but so far two people I know have
been able to reproduce this issue. A file is attached to this bug report which
should reproduce it.
The main issue here is that that "Edit Application" dialog is what added the
single commas to the start and end of the Exec line, therefore making it
possible for someone to make an application invalid and be unable to edit it if
they're unaware of the location of the desktop file on the filesystem (this
could be a separate bug, let me know)
STEPS TO REPRODUCE
1. Create a .desktop file with an Exec line that starts and ends on a single
comma (') and that contains command line switches (--example)
2. Open kickoff, search the malformed .desktop file and right click it,
selecting Edit Application
OBSERVED RESULT
plasmashell segfaults
EXPECTED RESULT
no crash occurs, instead plasmashell should let
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 6.2.10-arch1-1 (64-bit)
(available in About System)
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
ADDITIONAL INFORMATION
A file is attached to this bug report which should reproduce the issue
described.
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kconfig] [Bug 460260] On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one.
https://bugs.kde.org/show_bug.cgi?id=460260 David Rubio changed: What|Removed |Added Platform|Fedora RPMs |Archlinux --- Comment #10 from David Rubio --- Whoever changed it to Fedora RPMs: i made this report on arch, but it probably includes all distros. Switching back to Arch just because that's where the report was taken from. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 460260] On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one.
https://bugs.kde.org/show_bug.cgi?id=460260 David Rubio changed: What|Removed |Added Keywords||multiscreen, usability -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 460260] On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one.
https://bugs.kde.org/show_bug.cgi?id=460260 --- Comment #2 from David Rubio --- I want to add that this mostly happens with KDE apps. It works for GTK apps, for example. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 460260] On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one.
https://bugs.kde.org/show_bug.cgi?id=460260 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 427875] On a multi screen setup, KDE app windows do not remember size, position, or the screen they were last opened on. For X11 when the left-most display is not the primary
https://bugs.kde.org/show_bug.cgi?id=427875 --- Comment #84 from David Rubio --- (In reply to Nate Graham from comment #83) > Not to my knowledge; let's get a new one going. Can you make sure to write > detailed steps to reproduce in it? Thanks! I filed it on 460260. Let me know if you need anything more on that issue, please. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 460260] New: On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one.
https://bugs.kde.org/show_bug.cgi?id=460260 Bug ID: 460260 Summary: On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one. Classification: Frameworks and Libraries Product: frameworks-kconfig Version: 5.99.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matt...@mjdsystems.ca Reporter: david.alejandro.ru...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY On a multi screen setup on Wayland, KDE app windows do not remember the size they had if the primary monitor is not the leftmost one. It's only if there's a secondary monitor at the left of the primary, it does not happen if there's a secondary monitor at the right of the primary. This is not 427875. This is about only size, and only on Wayland. Was told to make a new report on behalf of https://bugs.kde.org/show_bug.cgi?id=427875#c83 There's a video at the end of this report showcasing the issue in more detail. STEPS TO REPRODUCE 1. Have a multiscreen setup on Wayland 2. Have the primary screen be at the rightmost position (aka have a secondary screen at the left) 3. Open an app 4. Re-size and then close the app 5. Re-open the app OBSERVED RESULT The app will have forgotten the size you set when you resized it, ONLY if there's a monitor at the left of the primary monitor. It will work fine if there's a single monitor at the right of the primary monitor. EXPECTED RESULT App remembers its size properly regardless of where the primary monitor is located. SOFTWARE/OS VERSIONS Linux: 6.0.0-zen1-1-zen KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99 Qt Version: 5.15.6 ADDITIONAL INFORMATION Video of the issue: https://www.youtube.com/watch?v=8Tq37LDZYIU -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460223] Closing IntelliJ IDEA 2022.2.3 crashes kwin_wayland completely
https://bugs.kde.org/show_bug.cgi?id=460223 --- Comment #1 from David Rubio --- Adding that IntelliJ runs as a X11 application. I do not run any X11 applications beside this one (java please add Wayland support...), so I'm not too sure if anything could be going on here. I tried running another app as an X11 app, but closing it worked just fine. Considering the excruciatingly weird circumstances that make this crash (usually involving opening several parent windows, closing them, and then closing the window), I'm not sure how I'd go about reproducing this outside IntelliJ. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460223] Closing IntelliJ IDEA 2022.2.3 crashes kwin_wayland completely
https://bugs.kde.org/show_bug.cgi?id=460223 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com Keywords||wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460223] New: Closing IntelliJ IDEA 2022.2.3 crashes kwin_wayland completely
https://bugs.kde.org/show_bug.cgi?id=460223 Bug ID: 460223 Summary: Closing IntelliJ IDEA 2022.2.3 crashes kwin_wayland completely Classification: Plasma Product: kwin Version: 5.25.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- Created attachment 152694 --> https://bugs.kde.org/attachment.cgi?id=152694=edit stacktrace obtained using GDB SUMMARY Having IntelliJ IDEA running for a while, opening some dialogs, etc (aka working as usual) causes kwin_wayland to crash. This is not reproducible by me by just opening a window and closing it inmediatly, I have to work on it for a while, thus I'm not exactly sure what could trigger it. As you might imagine, this is making work on kwin_wayland excruciatingly difficult, as the whole Wayland session crashing is as good as the entire computer restarting, as everything gets forcefully closed. This is consistent, and has happened several days between this and last week. This also happened with Frameworks 5.98, but I'm on 5.99 now, so that's the current one. Not really sure of what component to pick here. STEPS TO REPRODUCE 1. Open IntelliJ 2. Do some work on it (open dialogs, open class files, commit popups, etc) 3. Close IntelliJ OBSERVED RESULT The entirety of the kwin_wayland session crashes EXPECTED RESULT No crash, or, as a concession, not bring down the entire Wayland session (which kills everything I was working on) SOFTWARE/OS VERSIONS Linux: 6.0.0-zen1-1-zen KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.99 Qt Version: 5.15.6 ADDITIONAL INFORMATION Attached is the stacktrace obtained using GDB. Debug symbols were used for it, but if anything is missing let me know. I'll be glad to provide any information that might be needed. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 427875] On a multi screen setup, KDE app windows do not remember size, position, or the screen they were last opened on. For X11 when the left-most display is not the primary
https://bugs.kde.org/show_bug.cgi?id=427875 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com --- Comment #82 from David Rubio --- While this is Wayland-specific, in Wayland windows do not remember window *size* if there's a secondary monitor... only if the left-most display is not the primary one. This is on Plasma 5.26 (beta) with KDE Frameworks 5.99. Is there any bug tracking this? It's quite an ordeal to have to use my left monitor on the right if I want... usable window sizes, since at 1440p the default windows sizes are tiny. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 431959] Can't unlock screen using KScreenLocker at all -- Password is always incorrect.
https://bugs.kde.org/show_bug.cgi?id=431959 --- Comment #2 from David Rubio --- Going back to KDE Frameworks 5.78 and kscreenlocker 5.20.80 fixes the issue. Since 5.79 is really early work, it's probably a fluke more than anything, but just putting this one the table for clarification. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432477] [git version] Jaggy icons when hovering over them (or not)
https://bugs.kde.org/show_bug.cgi?id=432477 --- Comment #7 from David Rubio --- (In reply to Michail Vourlakos from comment #6) > Definitely a PlasmaCore.IconItem issue... I moved the Tasks codepage to > Kirigami.Icon(s) and everything is painted correctly in my system. Yup, it's fine now :) On 08118d531c27588716d28f835cf7891782f8a439: https://i.imgur.com/hnHASpt.png (which is good!) I guess you could file a bug about PlasmaCore.IconItem. I wouldn't know how to word it. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432477] [git version] Jaggy icons when hovering over them (or not)
https://bugs.kde.org/show_bug.cgi?id=432477 --- Comment #4 from David Rubio --- (In reply to Michail Vourlakos from comment #3) > You can try the latest commit, it is trying to workaround and make things a > bit more affordable. It is trying to be crispy for normal size and smooth > in-between At 9547509ba94e2315ba05f52a10ce42d86c7a9210: https://imgur.com/vulGQ2J.png -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432477] [git version] Jaggy icons when hovering over them (or not)
https://bugs.kde.org/show_bug.cgi?id=432477 --- Comment #2 from David Rubio --- With "icon zoom" on hover, it seems to pretty much go away, but the animation is super jaggy. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432477] [git version] Jaggy icons when hovering over them (or not)
https://bugs.kde.org/show_bug.cgi?id=432477 --- Comment #1 from David Rubio --- Icon being hovered: https://i.imgur.com/mstlJef.png -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432477] New: [git version] Jaggy icons when hovering over them (or not)
https://bugs.kde.org/show_bug.cgi?id=432477 Bug ID: 432477 Summary: [git version] Jaggy icons when hovering over them (or not) Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- SUMMARY Icons on the tasks applet look really jaggy if you hover over it, and sometimes without hovering. Sometimes just doing latte-dock --replace will fix the icons appearing jagged when not hovering over them, but hovering over them again will make them jaggy. STEPS TO REPRODUCE 1. Dock with absolute size 48px, padding shouldn't matter, but I use 15% OBSERVED RESULT Before hovering over them: https://i.imgur.com/GpvpAAC.png After hovering over them: https://i.imgur.com/8R15adr.png Sometimes it looks like on the 2nd pic without hovering. Then you can just --replace and it might fix itself. EXPECTED RESULT Sharp icons. SOFTWARE/OS VERSIONS Linux: 5.10.12 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.78 Qt Version: 5.15.2 ADDITIONAL INFORMATION Last working commit in latte: d46864e0ade1f0edee7a6bc4b9f6a219baea79aa According to https://bugs.kde.org/show_bug.cgi?id=432444#c5, it might be a PlasmaCore.IconItems issue. If so please move it to the appropiate area. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432444] Blurry icons on latte tasks (on latest -git)
https://bugs.kde.org/show_bug.cgi?id=432444 --- Comment #6 from David Rubio --- (In reply to Michail Vourlakos from comment #5) > yeah open it... > and we can forward it to Plasma afterwards. Latte is now using > PlasmaCore.IconItems in roundToIconSize:false state so Latte can not fix > this any more... > > Personally I can not do any better. It might be on latte to be fair. The icons look *okay*, but if you hover over them then the icon looks bad and goes all jaggy and artifact-y (Parabolic effect issue?). I'll open the bug report with more details and a video. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432444] Blurry icons on latte tasks (on latest -git)
https://bugs.kde.org/show_bug.cgi?id=432444 --- Comment #4 from David Rubio --- (In reply to Michail Vourlakos from comment #3) > please try again, it should be fixed now. The should look crispy when the > tasks an not hovered and when a task is fully zoomed through the parabolic > effect. Well, now they're not blurry, but it's definitely still not quite there: https://i.imgur.com/8R15adr.png That icon definitely shouldn't look like that. Went back to d46864e0ade1f0edee7a6bc4b9f6a219baea79aa and it looks fine. Well. Might be worth another bug report since now it's not blur, it's... jaggy? -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432444] Blurry icons on latte tasks (on latest -git)
https://bugs.kde.org/show_bug.cgi?id=432444 --- Comment #1 from David Rubio --- On d46864e0ade1f0edee7a6bc4b9f6a219baea79aa setting the dock size to 47x or 46x (or 49x) still results in a midly-sharp icon. On latest git it's definitely way way blurrier. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 432444] New: Blurry icons on latte tasks (on latest -git)
https://bugs.kde.org/show_bug.cgi?id=432444 Bug ID: 432444 Summary: Blurry icons on latte tasks (on latest -git) Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- SUMMARY Last working commit: d46864e0ade1f0edee7a6bc4b9f6a219baea79aa Having a dock with absolute size 48px should show perfectly scaled 48x icons on the tasks applet. In latte-dock git, probably after ba502fa5951f9c5688d0ff6db06a25883cca5d7d, the icon size is not actually 48x (maybe 47x?) and the icon is blurry in result. STEPS TO REPRODUCE 1. Dock with absolute size 48x, padding shouldn't matter, but I use 15% OBSERVED RESULT Blurry icons EXPECTED RESULT Icons look sharp just like in the last working commit (d46864e0ade1f0edee7a6bc4b9f6a219baea79aa) SOFTWARE/OS VERSIONS Linux: 5.10.12 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.78 Qt Version: 5.15.2 ADDITIONAL INFORMATION Went back to commit d46864e0ade1f0edee7a6bc4b9f6a219baea79aa and it's fine. Tested 8ae3b4ecfb08c4c90fef3445aa1b1863b951644d and it's broken. It probably broke before that commit, but I didn't try compiling every commit in between. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 431959] Can't unlock screen using KScreenLocker at all -- Password is always incorrect.
https://bugs.kde.org/show_bug.cgi?id=431959 --- Comment #1 from David Rubio --- Created attachment 135073 --> https://bugs.kde.org/attachment.cgi?id=135073=edit /usr/lib/libexec/kscreenlocker_greet --testing logs -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 431959] New: Can't unlock screen using KScreenLocker at all -- Password is always incorrect.
https://bugs.kde.org/show_bug.cgi?id=431959 Bug ID: 431959 Summary: Can't unlock screen using KScreenLocker at all -- Password is always incorrect. Product: kscreenlocker Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcheckpass Assignee: plasma-b...@kde.org Reporter: david.alejandro.ru...@gmail.com CC: bhus...@gmail.com Target Milestone: --- SUMMARY On a full plasma -git session (Frameworks and Plasma Workspace/Desktop and everything else from git master), kscreenlocker(-git) will *always* say authentication failure. Trying to get any proper information by using the test greeter application is quite useless as it'll just say "Authentication Failure". Logging anywhere else works. TTY works, so I can just switch to a tty and type loginctl unlock-session 1, but this is not ideal. I can also "switch user" to my own user and it'll unlock the session just fine. I checked all the culprits: capslock is off, so is anything else that could make this not work. I actually even clicked "show password" and looked at it, the password is correct. STEPS TO REPRODUCE 1. Try to unlock your computer on -git plasma OBSERVED RESULT Unlock doesn't work at all. EXPECTED RESULT Being able to unlock my session with the correct password. SOFTWARE/OS VERSIONS Linux: 5.10.9 KDE Plasma Version: 5.21.80 KDE Frameworks Version: 5.79 Qt Version: 5.15.2 ADDITIONAL INFORMATION Whole session is git master. KScreenLocker test greeter logs will just display "Authentication Failure" no matter what. This has been reproduced by all users of the plasma-git session from chaotic-aur. The PKGBUILD used for kscreenlocker is https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=kscreenlocker-git, but trying just the normal kscreenlocker (not from git) doesn't work either. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 428613] Doesn't communicate to the user what's going on when the session has been locked due to excessive password attempt when pam_deny is in use
https://bugs.kde.org/show_bug.cgi?id=428613
David Rubio changed:
What|Removed |Added
CC||david.alejandro.rubio@gmail
||.com
--- Comment #10 from David Rubio ---
(In reply to Wachid Adi Nugroho from comment #8)
> Can't unlock on kscreenlocker, it said "Unlocking failed" even though I have
> entered the password correctly
>
> Operating system : Arch Linux x86_64
> kscreenlocker-git: v5.19.90.r13.g8c267ff-1
>
> > ❯ /usr/lib/libexec/kscreenlocker_greet --testing
> > qt.qpa.wayland: qtvirtualkeyboard currently is not supported at
> > client-side, use QT_IM_MODULE=qtvirtualkeyboard at compositor-side.
> > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:67:
> > TypeError: Property 'setAction' of object
> > ScreenLocker::WallpaperIntegration(0x5587add281c0) is not a function
> > Locked at 1610733974
> > file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:118:9:
> > QML Image: Cannot open: file:///usr/share/wallpapers/Next
> > qt.svg: :406:376: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :407:130: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :408:130: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :408:393: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :409:130: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :410:129: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :411:129: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :412:129: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :413:129: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :413:379: Could not add child element to parent element
> > because the types are incorrect.
> > qt.svg: :413:631: Could not add child element to parent element
> > because the types are incorrect.
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "en_US" .
> > Search paths ("/usr/share/qt/qtvirtualkeyboard/hunspell",
> > "/usr/share/hunspell", "/usr/share/myspell/dicts")
> > Authentication failure
> > Authentication failure
> > Authentication failure
> > Authentication failure
> > Authentication failure
I see the same issue. I can login on TTY just fine, I can login anywhere just
fine, but kscreenlocker says that. I guess that's worth another bug report
though, so I'll file it.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 431643] Aurorae decoration engine is inefficient
https://bugs.kde.org/show_bug.cgi?id=431643 --- Comment #5 from David Rubio --- (In reply to David Edmundson from comment #4) > From the hotspot it appears the FrameSVGItem is the worst offender of those > two issues. > > Copying some context from the other report. > > * FrameSVGItem is a 9-tile system > > * For each new size we can stretch (fastest), tile (fast) or re-render the > SVG into a new texture (super slow), based on hints > > * The default (for compatibility from Plasma 4 times) is to re-render > > * We are rendering /the entire/ frame behind the window. This is mostly the > centre tile > > > Setting > +tileCenter = true; > in framesvgitem.cpp:572 > > I don't think would break many themes. With most of the themes I could test, it looks to work okay. It's also waay faster. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 --- Comment #6 from David Rubio --- As a small heads-up, this also happens to kscreenlocker. If I have my mouse focused on screen A, the password * chars will start to be shown on screen B. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424795] "Open Link" action doesn't focus browser window
https://bugs.kde.org/show_bug.cgi?id=424795 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431643] Aurorae decoration engine is inefficient
https://bugs.kde.org/show_bug.cgi?id=431643 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 417716] With non-breeze aurorae theme and "No Borders" setting it's no longer possible to get resize cursor on titlebar's upper edge
https://bugs.kde.org/show_bug.cgi?id=417716 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #31 from David Rubio --- (In reply to Vlad Zahorodnii from comment #30) > (In reply to David Rubio from comment #27) > > It fixes it for me. Also the maximize animation is way smoother for some > > weird reason. > > > > But yeah, that fixed the issue for what I could test (by spamming the > > maximize button like 30 times) > > Thanks, that's great. I'll create a generic bug report to track performance > issues in Aurorae and close this one. Thanks you very much. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #28 from David Rubio --- (In reply to David Edmundson from comment #24) > Turns out the center is still visible slightly in the top. We can't just > disable it. > > It's fixable with a oneline in the theme, adding an element with the ID > hint-tile-center. I can't think of any super easy fix plasma side. Would that element have to be empty or does it need to contain something? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #27 from David Rubio --- (In reply to Vlad Zahorodnii from comment #26) > @David Rubio Can you please check whether 2d1994e0669 made things better? It fixes it for me. Also the maximize animation is way smoother for some weird reason. But yeah, that fixed the issue for what I could test (by spamming the maximize button like 30 times) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #18 from David Rubio --- Created attachment 134863 --> https://bugs.kde.org/attachment.cgi?id=134863=edit kwinrc (In reply to Vlad Zahorodnii from comment #17) > > setting it to the slowest animation speed notch still plays > Make sure that you don't have AnimationDurationFactor in your kwinrc file. I don't. I'm attaching my kwinrc. Anything odd in here? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #16 from David Rubio --- (In reply to Vlad Zahorodnii from comment #15) > On my machine, the maximize animation is choppy no matter where I click. The animation is definitely choppy even when double-clicking. When I click the maximize button the animation outright doesn't play at all for some cursed reason (setting it to the slowest animation speed notch still plays it instantly instead of it taking forever). I'd blame the theme but it works before 507. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #14 from David Rubio --- I find it really weird that the animation works only if I double click the titlebar, but clicking the maximize button does absolutely nothing. I tried reverting the cubic animation curve and that didn't do it either. Video: https://youtu.be/9prO3kiB6-w -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #12 from David Rubio --- (In reply to David Rubio from comment #11) > (In reply to Vlad Zahorodnii from comment #9) > > The problem is that aurorae decoration engine is inefficient. KWin gets the > > data from a texture where Aurorae composites the decoration and uploads it > > to another decoration texture atlas. Performance-wise, that's not good. By > > delaying compositing, we just made it more easier to miss the next vblank. > > Perhaps, we should increase the latency policy to "extremely high" to work > > around this bug until the performance hog is properly fixed. > > I did set it to extremely high (well, as high as it went), and the problem > is still there, just less so. It's just really annoying, but I don't think > that much people use Aurorae, thankfully? :P > > I just can't live without the theme I've used for so many years, but that's > me. Weirdly enough, double-clicking the titlebar plays the animation just fine 90% of the times, but clicking the "maximize" button barely plays it at all. Dunno what sort of difference that'd even make. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #11 from David Rubio --- (In reply to Vlad Zahorodnii from comment #9) > The problem is that aurorae decoration engine is inefficient. KWin gets the > data from a texture where Aurorae composites the decoration and uploads it > to another decoration texture atlas. Performance-wise, that's not good. By > delaying compositing, we just made it more easier to miss the next vblank. > Perhaps, we should increase the latency policy to "extremely high" to work > around this bug until the performance hog is properly fixed. I did set it to extremely high (well, as high as it went), and the problem is still there, just less so. It's just really annoying, but I don't think that much people use Aurorae, thankfully? :P I just can't live without the theme I've used for so many years, but that's me. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #42 from David Rubio --- Definitely too late to comment, but the patch mentioned fixed it for me too. It's super smooth now. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #34 from David Rubio --- Created attachment 134855 --> https://bugs.kde.org/attachment.cgi?id=134855=edit Last one was wrong, this one is the actual file. Oops. Sorry. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #33 from David Rubio --- Created attachment 134854 --> https://bugs.kde.org/attachment.cgi?id=134854=edit Attaching KWin timestamp log. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #32 from David Rubio --- (In reply to Vlad Zahorodnii from comment #23) > Created attachment 134845 [details] > patch > > No, there is not. Now I wonder what presentation timestamps kwin receives > via swap events. > > Can you run kwin_x11 --replace (in terminal) with the attached patch applied > and post its output here? Animations are way, way smoother now. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #14 from David Rubio --- Though, after changing what I told you, VSync is still absolutely wrong on XWayland apps: https://i.imgur.com/df82B3i.png And Chromium running natively on Wayland isn't any better: https://i.imgur.com/chVQSBR.png This is on a 144Hz monitor, aswell. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #13 from David Rubio --- (In reply to David Rubio from comment #12) > Oh wow. This is super cursed. I tried changing the common denominator > between my laptop and my desktop: the kernel. > > Turns out on my desktop I have a kernel optimized for gaming (say, > linux-tkg). Well, turns out KWin doesn't like that. At all. Specially on > Wayland. > > Changing to the default linux kernel makes the stutter way less than a > second or two freeze, which is super cursed. There's still a lot of frame > skips if there's any kind of significant CPU usage, but this whole report > seemed to be skewed by that custom kernel using the MuQSS scheduler. > > I don't think this is completely on KWin's side, so I might just say close > it. But as a random test I tested GNOME and it was completely fine. I wonder > what causes this difference. > > I'm sorry for the long report to just come to this conclusion, but might be > worth keeping in mind for future issues with KWin on Wayland. Reverting the > commits you told me to revert did help with 431415 at least. > > Thanks you. You can resolve this if you see fit. To be clear: there's still frame skips and stuttering. It's just not as bad as the original video shows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #12 from David Rubio --- Oh wow. This is super cursed. I tried changing the common denominator between my laptop and my desktop: the kernel. Turns out on my desktop I have a kernel optimized for gaming (say, linux-tkg). Well, turns out KWin doesn't like that. At all. Specially on Wayland. Changing to the default linux kernel makes the stutter way less than a second or two freeze, which is super cursed. There's still a lot of frame skips if there's any kind of significant CPU usage, but this whole report seemed to be skewed by that custom kernel using the MuQSS scheduler. I don't think this is completely on KWin's side, so I might just say close it. But as a random test I tested GNOME and it was completely fine. I wonder what causes this difference. I'm sorry for the long report to just come to this conclusion, but might be worth keeping in mind for future issues with KWin on Wayland. Reverting the commits you told me to revert did help with 431415 at least. Thanks you. You can resolve this if you see fit. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #11 from David Rubio --- Nevermind. I started playing a video on Youtube and the stutter on Wayland is back full throttle even on those commit hashes. X11 seems... fine, somehow. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #8 from David Rubio --- Reverting: kwayland-server: f67daa0711584058a8fefda76e898fe58d53ace7 kwin: 26b249061ee49dacc29320f93984de3d35012e1f to those commit hashes makes this issue dissapear. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #10 from David Rubio --- (In reply to Vlad Zahorodnii from comment #9) > Can you test kwayland-server and kwin at the following commits > > kwayland-server: f67daa0711584058a8fefda76e898fe58d53ace7 > kwin: 26b249061ee49dacc29320f93984de3d35012e1f > > this is just to rule out the changes prior to the compositing scheduling > rewrite. There's somehow still stutter. This makes me wonder why 5.20.5 works completely fine (just tested that aswell). The stutter is way less, though. There's some stutter, but it doesn't last nearly as long, I can type just fine without the compositor freezing while I'm typing, and the mouse doesn't freeze every 10 seconds or so. X11 has 0 issues with those commits aswell. In short, reverting to those commits makes it better, but there's still *some* stutter. Also 431415 is not reproducible to me anymore after reverting to those commits. The maximize animation now works 100% of the times. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #8 from David Rubio --- After a while of testing and a good minute or two of moving windows, I managed to record it happening on X11 aswell, where there's only one RenderLoop: https://youtu.be/GOkB5Wjx8Ac It's way more rare on X11. And on X11 the mouse keeps moving so it's somehow less annoying. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #7 from David Rubio --- I tried removing my kwinrc just in case. It didn't make a difference either, just in case. Without a kwinrc the Wayland session took a whole 2 minutes to start. That might be worth another bug report. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #6 from David Rubio --- (In reply to Vlad Zahorodnii from comment #5) > I wonder if it has anything to do with per-screen rendering. If there is > only one monitor connected, does the screen still occasionally freeze? Just tried that, sadly it makes no change :( -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #4 from David Rubio --- Also KDE Frameworks version should be 5.79, oops. Dunno if anyone can edit *that* part. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #3 from David Rubio --- (In reply to Vlad Zahorodnii from comment #2) > Odd... Does kwin/wayland 5.20.x suffer from this issue as well or is it a > regression? 5.20.5 is completely fine. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 David Rubio changed: What|Removed |Added OS|Other |Linux -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 --- Comment #1 from David Rubio --- For additional info, my specs are as follows: Ryzen 5 2600, RX 480, 16GB of RAM My laptop, where this doesn't happen (for some reason) it's Ryzen 5 3500U, Vega 8, 16GB of RAM I have both a 144Hz and 60Hz monitor on my main computer. Don't know how much of a difference this'd make on the issue. On further look at the video, this looks more like a lot of dropped frames. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431546] New: Stutter on Wayland session
https://bugs.kde.org/show_bug.cgi?id=431546 Bug ID: 431546 Summary: Stutter on Wayland session Product: kwin Version: git master Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- Created attachment 134805 --> https://bugs.kde.org/attachment.cgi?id=134805=edit The usual qdbus org.kde.KWin /KWin supportInformation SUMMARY Animations both on X11 and Wayland stutter, no matter the animation smoothness setting. Setting the "force smoothest animation" setting has no effect on making this any better. On Wayland, *everything* stops. Mouse movement, typing, everything. Nothing seems to be excluded from stuttering every 10 seconds or so for about half a second up to 2 seconds. Specially noticeable on mouse movement. On X11 it's not as extreme. It does stutter, but it doesn't pause *everything* when it does so, so I can see what I'm typing, I can move my mouse, etc. On Wayland the compositor just freezes everything every 10 or 15 seconds for like half a second or so. It's extremely bad. Video of the issue: https://youtu.be/5L_kVV2JGPU STEPS TO REPRODUCE 1. Install latest KWin master 2. Start wayland session OBSERVED RESULT 3. Everything stutters a lot. This seems to be hit-and-miss. On my laptop it's *fine*. On my PC it's horribly bad. And my PC is definitely more powerful than my lappy :p I got a video of it: https://youtu.be/5L_kVV2JGPU EXPECTED RESULT At the very least not this amount of stutter, but no stutter would be nice. Mouse movement not stopping. Being able to type a sentence without the compositor stuttering mid-sentence and not rendering what I'm typing until the (1 second or 2 second long) stutter stops SOFTWARE/OS VERSIONS Linux: 5.10.6 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.19 Qt Version: 5.15.2 ADDITIONAL INFORMATION This is unrelated to 431509 and 431449. Got told to make a new bug, so please don't mark it as duplicate :( -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #12 from David Rubio --- Video of the issue: https://youtu.be/5L_kVV2JGPU Keep in mind this does happen on X11, but it's both not as incredibly bad, and it doesn't pause your mouse movement or stop rendering what you're typing, which is *incredibly* bad. (Also there should be an edit comment option ;w;) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #11 from David Rubio --- (In reply to David Rubio from comment #9) > Okay, I tried "force smoothest animations" and I still saw lag. So I ran > VSync tester and... I'm not crazy, everything is stuttering a LOT. > > I was like okay I might have to turn it a notch more. I will. It didn't make > a dent, everything is still absolutely not-having-it, and this is on > Wayland, both for Wayland and X11 clients, VSyncTester has the same effect > on either. > > Proof: https://i.imgur.com/P9kUMdz.png On X11 it's not as extreme. It does stutter, but it doesn't pause *everything* when it does so, so I can see what I'm typing, I can move my mouse, etc. On Wayland the compositor just freezes everything every 10 or 15 seconds for like half a second or so. It's extremely bad. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 --- Comment #10 from David Rubio --- (In reply to David Rubio from comment #9) > Okay, I tried "force smoothest animations" and I still saw lag. So I ran > VSync tester and... I'm not crazy, everything is stuttering a LOT. > > I was like okay I might have to turn it a notch more. I will. It didn't make > a dent, everything is still absolutely not-having-it, and this is on > Wayland, both for Wayland and X11 clients, VSyncTester has the same effect > on either. > > Proof: https://i.imgur.com/P9kUMdz.png I'm running an AMD RX 480. So the env variable sadly makes no difference to me. On Wayland I can tell the stuttering as I'm typing this and every 5 words it stops rendering me typing them... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431509] All animation laggy
https://bugs.kde.org/show_bug.cgi?id=431509 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com --- Comment #9 from David Rubio --- Okay, I tried "force smoothest animations" and I still saw lag. So I ran VSync tester and... I'm not crazy, everything is stuttering a LOT. I was like okay I might have to turn it a notch more. I will. It didn't make a dent, everything is still absolutely not-having-it, and this is on Wayland, both for Wayland and X11 clients, VSyncTester has the same effect on either. Proof: https://i.imgur.com/P9kUMdz.png -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431449] set new latency contr to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 --- Comment #14 from David Rubio --- (In reply to tempel.julian from comment #11) > The difference between "Balance of latency and smoothness" and "prefer > smoother animations" seems at least to be less with 125Hz mouse polling rate > vs. 1000Hz and 85Hz display refresh rate. However, it's a bit hard to tell, > as the 125Hz polling rate look really bad in general. I really think the > goal should be to make it as good as possible with 1000Hz. > > Also, I think it would be really unfortunate to roll out Plasma 5.21 with > default settings that wouldn't suite a substantial part of the user base > well (as both David Rubio and me have issues with very different refresh > rates), especially if there's the chance to basically avoid the issue for > free with slightly different "golden numbers". I have a 144Hz monitor, so 125Hz polling rate actually does look really bad :P But yeah, smoothness of animations and stuttering is definitely more noticeable on my 144Hz monitor than in my 60Hz monitor. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431449] set new latency contr to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 --- Comment #12 from David Rubio --- 431509 might also just be this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431449] set new latency contr to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 --- Comment #13 from David Rubio --- (In reply to David Rubio from comment #12) > 431509 might also just be this. At least in part, but it seems like it's not as cut clear and might be different :p -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431449] set new latency contr to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 --- Comment #9 from David Rubio --- Ah, if I move it slowly the Hz goes down. (In reply to David Rubio from comment #8) > evhz: > Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 906Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 898Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz > Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 890Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 880Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 872Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 861Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 854Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 842Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 830Hz > Logitech G203 Prodigy Gaming Mouse: Latest 125Hz, Average 817Hz > Logitech G203 Prodigy Gaming Mouse: Latest 3Hz, Average 801Hz > Logitech G203 Prodigy Gaming Mouse: Latest90Hz, Average 787Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 776Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 766Hz > Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 753Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 746Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 735Hz > Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 730Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 719Hz > Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 706Hz > Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 694Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 686Hz > Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 686Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 674Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 664Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 652Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 642Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 634Hz > Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 626Hz > Logitech G203 Prodigy Gaming Mouse: Latest 166Hz, Average 613Hz > Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 601Hz > Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 591Hz > > Should be stuck at 1000Hz, but guess not. After re-setting it to 1000Hz, it's now stuck at 1000Hz, lol Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 1000Hz Logitech G203 Prodigy Gaming Mouse: Lates
[kwin] [Bug 431449] set new latency contr to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 --- Comment #8 from David Rubio --- evhz: Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 906Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 898Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 890Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 890Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 880Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 872Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 861Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 854Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 842Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 830Hz Logitech G203 Prodigy Gaming Mouse: Latest 125Hz, Average 817Hz Logitech G203 Prodigy Gaming Mouse: Latest 3Hz, Average 801Hz Logitech G203 Prodigy Gaming Mouse: Latest90Hz, Average 787Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 776Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 766Hz Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 753Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 746Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 735Hz Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 730Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 719Hz Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 706Hz Logitech G203 Prodigy Gaming Mouse: Latest 200Hz, Average 694Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 686Hz Logitech G203 Prodigy Gaming Mouse: Latest 1000Hz, Average 686Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 674Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 664Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 652Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 642Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 634Hz Logitech G203 Prodigy Gaming Mouse: Latest 500Hz, Average 626Hz Logitech G203 Prodigy Gaming Mouse: Latest 166Hz, Average 613Hz Logitech G203 Prodigy Gaming Mouse: Latest 250Hz, Average 601Hz Logitech G203 Prodigy Gaming Mouse: Latest 333Hz, Average 591Hz Should be stuck at 1000Hz, but guess not. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431450] git-master regression: Alt + Tab out of Wine DXVK fullscreen windows makes it freeze
https://bugs.kde.org/show_bug.cgi?id=431450 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com --- Comment #1 from David Rubio --- Created attachment 134748 --> https://bugs.kde.org/attachment.cgi?id=134748=edit Attaching the usual qdbus org.kde.KWin /KWin supportInformation As this one is a more general report, maybe worth merging the content of 431441 into this one. I can confirm this issue. Video: https://www.youtube.com/watch?v=xwJplgxeZyQ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431449] set new latency option to "prefer smoother animations" by default to prevent stutter
https://bugs.kde.org/show_bug.cgi?id=431449 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com --- Comment #2 from David Rubio --- The stutter in the default option is specially noticeable on Wayland. The compositor stutters like crazy on my (midly old, arguably...) RX 480. Anything that's not "prefer smoother animations" would inevitably cause even the cursor to stutter (which is super annoying), and even on that setting it will inevitably stutter randomly, making so the cursor stops moving completely for a second or so. On X doing "prefer smoother animations" works fine and I have no stutter. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 --- Comment #5 from David Rubio --- (In reply to Vlad Zahorodnii from comment #4) > Kickoff and KRunner position themselves. If they do it wrong, it's a > plasmashell bug. > > As for osu! and Firefox, they most likely position themselves on a wrong > monitor. Either way, Firefox is placed as expected when running with native > Wayland support. Given that these are two separate issues, I'll move this > bug to plasmashell as it's mostly about kickoff and krunner. You're right. Thanks for moving it to the correct category :) osu! runs on XWayland, so I guess it's a similar issue. Firefox on native wayland does position itself on the wrong monitor to me, but seems like only if I start it maximized. I'll file the bug upstream if you think that part it's a Firefox bug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431441] Minimizing some fullscreen windows causes the screen to appear frozen
https://bugs.kde.org/show_bug.cgi?id=431441 --- Comment #1 from David Rubio --- I *thought* it might have been because I had keep thumbnails to always, but I set it to Never to test, and I can get the same result even like so. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #7 from David Rubio --- (In reply to David Rubio from comment #5) > (In reply to Vlad Zahorodnii from comment #4) > > Cannot reproduce. > > > > I wonder if kwin has a huge frame drop. Can you reduce the animation speed > > in the system settings? > > I tried the minimum speed and the minimize animation still only played > around 1/4th of the times I tried. > I put the animation at the slowest notch. Besides systemsettings5 crashing inmediatly after that (report coming...) the animation definitely wasn't playing. Sometimes it would, and it would be unsufferably slow (as you would expect from it being set at the slowest speed), but when it didn't play Maximize was instant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431441] New: Minimizing some fullscreen windows causes the screen to appear frozen
https://bugs.kde.org/show_bug.cgi?id=431441 Bug ID: 431441 Summary: Minimizing some fullscreen windows causes the screen to appear frozen Product: kwin Version: git master Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- SUMMARY When I minimize the game osu! (https://osu.ppy.sh) running under wine, KWin on X11, whether the compositor is enabled or not, will show weird effects and not show any other application (nor the game again) when you alt+tab. This used to happen before on stable when you did this with the compositor enabled. Now it happens even with the compositor disabled. STEPS TO REPRODUCE 1. Open osu! 2. Minimize osu! OBSERVED RESULT KWin won't show any windows and there will be a ghost game window on top of everything but the Alt+Tab dialog and KRunner. EXPECTED RESULT The window minimizes correctly. SOFTWARE/OS VERSIONS Linux: 5.10.4 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.79 Qt Version: 5.15.2 ADDITIONAL INFORMATION Video: https://www.youtube.com/watch?v=xwJplgxeZyQ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #6 from David Rubio --- Also for CSD windows it also plays 100% of the times. It's only when the window is decorated by Aurorae. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #5 from David Rubio --- (In reply to Vlad Zahorodnii from comment #4) > Cannot reproduce. > > I wonder if kwin has a huge frame drop. Can you reduce the animation speed > in the system settings? I tried the minimum speed and the minimize animation still only played around 1/4th of the times I tried. There's a lot of frame drops on KWin Wayland master, but this doesn't seem to be a frame drop here, as even with the minimum animation speed the minimize animation is instant. Thing is, like one in 10 times it would *actually* play, so I know it's *active*. This does NOT happen with Breeze, so for me it looks to be Aurorae-specific, but I could repro it with basically any aurorae theme, all the time. I tried on 5.20.5 and the maximize animation plays fine 100% of the times. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 --- Comment #3 from David Rubio --- The game osu! also always opens in the wrong monitor, aka any monitor where the cursor is *not* located at. Firefox too, sometimes. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #3 from David Rubio --- If you try to replicate this issue, this *might* work sometimes, then out of nowhere the effect will stop playing completely, then start again. Try using your computer for 10 minutes or so with an Aurorae theme on Wayland, and you ought to hit it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #2 from David Rubio --- Video of the issue: https://www.youtube.com/watch?v=HS4vYuRlL1I -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 --- Comment #1 from David Rubio --- Created attachment 134725 --> https://bugs.kde.org/attachment.cgi?id=134725=edit qdbus org.kde.KWin /KWin supportInformation -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431415] New: Maximize animation does not work on Wayland
https://bugs.kde.org/show_bug.cgi?id=431415 Bug ID: 431415 Summary: Maximize animation does not work on Wayland Product: kwin Version: git master Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: aurorae Assignee: kwin-bugs-n...@kde.org Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- SUMMARY Maximize animation does not work when using Aurorae themes on Wayland. Switching to Breeze makes it work properly again. STEPS TO REPRODUCE 1. Switch to an Aurorae theme 2. Minimize/Maximize a window a few dozen times OBSERVED RESULT The animation plays rarely, and most of the times it doesn't play at all. This was tested with the Qogir Aurorae theme and Plastik. EXPECTED RESULT The Maximize animation should play 100% of the times. SOFTWARE/OS VERSIONS Linux: KDE Plasma Version: 5.20.80 (plasma-desktop git) KDE Frameworks Version: 5.79 Qt Version: 5.15.2 ADDITIONAL INFORMATION Built from git master today. Everything from KWin down to plasma-desktop is built from master. Commit built on plasma-desktop is a274b24e29feebdfac16d7ae262a21cf14710896, commit built on KWin is 68a7daff58a4f34c48f0cb23ed0b49d04d255934 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 --- Comment #2 from David Rubio --- OBSERVED RESULT KRunner and other windows (kickoff, for example) open on the monitor where the mouse is NOT at. Sorry, I filed the bug at 4AM, and the observed result should say that ;w; -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430524] Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 --- Comment #1 from David Rubio --- Here's a video outlining the issue: https://www.youtube.com/watch?v=Zgf5tCjAJqQ=youtu.be Right now I'm running MR 507, *but* on KWin master without 507 applied, the same thing happens. Same on KWin 5.20.4 directly from Arch's repos. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430524] New: Windows and Kickoff / KRunner opens in the wrong monitor
https://bugs.kde.org/show_bug.cgi?id=430524 Bug ID: 430524 Summary: Windows and Kickoff / KRunner opens in the wrong monitor Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: david.alejandro.ru...@gmail.com Target Milestone: --- Created attachment 134167 --> https://bugs.kde.org/attachment.cgi?id=134167=edit qdbus org.kde.KWin /KWin supportInformation SUMMARY Windows and Kickoff / KRunner opens in the wrong monitor under Wayland. This does NOT happen on X11. I have two monitors: HDMI-A-1, and HDMI-A-2, in the following order [HDMI-A-2 HDMI-A-1], with my primary (as in, the monitor I use!) being HDMI-A-1. KRunner will *always* open in my second screen (HDMI-A-2). Always, so will Kickoff if it's on two panels. This happens using either KScreen, KDisplay/Disman and KScreen directly from Git master. STEPS TO REPRODUCE 1. Dual monitor system 2. Have main monitor to the right of the monitor you use 3. Use "active screen follows mouse" 4. Everything opens on the secondary monitor OBSERVED RESULT KRunner and other windows (kickoff, for example) open on the monitor where the mouse is at. EXPECTED RESULT A lot of windows open on the "secondary" monitor SOFTWARE/OS VERSIONS Linux: Linux 5.10.1-arch1 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION KWin built from Git master to test if this happened on master. It does. -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 400929] kwallet-pam errors when logging into Plasma from lightdm
https://bugs.kde.org/show_bug.cgi?id=400929 --- Comment #15 from David Rubio --- (In reply to Albert Astals Cid from comment #14) > (In reply to David Rubio from comment #12) > > (In reply to David Rubio from comment #11) > > > (In reply to Albert Astals Cid from comment #10) > > > > The patches are wrong, they change the behaviour of two things that are > > > > not > > > > released in sync (kwalletd and pam-kwallet), so they would break every > > > > single user for a while until everyone was using the new version, > > > > doesn't > > > > seem like a reasonable solution. > > > > > > > > Maybe instead of putting pressure here you'll could put pressure in > > > > https://github.com/canonical/lightdm/issues/134 > > > > > > Ah. Fair. > > > Well, this same error appears if you use KWallet on literally anything > > > other > > > than SDDM, so it's 100% not only a lightdm error > > > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > > > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > > > feels like a KWallet error for sure. > > > > > > I'll chime in there, though :) > > > > Oh. I read the bug report now. Well, one question would be why it doesn't > > work with startx either, even if PAM is configured to open the wallet. > > I've no idea and no interest in debugging that. If you're interested, ask > yourself who is loading pam_kwallet5.so before X starts? When sddm it's > sddm, when gdm it's gdm, when lightdm is lightdm, if you're not using any of > those, who is doing it? Usually to use PAM with startx (as far as I'm aware) you have to load it before X starts, which might be an issue here if kwallet5 requires X (anything special that makes it require such?) -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 400929] kwallet-pam errors when logging into Plasma from lightdm
https://bugs.kde.org/show_bug.cgi?id=400929 --- Comment #12 from David Rubio --- (In reply to David Rubio from comment #11) > (In reply to Albert Astals Cid from comment #10) > > The patches are wrong, they change the behaviour of two things that are not > > released in sync (kwalletd and pam-kwallet), so they would break every > > single user for a while until everyone was using the new version, doesn't > > seem like a reasonable solution. > > > > Maybe instead of putting pressure here you'll could put pressure in > > https://github.com/canonical/lightdm/issues/134 > > Ah. Fair. > Well, this same error appears if you use KWallet on literally anything other > than SDDM, so it's 100% not only a lightdm error > Just trying to use startx, and configuring /etc/pam/login to open KWallet, > it fails with this exact error. Same on GDM, or anything *but* SDDM. This > feels like a KWallet error for sure. > > I'll chime in there, though :) Oh. I read the bug report now. Well, one question would be why it doesn't work with startx either, even if PAM is configured to open the wallet. -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 400929] kwallet-pam errors when logging into Plasma from lightdm
https://bugs.kde.org/show_bug.cgi?id=400929 --- Comment #11 from David Rubio --- (In reply to Albert Astals Cid from comment #10) > The patches are wrong, they change the behaviour of two things that are not > released in sync (kwalletd and pam-kwallet), so they would break every > single user for a while until everyone was using the new version, doesn't > seem like a reasonable solution. > > Maybe instead of putting pressure here you'll could put pressure in > https://github.com/canonical/lightdm/issues/134 Ah. Fair. Well, this same error appears if you use KWallet on literally anything other than SDDM, so it's 100% not only a lightdm error Just trying to use startx, and configuring /etc/pam/login to open KWallet, it fails with this exact error. Same on GDM, or anything *but* SDDM. This feels like a KWallet error for sure. I'll chime in there, though :) -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 400929] kwallet-pam errors when logging into Plasma from lightdm
https://bugs.kde.org/show_bug.cgi?id=400929 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com --- Comment #9 from David Rubio --- Any reasons nobody has tried to mainline the patches that do -in fact- fix this issue? even if they were presented in the right way, this issue could be fixed by just those simple patches being applied, or similar versions of them. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #70 from David Rubio --- (In reply to David Rubio from comment #67) > (In reply to Matthias Mueller from comment #66) > > i only had a black wallpaper on the second monitor once since it was > > "fixed". (Manjaro testing here, so currently qt5-base 5.15.1-3 and > > plasma-desktop 5.20.2-1 > > ) > > I only have seen the wallpaper misplacement myself aswell. I've counted > about 7 times since 5.20 was released. Not many, but it happens. I just got a black wallpaper this startup on my second screen, so yes, it happens aswell. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428379] System tray popup keeps switching monitor after clicking actions in expandable list items
https://bugs.kde.org/show_bug.cgi?id=428379 David Rubio changed: What|Removed |Added CC||david.alejandro.rubio@gmail ||.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #67 from David Rubio --- (In reply to Matthias Mueller from comment #66) > i only had a black wallpaper on the second monitor once since it was > "fixed". (Manjaro testing here, so currently qt5-base 5.15.1-3 and > plasma-desktop 5.20.2-1 > ) I only have seen the wallpaper misplacement myself aswell. I've counted about 7 times since 5.20 was released. Not many, but it happens. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #65 from David Rubio --- (In reply to d3coder from comment #63) > For me it behaves like in 5.15.0, but randomly > Panel is on wrong monitor, desktop icons are on wrong monitor, notifications > appear near center of wrong monitor. I don't use the plasma panel or desktop icons, which explains why I don't see it :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #64 from David Rubio --- Interesting. I can confirm is quite random now though. It happens like at really random times and sometimes it stops happening for a while and then it confuses me :p -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #62 from David Rubio --- Well, actually, notifications now are in the correct monitor when it happens, so is KRunner. The issue is only now with the wallpaper, which either: - Goes black on second monitor - Is shuffled between monitors - Reset to the default wallpaper on all monitors All of which get fixed by a quick `plasmashell --replace` -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #61 from David Rubio --- same as d3coder I could record another video, but its basically the same behavior. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #57 from David Rubio --- I can confirm this is happening again. Started happening somewhere between plasmashell 5.20.0 and 5.20.2, somehow :p -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #52 from David Rubio --- Thanks you all for the help <3 I chimed in on Arch's bug tracker to backport the fix. Haven't heard back, though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426496] Multiple monitor assignment is wrong after update to Qt 5.15.1
https://bugs.kde.org/show_bug.cgi?id=426496 --- Comment #49 from David Rubio --- (In reply to Daniel Baumgartner from comment #48) > It's fixed with Qt 5.15.1-2.1 (opensuse tumbleweed 20200925) > > changelog: > - Revert commit to fix screen geometry on startup (boo#1176750, QTBUG-86604): > * 0001-Revert-Emit-QScreen-availableG-g-eometryChanged-on-l.patch I compiled my own qt5-base with the patch on the Qt bug tracker, and it works now. I don't know if they will release a new version over this though. I'm guessing not. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 416497] No shadows on GTK menus
https://bugs.kde.org/show_bug.cgi?id=416497 --- Comment #7 from David Rubio --- Probably more useful note, even: Deepin's fork of KWin has this bug fixed. Maybe worth a look there? -- You are receiving this mail because: You are watching all bug changes.
