Created attachment 127007 [details] Floating decoration/title-bar alacritty window SUMMARY On Wayland+Plasma using iHD driver and iris Mesa driver when first opening alacritty there's a gap between the decoration/title bar and the window contents. See image for reference. This gap will remain until either the window is moved (click on title bar and drag window around) or the window is maximized and then resized (double click on title bar to maximize, double click on title bar again to resize to original window size). I've confirmed this happens even with a brand new plasma user created and logged on with defaults of both plasma and alacritty. I've also confirmed the issue is NOT present when starting Plasma with X11 instead. I've also confirmed the issue is not present if run within Sway for instance. STEPS TO REPRODUCE 1. Open Alacritty (either using custom keyboard shortcut, application launcher, run dialog, or even terminal) OBSERVED RESULT 2. Notice gap between titlebar/decoration and main application window which makes it appear that title bar is floating and disconnected 3. Gap will remain unless window is moved (while clicking on titlebar drag window to move) or is maximized and re-sized again (double click on title bar to maximize, then double click again to resize to original) EXPECTED RESULT Title-bar/window decoration is connected to main window as expected SOFTWARE/OS VERSIONS Linux/KDE Plasma: OS: Linux lap 5.5.11-arch1-1 #1 SMP PREEMPT Sun, 22 Mar 2020 16:33:15 +0000 x86_64 GNU/Linux Alacritty Version: alacritty 0.4.1 KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0-1 Qt Version: 5.14.1 ADDITIONAL INFORMATION Output of `qdbus org.kde.KWin /KWin supportInformation` https://gist.github.com/CarbonChauvinist/8d4902b5fe16aff41fbdd30fb76fca20 Screen grab of issue attached.
Additional information as to possible cause here in link below from github issue from alacritty's repo. https://github.com/alacritty/alacritty/issues/3517 Though this is devspeak and above my comprehension, AFAICT the tldr basically states: "Having instantiated, but not yet mapped sub-surfaces causes this behavior in KDE..." they found out they could work around it in their client application if they "either position the sub-surfaces so that they are completely encompassed by the parent surface, or you can instantiate them on-demand, just before mapping them."
Can I have output of "WAYLAND_DEBUG=1 alacritty" and reproducing this bug
Created attachment 128119 [details] WAYLAND_DEBUG=1 alacritty
(In reply to David Edmundson from comment #2) I've attached the log file captured via $ WAYLAND_DEBUG=1 alacritty 2>&1 | tee log.txt The attached log captures me simply using the window decoration buttons to maximize and restore the window in order to address the floating titlebar, then closing the application.
Created attachment 128545 [details] CSD Drawn Though Set to 'None' in alacritty.yml As another point that may be related, when setting the decoration to 'none' in alacritty.yml there is still a CSD drawn in plasma (see attached screen grab for reference). This does not happen when run with the same 'none' setting in Weston compositor. Interestingly, the vertical size of this CSD seems to be about the same gap that exists between alacritty's window and plasma's breeze decoration that caused me to open this original bug in the first place - may be related?
Created attachment 128546 [details] WAYLAND_DEBUG=1 alacritty (with 'none' decoration setting but CSD still drawn) And just for good measure here's the result WAYLAND_DEBUG log from starting alacritty with the 'none' decoration setting which still results in a CSD being drawn in plasma.
Hi, to get better understanding why this could happen, let me explain how decorations are handled in alacritty, so you may have a better understanding why you're facing this bug in KDE. First of all, all decorations on Wayland in alacritty are done by this project[1]. So it handled them by ALWAYS creating 5 subsurfaces[2], when you try creating a window, and SSD/CSD mode doesn't really matter here, since it's fine to create them, but not draw anything to them(it's a bit ugly, but it's correct code, that is being handled by mostly all compositors correctly). So those 5 subsurfaces are 1 for title bar and 4 for borders, the title bar is 30px, so one call to window geometry is -30px offset for some initial drawing, however that subsurface is not presented. However you may see the `set_geometry` with -30, ones, however there will be a proper set geometry later AFAICS. So, my theory is that our subsurfaces setup is somehow confusing kwin and it thinks that it should allocate space for those subsurfaces, where in reality it shouldn't (sway handles it correctly here AFAIK). But it could be that geometry calls are confusing kwin as well and it not trying to redraw window, idk. Also, you don't need alacritty to test this bug on, just any example from [1] should do a job(It uses rust wayland impl by default, so WAYLAND_DEBUG could be a bit different in terms of how it looks). Just running 'cargo run --example kbd_input' on those examples will likely work to repro and the code is more transparent and could give a better understanding why it happens. [1] - https://github.com/Smithay/client-toolkit [2] - https://github.com/Smithay/client-toolkit/blob/3555b3ce138422dc117e5b9ae33a22f574aa32be/src/window/concept_frame.rs#L346
> [ 11221.936] -> xdg_surface@32.set_window_geometry(0, -30, 1400, 600) Passing "-30" seems wrong. If you don't want to have a gap between server-side decorations and window contents, pass 0 instead of -30 or even better don't create sub-surfaces at all.
Urgh, I was looking at a wrong wayland debug output file.
>Passing "-30" seems wrong Nah, it's not that wrong. It'll indeed create a gap if we don't resize later and update geometry, but we do resize and use proper geometry, so I don't see much issues. Unless you can repro when we don't update window geometry to proper values. >even better don't create sub-surfaces at all. That could be the right thing to do, but creating sub-surfaces here is absolutely valid thing, and compositor should handle, don't you think?
You're absolutely right. The compositor should handle sub-surfaces well no matter what. I believe that we see this bug because kwin used to compute the effective window geometry incorrectly.
(In reply to Kirill Chibisov from comment #7) > Also, you don't need alacritty to test this bug on, just any example from > [1] should do a job(It uses rust wayland impl by default, so WAYLAND_DEBUG > could be a bit different in terms of how it looks). Just running 'cargo run > --example kbd_input' on those examples will likely work to repro and the > code is more transparent and could give a better understanding why it > happens. > Thank you for the detailed response. I've attached a log as you suggested of the following command: $ WAYLAND_DEBUG=1 cargo -v -v run --example kbd_input 2>&1 | tee ~/419235_cargo_example.log
Created attachment 129782 [details] WAYLAND_DEBUG=1 cargo -v -v run --example kbd_input
Created attachment 129783 [details] cargo example screenshot - duplicate decorations I should add that the issue is reproducible when running the cargo tests, somewhat -- here the titlebars are duplicated one from kwin and one from this rust library IIUC. Anyway, here is a screenshot of the result
Created attachment 129784 [details] another wayland debug cargo log - this time with actions Sorry for the spammed messages, thought it might be more helpful/useful to give a bit more information. Here's a longer wayland debug log captured as follows: When running the cargo test the application first appears with two titlebars, the kwin titlebar ontop of the CSD titlebar. Interacting with the CSD titlebar produces no feedback. If one minimizes the window using the kwin title bar decorations and then brings back to focus the window still has both title bars. If I then actually move the application window, click and drag the window on the screen, the CSD title bar disappears but leaves the gap between the kwin decoration titlebar that I originally opened this ticket for. I've attached the log of me doing the above here.
Created attachment 129794 [details] screen capture of cargo run --example kdb_input Finally, here's a screen capture of what I described above (this attachment is resampled sorry for blurriness) link below to bigger file size below https://github.com/CarbonChauvinist/webshare/raw/master/output2.mp4
Can't reproduce anymore and there were window geometry handling fixes. Reopen if alacritty still has a gap.