simple_window example immediately crashes [Arch+Gnome]

[mitchmindtree]

Hey there!

I thought I'd have a go at running the wayland-window example after your comment at tomaka/winit#163 to test whether or not resizing or window works on this, however the example crashes as soon as it is run. Here is the output with RUST_BACKTRACE=1 WAYLAND_DEBUG=1 cargo run --example simple_window:

[456283.075]  -> wl_display@1.get_registry(new id wl_registry@2)
[456283.109]  -> wl_display@1.sync(new id wl_callback@3)
[456283.251] wl_display@1.delete_id(3)
[456283.263] wl_registry@2.global(1, "wl_drm", 2)
[456283.278] wl_registry@2.global(2, "wl_compositor", 3)
[456283.286] wl_registry@2.global(3, "wl_shm", 1)
[456283.295] wl_registry@2.global(5, "wl_output", 2)
[456283.311] wl_registry@2.global(6, "wl_data_device_manager", 3)
[456283.322] wl_registry@2.global(7, "gtk_primary_selection_device_manager", 1)
[456283.335] wl_registry@2.global(8, "zxdg_shell_v6", 1)
[456283.346] wl_registry@2.global(9, "wl_shell", 1)
[456283.358] wl_registry@2.global(10, "gtk_shell1", 1)
[456283.370] wl_registry@2.global(11, "wl_subcompositor", 1)
[456283.385]  -> wl_registry@2.bind(2, "wl_compositor", 3, new id [unknown]@4)
[456283.398]  -> wl_registry@2.bind(11, "wl_subcompositor", 1, new id [unknown]@5)
[456283.410]  -> wl_registry@2.bind(3, "wl_shm", 1, new id [unknown]@6)
[456283.422]  -> wl_registry@2.bind(9, "wl_shell", 1, new id [unknown]@7)
[456283.434] wl_registry@2.global(12, "zwp_pointer_gestures_v1", 1)
[456283.442] wl_registry@2.global(13, "zwp_tablet_manager_v2", 1)
[456283.451] wl_registry@2.global(14, "wl_seat", 5)
[456283.459] wl_registry@2.global(15, "zwp_relative_pointer_manager_v1", 1)
[456283.467] wl_registry@2.global(16, "zwp_pointer_constraints_v1", 1)
[456283.475] wl_registry@2.global(17, "zxdg_exporter_v1", 1)
[456283.484] wl_registry@2.global(18, "zxdg_importer_v1", 1)
[456283.492] wl_callback@3.done(4914)
[456283.540]  -> wl_compositor@4.create_surface(new id wl_surface@3)
[456283.549]  -> wl_shm@6.create_pool(new id wl_shm_pool@8, fd 5, 64)
[456283.560]  -> wl_shm_pool@8.create_buffer(new id wl_buffer@9, 0, 4, 4, 16, 0)
[456283.579]  -> wl_registry@2.bind(14, "wl_seat", 1, new id [unknown]@10)
[456283.592]  -> wl_surface@3.attach(wl_buffer@9, 0, 0)
[456283.601]  -> wl_surface@3.commit()
[456283.614]  -> wl_shm@6.create_pool(new id wl_shm_pool@11, fd 7, 1536)
[456283.626]  -> wl_compositor@4.create_surface(new id wl_surface@12)
[456283.633]  -> wl_compositor@4.create_surface(new id wl_surface@13)
[456283.638]  -> wl_compositor@4.create_surface(new id wl_surface@14)
[456283.644]  -> wl_compositor@4.create_surface(new id wl_surface@15)
[456283.652]  -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@16, wl_surface@12, wl_surface@3)
[456283.663]  -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@17, wl_surface@13, wl_surface@3)
[456283.673]  -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@18, wl_surface@14, wl_surface@3)
[456283.682]  -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@19, wl_surface@15, wl_surface@3)
[456283.692]  -> wl_subsurface@16.set_desync()
[456283.696]  -> wl_subsurface@17.set_desync()
[456283.699]  -> wl_subsurface@18.set_desync()
[456283.702]  -> wl_subsurface@19.set_desync()
[456283.706]  -> wl_shell@7.get_shell_surface(new id wl_shell_surface@20, wl_surface@3)
[456283.714]  -> wl_shell_surface@20.set_toplevel()
[456283.717]  -> wl_seat@10.get_pointer(new id wl_pointer@21)
[456283.822]  -> wl_shm@6.create_pool(new id wl_shm_pool@22, fd 9, 1024)
[456283.947]  -> wl_shm_pool@22.resize(4352)
[456283.975]  -> wl_shm_pool@22.resize(11008)
[456284.034]  -> wl_shm_pool@22.resize(24320)
[456284.138]  -> wl_shm_pool@22.resize(50944)
[456284.332]  -> wl_shm_pool@22.resize(104192)
[456285.135]  -> wl_shm_pool@22.resize(210688)
[456285.301]  -> wl_shm_pool@22.resize(423680)
[456286.601]  -> wl_shm_pool@22.resize(849664)
[456289.772]  -> wl_shm_pool@22.resize(1701632)
[456297.692]  -> wl_compositor@4.create_surface(new id wl_surface@23)
[456297.733]  -> wl_shm_pool@11.resize(3072)
[456300.224]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@24, 0, 32, 24, 128, 0)
[456300.279]  -> wl_surface@12.attach(wl_buffer@24, 0, 0)
[456300.291]  -> wl_subsurface@16.set_position(-8, -24)
[456300.301]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@25, 0, 8, 16, 32, 0)
[456300.318]  -> wl_surface@13.attach(wl_buffer@25, 0, 0)
[456300.328]  -> wl_subsurface@17.set_position(16, 0)
[456300.347]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@26, 0, 32, 8, 128, 0)
[456300.365]  -> wl_surface@14.attach(wl_buffer@26, 0, 0)
[456300.374]  -> wl_subsurface@18.set_position(-8, 16)
[456300.382]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@27, 0, 8, 16, 32, 0)
[456300.399]  -> wl_surface@15.attach(wl_buffer@27, 0, 0)
[456300.409]  -> wl_subsurface@19.set_position(-8, 0)
[456300.418]  -> wl_surface@12.commit()
[456300.422]  -> wl_surface@13.commit()
[456300.426]  -> wl_surface@14.commit()
[456300.429]  -> wl_surface@15.commit()
[456319.530]  -> wl_buffer@24.destroy()
[456319.558]  -> wl_buffer@25.destroy()
[456319.563]  -> wl_buffer@26.destroy()
[456319.566]  -> wl_buffer@27.destroy()
[456319.577]  -> wl_shm_pool@11.resize(26112)
[456334.638]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@28, 0, 272, 24, 1088, 0)
[456334.684]  -> wl_surface@12.attach(wl_buffer@28, 0, 0)
[456334.700]  -> wl_subsurface@16.set_position(-8, -24)
[456334.708]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@29, 0, 8, 128, 32, 0)
[456334.721]  -> wl_surface@13.attach(wl_buffer@29, 0, 0)
[456334.728]  -> wl_subsurface@17.set_position(256, 0)
[456334.734]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@30, 0, 272, 8, 1088, 0)
[456334.750]  -> wl_surface@14.attach(wl_buffer@30, 0, 0)
[456334.763]  -> wl_subsurface@18.set_position(-8, 128)
[456334.771]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@31, 0, 8, 128, 32, 0)
[456334.786]  -> wl_surface@15.attach(wl_buffer@31, 0, 0)
[456334.793]  -> wl_subsurface@19.set_position(-8, 0)
[456334.801]  -> wl_surface@12.commit()
[456334.804]  -> wl_surface@13.commit()
[456334.807]  -> wl_surface@14.commit()
[456334.809]  -> wl_surface@15.commit()
[456354.909]  -> wl_shm_pool@8.resize(131072)
[456354.995]  -> wl_buffer@9.destroy()
[456355.010]  -> wl_shm_pool@8.create_buffer(new id wl_buffer@32, 0, 256, 128, 1024, 0)
[456355.050]  -> wl_surface@3.attach(wl_buffer@32, 0, 0)
[456355.061]  -> wl_surface@3.commit()
[456355.097] wl_shell_surface@20.configure(0, 0, 0)
[456355.125]  -> wl_buffer@28.destroy()
[456355.130]  -> wl_buffer@29.destroy()
[456355.132]  -> wl_buffer@30.destroy()
[456355.136]  -> wl_buffer@31.destroy()
[456355.157]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@33, 0, 0, 24, 0, 0)
[456355.179]  -> wl_surface@12.attach(wl_buffer@33, 0, 0)
[456355.189]  -> wl_subsurface@16.set_position(-8, -24)
[456355.195]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@34, 0, 8, -32, 32, 0)
[456355.207]  -> wl_surface@13.attach(wl_buffer@34, 0, 0)
[456355.214]  -> wl_subsurface@17.set_position(-16, 0)
[456355.220]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@35, 0, 0, 8, 0, 0)
[456355.234]  -> wl_surface@14.attach(wl_buffer@35, 0, 0)
[456355.241]  -> wl_subsurface@18.set_position(-8, -32)
[456355.247]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@36, 0, 8, -32, 32, 0)
[456355.260]  -> wl_surface@15.attach(wl_buffer@36, 0, 0)
[456355.266]  -> wl_subsurface@19.set_position(-8, 0)
[456355.273]  -> wl_surface@12.commit()
[456355.276]  -> wl_surface@13.commit()
[456355.279]  -> wl_surface@14.commit()
[456355.282]  -> wl_surface@15.commit()
[456355.285]  -> wl_buffer@32.destroy()
[456355.288]  -> wl_shm_pool@8.create_buffer(new id wl_buffer@37, 0, -16, -32, -64, 0)
[456355.301]  -> wl_surface@3.attach(wl_buffer@37, 0, 0)
[456355.308]  -> wl_surface@3.commit()
[456358.365] wl_display@1.delete_id(24)
[456358.416] wl_display@1.delete_id(25)
[456358.421] wl_display@1.delete_id(26)
[456358.424] wl_display@1.delete_id(27)
[456358.428] wl_display@1.delete_id(9)
[456358.431] wl_display@1.delete_id(28)
[456358.435] wl_display@1.delete_id(29)
[456358.438] wl_display@1.delete_id(30)
[456358.441] wl_display@1.delete_id(31)
[456358.445] wl_display@1.error(wl_shm_pool@11, 1, "invalid width, height or stride (0x24, 0)")
wl_shm_pool@11: error 1: invalid width, height or stride (0x24, 0)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 71, message: "Protocol error" } }', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868
stack backtrace:
   1:     0x5626dfd3106c - std::sys::imp::backtrace::tracing::imp::write::hf33ae72d0baa11ed
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x5626dfd3359e - std::panicking::default_hook::{{closure}}::h59672b733cc6a455
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x5626dfd331a4 - std::panicking::default_hook::h1670459d2f3f8843
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x5626dfd33a3b - std::panicking::rust_panic_with_hook::hcf0ddb069e7beee7
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x5626dfd338d4 - std::panicking::begin_panic::hd6eb68e27bdf6140
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x5626dfd337f9 - std::panicking::begin_panic_fmt::hfea5965948b877f8
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:501
   7:     0x5626dfd33787 - rust_begin_unwind
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:477
   8:     0x5626dfd59b6d - core::panicking::panic_fmt::hc0f6d7b2c300cdd9
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/panicking.rs:69
   9:     0x5626dfcc9212 - core::result::unwrap_failed::h7b34ac9c984002a6
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/macros.rs:29
  10:     0x5626dfcc153c - <core::result::Result<T, E>>::unwrap::h2f1dd5149280877b
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:745
  11:     0x5626dfcd2fd5 - simple_window::main::h9882c10bc202ffda
                        at /home/mindtree/programming/rust/wayland-window/examples/simple_window.rs:127
  12:     0x5626dfd3a4ca - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  13:     0x5626dfd33f46 - std::rt::lang_start::hd7c880a37a646e81
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:436
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panic.rs:361
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/rt.rs:57
  14:     0x5626dfcd3fb2 - main
  15:     0x7fb02e598510 - __libc_start_main
  16:     0x5626dfcb6599 - _start
  17:                0x0 - <unknown>
