Created attachment 110127 [details] The width and height are set to be 100% I'm using a 4k monitor. After upgrading to KDE Plasma 12.0 (11.95), the width and height of the Yakuake terminal cannot be correctly set. I set the both of them to be 100%, while it actually only 50%.
I'm facing the same bug after my upgrade today. I'm using ArchLinux. Versions: yakuake: 3.0.4 plasma: 5.12.0 qt: 5.10.0 I have a 4k monitor running at native resolution 3840x2160. I also set scale display factor to 2, which KDE translates to QT_SCREEN_SCREAN_SCALE_FACTORS. I tried quitting and removing ~/.cache/yakuake and restarting but with no success.
Another report of the same bug: https://bugs.kde.org/show_bug.cgi?id=388217
Some investigation: Given my resolution 3840x2160, It appears that Qt returns screen geometry as 1920x1080, which has been scaled down by QT_SCREEN_SCALE_FACTORS=2. Then in KWindowSystem::workArea, which calls QScreen::geometry internally in X11 plugin[1], the returned value is scaled down the second time[2], and returns 960x540. Therefore yakuake calculates using wrong max height and width of the screen. [1] https://cgit.kde.org/kwindowsystem.git/tree/src/platforms/xcb/kwindowsystem.cpp#n73 [2] https://cgit.kde.org/kwindowsystem.git/tree/src/kwindowsystem.cpp#n599
Solved in a recently openSUSE Tumbleweed upgrade for reasons unknown.
(In reply to Marcel from comment #4) > Solved in a recently openSUSE Tumbleweed upgrade for reasons unknown. It happened again after I changed the theme.
I finally figure out why the size is wrong. If the top panel is center aligned, then the size will be wrong! After changing the alignment to "left", the size becomes normal.
(In reply to Marcel from comment #6) > I finally figure out why the size is wrong. If the top panel is center > aligned, then the size will be wrong! After changing the alignment to > "left", the size becomes normal. Well, it seems that auto hide is the reason why the size is abnormal.
workaround: QT_AUTO_SCREEN_SCALE_FACTOR=1;yakuake Happens only when screen scaling is active (scaling 1.5 for my hdpi screen)
sorry, wrong workaround, i use export QT_SCREEN_SCALE_FACTORS=1
*** Bug 392960 has been marked as a duplicate of this bug. ***
This is still an issue for me with Yakuake 3.0.5, Plasma 5.14.5, and QT 5.12, and Frameworks version 5.54.0. The only workaround for my use case is to use Yakuake 'Fullscreen' (ctrl+shift+F11) but this has the undesirable side effect of forcing Yakuake to be on top of any windows on the same virtual desktop, i.e. 'keep above' no longer works the way it should. Kernel 4.20 but that doesn't really matter.
I've found a workaround. Adding/removing virtual desktops seems to force Qt to recalculate the desktop size and makes Yakuake's sizing correct.
both bug 388217 and bug 401982 seem related/duplicate.
bug 377063 seems related
comment https://bugs.kde.org/show_bug.cgi?id=389448#c9 works for me
https://bugs.kde.org/show_bug.cgi?id=389448#c9 works for me as well.
*** Bug 369178 has been marked as a duplicate of this bug. ***
bug 396814 and bug 415184 seem to be related.
Spent some time digging into it, and this is what I came up with regarding this bug: The issue appears to happen whenever windows scaling of Plasma is set to something greater than 1 on a high dpi monitor. Yakuake will generate its initial dimensions based off of the original, unscaled dpi. This is accurate to observations of various testing on a high dpi system This is why Yakuake isn't centered on the screen: Yakuake specifies its own width via percentage of the max width of the screen, but it does so before the dpi is scaled. The issue seems to be reliably solved when a new virtual desktop is generated and Yakuake is reopened in it. Somehow, this generation forces Yakuake to recalculate the screen width in accordance to the scaled values. getDesktopGeometry() at yakuake/app/mainwindow.cpp:1435 seems to be where Yakuake is getting the information used to determine its dimensions. For non-Wayland and non-fullscreen, KWindowSystem::workArea() in kwindowsystem.cpp:601 is being called, which appears to then call devicePixelRatio() I believe this is the reason why the bug occurs: devicePixelRatio(), from the QGuiApplication class simply gets the HIGHEST screen device pixel ratio found on the system. We need to somehow programmatically determine the user's specified display/monitor scaling, and apply this in KwindowSystem::workArea() This can potentially done by using QWindow::devicePixelRatio() instead of QGuiApplication::devicePixelRatio(), as the QWindow variant specifically gets the pixel ratio for the specified window, which should respect the system's dpi scaling. I suspect that the creation of a virtual desktop on Plasma forces a re-calculation of devicePixelRatio(), potentially being called from QWindow, which is why the Yakuake window is 'fixed' when generating a new Plasma desktop. This is all speculation, however.
*** Bug 415184 has been marked as a duplicate of this bug. ***
Created attachment 126511 [details] attachment-31031-0.html Right I put too many reports in, my mistake! Sorry! I think a total of 4 0ver the last yr. Did not know better. regards; GE On Sat, Feb 29, 2020 at 10:07 PM Andrew Hou <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=389448 > > Andrew Hou <andrewfhou@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |gregorye541@gmail.com > > --- Comment #20 from Andrew Hou <andrewfhou@gmail.com> --- > *** Bug 415184 has been marked as a duplicate of this bug. *** > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 388217 has been marked as a duplicate of this bug. ***
*** Bug 377063 has been marked as a duplicate of this bug. ***
*** Bug 416901 has been marked as a duplicate of this bug. ***
*** Bug 415022 has been marked as a duplicate of this bug. ***
Created attachment 126520 [details] attachment-8639-0.html Yes it probably is, thanks On Sun, Mar 1, 2020 at 2:17 AM Andrew Hou <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #25 from Andrew Hou <andrewfhou@gmail.com> --- > *** Bug 415022 has been marked as a duplicate of this bug. *** > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 126523 [details] attachment-10060-0.html This has been fixed. Thank you guy's so much for doing this for me! Have a blessed life! GE On Sun, Mar 1, 2020 at 9:18 AM Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=389448 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Priority|NOR |HI > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Gregory Ernest from comment #27) > This has been fixed. Thank you guy's so much for doing this for me! > Have a blessed life! > GE Has this been fixed? the problem persists for me in recent OpenSUSE Tumbleweed (Plasma 5.19, KDE Frameworks 5.70, Qt 5.15, Yakuake 20.04.1 which reports itself as 3.0.5+)
I've been seeing this bug after moving my configuration from Kubuntu to OpenSUSE Tumbleweed. To get back proper scaling in Plasma, I had to set global scaling to 200% and PLASMA_USE_QT_SCALING=1 (in Kubuntu I had been using global scaling 100% and had set the scale using screen DPI). Since then Yakuake has been showing this behaviour. This seems to be consistent with Andrew Hou's observation that the initial geometry is based on a mix-up between logical and physical dimensions. In the meantime, I am resorting to an ugly workaround with a startup script that adds and then removes a virtual desktop using wmctrl.
Yes, it makes sense. When using PLASMA_USE_QT_SCALING=1, there's a mismatch in resolutions because Plasma uses the logical (scaled) resolution while KWin and KWindowSystem still speak in physical (unscaled) resolutions. This doesn't happen on Wayland because both of them use the logical resolution there. As far as I can tell, it's not super feasible to teach KWin to speak logical resolutions, so we need to convert between the two, probbly by having Yaukaue multiply the resolution it gets back from KWindowSystem by the device pixel ratio.
Thank you On Sat, Jun 27, 2020 at 12:02 PM Philipp Reichmuth <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #29 from Philipp Reichmuth <philipp.reichmuth@gmail.com> --- > I've been seeing this bug after moving my configuration from Kubuntu to > OpenSUSE Tumbleweed. To get back proper scaling in Plasma, I had to set global > scaling to 200% and PLASMA_USE_QT_SCALING=1 (in Kubuntu I had been using global > scaling 100% and had set the scale using screen DPI). Since then Yakuake has > been showing this behaviour. > > This seems to be consistent with Andrew Hou's observation that the initial > geometry is based on a mix-up between logical and physical dimensions. > > In the meantime, I am resorting to an ugly workaround with a startup script > that adds and then removes a virtual desktop using wmctrl. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Thanks again On Sat, Jun 27, 2020 at 12:36 PM Nate Graham <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|Width and height of the |Width and height of the > |window doesn't set |window doesn't set > |correctly on HiDPI screen |correctly on HiDPI screen > |after upgrade to plasma |when using Plasma Qt > |5.12 |scaling on X11 > Blocks| |356446 > > --- Comment #30 from Nate Graham <nate@kde.org> --- > Yes, it makes sense. When using PLASMA_USE_QT_SCALING=1, there's a mismatch in > resolutions because Plasma uses the logical (scaled) resolution while KWin and > KWindowSystem still speak in physical (unscaled) resolutions. This doesn't > happen on Wayland because both of them use the logical resolution there. > > As far as I can tell, it's not super feasible to teach KWin to speak logical > resolutions, so we need to convert between the two, probbly by having Yaukaue > multiply the resolution it gets back from KWindowSystem by the device pixel > ratio. > > > Referenced Bugs: > > https://bugs.kde.org/show_bug.cgi?id=356446 > [Bug 356446] plasmashell does not respect QT_DEVICE_PIXEL_RATIO on X > -- > You are receiving this mail because: > You are on the CC list for the bug.
Should be fixed by https://invent.kde.org/utilities/yakuake/-/merge_requests/22
thanks so much for the direct attention to this. On Sun, Jun 28, 2020 at 11:26 AM Nate Graham <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|CONFIRMED |ASSIGNED > > --- Comment #33 from Nate Graham <nate@kde.org> --- > Should be fixed by https://invent.kde.org/utilities/yakuake/-/merge_requests/22 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
This is working properly for me when using PLASMA_USE_QT_SCALING=1 on X11 with everything from git master on a high DPI screen. Can anyone with a similar setup confirm or deny?
This works for me as well on my machine (X11, non-HiDPI screen, simulated with display scaled to 125%), both without the PLASMA_USE_QT_SCALING environment variable set, and with it set to 1
Andrew I hope you are well, Thank you and the other's that have worked on this for me! I really do appreciate that and so far things seem fine. I see Yakuake change from the small to the default size. That is great! You have a nice holiday weekend and of course Stay safe. Hope your University is accommodating you and others during this difficult time. Again thank you so much! Greg On Fri, Jul 3, 2020 at 8:51 PM Andrew Hou <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #36 from Andrew Hou <andrewfhou@gmail.com> --- > This works for me as well on my machine (X11, non-HiDPI screen, simulated with > display scaled to 125%), both without the PLASMA_USE_QT_SCALING environment > variable set, and with it set to 1 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Awesome, looks like this got accidentally fixed somewhere else! :)
Is the fix only enabled by PLASMA_USE_QT_SCALING=1? If so, why is it not the default? I would prefer that the bug stays open until it works as intended out of the box.
Thank you Nate, Happy holiday! On Sat, Jul 4, 2020 at 4:50 AM Lastique <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #39 from Lastique <andysem@mail.ru> --- > Is the fix only enabled by PLASMA_USE_QT_SCALING=1? If so, why is it not the > default? > > I would prefer that the bug stays open until it works as intended out of the > box. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Looks like it works both with and without it now, and I've proposed making it the default in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/139/diffs
Thanks Nate for the info, things seem much better on my end. What you guy's do is very special. Please stay safe and tell your team I appreciate everything! Best regards; Greg On Mon, Jul 6, 2020 at 10:16 AM Nate Graham <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #41 from Nate Graham <nate@kde.org> --- > Looks like it works both with and without it now, and I've proposed making it > the default in > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/139/diffs > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 412308 has been marked as a duplicate of this bug. ***
*** Bug 417959 has been marked as a duplicate of this bug. ***
which version is this fixed in? I'm still seeing the same behaviour with Yakuake 20.08.0, Plasma 5.19.4, Frameworks 5.73.0, Qt 5.15.0. With screen scaling set to 200% and PLASMA_USE_QT_SCALING=1, Yakuake opens at 50% screen with. If I add and remove a virtual desktop, it rescales to 100% screen with. Before the 20.08 update, it would resize instantly; since the 20.08 update I have to close and reopen the Yakuake terminal window.
I still get this problem with Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75. At 200% display scaling on X11, the Yakuake window opens across 50% of the screen. As soon as I add and remove a virtual desktop, the window opens across the full width of the screen. This happens only on X11, in the Wayland session it works fine out of the box.
Thank you for the info, Have a nice weekend. On Fri, Oct 16, 2020 at 6:47 PM Philipp Reichmuth <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #46 from Philipp Reichmuth <philipp.reichmuth@gmail.com> --- > I still get this problem with Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75. > > At 200% display scaling on X11, the Yakuake window opens across 50% of the > screen. As soon as I add and remove a virtual desktop, the window opens across > the full width of the screen. > > This happens only on X11, in the Wayland session it works fine out of the box. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I was able to resolve this by deleting ~/.config/yakuakerc and resetting the settings. It fixed the half open problem for me. It was still doing it even when I had two 1440p screens, one in landscape and one in portrait.
Created attachment 132632 [details] Behaviour on HiDPI screen with 20.08.2 and Plasma 5.20 So I deleted .yakuakerc, and when it didn't work I cleaned out my .config directory and started from scratch. Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75.0, Qt 5.15.1 on OpenSUSE TW, screen scaling set to 200%. The screencast shows the behaviour I'm still seeing: Yakuake opens at 50% screen width until I add and remove a virtual desktop, the next time I open it it opens at 100%.
You seem to be making some headway, Good job! thank you again for the information, Greg On Thu, Oct 22, 2020 at 6:49 AM Philipp Reichmuth <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #49 from Philipp Reichmuth <philipp.reichmuth@gmail.com> --- > Created attachment 132632 [details] > --> https://bugs.kde.org/attachment.cgi?id=132632&action=edit > Behaviour on HiDPI screen with 20.08.2 and Plasma 5.20 > > So I deleted .yakuakerc, and when it didn't work I cleaned out my .config > directory and started from scratch. Yakuake 20.08.2, Plasma 5.20.0, Frameworks > 5.75.0, Qt 5.15.1 on OpenSUSE TW, screen scaling set to 200%. > > The screencast shows the behaviour I'm still seeing: Yakuake opens at 50% > screen width until I add and remove a virtual desktop, the next time I open it > it opens at 100%. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I'm reopening this, the behaviour persists for me on Yakuake 20.08.2 with Plasma 5.20.0 on OpenSUSE TW 20201021. I've removed ~/.config/yakuakerc and cleared out ~/.cache and I'm still seeing the same thing (see screencast).
If it helps - interestingly if I kill the Yakuake process and restart it, it opens correctly from the start, so there is some change here that persists. Steps to reproduce on my system (recent OpenSUSE TW, X11, KDE 5.20.2, scale factor 200%, 9 virtual desktops, Yakuake bound to F12 key): 1. Initial launch of Yakuake (e.g. through autostart) 2. Press F12, Yakuake window opens at 50% width 3. Type `wmctrl -n 10 && wmctrl -n 9` (i.e. add and remove a virtual desktop) 4. Press Esc to close the Yakuake window, which is still at 50% width 5. Press F12 again, Yakuake window now opens at 100% width 6. Type `killall -9 yakuake` 7. Open Konsole, in Konsole type `ps -ax | grep yakuake` --> not running 8. Launch Yakuake again 9. Press F12, Yakuake window still opens at 100% width
Thank you Philipp Reichmuth for this valuable update. Please stay safe and thank you all for working on this bug. Gregory Ernest On Thu, Nov 12, 2020 at 9:42 AM Philipp Reichmuth <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #52 from Philipp Reichmuth <philipp.reichmuth@gmail.com> --- > If it helps - interestingly if I kill the Yakuake process and restart it, it > opens correctly from the start, so there is some change here that persists. > > Steps to reproduce on my system (recent OpenSUSE TW, X11, KDE 5.20.2, scale > factor 200%, 9 virtual desktops, Yakuake bound to F12 key): > > 1. Initial launch of Yakuake (e.g. through autostart) > 2. Press F12, Yakuake window opens at 50% width > 3. Type `wmctrl -n 10 && wmctrl -n 9` (i.e. add and remove a virtual desktop) > 4. Press Esc to close the Yakuake window, which is still at 50% width > 5. Press F12 again, Yakuake window now opens at 100% width > 6. Type `killall -9 yakuake` > 7. Open Konsole, in Konsole type `ps -ax | grep yakuake` --> not running > 8. Launch Yakuake again > 9. Press F12, Yakuake window still opens at 100% width > > -- > You are receiving this mail because: > You are on the CC list for the bug.
With a more recent update (TW 20201127, Plasma 5.20.3, Frameworks 5.76, Qt 5.15.2, Yakuake 20.08.3) the problem has disappeared for me.
My problem seems to be resolved also. thank you guys so much for dealing with this problem. Happy Holidays and be safe! On Mon, Nov 30, 2020 at 7:50 AM Philipp Reichmuth <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > --- Comment #54 from Philipp Reichmuth <philipp.reichmuth@gmail.com> --- > With a more recent update (TW 20201127, Plasma 5.20.3, Frameworks 5.76, Qt > 5.15.2, Yakuake 20.08.3) the problem has disappeared for me. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Phew!
If I didn't thank you all for your talented efforts, I am grateful. Happy holidays and stay safe guy',s. On Mon, Nov 30, 2020 at 9:50 AM Nate Graham <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=389448 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |FIXED > Status|REOPENED |RESOLVED > > --- Comment #56 from Nate Graham <nate@kde.org> --- > Phew! > > -- > You are receiving this mail because: > You are on the CC list for the bug.