[vim/vim] Gvim stops redrawing content after resizing on KDE desktop (Issue #15972)
zdohnal
Steps to reproduce
- gvim --clean
- resize window with mouse (usually from smaller to larger window)
- try to write in insert mode, or enter a command
Expected behaviour
Gvim redrawing the screen, showing what user wrote if it is in correct mode
Version of Vim
9.1.0825 (the latest commit b5e7da1f27)
Environment
OS: Fedora 40
Desktop Environment: KDE
plasma-workspace-6.2.2-1.fc40.x86_64
kwayland-6.2.2-1.fc40.x86_64
kwin-6.2.2-1.fc40.x86_64
kwayland-server-5.24.5-6.fc40.x86_64
Logs and stack traces
I've tried to debug the issue a little - "frame_draw()" which I understand as a function which does the redrawing, is still called, but the screen content is not redrawn. The content can be seen again after resizing the window from Vim command mode, or sometimes I'm able to get it updated with making the window smaller. The original report https://bugzilla.redhat.com/show_bug.cgi?id=2322919 .
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Blaine Simpson
Have had same exact problem since updating at about the same time. I've applied minor updates since then and still have the problem with plasma-workspace 6.2.3-1. Disappointing to have to switch to a Windows computer to run gvim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
FocusedWolf
IDK if related but recently i starting having an issue where i couldn't resize GVim on KDE. I noticed i could still resize if i moved the mouse slow but if i dragged passed the bounds of the window it aborted and gvim became frozen ignoring all input. Right away i assumed it was Wayland. Fixed it by adding "GVIM_ENABLE_WAYLAND=1" to /etc/environment. My notes said to skip this step because gvim was capable of auto-detecting whether it was running under a Wayland session but that doesn't seem to be the case since the update. The alternate ways to set this environment variable is to put "export GVIM_ENABLE_WAYLAND=true" in /etc/locale.conf or ~/.bashrc
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
Oh wow, yes, that completely fixes it.
GVIM_ENABLE_WAYLAND=1 gvim works fine and can be resized.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Blaine Simpson
Same for me!
Oh wow, yes, that completely fixes it.
GVIM_ENABLE_WAYLAND=1 gvimworks fine and can be resized.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
With the environment variable set, resizing the gvim window prints these errors to the terminal:
(gvim:758888): Gdk-WARNING **: 14:25:03.223: gdk-frame-clock: layout continuously requested, giving up after 4 tries
(gvim:758888): Gdk-WARNING **: 14:25:03.256: gdk-frame-clock: layout continuously requested, giving up after 4 tries
I don't know if that's related to the problem. Maybe when the env var isn't set, that operation never gives up and so gets stuck?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
With the environment variable set, resizing the gvim window prints these errors to the terminal:
(gvim:758888): Gdk-WARNING **: 14:25:03.223: gdk-frame-clock: layout continuously requested, giving up after 4 tries (gvim:758888): Gdk-WARNING **: 14:25:03.256: gdk-frame-clock: layout continuously requested, giving up after 4 triesI don't know if that's related to the problem. Maybe when the env var isn't set, that operation never gives up and so gets stuck?
I don't get those warnings on Fedora 41, but do still have the resizing bug, so the warnings seem to be unrelated.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
Using GVIM_ENABLE_WAYLAND=1 gvim on a remote host over ssh -X (or with ForwardX11=yes) causes the gvim window to open on the remote host's local display, not on the local ssh client's display. So the env var is not a complete workaround, it's only usable when running gvim locally.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vít Ondruch
Just FTR, I have spent a lot of time (unsuccessfully) hunting down #12671. Given that one of the symptoms that one of the GTK timer is down, I can imagine the warning above might point to something.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I have no idea about WAYLAND, but certainly there must be a way to tell wayland where to draw the aplication. Similar like using the $DISPLAY environment variable on X11. Perhaps try to set $DISPLAY to your local PC.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
It's set of course (because it works over SSH without the environment variable set).
Reading around a bit, it might be necessary to use waypipe.
But if gvim was resizable when used over xwayland (or however it works) then the environment variable wouldn't be needed and so neither would waypipe
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Well, it sounds like a wayland usage question to me
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jorge Nerín
😕 I think the wayland over ssh is another totally unrelated issue, wayland does not forward the display using the X11 protocol, so it just doesn't work using ssh -X or ssh -Y.
Barring that, I have the symptoms described in this issue. On my local machine that runs wayland natively gvim (version Gentoo-9.1.0366) just behaves as described in this bug, with no ssh or forwarding between machines involved. Using GVIM_ENABLE_WAYLAND=1 gvim makes it behave properly, there's a rendering artifact with icon sizes being bigger than they should, potentially related to being a dual display with one 4k screen with scaling enabled at 175% and another 1080p screen at 100%, but that may be due to the GTK theme or icon set; it doesn't bother me too much now, and I think it's unrelated to the window resizing bug.
I see that according to qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole plain gvim launches it in X11 mode, as it appears in the "X11 windows" section, if I launch GVIM_ENABLE_WAYLAND=1 gvim it appears in the Wayland section, and I can resize it without issues.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
I think the wayland over ssh is another totally unrelated issue, wayland does not forward the display using the X11 protocol, so it just doesn't work using ssh -X or ssh -Y.
Yes I agree it's unrelated, my reason for bringing it up is just that setting GVIM_ENABLE_WAYLAND=1 gvim is only a solution for local gvim sessions, because if you're using it over ssh -X then you can't define the env var, and the resizing bug is a problem again.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
there's a rendering artifact with icon sizes being bigger than they should, potentially related to being a dual display with one 4k screen with scaling enabled at 175% and another 1080p screen at 100%, but that may be due to the GTK theme or icon set
That reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=2121076 which is caused by a missing (or not correctly scaled) icon.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Josh Holtrop
holtrop left a comment (vim/vim#15972)I think the wayland over ssh is another totally unrelated issue, wayland does not forward the display using the X11 protocol, so it just doesn't work using ssh -X or ssh -Y.
Yes I agree it's unrelated, my reason for bringing it up is just that setting
GVIM_ENABLE_WAYLAND=1 gvimis only a solution for local gvim sessions, because if you're using it overssh -Xthen you can't define the env var, and the resizing bug is a problem again.
I am hitting this issue as well. Unfortunately setting GVIM_ENABLE_WAYLAND seems to break gvim's clientserver functionality (--servername / --serverlist) so this isn't even a good workaround for local gvim sessions for users who use the clientserver features.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#15972)Unfortunately setting
GVIM_ENABLE_WAYLANDseems to break gvim's clientserver functionality (--servername / --serverlist) so this isn't even a good workaround for local gvim sessions for users who use the clientserver features.
Good news for you:
#17839
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#15972)By the way I also noticed resizing issues with gvim-x11 on kde on wayland where gvim-x11 uses xwayland as backend. Friends using real xorg-server I've asked to test don't experience same issues.
I believe plasma+xwayland might be confusing gvim-x11 coordinates, not sure why as it won't happen elsewhere.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.