[456471.254]  -> wl_shm_pool@22.destroy()

simple_window_debug.txt

Any ideas what might be going on here?

[mitchmindtree]

The crash seems to occur immediately after a call to the wayland_window::Handler::configure method implemented for Window. Upon entering the main loop, it is called the first time with the dimensions (256, 128), which seems fine as it indicates the window's initial dimensions. However, during the next pass of the loop, the method is called again dimensions (-16, -32) which are invalid and are likely the cause of the [456358.4(45] wl_display@1.error(wl_shm_pool@11, 1, "invalid width, height or stride (0x24, 0)") I posted in my previous comment.

If I change the configure implementation to ignore invalid dimensions like this:

if width <= 0 || height <= 0 {
    return;
}

The window seems to run relatively normally. It initially appears far offscreen to the left (this might have something to do with the different DPIs on each of my displays, though I'm unsure) but if I enter Gnome's "Activities" HUD I can move it back onto my other display and see it appearing normally:

The invlid dimensions don't seem to appear again after that first call in the second pass of the main loop, so perhaps it has something to do with the initial setup of the window or the decorations.

The window still seems to ignore resizing and dragging, despite the resize cursor showing correctly when hovering the mouse over each of the edges. I can also see that the event_queue is actually dispatching events during resize, however configure never gets called with the new dimensions. Curiously, if I click the terminal window (with which the simple_window example is ran), configure does get called however the width and height passed to it are the always (256, 120) so nothing changes.

I'll continue to dig deeper, though would still love to hear your thoughts in the meantime as I'm still a newbie when it comes to linux and wayland!

Thanks for all your efforts on wayland btw! I'm running an Arch+Gnome+Wayland system as my main development machine now so I'm keen to do my best to help get this into shape :+1:

[elinorbgr]

Yes, actually the example implementation should be something like

impl wayland_window::Handler for Window {
    fn configure(&mut self, _: &mut EventQueueHandle, _: wl_shell_surface::Resize, width: i32, height: i32) {
        use std::cmp::max;
        self.newsize = Some((max(width,1), max(height,1)))
    }
}

So that the window refuses to be resized smaller than (1,1) (which would be a protocol error anyway).

Regarding the fact that the window does not behave well... In your logs, when you try resizing it by grabbing a border, do you see the client sending a wl_shell_surface@...resize() event ?

PS: I will be quite busy today and the next two days, son won't be able to answer a lot, sorry.

[mitchmindtree]

@vberger yes, but only at the very beginning of the resize - does that sound correct?

Here is an annotated log from the moment I press the left mouse button and begin the attempt to resize from the right edge of the window:

Press the resizable edge:

[814139.649] wl_pointer@21.button(20109, 10070859, 272, 1)
[814139.727]  -> wl_shell_surface@20.resize(wl_seat@10, 20109, 8)

Drag the resizable edge to the right, attempting to make it wider (window desn't actually resize):

[815561.237] wl_pointer@21.motion(10072280, 4.179688, 85.035156)
[815578.364] wl_pointer@21.motion(10072295, 4.351562, 85.035156)
[815593.633] wl_pointer@21.motion(10072311, 4.527344, 85.035156)
[815610.814] wl_pointer@21.motion(10072326, 4.710938, 85.035156)
[815627.786] wl_pointer@21.motion(10072342, 4.894531, 85.035156)
[815644.873] wl_pointer@21.motion(10072357, 5.085938, 85.035156)
[815660.386] wl_pointer@21.motion(10072372, 5.277344, 85.035156)
[815680.182] wl_pointer@21.motion(10072395, 5.613281, 85.035156)
[815695.733] wl_pointer@21.motion(10072411, 5.968750, 85.035156)
[815712.571] wl_pointer@21.motion(10072426, 6.324219, 85.035156)
[815728.408] wl_pointer@21.motion(10072441, 6.496094, 85.035156)
[815746.070] wl_pointer@21.motion(10072464, 7.011719, 85.035156)
[815761.964] wl_pointer@21.motion(10072480, 7.355469, 85.035156)
[815780.930] wl_pointer@21.motion(10072488, 7.527344, 85.203125)
[815796.711] wl_pointer@21.motion(10072511, 7.527344, 85.367188)
[815870.186] wl_pointer@21.motion(10072587, 7.675781, 85.367188)
[817066.688] wl_pointer@21.motion(10073786, 7.785156, 85.367188)
[817765.569] wl_pointer@21.motion(10074484, 7.867188, 85.367188)
[818236.053] wl_pointer@21.motion(10074953, 7.953125, 85.367188)

Release the mouse button:

[818401.878] wl_pointer@21.button(20110, 10075122, 272, 0)
[818420.178] wl_pointer@21.leave(20111, wl_surface@13)
[818420.266]  -> wl_surface@23.attach(wl_buffer@34, 0, 0)
[818420.282]  -> wl_surface@23.damage(0, 0, 24, 24)
[818420.290]  -> wl_surface@23.commit()
[818420.294]  -> wl_pointer@21.set_cursor(20111, wl_surface@23, 4, 4)

Alt-tab back to the Terminal

[826417.962] wl_shell_surface@20.configure(0, 272, 152)
[826418.011]  -> wl_buffer@40.destroy()
[826418.018]  -> wl_buffer@41.destroy()
[826418.022]  -> wl_buffer@42.destroy()
[826418.025]  -> wl_buffer@43.destroy()
[826434.931]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@46, 0, 272, 24, 1088, 0)
[826435.139]  -> wl_surface@12.attach(wl_buffer@46, 0, 0)
[826435.171]  -> wl_subsurface@16.set_position(-8, -24)
[826435.185]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@47, 0, 8, 120, 32, 0)
[826435.210]  -> wl_surface@13.attach(wl_buffer@47, 0, 0)
[826435.230]  -> wl_subsurface@17.set_position(256, 0)
[826435.245]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@48, 0, 272, 8, 1088, 0)
[826435.278]  -> wl_surface@14.attach(wl_buffer@48, 0, 0)
[826435.288]  -> wl_subsurface@18.set_position(-8, 120)
[826435.294]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@49, 0, 8, 120, 32, 0)
[826435.318]  -> wl_surface@15.attach(wl_buffer@49, 0, 0)
[826435.327]  -> wl_subsurface@19.set_position(-8, 0)
[826435.335]  -> wl_surface@12.commit()
[826435.339]  -> wl_surface@13.commit()
[826435.341]  -> wl_surface@14.commit()
[826435.343]  -> wl_surface@15.commit()
[826435.350]  -> wl_buffer@44.destroy()
[826435.356]  -> wl_shm_pool@8.create_buffer(new id wl_buffer@50, 0, 256, 120, 1024, 0)
[826435.373]  -> wl_surface@3.attach(wl_buffer@50, 0, 0)
[826435.382]  -> wl_surface@3.commit()

