[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 241557] Kwin's Zoom effect conflicts with other desktop effects like Blur
https://bugs.kde.org/show_bug.cgi?id=241557 --- Comment #17 from Antonio Orefice --- Any particular reason this bug is still marked as UNCONFIRMED (!?) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 241557] Kwin's Zoom effect conflicts with other desktop effects like Blur
https://bugs.kde.org/show_bug.cgi?id=241557 --- Comment #19 from Antonio Orefice --- Yes, yes, i did not mean that. I really mean just what i asked :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell keeps eating ram (NVIDIA BLOB), but never release it.
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #12 from Antonio Orefice --- For what is worth, the bug is present even in plasmoidviewer. Just play with it and see how his memory usage grows with ease. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell keeps eating ram, but never release it.
https://bugs.kde.org/show_bug.cgi?id=368838 Antonio Orefice changed: What|Removed |Added Summary|plasmashell keeps eating|plasmashell keeps eating |ram (NVIDIA BLOB), but |ram, but never release it. |never release it. | -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] New: Some effects goes slowmotion when vsync is disabled
https://bugs.kde.org/show_bug.cgi?id=372739 Bug ID: 372739 Summary: Some effects goes slowmotion when vsync is disabled Product: kwin Version: 5.8.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- Since i found that enabling nvidia internal full composition pipeline gives me stuttering free playback in dual head setups, i decided to use it instead of kwin's internal vsync logics. Since i disabled kwin vsync, dragging windows has become very, very slow, and it seems even fadein/fade out effects are slower. The affected effects are not jerky or stuttering, they move just as slow-motion. Other effects seems unaffected, like magic lamp. Since then, i reverted to xrender. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Some effects goes slowmotion when vsync is disabled
https://bugs.kde.org/show_bug.cgi?id=372739 --- Comment #1 from Antonio Orefice --- Ok, i've to add several information to this report, sorry. The slowness was due to a setting i have in my kwinrc: MaxFPS=300 I have to specify it because: 1) with vsync disabled, kwin render frames at 60hz, why? i don't know. 2) i switch between 60hz and 75hz and 300 is the closer multiple integer to both. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Vsync disabled: slowmotion effects or wrong fps?
https://bugs.kde.org/show_bug.cgi?id=372739 Antonio Orefice changed: What|Removed |Added Summary|Some effects goes |Vsync disabled: slowmotion |slowmotion when vsync is|effects or wrong fps? |disabled| -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Vsync disabled: slowmotion effects or wrong fps?
https://bugs.kde.org/show_bug.cgi?id=372739 --- Comment #3 from Antonio Orefice --- Hi Martin, thanks for answering. The real issue here, is that kwin is unable to detect the right refresh rate when vsync is disabled. Can we continue here or should i open another bug report about that? Or maybe even that would be marked as invalid? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Vsync disabled: slowmotion effects or wrong fps?
https://bugs.kde.org/show_bug.cgi?id=372739 --- Comment #5 from Antonio Orefice --- Hi again, maybe there is a misunderstanding here, sorry. The problem i have with limited framerate does not depend on the driver settings, I'm able to reproduce it even without nvidia's ForceFullCompositionPipeline=On What happens, is that if i remove MaxFPS= line from kwinrc and disable any "tearing prevention" in the compositor settings, kwin seems to render things at 60..62fps. I gather this information: 1- From the kwin's "Show FPS" effect: it shows 60..62 fps 2- by observing the windows edges while i drag it: If kwin's render rate were close to the display refresh, i'd expect to see smooth window dragging with a single "tearing" line, and this is indeed what happens if i specify MaxFPS=75 OR if i switch to a 60hz mode. But what happens is that the movement is jerky and there are several tearing lines/artifacts. As soon as i enable kwin's Tearing prevention ON (the method doesn't matter), the fps effect jumps to 75, i repeat, this happens with AND without any special driver configuration. Thanks for your attention. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Vsync disabled: slowmotion effects or wrong fps?
https://bugs.kde.org/show_bug.cgi?id=372739 --- Comment #7 from Antonio Orefice --- Created attachment 102386 --> https://bugs.kde.org/attachment.cgi?id=102386&action=edit supportinformation from kwin when running without vsync enabled -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372739] Vsync disabled: slowmotion effects or wrong fps?
https://bugs.kde.org/show_bug.cgi?id=372739 --- Comment #8 from Antonio Orefice --- and it picks: Refresh Rate: 75.0247 for both monitors with and without tearing prevention enabled, which should be fine... What puzzles me is why window movements are: *jerky: with vsync disabled and screen at 75hz *smooth: with vsync enabled at any refresh rate with vsync disabled and screen at 60hz with vsync disabled and screen at 75hz but MaxFPS=75 specified in kwinrc -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell keeps eating ram, but never release it.
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #13 from Antonio Orefice --- Created attachment 102436 --> https://bugs.kde.org/attachment.cgi?id=102436&action=edit plasmoidviewer: memory maps, memory status and "valgrind --tool=memcheck --leak-check=full" log As i found that plasmoidviewer leaks memory too, i was able to make a valgrind log out of it (too slow for the whole plasmashell). See that VmRSS jumped from 392504kB to 453376kB, all i did was moving, rotate and resize it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell keeps eating ram, but never release it.
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #14 from Antonio Orefice --- Created attachment 102437 --> https://bugs.kde.org/attachment.cgi?id=102437&action=edit log with debug symbols enabled for qt5-declarative and qt5-base Same as before, but with debug symbols for (what i think) relevant libraries. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 372812] Changing the volume with the wheel switches open windows
https://bugs.kde.org/show_bug.cgi?id=372812 Antonio Orefice changed: What|Removed |Added CC||kokok...@gmail.com -- 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 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 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.
[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.
[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] 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 #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.
[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.
[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 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 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 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] 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
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 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 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) 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 --- 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 #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 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] 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.
[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] 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 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.
[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 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 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 #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 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 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 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 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 #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 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 #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 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 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 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.
[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.
[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 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.
[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 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 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 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.
[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 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.
[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.
[Oxygen] [Bug 427417] New: Changing Shading -> contrast does not change anything.
https://bugs.kde.org/show_bug.cgi?id=427417 Bug ID: 427417 Summary: Changing Shading -> contrast does not change anything. Product: Oxygen Version: 5.19.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: style Assignee: unassigned-b...@kde.org Reporter: kokok...@gmail.com Target Milestone: --- SUMMARY Using oxygen decoration, if i modify shading->contrast in systemsettings -> Colors, nothing changes STEPS TO REPRODUCE 1. Select oxygen decoration 2. Open systemsettings -> Colors, edit the used color scheme 3. Modify Shading -> Contrast OBSERVED RESULT Dolphin window does not change his appearance, eg: the gradient in the background is the same. EXPECTED RESULT Window background should paint a different gradient, following the contrast setting given by color scheme. Other elements that i think should change color reacting to contrast preference stays the same (like the frame under the toolbar icons) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION Used to work in the past. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 427417] Changing Shading -> contrast does not change anything.
https://bugs.kde.org/show_bug.cgi?id=427417 --- Comment #1 from Antonio Orefice --- i noticed that the value for "contrast" in kdeglobals in [KDE] section is not updated by the color config utility. But if i chang it manualy and logout/login, then the contrast changes. I'm a bit lost now, because it seems not to be an oxygen style bug, but i don't know what component to choose to modify this bugreport. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 427417] Changing Shading -> contrast does not change anything.
https://bugs.kde.org/show_bug.cgi?id=427417 Antonio Orefice changed: What|Removed |Added Product|Oxygen |kde Component|style |general Version|5.19.5 |unspecified -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 427417] Changing Shading -> contrast does not change anything.
https://bugs.kde.org/show_bug.cgi?id=427417 --- Comment #2 from Antonio Orefice --- Hi Nate, Initially i identified the component as Oxygen, but i noticed that the color systemsettings module just does not update che "contrast" setting into the kdeglobals file. If i change it manually, oxygen reacts correctly. -- 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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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-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 --- 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 #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 #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 #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 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 #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 --- 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 #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.
[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.
[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 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 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 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 #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.
[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.
[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 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 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 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 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 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 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 #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.
