sway
sway copied to clipboard
swaywm
Use wlroots scene graph api
Closes: #6562 #7120 #6914 #6821 #6960 #6148 #5867 #5497 #5460 #6469 Supersedes: #6820 #6747
This should be enough where if most people were on this patch, they wouldn't know it. However, there are some features still missing from the port:
- [ ] Opacity support
Scene graph doesn't have support for specifying the opacity of a
wlr_scene_surface. However, implementing this would not be enough because we send in xdg surfaces into relevant helper functions that hide the surfaces / subsurfaces away from us. The easiest fix from the perspective of the user is the ability to specify the opacity of an entire subtree. - [ ] Surface scissor We're also missing support for specifying a scissor region for a surface node. This is useful because it will prevent applications that don't respect a configure from possibly rendering on top of other tiled applications. Again, the actual surface nodes are hidden from us, so it would be easiest to specify a scissor region for an entire subtree.
- [x] Buffer node output awareness
Scenes already handle client output awareness for us (
wlr_surface_send_enter,wlr_surface_send_leave) However, we don't have this information for buffer nodes so we can do more optimized text rending. For now text rendering is hard coded to a 2x screen scale and grey scale sub pixel handling. An appropriate solution to this problem is to supportwl_signals for output enter/exit events and the ability to overwrite the buffer in awlr_scene_buffer. - [ ] scale_filter option Scenes do linear filtering only. We need some way to specify this.
Wayland backend specific bugs (not regressions of this branch):
- Xwayland damage tracking issues, especially noticeable when entering/exiting full screen. This seems like a wlroots bug.
- Xwayland cropped cursor on HiDPI This is probably a bug I introduced but I'm not sure. This also happens sometimes in sway-git, maybe I messed the code up enough to make it 100% reproducible.
- Pointer lock doesn't work
Although there are xwayland damage tracking issues, this does not mean that current git is unaffected by damage tracking issues. In fact, this branch fixes damage tracking issues with subsurfaces on a xdg_surface popup, so as far as I know, for wayland clients damage tracking is perfect.
Hmm, the xwayland damage tracking issue goes away on DRM. That's very strange.
I'm getting some sort of nonsense SIGSEGV crash on DRM. This is what was in the core dump. @emersion can you make anything out in this?
[Current thread is 1 (Thread 0x7ffff671f5c0 (LWP 74245))]
(gdb) bt full
#0 0x00007ffff78603e0 in () at /usr/lib/libxkbcommon.so.0
#1 0x00007ffff792e0c0 in wlr_keyboard_keymaps_match (km1=0x55555632a080, km2=0x300000002) at ../types/wlr_keyboard.c:284
km1_str = 0x55555624cf80 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 708;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <repeats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>...
km2_str = 0x555555f842e0 "\320\313\001VUU"
result = false
#2 0x0000555555584589 in sway_keyboard_group_remove_invalid (keyboard=0x555556329320) at ../sway/input/keyboard.c:872
group = 0x5555562b6e10
device = 0x55555631c2f0
wlr_keyboard = 0x555556329150
seat = 0x555555ea5e70
sc = 0x555555f842e0
#3 0x0000555555584f24 in sway_keyboard_configure (keyboard=0x555556329320) at ../sway/input/keyboard.c:1082
input_config = 0x0
wlr_device = 0x5555563290d0
__PRETTY_FUNCTION__ = "sway_keyboard_configure"
keymap = 0x5555569828c0
keymap_changed = false
effective_layout_changed = false
repeat_rate = 25
repeat_delay = 600
repeat_info_changed = false
seat = 0x55555631c2f0
#4 0x0000555555588320 in seat_configure_keyboard (seat=0x555555ea5e70, seat_device=0x55555631c1e0) at ../sway/input/seat.c:781
focus = 0x555555585a87 <sway_input_configure_libinput_device+24>
#5 0x000055555558865f in seat_configure_device (seat=0x555555ea5e70, input_device=0x55555631c2f0) at ../sway/input/seat.c:858
seat_device = 0x55555631c1e0
#6 0x000055555557e093 in input_manager_configure_input (input_device=0x55555631c2f0) at ../sway/input/input-manager.c:530
seat = 0x555555ea5e70
#7 0x000055555557e0f8 in input_manager_configure_all_inputs () at ../sway/input/input-manager.c:537
input_device = 0x55555631c2f0
#8 0x00005555555c26e8 in output_disable (output=0x55555634ec10) at ../sway/tree/output.c:282
__PRETTY_FUNCTION__ = "output_disable"
index = 0
#9 0x000055555557817b in handle_destroy (listener=0x55555634ed08, data=0x55555634e030) at ../sway/desktop/output.c:212
output = 0x55555634ec10
server = 0x5555555e85c0 <server>
--Type <RET> for more, q to quit, c to continue without paging--
#10 0x00007ffff794e2a4 in wlr_signal_emit_safe (signal=0x55555634e250, data=0x55555634e030) at ../util/signal.c:29
pos = 0x55555634ed08
l = 0x55555634ed08
cursor = {link = {prev = 0x55555634ed08, next = 0x555556326040}, notify = 0x7ffff794e1ee <handle_noop>}
end = {link = {prev = 0x55555699c128, next = 0x55555634e250}, notify = 0x7ffff794e1ee <handle_noop>}
#11 0x00007ffff790873b in wlr_output_destroy (output=0x55555634e030) at ../types/output/output.c:429
cursor = 0x55555560b840
tmp_cursor = 0x7ffff79a8000
#12 0x00007ffff78e8809 in disconnect_drm_connector (conn=0x55555634e030) at ../backend/drm/drm.c:1540
__PRETTY_FUNCTION__ = "disconnect_drm_connector"
#13 0x00007ffff78e885a in destroy_drm_connector (conn=0x55555634e030) at ../backend/drm/drm.c:1546
#14 0x00007ffff78e279f in backend_destroy (backend=0x555555622c30) at ../backend/drm/backend.c:38
drm = 0x555555622c30
conn = 0x55555634e030
next = 0x55555634e3a0
fb = 0x555556017ee8
fb_tmp = 0x5555563290d0
#15 0x00007ffff78e0be9 in wlr_backend_destroy (backend=0x555555622c30) at ../backend/backend.c:63
#16 0x00007ffff78f61a4 in multi_backend_destroy (wlr_backend=0x55555560b7f0) at ../backend/multi/backend.c:59
sub = 0x5555556160b0
backend = 0x55555560b7f0
#17 0x00007ffff78f63b5 in handle_display_destroy (listener=0x55555560b840, data=0x55555560b700) at ../backend/multi/backend.c:134
backend = 0x55555560b7f0
#18 0x00007ffff79b28ff in wl_display_destroy () at /usr/lib/libwayland-server.so.0
#19 0x0000555555575460 in server_fini (server=0x5555555e85c0 <server>) at ../sway/server.c:263
#20 0x00005555555748fd in main (argc=1, argv=0x7fffffffead8) at ../sway/main.c:436
verbose = false
debug = false
validate = false
allow_unsupported_gpu = false
long_options =
{{name = 0x5555555cb230 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x5555555cb235 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x5555555cb23c "validate", has_arg = 0, flag = 0x0, val = 67}, {name = 0x5555555cb245 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x5555555cb24b "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x5555555cb253 "verbose", has_arg = 0, flag = 0x0, val = 86}, {name = 0x5555555cb25b "get-socketpath", has_arg = 0, flag = 0x0, val = 112}, {name = 0x5555555cb26a "unsupported-gpu", has_arg = 0, flag = 0x0, val = 117}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
config_path = 0x0
usage = 0x5555555cac88 "Usage: sway [options] [command]\n\n -h, --help", ' ' <repeats 13 times>, "Show help message and quit.\n -c, --co--Type <RET> for more, q to quit, c to continue without paging--
nfig <config> Specify a config file.\n -C, --validate Check the validity of the config file, th"...
c = -1
I have another code dump here that makes more sense. 0x1900000000 is a fishy address for wlr_keyboard->group
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/88561' in core file too small.
#0 0x0000557470b9f596 in sway_keyboard_group_remove_invalid (keyboard=0x557472977a70) at ../sway/input/keyboard.c:872
--Type <RET> for more, q to quit, c to continue without paging--
872 if (!wlr_keyboard_keymaps_match(keyboard->keymap, group->keyboard.keymap) ||
[Current thread is 1 (Thread 0x7fe4060b35c0 (LWP 88561))]
(gdb) bt full
#0 0x0000557470b9f596 in sway_keyboard_group_remove_invalid (keyboard=0x557472977a70) at ../sway/input/keyboard.c:872
group = 0x1900000000
device = 0x55747296aa40
wlr_keyboard = 0x5574729778a0
seat = 0x5574724efcb0
sc = 0x5574725cd100
#1 0x0000557470b9ff4b in sway_keyboard_configure (keyboard=0x557472977a70) at ../sway/input/keyboard.c:1082
input_config = 0x0
wlr_device = 0x557472977820
__PRETTY_FUNCTION__ = "sway_keyboard_configure"
keymap = 0x55747257c980
keymap_changed = false
effective_layout_changed = false
repeat_rate = 25
repeat_delay = 600
repeat_info_changed = false
seat = 0x55747296aa40
#2 0x0000557470ba3347 in seat_configure_keyboard (seat=0x5574724efcb0, seat_device=0x55747296a930) at ../sway/input/seat.c:781
focus = 0x557470ba0aae <sway_input_configure_libinput_device+24>
#3 0x0000557470ba3686 in seat_configure_device (seat=0x5574724efcb0, input_device=0x55747296aa40) at ../sway/input/seat.c:858
seat_device = 0x55747296a930
#4 0x0000557470b990ba in input_manager_configure_input (input_device=0x55747296aa40) at ../sway/input/input-manager.c:530
seat = 0x5574724efcb0
#5 0x0000557470b9911f in input_manager_configure_all_inputs () at ../sway/input/input-manager.c:537
input_device = 0x55747296aa40
#6 0x0000557470bdd70f in output_disable (output=0x557472990a70) at ../sway/tree/output.c:281
__PRETTY_FUNCTION__ = "output_disable"
index = 0
#7 0x0000557470b9317b in handle_destroy (listener=0x557472990b68, data=0x5574729b0b60) at ../sway/desktop/output.c:211
output = 0x557472990a70
server = 0x557470c035c0 <server>
#8 0x00007fe4072e22a4 in wlr_signal_emit_safe (signal=0x5574729b0d80, data=0x5574729b0b60) at ../util/signal.c:29
pos = 0x557472990b68
l = 0x557472990b68
cursor = {link = {prev = 0x557472990b68, next = 0x5574729b06b0}, notify = 0x7fe4072e21ee <handle_noop>}
end = {link = {prev = 0x557472fe9b18, next = 0x5574729b0d80}, notify = 0x7fe4072e21ee <handle_noop>}
#9 0x00007fe40729c73b in wlr_output_destroy (output=0x5574729b0b60) at ../types/output/output.c:429
cursor = 0x557471c55840
tmp_cursor = 0x7fe40733c000
#10 0x00007fe40727c809 in disconnect_drm_connector (conn=0x5574729b0b60) at ../backend/drm/drm.c:1540
__PRETTY_FUNCTION__ = "disconnect_drm_connector"
#11 0x00007fe40727c85a in destroy_drm_connector (conn=0x5574729b0b60) at ../backend/drm/drm.c:1546
#12 0x00007fe40727679f in backend_destroy (backend=0x557471c6cc30) at ../backend/drm/backend.c:38
drm = 0x557471c6cc30
conn = 0x5574729b0b60
next = 0x5574729b0ed0
fb = 0x557472660c38
fb_tmp = 0x557472977820
#13 0x00007fe407274be9 in wlr_backend_destroy (backend=0x557471c6cc30) at ../backend/backend.c:63
#14 0x00007fe40728a1a4 in multi_backend_destroy (wlr_backend=0x557471c557f0) at ../backend/multi/backend.c:59
sub = 0x557471c600b0
backend = 0x557471c557f0
#15 0x00007fe40728a3b5 in handle_display_destroy (listener=0x557471c55840, data=0x557471c55700) at ../backend/multi/backend.c:134
backend = 0x557471c557f0
#16 0x00007fe4073468ff in wl_display_destroy () at /usr/lib/libwayland-server.so.0
#17 0x0000557470b90460 in server_fini (server=0x557470c035c0 <server>) at ../sway/server.c:263
#18 0x0000557470b8f8fd in main (argc=1, argv=0x7ffd6dd386a8) at ../sway/main.c:436
Thanks for working on this!
I've patched my local install with this PR, and will dogfood it for a while.
Some early notes (I'll update this list as I come across things):
- Some transactions seem delayed, despite not being logged as having timed out. If I have a workspace with only
V[kitty kitty]and try interactive resizing, it is very juddery.V[uxterm uxterm]works fine, as do some other apps. - Borders are sometimes drawn in the wrong location, seems to be most easily triggered with kitty and very uneven splits. The borders are persistent (i.e. are not damage artifacts). If I had to guess, they are the borders from hidden tabs, the last time they were visible? They go away when flicking between tabs. Visual example:
Left kitty panel has borders drawn in the wrong place
- Borders are sometimes drawn in the wrong location
Seems to be a regression of a recent memory leak fix, I changed out the layout of the tree structure and I forgot to disable non-visible borders.
- Some transactions seem delayed
Thanks for letting me know about this oddball application. I'm able to reproduce. None of my applications have transaction issues so I haven't noticed there's a problem.
- Presentation time seems to be unimplemented or nonfunctional.
- When floating a tabbed application, the tab bar remained visible but wasn't redrawn to the right dimensions. Not all applications seem to trigger this.
Screenshot
- Other tab orientations that shouldn't be possible:
Screenshot
-
Rearranging layouts via window drag-and-drop (while holding Ctrl) appears nonfunctional. Rearranging tabs works, though.
-
Gaps drawn in unexpected places:
Screenshot
- Presentation time seems to be unimplemented or nonfunctional.
f6c900521e2f6c3020977d1b1b3f3010104f6780
- Borders are sometimes drawn in the wrong location
Fixed.
The kitty thing is escaping me.
reconfiguring 145
reconfigured serial: 144 expecting: 145
reconfigured serial: 144 expecting: 145
reconfigured serial: 144 expecting: 145
reconfigured serial: 144 expecting: 145
transaction timeout --------------------------------------------------------------
Kitty is getting reconfigured then responding with a bunch of commits with an out of date serial. Kitty bug?
Foot for reference:
reconfiguring 285
reconfigured serial: 285 expecting: 285
transaction completed
transaction completed
reconfiguring 286
reconfigured serial: 286 expecting: 286
transaction completed
transaction completed
reconfiguring 287
reconfigured serial: 287 expecting: 287
transaction completed
transaction completed
reconfiguring 288
reconfigured serial: 288 expecting: 288
transaction completed
transaction completed
reconfiguring 289
reconfigured serial: 289 expecting: 289
transaction completed
transaction completed
reconfiguring 290
reconfigured serial: 290 expecting: 290
transaction completed
Confirmed the borders look correct now + presentation-time works, great!
Kitty is getting reconfigured then responding with a bunch of commits with an out of date serial. Kitty bug?
Hmm, does it ever ack + commit to the same serial twice? If so that might be a bug (I'm not super familiar with the spec here -- but most invalid states result in protocol errors, which isn't happening here?), otherwise it's expected: the compositor may send multiple xdg_surface.configure events before the client has a chance to resize, ack, and commit a buffer (especially likely with hidpi mice). The documentation says:
If the client receives multiple configure events before it can respond to one, it only has to ack the last configure event.
A client is not required to commit immediately after sending an ack_configure request - it may even ack_configure several times before its next surface commit.
A client may send multiple ack_configure requests before committing, but only the last request sent before a commit indicates which configure event the client really is responding to.
...
If the client receives multiple configure events before it can respond to one, it is free to discard all but the last event it received.
- Gaps drawn in unexpected places:
I'm not 100% familiar with how gaps should work because I don't use them. I suspect that there should be no gaps in the tiled windows on the bottom right corner?
- Gaps drawn in unexpected places:
Fixed.
- When floating a tabbed application, the tab bar remained visible but wasn't redrawn to the right dimensions. Not all applications seem to trigger this.
That's weird. Maybe something to do with client side decorations? But that's working fine for me.
What display type are you using for qemu? I use -device virtio-vga-gl -display gtk,gl=on and it works fine.
Fixed.
Great!
What display type are you using for qemu?
Whoops, I think I confused you with the application in my screenshot -- it's not QEMU, it's https://looking-glass.io/. But... if you already have a QEMU VM and are feeling brave, you should be able to painlessly at least start Looking Glass:
Instructions
While your QEMU VM is running...
$ git clone https://github.com/gnif/LookingGlass
$ cd LookingGlass
$ git submodule update --init --recursive
$ cd client
$ mkdir build
$ cd build
$ cmake ..
$ sudo truncate --size 256M /dev/shm/looking-glass
$ sudo chown $(whoami):$(whoami) /dev/shm/looking-glass
$ ./looking-glass-client
If it complains, try ./looking-glass-client -s instead. It should say that it's using the Wayland backend in a log line at startup. If you get build errors for missing stuff, you can disable a bunch: -DENABLE_PIPEWIRE=no -DENABLE_X11=no etc.
You should get a window like
that reproduces the issue. Its interaction with xdg-shell is here: https://github.com/gnif/LookingGlass/blob/master/client/displayservers/Wayland/shell_xdg.c
- Rearranging layouts via window drag-and-drop
Fixed.
- When floating a tabbed application, the tab bar remained visible but wasn't redrawn to the right dimensions. Not all applications seem to trigger this.
The drag-and-drop stuff ended up being quite a little rabbit hole. I ended up fixing multiple issues. One of those issues explains your symptoms so I would like you to retest. I tried out looking glass myself, and it behaves normally. Give the bug I fixed, I don't think it had anything to do with looking glass itself. But the drag-and-drop stuff corrupted your workspace making any client bugged. I fixed it and added some asserts to prevent that corruption in the future.
The kitty thing is escaping me.
Kitty seems to only be acknowledging resizes, but not committing them afterwards. Not sure why it works on the master branch though. https://github.com/kovidgoyal/kitty/blob/cf520646a9261f6dada07d7a6735e10f6c1b27a2/glfw/wl_window.c#L506
Hmm. We have two handlers. We have a xdgToplevelListener which will do a wl_surface_commit. We also have a xdgSurfaceListener which just acks the configure. Maybe wlroots/sway is calling these handlers in the wrong order?
This patch for wlroots fixes kitty but breaks pretty much everything else. @Xyene @emersion any thoughts on this? Why does current master work?
diff --git a/types/xdg_shell/wlr_xdg_surface.c b/types/xdg_shell/wlr_xdg_surface.c
index 73ed66c9..9ed34697 100644
--- a/types/xdg_shell/wlr_xdg_surface.c
+++ b/types/xdg_shell/wlr_xdg_surface.c
@@ -136,6 +136,8 @@ static void surface_send_configure(void *user_data) {
configure->serial = surface->scheduled_serial;
configure->surface = surface;
+ xdg_surface_send_configure(surface->resource, configure->serial);
+
switch (surface->role) {
case WLR_XDG_SURFACE_ROLE_NONE:
assert(0 && "not reached");
@@ -154,8 +156,6 @@ static void surface_send_configure(void *user_data) {
}
wlr_signal_emit_safe(&surface->events.configure, configure);
-
- xdg_surface_send_configure(surface->resource, configure->serial);
}
uint32_t wlr_xdg_surface_schedule_configure(struct wlr_xdg_surface *surface) {
05:31:45 Nefsen402 | Is it part of the wayland protocol where a xdg_configure must happen after a toplevel_configure? See https://github.com/swaywm/sway/pull/6844#issuecomment-1054071084 for context.
05:43:37 kennylevinsen | Nefsen402: yes, it's required
05:43:47 kennylevinsen | xdg_surface::configure is strictly speaking the configure event that must be ackedc
05:44:11 vyivel | xdg_surface::configure marks the end of the configure sequence
05:44:28 Nefsen402 | Thanks, I guess I'll have to send in a kitty patch.
05:44:33 kennylevinsen | as per xdg_surface::configure documentation, roles like xdg_toplevel can augment the states that this configure represents, such as through xdg_toplevel::configure
Great work, can confirm things are better now. Looks like you also fixed left/bottom borders getting chopped off in full-workspace views :)
When floating a tabbed application, the tab bar remained visible but wasn't redrawn to the right dimensions. Not all applications seem to trigger this.
Persists in Looking Glass, but the other tab weirdness is gone. To reproduce this, I just started from T[kitty looking-glass] and floated Looking Glass. I just realized that starting it with -d (borderless mode) is necessary to reproduce this, so it's probably around CSD handling.
Screenshot
Not sure why it works on the master branch though.
Not sure if this isn't a red herring or a hint... but given something like V[kitty gedit], performing an interactive resize by dragging the gedit window is smooth, but juddery if dragging on kitty. I'd expect both to be equally choppy if kitty is holding up the transaction: both the gedit and kitty configures should be in the same transaction.
Persists in Looking Glass, but the other tab weirdness is gone. To reproduce this, I just started from
T[kitty looking-glass]and floated Looking Glass
Still having trouble reproducing this problem, is this the way you did it?
https://user-images.githubusercontent.com/3621017/156036298-62d547ea-af53-4962-ba75-904d9b535738.mp4
Yes, that's precisely what I did to cause the issue to occur. Maybe relevant is that I have workspace_layout tabbed in my config, so the terminal + application window are direct children of the workspace? I haven't tried to see if the issue reproduces when that's not the case, but can try later today.
Confirmed it doesn't reproduce when
workspace_layoutis nottabbed.
That's funny, I still can't reproduce it. I committed my pending changes just cleaning up some, but it shouldn't change anything.
https://github.com/Nefsen402/sway/blob/7709ef93ceda88f04febb0034def28d593866d9f/sway/desktop/transaction.c#L405 should disable the title bar from displaying with client side decorations. Can you confirm this code is running?
It's not, it goes down the B_NONE branch instead (toggling floating toggles it between B_NORMAL and B_NONE). Adding wlr_scene_node_set_enabled(con->title_bar.node, false); in the B_NONE branch seems to fix the issue when floating the window, but makes the titlebar disappear when the window is tiled and focused.
If the layout is B_NONE then it should be hitting this assert https://github.com/Nefsen402/sway/blob/7709ef93ceda88f04febb0034def28d593866d9f/sway/desktop/transaction.c#L444. If a container is B_NONE then it's view paramater shouldn't be NULL, in which case it will go down this branch https://github.com/Nefsen402/sway/blob/7709ef93ceda88f04febb0034def28d593866d9f/sway/desktop/transaction.c#L384.
Where are you adding this branch?
Edit. Nevermind, I was thinking of the wrong thing. I think I'm piecing this together.
I'm able to reproduce. The problem wasn't only about having workspace_layout tabbed but also default_border none.
- Resizing a floating
geditis juddery. Maybe another incarnation of the configure issue?
This PR
https://user-images.githubusercontent.com/1403503/156079589-0616c7c5-74c4-4302-9ac7-1bd599092f92.mp4
master
https://user-images.githubusercontent.com/1403503/156079566-a8ca6378-9350-4d4c-9fb8-ebecf1e8f744.mp4
- Resizing something like a floating Firefox causes it to paint well outside its borders for the duration of the resize. Amusingly, trying to capture this with
wf-recordermakes the issue go away, but I could get screenshots.
Screenshots
I sent in a patch to kitty: https://github.com/kovidgoyal/kitty/pull/4768
... After trying to figure out for 5 hours where the kitty build system put my linked binary.
- Resizing a floating
geditis juddery. Maybe another incarnation of the configure issue?
wlroots bug? This diff fixes the problem.
diff --git a/types/scene/xdg_shell.c b/types/scene/xdg_shell.c
index 9b3ad71c..ef2e30ef 100644
--- a/types/scene/xdg_shell.c
+++ b/types/scene/xdg_shell.c
@@ -68,7 +68,7 @@ static void scene_xdg_surface_handle_xdg_surface_commit(struct wl_listener *list
void *data) {
struct wlr_scene_xdg_surface *scene_xdg_surface =
wl_container_of(listener, scene_xdg_surface, xdg_surface_commit);
- scene_xdg_surface_update_position(scene_xdg_surface);
+ //scene_xdg_surface_update_position(scene_xdg_surface);
}
struct wlr_scene_node *wlr_scene_xdg_surface_create(
Sway master is currently ignoring the x, y position of wlr_xdg_surface_get_geometry on a toplevel. The xdg-shell wlr_scene abstraction we use does not ignore these values. Practically, these x, y coordinates should always be 0 for a toplevel but in the case of gedit they are not. @vyivel Is this a client bug or maybe we should look closer into wlroots?
The reason this is not happening for tiling windows is because we are overwriting the position with our own here: https://github.com/Nefsen402/sway/blob/ced8da83b8825ce61bdcca197bff501c5bc78144/sway/tree/view.c#L867. We probably shouldn't be doing this, but it also shouldn't matter.
^ these two points are completely wrong. Turns out gedit was rendering drop shadows when in floating mode confusing wlroots. When tiling, those drop shadows are disabled and things start working normally.
Fixed by: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3468
- Resizing something like a floating Firefox causes it to paint well outside its borders for the duration of the resize. Amusingly, trying to capture this with
wf-recordermakes the issue go away, but I could get screenshots.
I'm having trouble reproducing this, but this would be caused by firefox not configuring itself properly and maybe you're running a bit into:
- Surface scissor
As stated in the PR initial notes.
gedit and similar clients should be fixed up for real now, was actually a me problem, not wlroots.
Awesome, can confirm that's the case here. Also, Firefox no longer resizes strangely either. Getting there :)
- Many X11 applications time out transactions during interactive resizes in a similar way to
kitty, but only when floating: tested uxterm, Slack, CLion.