Should it be continually receiving resize events? Or only the very first?

I also tried dragging the window by grabbing the top bar with the left mouse button and moving it slightly to the right. Here are the logs for that:

Left-press the top title bar of the window:

[1142431.986] wl_pointer@21.button(21483, 10399152, 272, 1)
[1142432.020]  -> wl_shell_surface@20.move(wl_seat@10, 21483)

Attempt to drag the cursor to the right by moving the mouse (window doesn't actually move):

[1144728.157] wl_pointer@21.motion(10401447, 154.250000, 8.613281)
[1144744.943] wl_pointer@21.motion(10401462, 154.421875, 8.613281)
[1144761.082] wl_pointer@21.motion(10401478, 154.597656, 8.613281)
[1144777.543] wl_pointer@21.motion(10401493, 154.871094, 8.613281)
[1144795.330] wl_pointer@21.motion(10401508, 155.152344, 8.613281)
[1144810.354] wl_pointer@21.motion(10401524, 155.445312, 8.613281)
[1144826.021] wl_pointer@21.motion(10401539, 155.843750, 8.613281)
[1144843.374] wl_pointer@21.motion(10401555, 156.261719, 8.613281)
[1144858.800] wl_pointer@21.motion(10401578, 157.531250, 8.613281)
[1144881.282] wl_pointer@21.motion(10401593, 158.261719, 8.613281)
[1144896.999] wl_pointer@21.motion(10401608, 158.753906, 8.613281)
[1144917.378] wl_pointer@21.motion(10401631, 159.457031, 8.613281)
[1144933.127] wl_pointer@21.motion(10401647, 159.914062, 8.613281)
[1144952.112] wl_pointer@21.motion(10401670, 160.550781, 8.613281)
[1145003.190] wl_pointer@21.motion(10401716, 160.734375, 8.613281)
[1145206.336] wl_pointer@21.motion(10401923, 160.878906, 8.613281)
[1145223.372] wl_pointer@21.motion(10401938, 161.113281, 8.613281)
[1145242.660] wl_pointer@21.motion(10401954, 161.343750, 8.613281)
[1145276.560] wl_pointer@21.motion(10401992, 162.031250, 8.613281)
[1145294.371] wl_pointer@21.motion(10402007, 162.265625, 8.613281)
[1145310.132] wl_pointer@21.motion(10402023, 162.500000, 8.613281)
[1145329.631] wl_pointer@21.motion(10402046, 162.953125, 8.613281)
[1145345.538] wl_pointer@21.motion(10402061, 163.320312, 8.613281)
[1145364.904] wl_pointer@21.motion(10402069, 163.507812, 8.613281)
[1145380.779] wl_pointer@21.motion(10402084, 163.687500, 8.613281)
[1145996.511] wl_pointer@21.motion(10402713, 163.824219, 8.613281)
[1146080.881] wl_pointer@21.motion(10402798, 163.925781, 8.613281)
[1146250.205] wl_pointer@21.motion(10402967, 164.023438, 8.613281)
[1147148.209] wl_pointer@21.motion(10403865, 164.113281, 8.613281)
[1147207.543] wl_pointer@21.motion(10403926, 164.195312, 8.613281)

Release the mouse button

[1147207.601] wl_pointer@21.button(21484, 10403926, 272, 0)

[elinorbgr]

I may be missing something, but to me it looks like Gnome is not behaving correctly as a compositor here.

The expected behavior (and what weston does) is that the client should send a single "resize" or "move" request, to initiate the interactive resize or move, and then the compositor should handle the rest : move the window around, or continually send "configure" events to notify the client about its new size. Until the mouse button is released.

Now, it's entirely possible that the gnome developers did not bother implementing wl_shell fully because they are focusing on xdg_shell, and ideally we'd be using it too. But we can't before rust 1.17, as it requires the "recursive_static" feature gate which will only be stabilized then.

Le 24 avril 2017 08:00:37 GMT+02:00, mitchmindtree notifications@github.com a écrit :

@vberger yes, but only at the very beginning of the resize - does that sound correct?

Here is an annotated log from the moment I press the left mouse button and begin the attempt to resize from the right edge of the window:

Press the resizable edge:

[814139.649] wl_pointer@21.button(20109, 10070859, 272, 1)
[814139.727]  -> wl_shell_surface@20.resize(wl_seat@10, 20109, 8)

Drag the resizable edge to the right, attempting to make it wider (window desn't actually resize):

[815561.237] wl_pointer@21.motion(10072280, 4.179688, 85.035156)
[815578.364] wl_pointer@21.motion(10072295, 4.351562, 85.035156)
[815593.633] wl_pointer@21.motion(10072311, 4.527344, 85.035156)
[815610.814] wl_pointer@21.motion(10072326, 4.710938, 85.035156)
[815627.786] wl_pointer@21.motion(10072342, 4.894531, 85.035156)
[815644.873] wl_pointer@21.motion(10072357, 5.085938, 85.035156)
[815660.386] wl_pointer@21.motion(10072372, 5.277344, 85.035156)
[815680.182] wl_pointer@21.motion(10072395, 5.613281, 85.035156)
[815695.733] wl_pointer@21.motion(10072411, 5.968750, 85.035156)
[815712.571] wl_pointer@21.motion(10072426, 6.324219, 85.035156)
[815728.408] wl_pointer@21.motion(10072441, 6.496094, 85.035156)
[815746.070] wl_pointer@21.motion(10072464, 7.011719, 85.035156)
[815761.964] wl_pointer@21.motion(10072480, 7.355469, 85.035156)
[815780.930] wl_pointer@21.motion(10072488, 7.527344, 85.203125)
[815796.711] wl_pointer@21.motion(10072511, 7.527344, 85.367188)
[815870.186] wl_pointer@21.motion(10072587, 7.675781, 85.367188)
[817066.688] wl_pointer@21.motion(10073786, 7.785156, 85.367188)
[817765.569] wl_pointer@21.motion(10074484, 7.867188, 85.367188)
[818236.053] wl_pointer@21.motion(10074953, 7.953125, 85.367188)

Release the mouse button:

[818401.878] wl_pointer@21.button(20110, 10075122, 272, 0)
[818420.178] wl_pointer@21.leave(20111, wl_surface@13)
[818420.266]  -> wl_surface@23.attach(wl_buffer@34, 0, 0)
[818420.282]  -> wl_surface@23.damage(0, 0, 24, 24)
[818420.290]  -> wl_surface@23.commit()
[818420.294]  -> wl_pointer@21.set_cursor(20111, wl_surface@23, 4, 4)

Alt-tab back to the Terminal

[826417.962] wl_shell_surface@20.configure(0, 272, 152)
[826418.011]  -> wl_buffer@40.destroy()
[826418.018]  -> wl_buffer@41.destroy()
[826418.022]  -> wl_buffer@42.destroy()
[826418.025]  -> wl_buffer@43.destroy()
[826434.931]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@46, 0,
272, 24, 1088, 0)
[826435.139]  -> wl_surface@12.attach(wl_buffer@46, 0, 0)
[826435.171]  -> wl_subsurface@16.set_position(-8, -24)
[826435.185]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@47, 0,
8, 120, 32, 0)
[826435.210]  -> wl_surface@13.attach(wl_buffer@47, 0, 0)
[826435.230]  -> wl_subsurface@17.set_position(256, 0)
[826435.245]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@48, 0,
272, 8, 1088, 0)
[826435.278]  -> wl_surface@14.attach(wl_buffer@48, 0, 0)
[826435.288]  -> wl_subsurface@18.set_position(-8, 120)
[826435.294]  -> wl_shm_pool@11.create_buffer(new id wl_buffer@49, 0,
8, 120, 32, 0)
[826435.318]  -> wl_surface@15.attach(wl_buffer@49, 0, 0)
[826435.327]  -> wl_subsurface@19.set_position(-8, 0)
[826435.335]  -> wl_surface@12.commit()
[826435.339]  -> wl_surface@13.commit()
[826435.341]  -> wl_surface@14.commit()
[826435.343]  -> wl_surface@15.commit()
[826435.350]  -> wl_buffer@44.destroy()
[826435.356]  -> wl_shm_pool@8.create_buffer(new id wl_buffer@50, 0,
256, 120, 1024, 0)
[826435.373]  -> wl_surface@3.attach(wl_buffer@50, 0, 0)
[826435.382]  -> wl_surface@3.commit()

