[kwin] [Bug 434829] kwin resets custom luts (colord-kde) at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #17 from Antonio Orefice --- Ok, I'm just going to use xrandr and trigger a lut reload. If anyone needs: koko@Gozer# cat /koko/scripts/benq.keep.lut.sh #!/bin/bash dispwin -d 1 -s /koko/tmp/1.lut dispwin -d 2 -s /koko/tmp/2.lut state_old=$(xrandr |md5sum) while true ; do sleep 5 state_new=$(xrandr |md5sum) if [ "$state_new" != "$state_old" ] ; then echo "Trig" sleep 1 dispwin -d 1 /koko/tmp/1.lut dispwin -d 2 /koko/tmp/2.lut state_old=$state_new fi done -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #15 from Antonio Orefice --- (In reply to Zamundaaa from comment #12) > KWin does not have any information about what other applications are doing > or not doing with the lut, so it can't keep your use case working. In case you don't know, Lut can be downloaded from Xorg as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #14 from Antonio Orefice --- Ok, can plasma just stop resetting the lut when resolution changes? I've edited the bug title to reflect that. If even that is not possible, feel free to close. Have a good day. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 Antonio Orefice changed: What|Removed |Added Resolution|UPSTREAM|--- Status|RESOLVED|REOPENED Summary|kwin resets custom luts |kwin resets custom luts |(colord-kde) when starting |(colord-kde) at resolution |or at resolution change |change --- Comment #13 from Antonio Orefice --- (In reply to Zamundaaa from comment #10) > There's lots of different processes setting gamma ramps to different values > on different times on Xorg. If you set the ICC profile on Wayland, nothing > will be able to override that, but fixing this on Xorg isn't really feasible I'm not sure I get it. Kde used to Not doing that, why can't it stop doing it now? Also, what does a resolution change has to do with a color profile is out of my understanding.(In reply to Zamundaaa from comment #12) > It doesn't have anything to do with color profiles, but Xorg has only one > LUT that any and every application can set, and that we need to use for > night color. With night color, we need to ensure that the lut is set > appropriately when a new display is connected, otherwise the wrong lut may > be set and the colors differently than expected. > KWin does not have any information about what other applications are doing > or not doing with the lut, so it can't keep your use case working. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) when starting or at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 Antonio Orefice changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|UPSTREAM|--- --- Comment #11 from Antonio Orefice --- (In reply to Zamundaaa from comment #10) > There's lots of different processes setting gamma ramps to different values > on different times on Xorg. If you set the ICC profile on Wayland, nothing > will be able to override that, but fixing this on Xorg isn't really feasible I'm not sure I get it. Kde used to Not doing that, why can't it stop doing it now? Also, what does a resolution change has to do with a color profile is out of my understanding. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482878] Problems on x11 when dragging windows offscreen left or up
https://bugs.kde.org/show_bug.cgi?id=482878 --- Comment #2 from Antonio Orefice --- Just noticed that when the compositor is active and the window is offscreen, mouse clicks are offsetted. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482878] Problems on x11 when dragging windows offscreen left or up
https://bugs.kde.org/show_bug.cgi?id=482878 Antonio Orefice changed: What|Removed |Added Summary|Problems on x11 when|Problems on x11 when |dragging windows offscreen |dragging windows offscreen |left or up if compositor is |left or up |disabled| --- Comment #1 from Antonio Orefice --- Just noticed that when -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482878] Problems on x11 when dragging windows offscreen left or up if compositor is disabled
https://bugs.kde.org/show_bug.cgi?id=482878 Antonio Orefice changed: What|Removed |Added Summary|On x11 you cannot drag |Problems on x11 when |windows offscreen left or |dragging windows offscreen |up if compositor is |left or up if compositor is |disabled|disabled -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482878] New: On x11 you cannot drag windows offscreen left or up if compositor is disabled
https://bugs.kde.org/show_bug.cgi?id=482878 Bug ID: 482878 Summary: On x11 you cannot drag windows offscreen left or up if compositor is disabled Classification: Plasma Product: kwin Version: 6.0.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- SUMMARY On x11 you cannot drag windows offscreen left or up if compositor is disabled works ok right or down. STEPS TO REPRODUCE 1. Use X11 session 2. try to drag a window offscreen left or up OBSERVED RESULT Window is stuck to the screen border. EXPECTED RESULT Worked fine in plasma 5, why not now? SOFTWARE/OS VERSIONS Linux: Archlinux, plasma 6.01 KDE Plasma Version: 6.01 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482876] Some applications won't go fullscreen on X11 when screen scaling is enabled
https://bugs.kde.org/show_bug.cgi?id=482876 --- Comment #1 from Antonio Orefice --- Some screen scaling setting allow for fullscreen, like 200% -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482876] New: Some applications won't go fullscreen on X11 when screen scaling is enabled
https://bugs.kde.org/show_bug.cgi?id=482876 Bug ID: 482876 Summary: Some applications won't go fullscreen on X11 when screen scaling is enabled Classification: Plasma Product: kwin Version: 6.0.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- SUMMARY Some applications won't go fullscreen on X11 when screen scaling is enabled STEPS TO REPRODUCE 1. Use X11 session 2. Set screen scaling to 150% 3. logout / login 4. try to make dolphin fullscreen via taskbar or a shortcut. OBSERVED RESULT Via taskbar the full screen option is grayed out shortcut won't work EXPECTED RESULT Worked fine in plasma 5, why not now? SOFTWARE/OS VERSIONS Linux: Archlinux, plasma 6.01 KDE Plasma Version: 6.01 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] With an Intel iGPU, animations aren't as smooth on Wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #77 from Antonio Orefice --- Just tried with an i5-1035g1 under wayland with its gpu that should be far more performant than my haswell, but still on the logout screen mouse cursor was stuttering (a lot) under wayland on the newer cpu and butter smooth on X11 on the aging haswell. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 480306] Audio balance is lost when setting volume to 0
https://bugs.kde.org/show_bug.cgi?id=480306 --- Comment #6 from Antonio Orefice --- (In reply to fanzhuyifan from comment #5) > You could also share a link to a screencast of the problem you are seeing. yeah, ofc. but the problem seems pretty clear, we can avoid the bloat when plain text is enough ;) -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 480306] Audio balance is lost when setting volume to 0
https://bugs.kde.org/show_bug.cgi?id=480306 --- Comment #3 from Antonio Orefice --- (In reply to fanzhuyifan from comment #2) > On plasma 6, I can only reproduce this when the volume is set to 0 -- > balance is lost afterwards. The balance is preserved when I set the volume > to 100. > > Another weird thing about the UI: > > In system settings if you click balance then you can only move the > individual sliders individually. However, now when you use the buttons or > the applet, you can move the overall volume, which changes both sliders > while preserving their ratio. > > If you click balance again, you get back one slider. If you move that slider > and click balance again, sometimes you see balance is preserved. Sometimes > the balance is lost. The behavior seems pr Is it (In reply to fanzhuyifan from comment #2) > On plasma 6, I can only reproduce this when the volume is set to 0 -- > balance is lost afterwards. The balance is preserved when I set the volume > to 100. Weird, is it preserved even if you set, say, left to a very low value and right to a very high one? -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 480306] Audio balance is reset/lost when setting volume "too" high or "too" low.
https://bugs.kde.org/show_bug.cgi?id=480306 --- Comment #1 from Antonio Orefice --- Easy fix would be to put a minimum and a maximum to allowed volume range when panning is in use. If one of the slider reaches 100, don't move the others If one of the slider reaches 0, don't move the others -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 480306] New: Audio balance is reset/lost when setting volume "too" high or "too" low.
https://bugs.kde.org/show_bug.cgi?id=480306 Bug ID: 480306 Summary: Audio balance is reset/lost when setting volume "too" high or "too" low. Classification: Plasma Product: plasma-pa Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kokok...@gmail.com CC: isma...@gmail.com, m...@ratijas.tk, now...@gmail.com Target Milestone: --- STEPS TO REPRODUCE 0. Set volume to 50% 1. Open Audio settings 2. Click Balance to unlock multiple sliders (left and right for me) 3. Set each to a different value 4. Using plasma applet, set volume to 100 5. Set volume back to 50% OBSERVED RESULT Audio Balance setting is lost. EXPECTED RESULT Audio balance set to where you first put at point 3 SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12+kde+r147 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467283] [Wayland][Intel][HiDPI] Laggy maximize animation with custom Aurorae theme
https://bugs.kde.org/show_bug.cgi?id=467283 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com --- Comment #3 from Antonio Orefice --- (In reply to David Edmundson from comment #2) > > *** This bug has been marked as a duplicate of bug 452119 *** Can't see any mention of the behaviour on Xorg; Why setting this as a duplicate of bug 452119 ? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) when starting or at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #9 from Antonio Orefice --- And again, it resets luts on resolution changes. Also, the previous hack does not work anymore. Could you please suggest another workaround if fixing this issue is not an option, please? -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467604] Kate/kwrite unuseful wasted space that also don't allow to grab scrollbars near the edge of the screen when maximized.
https://bugs.kde.org/show_bug.cgi?id=467604 --- Comment #3 from Antonio Orefice --- Created attachment 157441 --> https://bugs.kde.org/attachment.cgi?id=157441&action=edit Right side bar expanded too, the reason why scrolling on the edge isn't working -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467604] Kate/kwrite unuseful wasted space that also don't allow to grab scrollbars near the edge of the screen when maximized.
https://bugs.kde.org/show_bug.cgi?id=467604 --- Comment #2 from Antonio Orefice --- Created attachment 157439 --> https://bugs.kde.org/attachment.cgi?id=157439&action=edit Can't scroll on the edge of a maximized window, see mouse shape. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467604] Kate/kwrite unuseful wasted space that also don't allow to grab scrollbars near the edge of the screen when maximized.
https://bugs.kde.org/show_bug.cgi?id=467604 --- Comment #1 from Antonio Orefice --- Created attachment 157438 --> https://bugs.kde.org/attachment.cgi?id=157438&action=edit Empty toolbars expanded -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467604] New: Kate/kwrite unuseful wasted space that also don't allow to grab scrollbars near the edge of the screen when maximized.
https://bugs.kde.org/show_bug.cgi?id=467604 Bug ID: 467604 Summary: Kate/kwrite unuseful wasted space that also don't allow to grab scrollbars near the edge of the screen when maximized. Classification: Applications Product: kate Version: 22.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: part Assignee: kwrite-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- Created attachment 157437 --> https://bugs.kde.org/attachment.cgi?id=157437&action=edit Useless space stolen by a shrinked toolbar STEPS TO REPRODUCE 1. install kate/kwrite 22.12.3 2. start kwrite 3. Note the wasted space between the menu and the content window (first attachment and second attachment) 3b. of course those are meant to accomodate some content, but as far as i can see, even when shrinked to the maximum, they still takes space and it seems there is no way to completely disable them 4. for the very same reason, even when the window is maximized, if you move the mouse to the very right side of the screen, click and drag, expecting to have focused the scrollbar and to scroll, it does not scroll, because the mouse has focused the handler of a toolbar insteald of the scrollbar itself. Downgrading to 22.08.3 instantly fixes it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #47 from Antonio Orefice --- (In reply to Lemmiwinks from comment #46) > I think I made an observation: under System Settings -> Compositor, setting > the latency to "force smoothest animations", seems to almost fix the problem > for me. Maybe someone could try this... The very same workaround is pointed out by the reporter in the very first post. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462164] Window contents are blurry when restoring a maximized window by dragging the title bar
https://bugs.kde.org/show_bug.cgi?id=462164 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com --- Comment #4 from Antonio Orefice --- Confirmed for me. It also happens in firefox (or all gtk apps?) that uses CSD when you unmaximize them. Worst part is that firefox stays blurry until maximized again or compositor not disabled ofc. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #42 from Antonio Orefice --- (In reply to Joshua T from comment #40) > (In reply to Antonio Orefice from comment #38) > > (In reply to Joshua T from comment #37) > > > I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues > > > on my Intel UHD 600. Animations were very close to 60 FPS. I have > > > definitely > > > seen this problem in the past. Or is Fedora doing something differently? > > > > Are you unable to spot any performance degradation versus Xorg then? > > I used the Show Kwin FPS desktop effect, and Xorg was only slightly smoother > than Wayland. If you take a look at the first post, you'll read that the fps effect is not a good meter; indeed using it workarounds the issues under Wayland. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #38 from Antonio Orefice --- (In reply to Joshua T from comment #37) > I just tried Fedora KDE Rawhide with Wayland, and I didn't have any issues > on my Intel UHD 600. Animations were very close to 60 FPS. I have definitely > seen this problem in the past. Or is Fedora doing something differently? Are you unable to spot any performance degradation versus Xorg then? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451590] Stutter on right-most screen of multi-screen setup when opening WindowHeap-based effects
https://bugs.kde.org/show_bug.cgi?id=451590 --- Comment #26 from Antonio Orefice --- For me, it is not (only) a matter of having a second screen or not. Yes, having multiple screens make the things worse for me too, but it is just because my igp is more taxed that way. Indeed, on a single monitor setup, I noticed that on a machine not yet "upgraded" to kwin 5.25, i can use present windows effect with 20 windows on screen and everything is really smooth. my monitor is 75hz and everything moves fine. On the upgraded machine, instead, same hardware, single screen, if i open 15 windows and then activate present windows the animation stutters to something around 20/30fps. If I activate the effect mutliple times very fast, intel_gpu_top reports almost 100% gpu use. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451590] Stutter on right-most screen of multi-screen setup when opening WindowHeap-based effects
https://bugs.kde.org/show_bug.cgi?id=451590 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435423] Morphing popups effect does not morph. (no X-Fade)
https://bugs.kde.org/show_bug.cgi?id=435423 --- Comment #10 from Antonio Orefice --- (In reply to Nate Graham from comment #8) > Can reproduce 100% on Wayland, but not X11, interestingly. I have to point out that this bug is not about wayland not sliding and morphing the shape of the popup, which works correctly on X11, but that the Crossfade effect does not work on X11. ** ->> "Effect.CrossFadePrevious" -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] kwin on wayland: mouse pointer is synchronized or not using hardware cursor.
https://bugs.kde.org/show_bug.cgi?id=452117 --- Comment #7 from Antonio Orefice --- (In reply to Nate Graham from comment #6) > FWIW I've also been running with KWIN_DRM_NO_AMS=1, just because it keeps > kwin_wayland's CPU usage down. I haven't noticed any regressions. Yes, I opened something like 300 glxgears at the minimum gpu clock to have stuttering mouse with KWIN_DRM_NO_AMS=1. It is not something i worry about :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #10 from Antonio Orefice --- (In reply to Zamundaaa from comment #9) > I don't know how to check the memory clock on Intel systems, searching for > it doesn't yield results for the dynamic memory speed either. > > We can just check for it differently though: If you start glxgears and leave > that running instead of the fps effect, does that make KWin run smooth? Already did, please see end of comment 5. It does, but marginally and frequency is even higher. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #8 from Antonio Orefice --- Aye, i've read better, sorry. I don't know how to read current memory clock speed. Do you have advices? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #7 from Antonio Orefice --- (In reply to Zamundaaa from comment #6) > What does the memory clock do with the fps effect? GPU core clock is not the > single deciding factor on performance If you are asking me, I've no idea. I answered to your previous question: "Does the GPU or memory clock go up if you enable it?" I don't know which go up when i enable the Show FPS effect, because intel gpu utils refers to a generic "gpu frequency". However, since you asked about one of those frequencies, i answered Yes, because intel_gpu_top reports an higher frequency when i enable FPS effect. Note that the actual minimum frequency for non idle state is 200mhz; in idle state the gpu reaches 1mhz. If when i enable FPS effect i get something lower, it probabily means that it is just waking up the gpu from time to time. Could you please be more specific? I'm having hard times trying to understand your point. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] kwin on wayland: mouse pointer is synchronized or not using hardware cursor.
https://bugs.kde.org/show_bug.cgi?id=452117 --- Comment #5 from Antonio Orefice --- (In reply to Zamundaaa from comment #4) > It's more or less an issue with how the atomic modesetting API currently > works, changing that is not trivial but being worked on. You can use the > environment variable "KWIN_DRM_NO_AMS=1" to have KWin fall back to the > legacy API to work around this if it's important to you. Since Kwin performances under wayland on my i4590 integrated Haswell igp won't allow me to have smooth animations unless I set the higher latency setting in the compositor (on X11 it is so much better) I've to set an high latency which makes the mouse pointer sluggish, as it slips under your hand, and even selecting text or clicking little icons becomes a remarkable achievement, so yes, it is definitely important to me. KWIN_DRM_NO_AMS=1 makes things so much better, thanks. However, under high gpu stress, mouse still stutters, while i've been unable to replicate any mouse stuttering under xorg (i managed to completely paralize the whole desktop with countless 3D clients, mouse remained butterly smooth, not a single frame drop) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #5 from Antonio Orefice --- (In reply to Zamundaaa from comment #3) > > But what REALLY helps, is enabling the Show FPS effect > > Does the GPU or memory clock go up if you enable it? Enabling show fps effects bump the gpu use to about 150mhz. Which is a weird value, because the lowest non-idle setting should be 200mhz, so i suspect it is averaging results. By the way, the desktop is almost smooth everytime with show fps effeca and with lowest latency. However if i turn off "show fps" and artificially put the gpu mhz to a higher value state with glxgears to 200mhz, then while it is a bit better than without glxgears, it is definitely not smooth as with the show fps effect running, so i suspect is not just a matter of gpu idling too much. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 --- Comment #4 from Antonio Orefice --- (In reply to Zamundaaa from comment #3) > > But what REALLY helps, is enabling the Show FPS effect > > Does the GPU or memory clock go up if you enable it? If I remember right, it goes from 2mhz to about 200mhz. I'll check it by monday. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] kwin on wayland: mouse pointer is synchronized or not using hardware cursor.
https://bugs.kde.org/show_bug.cgi?id=452117 Antonio Orefice changed: What|Removed |Added Summary|kwin on wayland not using |kwin on wayland: mouse |hardware cursor |pointer is synchronized or ||not using hardware cursor. --- Comment #3 from Antonio Orefice --- It happens even under weston, so at this point is not clear to me if it depends on the compositor or on wayland itself. It also seem that even the hardware mouse plane runs synchronized with the others: https://gitlab.freedesktop.org/wayland/weston/-/issues/602#note_1322651 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] kwin on wayland not using hardware cursor
https://bugs.kde.org/show_bug.cgi?id=452117 --- Comment #2 from Antonio Orefice --- Created attachment 147873 --> https://bugs.kde.org/attachment.cgi?id=147873&action=edit modetest from libdrm It seems hardware cursor is available. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452119] New: Poor performance on intel igp on wayland versus Xorg
https://bugs.kde.org/show_bug.cgi?id=452119 Bug ID: 452119 Summary: Poor performance on intel igp on wayland versus Xorg Product: kwin Version: 5.24.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- Today i switched from x11 to wayland, but unfortunately windows keep stuttering when doing basic movement/maximizing. I'd say the effect is more pronunced when there are more windows on screen. If i go for low latency, even dragging a window with wobbly effect on stutters. I may not have a fast gpu, granted, it is an haswell igp, but under xorg, it is butter smooth in driving 2 monitors at 1920x1080. To have smooth animations with not so much frames dropped, i've to use the highest latency setting. While intel_gpu_top reports no significant gpu usage (20%), even when windows are stuttering, one thing that helps is setting the igp min frequency to an higher value; that way i can even use the balanced preset. But what REALLY helps, is enabling the Show FPS effect. With just that active, i can even force the lowest latency settings, and everything is magically smooth like under Xorg. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] kwin on wayland not using hardware cursor
https://bugs.kde.org/show_bug.cgi?id=452117 --- Comment #1 from Antonio Orefice --- [plasmauser@Gozer tmp]$ zgrep Cursor wayland-session.log.gz kwin_wayland_drm: Plane 41 has properties "type"="Cursor", "SRC_X"=0, "SRC_Y"=0, "SRC_W"=0, "SRC_H"=0, "CRTC_X"=0, "CRTC_Y"=0, "CRTC_W"=0, "CRTC_H"=0, "FB_ID"=0, "CRTC_ID"=0, "rotation"=invalid value: 1, "IN_FORMATS"=42 kwin_wayland_drm: Plane 56 has properties "type"="Cursor", "SRC_X"=0, "SRC_Y"=0, "SRC_W"=0, "SRC_H"=0, "CRTC_X"=0, "CRTC_Y"=0, "CRTC_W"=0, "CRTC_H"=0, "FB_ID"=0, "CRTC_ID"=0, "rotation"=invalid value: 1, "IN_FORMATS"=57 kwin_wayland_drm: Plane 71 has properties "type"="Cursor", "SRC_X"=0, "SRC_Y"=0, "SRC_W"=0, "SRC_H"=0, "CRTC_X"=0, "CRTC_Y"=0, "CRTC_W"=0, "CRTC_H"=0, "FB_ID"=0, "CRTC_ID"=0, "rotation"=invalid value: 1, "IN_FORMATS"=72 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452117] New: kwin on wayland not using hardware cursor
https://bugs.kde.org/show_bug.cgi?id=452117 Bug ID: 452117 Summary: kwin on wayland not using hardware cursor Product: kwin Version: 5.24.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- Created attachment 147863 --> https://bugs.kde.org/attachment.cgi?id=147863&action=edit qdbus org.kde.KWin /KWin supportInformation SUMMARY *** There is cursor input lag *** STEPS TO REPRODUCE 1. In the compositor settings, switch from lowest latency to higher one 2. see that mouse lag changes You can even try to saturate the gpu use; the mouse will start to stutter too. Under Xorg, i've regular hardware mouse cursor. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) when starting or at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #8 from Antonio Orefice --- The situation is improved. Now kwin does not reset the lut anymore when changing resolution, but just when it starts. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 451531] New: Dual head, different resolutions, clone mode -> missing panel.
https://bugs.kde.org/show_bug.cgi?id=451531 Bug ID: 451531 Summary: Dual head, different resolutions, clone mode -> missing panel. Product: KScreen Version: 5.24.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- STEPS TO REPRODUCE 0. have a clean kde/plasma config. 1. Have 2 monitors connected, HDMI2,HDMI1 2. open screen configuration 3. set HDMI1 primary, enable HDMI1 4. set HDMI1 resolution to 1280x720 5. set HDMI2 as clone of HDMI1 with a resolution of 1920x1080, enable HDMI2, leave HDMI1 as the primary. 7. apply 7.5 is panel already gone? 8. log out 9. log in. 10. panel is gone. cli version (sorry, cannot figured out how to use kscreen-doctor to clone) xrandr --output HDMI2 --same-as HDMI1 kscreen-doctor output.HDMI1.enable output.HDMI1.primary output.HDMI1.mode.1280x720@60 output.HDMI2.enable output.HDMI2.mode.1920x1080@60 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux packages KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3+kde+r133-1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443434] Window resizing broken when using wobbly windows + resize effects
https://bugs.kde.org/show_bug.cgi?id=443434 --- Comment #4 from Antonio Orefice --- (In reply to Vlad Zahorodnii from comment #2) > Given the wayland issues and in part maintenance costs, this change > drops the resize effect. Note that it can be still reimplemented without > kwin core changes, but it would still suffer from the aforementioned > issues. Does it mean it can be implemented via js as an external effect? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443434] Window resizing broken when using wobbly windows + resize effects
https://bugs.kde.org/show_bug.cgi?id=443434 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com --- Comment #3 from Antonio Orefice --- Created attachment 146905 --> https://bugs.kde.org/attachment.cgi?id=146905&action=edit The effect of missing fast windows scaling The fast windows scaling was a godsend for performance and helped to keep cpu and battery usage lower by avoiding useless repaints, it was extremely useful to smooth resize lagging windows like firefox or even the systemsettings one; Try to resize the systemsettings window; it is not a good show at all! The attachment shows what happens when a window don't redraw his content fast enough while you resize. My opinion is that has been killed in favour of an useless *option* of a "wow effect!" and that it can even leads to a uglier experience! So, instead of ditching the whole resize effect , may i suggest one of the following instead: 1) Disable the wobbly effect option for resize when fast window scaling is active 2) Disable the wobbly effect option for resize -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #19 from Antonio Orefice --- Hi, i've seen kwin 5.24 is out. Any news on this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434829] kwin resets custom luts (colord-kde) when starting or at resolution change
https://bugs.kde.org/show_bug.cgi?id=434829 --- Comment #7 from Antonio Orefice --- I spent some time to convert my .cal files to compliant icc profiles to try to better integrate into the colord subsystem. Unfortunately Vlad was right, even colord-kde isn't able to keep the icc profile loaded. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 448248] Cannot change Qbittorrent Tray icon anymore
https://bugs.kde.org/show_bug.cgi?id=448248 --- Comment #6 from Antonio Orefice --- Indeed, i was thinking the same. Qbittorrent used to be able to cycle across 3 icon styles, while now it is stuck to using the theme provided one. Also, even setting a style and restart qbittorrent does not change a thing, so even the 'not re-rendered" hypotesis looses weight imho. It is right to leave the resolved/intentional status for this bug? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 448248] Cannot change Qbittorrent Tray icon anymore
https://bugs.kde.org/show_bug.cgi?id=448248 --- Comment #4 from Antonio Orefice --- Thanks Konrad, i checked and the icon for qbittorrent was provideed since several releases from breeze-icons package, so no change in that. also, no change in qbittorrent, because to trigger the new, intentional, behavior it is sufficient to upgrade plasma. So if i understood properly, can you confirm that there is a way for apps to specify a custom icon for the tray, which is using org.freedesktop.StatusNotifierItem.IconPixmap instead of org.freedesktop.StatusNotifierItem.IconName, so that i can pass that information to qbittorrent developers? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 448248] Cannot change Qbittorrent Tray icon anymore
https://bugs.kde.org/show_bug.cgi?id=448248 --- Comment #2 from Antonio Orefice --- Yeah, i've to add that i'm still using the qt5 version of qbittorrent. Read: it does not depend on it, but seems plasma related. https://github.com/qbittorrent/qBittorrent/issues/15931 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 448248] New: Cannot change Qbittorrent Tray icon anymore
https://bugs.kde.org/show_bug.cgi?id=448248 Bug ID: 448248 Summary: Cannot change Qbittorrent Tray icon anymore Product: plasmashell Version: 5.23.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: kokok...@gmail.com CC: mate...@gmail.com Target Milestone: 1.0 SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. start qbittorrent 2. change tray icon theme to light/dark/default OBSERVED RESULT see that the icon does not change in the tray EXPECTED RESULT The icon to change in the tray It used to work before i updated plasma, and still works in lxqt. Palsma seems to prefer the theme icon now, instead of the one suggested by qbittorrent. This workarounds the issue: sudo mv /usr/share/icons/breeze/apps/48/qbittorrent.svg /usr/share/icons/breeze/apps/48/qbittorrent.svg.no killall plasmashell ; rm ~/.cache/icon-cache.kcache ; plasmashell -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #16 from Antonio Orefice --- f432ba78 | GOOD ebc785167 | BAD I'm unable to build in between, sorry. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435423] Morphing popups effect does not morph. (no X-Fade)
https://bugs.kde.org/show_bug.cgi?id=435423 --- Comment #6 from Antonio Orefice --- Used to work with some glitches in plasma 5.22.5 due to this being fixed: https://bugs.kde.org/show_bug.cgi?id=439689 Now the same bug has returned and this is following. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 424825] yakuake wont go fullscreen
https://bugs.kde.org/show_bug.cgi?id=424825 --- Comment #6 from Antonio Orefice --- 21.08.2 is still affected -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #15 from Antonio Orefice --- Maybe related, or not, we lost xfade on window resize too when using the resize effect that scales the window texture. I managed to bring xfade for (un)maximize effect by downgrading kwin,kdecoration and kwayland-server back to 5.22.5. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 Antonio Orefice changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Version|5.21.90 |5.23.0 --- Comment #14 from Antonio Orefice --- Unfortunately, the bug is back on kwin 5.23 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442129] Window resize effect: some apps becomes transparents for a while.
https://bugs.kde.org/show_bug.cgi?id=442129 --- Comment #1 from Antonio Orefice --- Created attachment 141362 --> https://bugs.kde.org/attachment.cgi?id=141362&action=edit resize konsole and dolphin forgot the attachment -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442129] New: Window resize effect: some apps becomes transparents for a while.
https://bugs.kde.org/show_bug.cgi?id=442129 Bug ID: 442129 Summary: Window resize effect: some apps becomes transparents for a while. Product: kwin Version: 5.22.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- SUMMARY When using window resize effect, and the size of a window is changed, it happens that the window becomes transparent for a while. It does not happen with all of the windows. In the video attached i show that some apps are fine: kwrite, dolphin others are not gtk3-demo, simple-scan, konsole Weird thing is that the maximize effect, which basically does the same thing of resizing, is fine. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices and SD cards after disconnecting and re-connecting them
https://bugs.kde.org/show_bug.cgi?id=438874 --- Comment #35 from Antonio Orefice --- (In reply to Attila from comment #34) > Here is my workaround until this bug has been fixed. > You need two USB devices. Let's call the first one "a dummy USB device". > > 1. Just Plug in the dummy USB device. > 2. You don't need to mount it. No access is needed. Don't remove the dummy > device. > 3. Plug in the USB device which you want to access. > 4. The device notifier should come up. > 5. You can mount it, access it and unmout it. > 6. Unplug the USB device. > 7. You can pluin the same USB device or another one and the device notifier > should always come up. It doesn't work for me, but what works for me is: plug usb-device1,unplug it. plug usb-device2,unplug it, replug usb-device1 It seems that unplug something doesn't trigger something, which is triggered by the plug of something else; just speculating ofc. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 424825] yakuake wont go fullscreen
https://bugs.kde.org/show_bug.cgi?id=424825 Antonio Orefice changed: What|Removed |Added Summary|yakuake 20.04.3 wont go |yakuake wont go fullscreen |fullscreen | Version|unspecified |21.08.0 -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 424825] yakuake 20.04.3 wont go fullscreen
https://bugs.kde.org/show_bug.cgi?id=424825 Antonio Orefice changed: What|Removed |Added Resolution|DUPLICATE |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #5 from Antonio Orefice --- Unfortunately it happens again. yakuake shortcut ctrl-shift-f11 does work mi kwin shortcut to make every window fullscreen (alt-f12) does not in yakuake 21.08.0 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices after connecting the device for 2nd time
https://bugs.kde.org/show_bug.cgi?id=438874 --- Comment #21 from Antonio Orefice --- (In reply to MikeC from comment #18) > I wonder if this is related: https://github.com/indilib/indi/pull/1521 I don't think so... If you open removable devices from systemsettings5, you can still see attached and detached devices there; it seems just plasma that ignores them. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435423] Morphing popups effect does not morph. (no X-Fade)
https://bugs.kde.org/show_bug.cgi?id=435423 --- Comment #5 from Antonio Orefice --- Created attachment 140545 --> https://bugs.kde.org/attachment.cgi?id=140545&action=edit Full morphingpopup.js that discards crossfades when the previous texture is wrong or missing. Full morphingpopup.js that discards crossfades when the previous texture is wrong or missing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435423] Morphing popups effect does not morph. (no X-Fade)
https://bugs.kde.org/show_bug.cgi?id=435423
Antonio Orefice changed:
What|Removed |Added
CC||kokok...@gmail.com
--- Comment #4 from Antonio Orefice ---
Created attachment 140544
--> https://bugs.kde.org/attachment.cgi?id=140544&action=edit
Video showing the issue as it is right now
Since the fixing of this bug:
https://bugs.kde.org/show_bug.cgi?id=439689
This one seems to be, altough partially, fixed.
Weird flashes on oxygen theme are gone, but crossfade acts weirdly, and when it
does, the window crossfades from transparency.
I made a slowmotion video to show what happens:
Crossfade works as expected when the pointer hovers from the first icon to the
kdialog taskbar thumbnail.
Then something wrird happens, pointer go to libreoffice thumbnail and the
crossfare still works, but the previous texture it uses is still the one from
konsole.
*--> (1) It seems that the effect takes the "previous" texture of the crossfade
<--*
*--> only when the new *size* of the popup window has changed.
<--*
Anyway, even if I've not understood very well the logic in morphingpopups.js, i
made a little workaround to it so that crossfade now works properly when the
popup changes size, and simply skip the morphing code alltogheter when it stay
the same size.
That way, we can avoid fading from a transparent texture or from a wrong one:
--
+ if (oldGeometry.width != newGeometry.width ||
+oldGeometry.height != newGeometry.height) {
if (!couldRetarget) {
window.fadeAnimation = animate({
window: window,
duration: morphingEffect.duration,
animations: [{
type: Effect.CrossFadePrevious,
to: 1.0,
from: 0.0
}]
});
}
+ }
--
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #9 from Antonio Orefice --- Thank YOU very much for your efforts. However, the same commit affects: https://bugs.kde.org/show_bug.cgi?id=438458 which, by gut feeling, it should not be due to previous pixmap. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #6 from Antonio Orefice --- Bisected. The offending commit is: koko@Gozer# git bisect good 47113e09b8a80497463725a795728a34e9db940c is the first bad commit commit 47113e09b8a80497463725a795728a34e9db940c Author: Vlad Zahorodnii Date: Thu Feb 4 11:07:20 2021 +0200 scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes. src/CMakeLists.txt | 8 + src/abstract_client.cpp| 8 +- src/abstract_client.h | 5 +- src/composite.cpp | 20 +- src/decorationitem.cpp | 35 ++ src/decorationitem.h | 36 ++ src/effects.cpp| 3 +- src/events.cpp | 4 - src/internal_client.cpp| 5 +- src/item.cpp | 345 src/item.h | 142 src/plugins/scenes/opengl/scene_opengl.cpp | 280 src/plugins/scenes/opengl/scene_opengl.h | 6 +- src/plugins/scenes/qpainter/scene_qpainter.cpp | 46 ++- src/plugins/scenes/qpainter/scene_qpainter.h | 5 +- src/plugins/scenes/xrender/scene_xrender.cpp | 26 +- src/scene.cpp | 433 - src/scene.h| 181 ++- src/shadowitem.cpp | 46 +++ src/shadowitem.h | 35 ++ src/surfaceitem.cpp| 119 +++ src/surfaceitem.h | 55 src/surfaceitem_internal.cpp | 46 +++ src/surfaceitem_internal.h | 34 ++ src/surfaceitem_wayland.cpp| 151 + src/surfaceitem_wayland.h | 61 src/surfaceitem_x11.cpp| 141 src/surfaceitem_x11.h | 47 +++ src/toplevel.cpp | 251 -- src/toplevel.h | 42 +-- src/unmanaged.cpp | 53 +-- src/unmanaged.h| 4 +- src/windowitem.cpp | 143 src/windowitem.h | 90 + src/x11client.cpp | 31 +- src/x11client.h| 3 +- src/xwaylandclient.cpp | 19 +- 37 files changed, 2015 insertions(+), 944 deletions(-) create mode 100644 src/decorationitem.cpp create mode 100644 src/decorationitem.h create mode 100644 src/item.cpp create mode 100644 src/item.h create mode 100644 src/shadowitem.cpp create mode 100644 src/shadowitem.h create mode 100644 src/surfaceitem.cpp create mode 100644 src/surfaceitem.h create mode 100644 src/surfaceitem_internal.cpp create mode 100644 src/surfaceitem_internal.h create mode 100644 src/surfaceitem_wayland.cpp create mode 100644 src/surfaceitem_wayland.h create mode 100644 src/surfaceitem_x11.cpp create mode 100644 src/surfaceitem_x11.h create mode 100644 src/windowitem.cpp create mode 100644 src/windowitem.h -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435378] Yakuake does not slide out properly anymore
https://bugs.kde.org/show_bug.cgi?id=435378 --- Comment #4 from Antonio Orefice --- Bisected. The offending commit is: koko@Gozer# git bisect good 47113e09b8a80497463725a795728a34e9db940c is the first bad commit commit 47113e09b8a80497463725a795728a34e9db940c Author: Vlad Zahorodnii Date: Thu Feb 4 11:07:20 2021 +0200 scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes. src/CMakeLists.txt | 8 + src/abstract_client.cpp| 8 +- src/abstract_client.h | 5 +- src/composite.cpp | 20 +- src/decorationitem.cpp | 35 ++ src/decorationitem.h | 36 ++ src/effects.cpp| 3 +- src/events.cpp | 4 - src/internal_client.cpp| 5 +- src/item.cpp | 345 src/item.h | 142 src/plugins/scenes/opengl/scene_opengl.cpp | 280 src/plugins/scenes/opengl/scene_opengl.h | 6 +- src/plugins/scenes/qpainter/scene_qpainter.cpp | 46 ++- src/plugins/scenes/qpainter/scene_qpainter.h | 5 +- src/plugins/scenes/xrender/scene_xrender.cpp | 26 +- src/scene.cpp | 433 - src/scene.h| 181 ++- src/shadowitem.cpp | 46 +++ src/shadowitem.h | 35 ++ src/surfaceitem.cpp| 119 +++ src/surfaceitem.h | 55 src/surfaceitem_internal.cpp | 46 +++ src/surfaceitem_internal.h | 34 ++ src/surfaceitem_wayland.cpp| 151 + src/surfaceitem_wayland.h | 61 src/surfaceitem_x11.cpp| 141 src/surfaceitem_x11.h | 47 +++ src/toplevel.cpp | 251 -- src/toplevel.h | 42 +-- src/unmanaged.cpp | 53 +-- src/unmanaged.h| 4 +- src/windowitem.cpp | 143 src/windowitem.h | 90 + src/x11client.cpp | 31 +- src/x11client.h| 3 +- src/xwaylandclient.cpp | 19 +- 37 files changed, 2015 insertions(+), 944 deletions(-) create mode 100644 src/decorationitem.cpp create mode 100644 src/decorationitem.h create mode 100644 src/item.cpp create mode 100644 src/item.h create mode 100644 src/shadowitem.cpp create mode 100644 src/shadowitem.h create mode 100644 src/surfaceitem.cpp create mode 100644 src/surfaceitem.h create mode 100644 src/surfaceitem_internal.cpp create mode 100644 src/surfaceitem_internal.h create mode 100644 src/surfaceitem_wayland.cpp create mode 100644 src/surfaceitem_wayland.h create mode 100644 src/surfaceitem_x11.cpp create mode 100644 src/surfaceitem_x11.h create mode 100644 src/windowitem.cpp create mode 100644 src/windowitem.h -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438458] Yakuake flashes solid color when closing it in Plasma 5.22 in X11
https://bugs.kde.org/show_bug.cgi?id=438458 --- Comment #9 from Antonio Orefice --- Bisected. The offending commit is: koko@Gozer# git bisect good 47113e09b8a80497463725a795728a34e9db940c is the first bad commit commit 47113e09b8a80497463725a795728a34e9db940c Author: Vlad Zahorodnii Date: Thu Feb 4 11:07:20 2021 +0200 scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes. src/CMakeLists.txt | 8 + src/abstract_client.cpp| 8 +- src/abstract_client.h | 5 +- src/composite.cpp | 20 +- src/decorationitem.cpp | 35 ++ src/decorationitem.h | 36 ++ src/effects.cpp| 3 +- src/events.cpp | 4 - src/internal_client.cpp| 5 +- src/item.cpp | 345 src/item.h | 142 src/plugins/scenes/opengl/scene_opengl.cpp | 280 src/plugins/scenes/opengl/scene_opengl.h | 6 +- src/plugins/scenes/qpainter/scene_qpainter.cpp | 46 ++- src/plugins/scenes/qpainter/scene_qpainter.h | 5 +- src/plugins/scenes/xrender/scene_xrender.cpp | 26 +- src/scene.cpp | 433 - src/scene.h| 181 ++- src/shadowitem.cpp | 46 +++ src/shadowitem.h | 35 ++ src/surfaceitem.cpp| 119 +++ src/surfaceitem.h | 55 src/surfaceitem_internal.cpp | 46 +++ src/surfaceitem_internal.h | 34 ++ src/surfaceitem_wayland.cpp| 151 + src/surfaceitem_wayland.h | 61 src/surfaceitem_x11.cpp| 141 src/surfaceitem_x11.h | 47 +++ src/toplevel.cpp | 251 -- src/toplevel.h | 42 +-- src/unmanaged.cpp | 53 +-- src/unmanaged.h| 4 +- src/windowitem.cpp | 143 src/windowitem.h | 90 + src/x11client.cpp | 31 +- src/x11client.h| 3 +- src/xwaylandclient.cpp | 19 +- 37 files changed, 2015 insertions(+), 944 deletions(-) create mode 100644 src/decorationitem.cpp create mode 100644 src/decorationitem.h create mode 100644 src/item.cpp create mode 100644 src/item.h create mode 100644 src/shadowitem.cpp create mode 100644 src/shadowitem.h create mode 100644 src/surfaceitem.cpp create mode 100644 src/surfaceitem.h create mode 100644 src/surfaceitem_internal.cpp create mode 100644 src/surfaceitem_internal.h create mode 100644 src/surfaceitem_wayland.cpp create mode 100644 src/surfaceitem_wayland.h create mode 100644 src/surfaceitem_x11.cpp create mode 100644 src/surfaceitem_x11.h create mode 100644 src/windowitem.cpp create mode 100644 src/windowitem.h -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435378] Yakuake does not slide out properly anymore
https://bugs.kde.org/show_bug.cgi?id=435378 --- Comment #3 from Antonio Orefice --- Since downgrading kwin to the now reported version solves the issue, i think the problem lies there. This: https://bugs.kde.org/show_bug.cgi?id=438458 seems to be a dupe. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435378] Yakuake does not slide out properly anymore
https://bugs.kde.org/show_bug.cgi?id=435378 Antonio Orefice changed: What|Removed |Added Version|unspecified |5.21.90 Component|compositing |scene-opengl CC||kokok...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438458] Yakuake flashes solid color when closing it in Plasma 5.22 in X11
https://bugs.kde.org/show_bug.cgi?id=438458 --- Comment #8 from Antonio Orefice --- Works fine till kwin 5.21.90 Downgrading it makes it work (have to downgrade kwayland-server to the same version too to make it happy) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438458] Yakuake flashes solid color when closing it in Plasma 5.22 in X11
https://bugs.kde.org/show_bug.cgi?id=438458 Antonio Orefice changed: What|Removed |Added Product|yakuake |kwin Component|general |scene-opengl Version|unspecified |5.21.90 Assignee|h...@kde.org|kwin-bugs-n...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more crossfade for window content
https://bugs.kde.org/show_bug.cgi?id=439689 Antonio Orefice changed: What|Removed |Added Version|5.22.3 |5.21.90 --- Comment #5 from Antonio Orefice --- First Broken version seems to be 5.21.90 I've had hard tme trying to bisect offending commit; but unfortunately all i've discovered so far is the following: Working till commit: Feb/15/21 22d386cd xwayland: Improve handling of Xwayland restarts [..] Broken at least from commit: apr/08/21 340c8b59 Update virtual desktops KCM docs Between them there is a black hole due to me having build problems. I've also changed the reported version to 5.21.90, because it worked till 5.21.5 which i've now downgraded to. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more Crossfade
https://bugs.kde.org/show_bug.cgi?id=439689 Antonio Orefice changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from Antonio Orefice --- PS: I've still a *not* upgraded system where maximize effect still does crossfades, while morphing popups does not, if it could be useful somehow. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more Crossfade
https://bugs.kde.org/show_bug.cgi?id=439689 --- Comment #2 from Antonio Orefice --- Created attachment 140468 --> https://bugs.kde.org/attachment.cgi?id=140468&action=edit maximize/minimize, no crossfade video. Oh weird, it is broken on 3 systems here. Fun fact: the first morphing to broke was the one referenced long time ago here: https://bugs.kde.org/show_bug.cgi?id=435423 ...in the sense that popups did not crossfade anymore, while window maximizing still worked. After some kwin release, the issue affected maximize animation too, so i tend to exclude drivers/hardware problems. Are you sure you cannot notice anything even with animations slowed down as in the video attached? I tried to install an older kwin version to rule out things, but unfortunately old kwin versions do not build on newer plasma. There are flashes/glitches in the video attached; they do depend on ffmpeg capturing while compositing and vsync is active (and it is not possible to disable vsync in kwin anymore...), don't mind them. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #41 from Antonio Orefice --- *** Bug 440382 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440382] Main toolbar elements messed up on (un)maximize when using split view.
https://bugs.kde.org/show_bug.cgi?id=440382 Antonio Orefice changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Antonio Orefice --- *** This bug has been marked as a duplicate of bug 430521 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #40 from Antonio Orefice --- *** Bug 434825 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 434825] Dolphin 20.12 shrinks places panel on unmaximize; 20.08 was fine
https://bugs.kde.org/show_bug.cgi?id=434825 Antonio Orefice changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REOPENED|RESOLVED --- Comment #16 from Antonio Orefice --- Setting as duplicate again, i checked and it is indeed fixed in the latest development branch. *** This bug has been marked as a duplicate of bug 430521 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440382] Main toolbar elements messed up on (un)maximize when using split view.
https://bugs.kde.org/show_bug.cgi?id=440382 Antonio Orefice changed: What|Removed |Added Summary|Main toolbar elements |Main toolbar elements |messed up on (un)maximize |messed up on (un)maximize |then using split view. |when using split view. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440382] New: Main toolbar elements messed up on (un)maximize then using split view.
https://bugs.kde.org/show_bug.cgi?id=440382 Bug ID: 440382 Summary: Main toolbar elements messed up on (un)maximize then using split view. Product: dolphin Version: 21.07.80 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: kokok...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 140386 --> https://bugs.kde.org/attachment.cgi?id=140386&action=edit Video of the bug SUMMARY When using split view and maximizing and unmaximizing the main dolphin window, toolbar elements got messed up. See Video attached. Offending commit: koko@Gozer# git bisect good 0cee94ce82ccb82afd0c4e22d77e251276e7a447 is the first bad commit commit 0cee94ce82ccb82afd0c4e22d77e251276e7a447 Author: Felix Ernst Date: Wed Jan 6 01:38:45 2021 + Fix location bar being wrongly aligned on first startup When starting Dolphin the very first time, the spacing in front of the location bar is wrong. This commit fixes this by completely updating all cached geometry every time adjustSpacing() is called. Because this happens once on a timer 100 ms after every url change, it will happen once shortly after the window is shown. At that point all geometry is where it should be and spacing calculation works as expected. The ViewContainer geometry retrieval is refactored into a small nested helper class in DolphinNavigatorsWidgetAction by the name ViewGeometriesHelper. Previously the logic of that class was divided between DolphinTabPage and DolphinNavigatorsWidgetAction. BUG: 429447 FIXED-IN: 21.04.0 src/dolphinnavigatorswidgetaction.cpp | 216 -- src/dolphinnavigatorswidgetaction.h | 78 src/dolphintabpage.cpp| 34 +- src/dolphintabpage.h | 5 - 4 files changed, 191 insertions(+), 142 deletions(-) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #37 from Antonio Orefice --- I bisected the issue, but even if i found the "bad" commit, it is not much useful, because it just exposes a bug introduced earlier and i cannot determine when using git bisect: In the past, the location bar were under the tabs, near the places panel. Then it was moved to the top and the users were not allowed to move it. Then the "bad" commit (not bad at all) 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1, allowed users to move the location bar where it was by simply removing the location bar from the main toolbar. So, I understood that dolphinui.rc is NOT needed to reproduce the issue, it just contained the information that the location bar was NOT present in the main toolbar, and as soon as the commit landed, that setting took place exposing the resize bug. So the bad commit could be anywhere between: 37327c9b0aae112c5890703cba1f0157043007e0 (Make UrlNavigators in the toolbar the only option) and 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1 (Allow having the UrlNavigators below the tab bar) --- koko@Gozer# git bisect bad 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1 is the first bad commit commit 50ca5af7e0ec460f9f004a3660efa10bb1dd8cb1 Author: Felix Ernst Date: Thu Nov 19 21:22:27 2020 + Allow having the UrlNavigators below the tab bar This commit restores the possibility to have the UrlNavigators below the tab bar. This will happen automatically whenever the UrlNavigator is removed from the toolbar. It is also now again possible to have the toolbar on the side. This option is disabled while the toolbar contains the UrlNavigators. This commit makes no changes to the new default which is having the UrlNavigators in the toolbar but makes sure that upgrading users won't be affected. src/dolphinmainwindow.cpp | 35 ++--- src/dolphinmainwindow.h | 13 src/dolphinnavigatorswidgetaction.cpp | 58 +-- src/dolphinnavigatorswidgetaction.h | 23 +- src/dolphintabpage.cpp| 23 -- src/dolphintabpage.h | 2 ++ src/main.cpp | 7 - 7 files changed, 110 insertions(+), 51 deletions(-) --- -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #36 from Antonio Orefice --- (In reply to Nate Graham from comment #34) > Thanks for the config file. I still cannot reproduce the issue even when I > use it on my own Dolphin. :( Given the config files posted, a way (not the only way) to reproduce the bug is: #1 shrink the dolphin window width to the minimum allowed, #2 maximize and unmaximize it. That triggers the window size bug, has the left panel has already been shrinked in step #1 Different combination of window size and places panel sizes triggers the window size bug *and* the places panel size bug -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #35 from Antonio Orefice --- Unfortunately on single screen setup (another system) things do not change. About the other thing i reported, i think they are related in the way that "dolphin is unable to correctly resize internal widgets anymore (used to work in the past)", and i think the problem in restoring the window size (and shrinking the places panel) depends on that. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 Antonio Orefice changed: What|Removed |Added Status|NEEDSINFO |REOPENED Resolution|WAITINGFORINFO |--- --- Comment #33 from Antonio Orefice --- Info given -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #32 from Antonio Orefice --- Created attachment 140350 --> https://bugs.kde.org/attachment.cgi?id=140350&action=edit other resize problems when in dual panel mode I've found that even using standard/shipped config files, there are widget resize problems when using dual panel view. This should be vanilla dolphin. See the video attached, I explicitely delete the config files, then i show the bug. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #31 from Antonio Orefice --- Sorry for the confusion, I've to retract my observations in comment 25 about ~/.config/dolphinrc, (i read and spoke about dolphinui.rc, ,sorry) Removing ~/.config/dolphinrc, does not change a thing. Sorry for the noise, everything stated in comment 25 was about dolphinui.rc which i think is the root of the problem. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #30 from Antonio Orefice --- Created attachment 140348 --> https://bugs.kde.org/attachment.cgi?id=140348&action=edit dolphinrc (In reply to Antonio Orefice from comment #29) > Hi Nate, i've attached one in the past in the other bug report: > https://bugs.kde.org/show_bug.cgi?id=434825 > https://bugs.kde.org/attachment.cgi?id=137023 Ok, it was "dolphinui.rc", and was the one causing problems. However, i'll attach you dolphinrc too from a dolphin that fails to restore window size when unmaximized. In both files there is no line starting with "maximized". -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #29 from Antonio Orefice --- Hi Nate, i've attached one in the past in the other bug report: https://bugs.kde.org/show_bug.cgi?id=434825 https://bugs.kde.org/attachment.cgi?id=137023 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #27 from Antonio Orefice --- I've no lines beginning with "Window-Maximized", but i've just this: "HDMI1 HDMI2 Window-Maximized 800x600=true" Deleted, killed dolphin, but the problem persisted. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 Antonio Orefice changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REOPENED --- Comment #25 from Antonio Orefice --- (In reply to Nate Graham from comment #24) > For anyone still experiencing the bug, can you try moving aside your > ~/.config/dolphinrc file and trying again? This will check to see if stale > config file entries could be causing the bug. Yep, starting from a newly generated file, it works as intended, as stated here: https://bugs.kde.org/show_bug.cgi?id=434825 However, the "intended" way raised some concerns about the removal of the search bar, quoting myself: > Also, the decision to move the url navigation widget > to the toolbar raises problems for the ones that > like to have text in the toolbar itself, because > enabling it breaks url navigation widget > alignment with the file view area. > moving the url navigation thing outside > of the toolbar raises the described problem again. > Another thing i noticed when i deleted dolphinui.rc, > is that the -previously present- "search toolbar", went gone. > It could be handy because one can use it to > accomodate url navigation bar, sacrifying some > space for the places panel. https://bugs.kde.org/show_bug.cgi?id=434825#c10 https://bugs.kde.org/show_bug.cgi?id=434825#c11 ...so basically the ones left with an old working configuration file have to choose to have resize problems (keep old file) or possibly disalignment of widgets when their sizes don't fit the intended position (...) I think the right way of handling this change would be the ability to keep the search bar and have dolphin able to properly resize itself, not asking users to delete their -previously working- configs. I understand the needs to simplify things, but not when that breaks working environments. This is happening more and more lately (Sorry.). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 438478] Device notifier shows SD card being inserted only once
https://bugs.kde.org/show_bug.cgi?id=438478 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 438079] scrolling in "window specific settings" jumps weirdly
https://bugs.kde.org/show_bug.cgi?id=438079 Antonio Orefice changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #4 from Antonio Orefice --- (In reply to David Edmundson from comment #3) > Thank you for the video. > Can you confirm if this happens with the breeze widget style? Yes, unfortunately, it does. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 438079] scrolling in "window specific settings" jumps weirdly
https://bugs.kde.org/show_bug.cgi?id=438079 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com --- Comment #2 from Antonio Orefice --- Created attachment 140045 --> https://bugs.kde.org/attachment.cgi?id=140045&action=edit Video I can confirm this bug since the "refactoring" of the effects window. Could we at least go back to the previous -working- classic window list, while thie bug is addressed, please? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] Maximize effect: no more Crossfade
https://bugs.kde.org/show_bug.cgi?id=439689 Antonio Orefice changed: What|Removed |Added Summary|Crossfade window effect |Maximize effect: no more |does not work |Crossfade -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439689] New: Crossfade window effect does not work
https://bugs.kde.org/show_bug.cgi?id=439689 Bug ID: 439689 Summary: Crossfade window effect does not work Product: kwin Version: 5.22.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-window-management Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- SUMMARY In the past when un/maximizing windows there was a nice crossfade effect betweeb the old window content and the target one. Now as soon as the animation starts, the new window content is displayed immediately and the old one is gone immediately, no more crossfade. STEPS TO REPRODUCE 1. activate maximize effect 2. slow down amination speed 3. (un)maximize a window 4. notice no crossfade OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices after connecting the device for 2nd time
https://bugs.kde.org/show_bug.cgi?id=438874 --- Comment #8 from Antonio Orefice --- Thank you for opening the bug report, i was just going to fill one myself. Confirmed of me, of course. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices after connecting the device for 2nd time
https://bugs.kde.org/show_bug.cgi?id=438874 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 Antonio Orefice changed: What|Removed |Added Status|NEEDSINFO |REOPENED Resolution|WAITINGFORINFO |--- --- Comment #20 from Antonio Orefice --- REOPENED and marked https://bugs.kde.org/show_bug.cgi?id=434825 as a duplicate for this. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #19 from Antonio Orefice --- *** Bug 434825 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
