Bug 419235

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.