Should it be continually receiving resize events? Or only the very first?

I also tried dragging the window by grabbing the top bar with the left mouse button and moving it slightly to the right. Here are the logs for that:

Left-press the top title bar of the window:

[1142431.986] wl_pointer@21.button(21483, 10399152, 272, 1)
[1142432.020]  -> wl_shell_surface@20.move(wl_seat@10, 21483)

Attempt to drag the cursor to the right by moving the mouse (window doesn't actually move):

[1144728.157] wl_pointer@21.motion(10401447, 154.250000, 8.613281)
[1144744.943] wl_pointer@21.motion(10401462, 154.421875, 8.613281)
[1144761.082] wl_pointer@21.motion(10401478, 154.597656, 8.613281)
[1144777.543] wl_pointer@21.motion(10401493, 154.871094, 8.613281)
[1144795.330] wl_pointer@21.motion(10401508, 155.152344, 8.613281)
[1144810.354] wl_pointer@21.motion(10401524, 155.445312, 8.613281)
[1144826.021] wl_pointer@21.motion(10401539, 155.843750, 8.613281)
[1144843.374] wl_pointer@21.motion(10401555, 156.261719, 8.613281)
[1144858.800] wl_pointer@21.motion(10401578, 157.531250, 8.613281)
[1144881.282] wl_pointer@21.motion(10401593, 158.261719, 8.613281)
[1144896.999] wl_pointer@21.motion(10401608, 158.753906, 8.613281)
[1144917.378] wl_pointer@21.motion(10401631, 159.457031, 8.613281)
[1144933.127] wl_pointer@21.motion(10401647, 159.914062, 8.613281)
[1144952.112] wl_pointer@21.motion(10401670, 160.550781, 8.613281)
[1145003.190] wl_pointer@21.motion(10401716, 160.734375, 8.613281)
[1145206.336] wl_pointer@21.motion(10401923, 160.878906, 8.613281)
[1145223.372] wl_pointer@21.motion(10401938, 161.113281, 8.613281)
[1145242.660] wl_pointer@21.motion(10401954, 161.343750, 8.613281)
[1145276.560] wl_pointer@21.motion(10401992, 162.031250, 8.613281)
[1145294.371] wl_pointer@21.motion(10402007, 162.265625, 8.613281)
[1145310.132] wl_pointer@21.motion(10402023, 162.500000, 8.613281)
[1145329.631] wl_pointer@21.motion(10402046, 162.953125, 8.613281)
[1145345.538] wl_pointer@21.motion(10402061, 163.320312, 8.613281)
[1145364.904] wl_pointer@21.motion(10402069, 163.507812, 8.613281)
[1145380.779] wl_pointer@21.motion(10402084, 163.687500, 8.613281)
[1145996.511] wl_pointer@21.motion(10402713, 163.824219, 8.613281)
[1146080.881] wl_pointer@21.motion(10402798, 163.925781, 8.613281)
[1146250.205] wl_pointer@21.motion(10402967, 164.023438, 8.613281)
[1147148.209] wl_pointer@21.motion(10403865, 164.113281, 8.613281)
[1147207.543] wl_pointer@21.motion(10403926, 164.195312, 8.613281)

Release the mouse button

[1147207.601] wl_pointer@21.button(21484, 10403926, 272, 0)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/vberger/wayland-window/issues/16#issuecomment-296531455

[mitchmindtree]

But we can't before rust 1.17, as it requires the "recursive_static" feature gate which will only be stabilized then.

Would you mind elaborating on this a little? Do you have plans to move to xdg_shell once 1.17 is released in a few days? Do you have a fork/feature/issue that I might be able to track somewhere? I'd be happy to test/help if there's a possibility it could solve this issue.

I asked in the wayland IRC about wl_shell:

< mindtree> hey folks, is wl-shell still (or was it ever fully) supported in the latest stable Gnome release? < ANON> mindtree, I'd be surprised if it was not, since so many programs use it in lack of a stable alternative. That said, I don't actually know.

After explaining my exact issues a little further, this was suggested:

Maybe there is an issue with input event serials, if the resize or move is dismissed immediately?

Could this be a possibility? There's probably a better place I could ask for support than the wayland IRC I suppose. I guess it is mutter that does not seem to be behaving as expected in this case - would I be correct in saying that?

[elinorbgr]

I have nothing working yet, apart from the API bindings to the xdg_shell protocol extension in the wayland-protocols crate.

My goal for wayland-window would be to have xdg_shell support as a cargo feature enabled by default (to remain pre-1.17 compatible) and try to use it at runtime, fallbacking to wl_shell (the current implementation) if it is not available.

But all this means quite some work tbh, and with the other wayland libs and smithay, I don't have a huge amount of time. So this got relatively low priority as the current backend seemed "good enough", especially considering xdg_shell is still an experimental protocol that has not reached a stable release (but wl_shell is already deprecated so everybody uses xdg_shell anyway, I guess...)

Le 24 avril 2017 11:38:25 GMT+02:00, mitchmindtree notifications@github.com a écrit :

But we can't before rust 1.17, as it requires the "recursive_static" feature gate which will only be stabilized then.

Would you mind elaborating on this a little? Do you have plans to move to xdg_shell once 1.17 is released in a few days? Do you have a fork/feature/issue that I might be able to track somewhere? I'd be happy to test/help if there's a possibility it could solve this issue.

I asked in the wayland IRC about wl_shell:

< mindtree> hey folks, is wl-shell still (or was it ever fully) supported in the latest stable Gnome release? < ANON> mindtree, I'd be surprised if it was not, since so many programs use it in lack of a stable alternative. That said, I don't actually know.

After explaining my exact issues a little further, this was suggested:

Maybe there is an issue with input event serials, if the resize or move is dismissed immediately?

Could this be a possibility? There's probably a better place I could ask for support than the wayland IRC I suppose. I guess it is mutter that does not seem to be behaving as expected in this case - would I be correct in saying that?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/vberger/wayland-window/issues/16#issuecomment-296595971

[mitchmindtree]

@vberger out of curiosity, what system do you run that uses wayland that runs this example successfully (including allowing to resize and move the window)?

[mitchmindtree]

I just ran the simple_window example with weston (launched in a window) and it seemed to work perfectly! Perhaps this does indicate that there's some issue with mutter's implementation of wl_shell.

[elinorbgr]

I do most of my testing using weston currently.

Le 24 avril 2017 13:17:10 GMT+02:00, mitchmindtree notifications@github.com a écrit :

@vberger out of curiosity, what system do you run that uses wayland that runs this example successfully (including allowing to resize and move the window)?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/vberger/wayland-window/issues/16#issuecomment-296623622

[mitchmindtree]

@vberger After doing a bit more research and talking to the gnome IRC it seems like Gnome's priority switched from supporting wl_shell to xdg_shell around 2014, so I feel my time might be best spent helping implement the xdg_shell feature for wayland-rs.

Could you possibly provide a small overview (perhaps a new issue at wayland-rs) of the work that needs to be done to make this happen and any recommended steps for approaching it? Could I perhaps use the existing wl_shell implementation as a rough guide for how to implement this in wayland-rs?

[elinorbgr]

Well, sure. Actually no work needs to be done on wayland-rs itself, only here, on wayland-window.

The bindings for xdg_shell are provided by the wayland-protocols crate: http://vberger.github.io/wayland-rs/wayland_protocols/unstable/xdg_shell/client/index.html

They are hidden behind the cargo features unstable_protocols (because the protocol is not stable) and nightly (for the static_recursion feature).

On this protocol, the entry point is the zxgd_shell_v6 global, you can start looking at the docs I linked just before. As a comparison, the current implementations uses the wl_shell global from the core wayland protocol: http://vberger.github.io/wayland-rs/wayland_client/protocol/wl_shell/index.html

[mitchmindtree]

@vberger what would be the best way to access the unstable xdg_shell module within the wayland_window crate? Should I import the wayland_protocols crate directly enabling the nightly and unstable_protocols features? Or should the unstable_protocols feature be made available through the wayland_client dependency somehow?

[elinorbgr]

The way the crates from wayland-rs are designed is that wayland-window should directly depend on wayland-protocols with the needed features. You'll also need the client feature for wayland-protocols.