Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

simple_window example immediately crashes [Arch+Gnome] #16

Closed
mitchmindtree opened this issue Apr 24, 2017 · 13 comments
Closed

simple_window example immediately crashes [Arch+Gnome] #16

mitchmindtree opened this issue Apr 24, 2017 · 13 comments

Comments

@mitchmindtree
Copy link
Contributor

mitchmindtree commented Apr 24, 2017 •
edited
Loading

Hey there!

I thought I'd have a go at running the wayland-window example after your comment at rust-windowing/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
Copy link
Contributor Author

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:

screenshot from 2017-04-24 15-02-34

screenshot from 2017-04-24 15-07-09

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 👍

@elinorbgr
Copy link
Member

elinorbgr commented Apr 24, 2017 •
edited
Loading

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
Copy link
Contributor Author

@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
Copy link
Member

elinorbgr commented Apr 24, 2017 via email

@mitchmindtree
Copy link
Contributor Author

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
Copy link
Member

elinorbgr commented Apr 24, 2017 via email

@mitchmindtree
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link
Member

elinorbgr commented Apr 24, 2017 via email

@mitchmindtree
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Contributor Author

mitchmindtree commented Apr 25, 2017 •
edited
Loading

@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
Copy link
Member

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.

@mitchmindtree mitchmindtree mentioned this issue Apr 25, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@elinorbgr @mitchmindtree