smithay/smithay

A smithy for rusty wayland compositors

Smithay

A smithy for rusty wayland compositors

Goals

Smithay aims to provide building blocks to create wayland compositors in Rust. While not being a full-blown compositor, it'll provide objects and interfaces implementing common functionalities that pretty much any compositor will need, in a generic fashion.

It supports the core Wayland protocols, the official protocol extensions, and some external extensions, such as those made by and for wlroots and KDE

Also:

• Documented: Smithay strives to maintain a clear and detailed documentation of its API and its functionalities. Compiled documentations are available on docs.rs for released versions, and here for the master branch.
• Safety: Smithay will target to be safe to use, because Rust.
• Modularity: Smithay is not a framework, and will not be constraining. If there is a part you don't want to use, you should not be forced to use it.
• High-level: You should be able to not have to worry about gory low-level stuff (but Smithay won't stop you if you really want to dive into it).

Anvil

Smithay as a compositor library has its own sample compositor: anvil.

To get informations about it and how you can run it visit anvil README

Other compositors that use Smithay

• Cosmic: Next generation Cosmic desktop environment
• Catacomb: A Wayland Mobile Compositor
• MagmaWM: A versatile and customizable Wayland Compositor
• Niri: A scrollable-tiling Wayland compositor
• Strata: A cutting-edge, robust and sleek Wayland compositor
• Pinnacle: A WIP Wayland compositor, inspired by AwesomeWM
• Sudbury: Compositor designed for ChromeOS

System Dependencies

(This list can depend on features you enable)

• libwayland
• libxkbcommon
• libudev
• libinput
• libgbm
• libseat
• xwayland

Contact us

If you have questions or want to discuss the project with us, our main chatroom is on Matrix: #smithay:matrix.org.

smithay's Issues

Examples folder

Likes wlc.rs and wlroots-rs, it would be nice to have some basic examples of the working functionalities.
I know this isn't an issue but I wasn't sure where to post this.

Rework backends as calloop event sources

Backends (drm, udev, libinput, etc...) should be reworkable as calloop event sources allowing greater flexibility in general and possibly a smoother overall design.

The idea would be to follow this general pattern:

• each backend generating events that need to be processed have a method with a prototype like:

  fn process_pending_events<F: FnMut(Event)>(&mut self, f: F) -> Result<...> { ... }

  that calls the provided closure on all pending events for this source, but does not block if no events are available
• each backend also implements the calloop::EventSource trait, proxying to the above method, allowing them to be easily inserted into an event loop.

This may need some modifications in calloop to work properly, the initial blocking point I've met is that currently some callback methods provide arguments that are borrows, while currently calloop requires Event: 'static, and I've not yet found a way to relax this constraint.

Implement `wl_pointer.set_cursor`

Smithay assumes monotonically increasing serials

...however that's not specified anywhere in the docs, and it's not even the case for the default serial counter which is said to wrap around on overflow. Example where the assumption takes place:

smithay/src/wayland/shell/xdg/xdg_handlers.rs

Lines 320 to 325 in 7fa7fe0

	role_data.pending_configures.retain(|&s| {
	if s == serial {
	found = true;
	}
	s > serial
	});

Should we implement CompositorToken with Send trait?

In my situation, I want to access the CompositorToken in multiple threads. The smithay's document indicates it should be sendable while the fact is not. Is the wayland c library already thread safe for this? Should we implement CompositorToken with Send trait?

[Discussion] Add clippy and rustfmt to travis

I don't know, how you normally manage this in your projects, but I have adapted to provide a rustfmt configuration for all my projects to get a mostly consistent style, which is also very useful for contributers and I found clippy's default lint to be quite helpful to avoid some rather common error.

Any thoughts?

Shell global handler

We need a handler for the shell protocols. A priori a single handler could possibly take care of both wl_shell and xdg_shell and provide an unified interface to the rest of the compositor.

These handlers would probably need to be integrated with the Compositor handler, as they also have a non-negligible of double-buffered state. So this could be our first dependency between two handlers in Smithay!

For reference, wl_shell, wl_shell_surface and the xdg_shell protocol.

I don't have any design plan for it yet.

Design of GraphicsBackend trait

This is a discussion for the GraphicsBackend trait.

At its simplest, it could just provide an OpenGL surface.

Remains a few questions:

• handling resize of the backend surface (when running embedded, as glutin/x11/wayland)
• handling modesetting (for the tty backend)
• support opengl-less setups?

Xwayland integration

Xwayland support apparently falls into 2 steps (information obtained by looking at weston's code)

• Routines to initialize and start the Xwayland server, the procedure itself seems quite straigthforward, see https://github.com/wayland-project/weston/blob/master/xwayland/launcher.c
• Have the wayland compositor connect to the started Xwayland server as a WM, and emulate the WM behavior so that x11 clients don't go crazy, see https://github.com/wayland-project/weston/blob/master/xwayland/window-manager.c#L2071 for the list of events to handle

The a-priori target for Smithay would be to automatically handle the Xwayland starting phase, and provide to the user an API to do the WM logic themselves:

• a set of methods to send X11 messages to the clients
• a handler trait to handle the events
• a wrapper handler to take the user handler object and introduce it into the eventloop as a handler for the FD event source that is the x11 socket, translating the x11 events into the trait methods

edit: as suggested by @Drakulix, the translation from x11 events to a handler trait should be optional, and the user of smithay should be able to handle the raw x11 socket itself, as due to all x11 extensions we cannot be sure we're doing it right...

Introduce implicit grab logic into the seat handler

Several input actions (mouse entering a surface, keyboard gaining focus, button click, ...) are associated with an "implicit grab" of the seat. The events providing such a grab provide a serial value, identifying the grab.

Some client action require the client to have such an active grab to take effect, and the client to provide the associated serial, otherwise the compositor should deny (=ignore) the request.

We should introduce this implicit-grab tracking logic in the seat handler provided by smithay, with the following properties (to be discussed if necessary):

• auto-generate serials for events, with a common serial pool for all seats (as there is a grab per seat, but the client request only provide a serial value, no seat identifier).
• every time a new implicit grab is generated for a seat, it obsoletes and replaces the previous one
• the seat should provide a logic to retrieve its current active grab and the associated serial
• we probably want to distinguish grabs associated with "leave" events from the rest, and maybe more. Meaning that the seat will store and provide access to some metadata about the grab.

Consolekit support

As an alternative session backend to logind, we need to implement Consolekit support.

Apparently, the consolekit API is fully on dbus: https://consolekit2.github.io/ConsoleKit2/

There are apparently a lot of similarities with the logind backend.

Vulkan backend support.

I just learned about rust and now am lamenting my decision to write vkwayland in CPP. This project looks to have most everything required to support a Vulkan Backend and I'd be interested in contributing.

Might I suggest to make use of vulkan-malloc and by extension dacite. I looked at vulkano and fear that it goes against the spirit of Vulakn by implementing runtime checks when a big selling point of Vulkan is that it mostly eliminates them.

Design of InputBackend trait

Here is to discuss the API we'll use for the InputBackend trait, to abstract over possible input sources.

Comes to mind:

• glutin
• raw X11
• wayland (running compositor as a client)
• libinput

My first take would be first study libinput API, which is most likely the most general of these 4 possibilities, and use this insight to build the trait.

This is not an hard requirement, after all we're not going to set the API in stone (at least not before 1.0), and we can also take a more incremental approach.

Basically, I think we can go the Handler way, as for the wayland-api part, and require some handler struct implementing a trait that'd look like:

trait InputBackendHandler {
    fn on_kbd_event(&mut self, ...);
    fn on_mouse_move(&mut self, ...);
    fn on_mouse_button(&mut self, ...);
   .... // touch events ? Other things ?
}

from this remains the question of multiple keyboard/mouses? I believe libinput already has the same notion of "seat" that the wayland protocol has. We should probably expose it?

Improve xdg_shell abstraction to better reflect the protocol

The xdg_shell protocol associates a specific meaning to its elaborate configure dance. To honor it, our abstraction should keep track of the contents of the different configure sent to the client, and when the client acks one, discard all the older ones, and mark this one as the "current" state of the client.

As such, smithay's users should not assume that the client automatically is in the state they last configured it to, but rather smithay should expose some API to allow for accessing the last state that was acked by the client.

Also, other protocol extensions tend to piggy-back more state on the xdg_shell configure, so we need to allow associating arbitrary data with a state, possibly with a similar mechanism as what we currently do with the role data, via traits (but as a product type rather than a sum type in this case).

So, a seemingly generic API t expose on Toplevel/Popup surfaces would be something like:

/// Mutably access the current pending state of this surface, to modify its contents
///
/// This can be used to integrate data from external protocols into the xdg_shell
/// configure mechanism
pub fn with_pending_state<T, F>(&self, F) -> T 
    where F: FnOnce(&mut ConfigureState) -> T
{
    /* ... */
}

/// Send the current pending state to the client
///
/// A copy of the pending state is stored as sent to the client, and will become the
/// current state when the client acks it.
pub fn send_configure(&self) {
    /* ... */
}

/// Retrieve last ackend state of this surface
pub fn with_current_state<T, F>(&self, F) -> T
    where F: FnOnce(&ConfigureState) -> T
{
    /* ... */
}

`wl_output`: Allow deleting all modes

While it currently is possible to remove Modes from an smithay::wayland::output::Output again, this requires keeping track of all added modes to do so.

The more common use-case is to re-scan the backend for supported modes, if something changes. In that case I have an updated list of supported modes that I want to be reflected by the wl_output object, but I have no idea, what modes were previously added (except for the currently active maybe).

A quick and dirty solution is to delete the Output and create a new one, but I propose to add a function to remove all previously added modes instead.

What are your thoughts on this @vberger ?

Make anvil HiDPI-aware

currently anvil is not dpi-aware, and following #102 this leads to graphical bugs when started using the winit backend on an HiDPI monitor.

Parts that need to be made dpi-aware:

• advertising DPI factor in monitors to clients
• rescaling clients buffers depending on the output dpi and their drawing dpi
• processing input events and converting them to logical coordinates before sending them to clients
• probably other things that I don't remember right now

Anvil: implement activated state for xdg toplevels

So that applications (notably GTK ones) look like they have focus when they have focus.

Correctly handle hardware / native cursors in anvil

Currently, when an alternate client-provided cursor is drawn in anvil, the original cursor (be it the native cursor on the winit backend, or the hardware cursor on a tty) is not hidden.

winit backend has stubbed timestamps for events

Right now, the winit backend stubs timestamps of events using a counter. This is obviously incorrect and needs to be fixed.

The issue though is that winit does not provide timestamps. So:

• do we emulate timestamps by just using the system time at the moment winit dispatches the event to us?
• do we try to get winit to provide timestamps?

wl_output integration

We seed some kind of manager to abstract away the management of outputs. Something that would expose a simple interface to add/remove outputs as they are received/removed from the hardware, and that would automatically add/remove globals from the clients.

Now, in order to avoid adding a new handler for each client, this will need some cooperation from wayland-server, by allowing a way to provide user_data to a global when declaring it, so that a single handler can still distinguish between the various wl_output globals.

Winit backend window resize

With the winit backend, resizing the window has some weird behaviour. The horizontal size updates correctly, however the vertical size appears to just jump to the full display height.

Disabling the following line seems to fix it for me:

smithay/src/backend/winit.rs

Line 704 in 0b2e4b4

window.window().set_inner_size(size);

Not sure where the issue lies, with winit, or whether the window shouldn't be resized during a resize event?

Running on GNOME Shell 3.32.2, on X11. Reproduced with anvil.

License

We should probably decide on a license.
I am in favor of something permissive.

Project plan

Hey @vberger,

I want to take part in smithay's development.
I would like to know what's to do, where I can help. :)

I would like to start looking into rendering possibly with glutin at first to have a more easy target. And nested rendering would most likely be very useful for testing, before I start to explore libdrm and sorts, but I am not sure if there is a lot to do in that direction, when there is not a lot to render.

I am basically searching for some easy entry points into contributing.

The final goal will of course be to move fireplace over to smithay, but that will of course take some time. ^^

Greetings,
Drakulix

Implement shell interactions (move, resize) on anvil

Right now, anvil ignores the move and resize events from the clients, we need to implement them at some point.

use RPC to make smithay language agonistic

I read this and thought to prevent this from happening in the future RPC
in the style of what Raph Levien did with xi-editor would be the way to go.
I assume this project is younger and more capable of making this change than wlroots which is why I'm suggesting this to you.

Design of the client handling helpers

An important part of smithay will revolve around actually handling the clients. Our goal is still to remain as generic as possible, so we don't target helpers that are "too smart", but rather providing very general functionality.

As a basic level, we can provide configurable global-handlers.

Thoughts about the core-protocol, per global:

• wl_compositor: This global is very dumb, and only has to track existing surfaces and regions. The only interesting thing we could provide that could be generic could be logic for keeping track of the content of regions, but I'm not sure how much a given compositor could want to customize it?
• wl_shm: This global is already mostly implemented (see #1), and provides simple primitives to automatically handle memory maps from the client and retrieve the contents of SHM buffers. Design needs to be polished, but it should mostly work. It mimics the functionality from the SHM helpers of libwayland-server.
• wl_shell: I haven't thought about it yet
• wl_subcompositor: Probably will be as dumb as the wl_compositor, so not sure we can inject a lot of smartness in there?
• wl_seat: We could help with some machinery to track the mouse/keyboard focus and forward the events to the clients, using libxkbcommon for the keyboard.
• wl_output: We can create simple handlers that store the configuration of an output and forward it to any client binding it.
• wl_data_device_manager: I've never used it, but from what I see the behavior should be quite similar across compositors, so I think we can add something here too.

Anvil: winit backend ignores host keymap settings

I have ctrl:swapcaps_and_switch_layout set in sway, but anvil ignores that.

Handle client EGL-backed buffers

This will require:

• Understanding the mesa<->wayland compositor integration
• Expose a way to fetch the contents of an EGL buffer in a way directly usable to render on OpenGL backends

Segmentation Fault

I played around a bit with smithay (mainly running weston examples) and manged to find a reproducible crash by segmentation fault.
Steps to reproduce:

• run winit example
• run weston-simple-shm
• focus winit example
• quit weston-simple-shm
• run weston-simple-touch
• focus winit example
• quit weston-simple-touch, segfault will ocurr after this

(focusing or runing weston-simple-shm does not always seem to be necessary, but this order makes the error occur 100% of the time)

Backtrace from LLDB:

Process 16005 stopped
* thread #1, name = 'winit', stop reason = signal SIGSEGV: invalid address (fault address: 0x376863)
    frame #0: 0x00005555557a0228 winit`core::sync::atomic::atomic_sub<usize>(dst=0x0000000000376863, val=1, order=Release) at atomic.rs:1536
(lldb) bt
* thread #1, name = 'winit', stop reason = signal SIGSEGV: invalid address (fault address: 0x376863)
  * frame #0: 0x00005555557a0228 winit`core::sync::atomic::atomic_sub<usize>(dst=0x0000000000376863, val=1, order=Release) at atomic.rs:1536
    frame #1: 0x00005555557a03d9 winit`core::sync::atomic::{{impl}}::fetch_sub(self=0x0000000000376863, val=1, order=Release) at atomic.rs:1300
    frame #2: 0x0000555555796b81 winit`alloc::arc::{{impl}}::drop<(core::sync::atomic::AtomicBool, core::sync::atomic::AtomicPtr<()>)>(self=0x00007ffff50c4f18) at arc.rs:933
    frame #3: 0x00005555557ed695 winit`core::ptr::drop_in_place<alloc::arc::Arc<(core::sync::atomic::AtomicBool, core::sync::atomic::AtomicPtr<()>)>>((null)=0x00007ffff50c4f18) at ptr.rs:59
    frame #4: 0x00005555557f0119 winit`core::ptr::drop_in_place<core::option::Option<alloc::arc::Arc<(core::sync::atomic::AtomicBool, core::sync::atomic::AtomicPtr<()>)>>>((null)=0x00007ffff50c4f18) at ptr.rs:59
    frame #5: 0x00005555557ee2c9 winit`core::ptr::drop_in_place<wayland_server::generated::server::wl_shell::WlShell>((null)=0x00007ffff50c4f10) at ptr.rs:59
    frame #6: 0x00005555557efeca winit`core::ptr::drop_in_place<(wayland_server::generated::server::wl_surface::WlSurface, wayland_server::generated::server::wl_shell::WlShell)>((null)=0x00007ffff50c4f00) at ptr.rs:59
    frame #7: 0x00005555557ef038 winit`core::ptr::drop_in_place<alloc::boxed::Box<(wayland_server::generated::server::wl_surface::WlSurface, wayland_server::generated::server::wl_shell::WlShell)>>((null)=0x00007fffffffba28) at ptr.rs:59
    frame #8: 0x00005555557ad428 winit`core::mem::drop<alloc::boxed::Box<(wayland_server::generated::server::wl_surface::WlSurface, wayland_server::generated::server::wl_shell::WlShell)>>(_x=0x00007ffff50c4f00) at mem.rs:788
    frame #9: 0x00005555557b0dd0 winit`smithay::wayland::shell::wl_handlers::destroy_shell_surface(shell_surface=0x00007fffffffbad0) at wl_handlers.rs:121
    frame #10: 0x00005555555e0b14 winit`wayland_server::event_loop::resource_destroy<wayland_server::generated::server::wl_shell_surface::WlShellSurface>(resource=0x00007fffef556280) at event_loop.rs:572
    frame #11: 0x00007ffff14b1c12 libwayland-server.so.0`___lldb_unnamed_symbol19$$libwayland-server.so.0 + 114
    frame #12: 0x00007ffff14b6619 libwayland-server.so.0`___lldb_unnamed_symbol91$$libwayland-server.so.0 + 57
    frame #13: 0x00007ffff14b1cff libwayland-server.so.0`wl_client_destroy + 79
    frame #14: 0x00007ffff14b1db9 libwayland-server.so.0`___lldb_unnamed_symbol20$$libwayland-server.so.0 + 89
    frame #15: 0x00007ffff14b39b2 libwayland-server.so.0`wl_event_loop_dispatch + 114
    frame #16: 0x0000555555a14e5c winit`wayland_server::event_loop::{{impl}}::dispatch(self=0x00007fffffffc6b8, timeout=Option<u32> @ 0x00007fffffffbe40) at event_loop.rs:405
    frame #17: 0x00005555555af228 winit`winit::main at winit.rs:310
    frame #18: 0x0000555555ac6b2f winit`panic_unwind::__rust_maybe_catch_panic at lib.rs:101
    frame #19: 0x0000555555abea9c winit`std::rt::lang_start [inlined] std::panicking::try<(),closure> at panicking.rs:459
    frame #20: 0x0000555555abea60 winit`std::rt::lang_start [inlined] std::panic::catch_unwind<closure,()> at panic.rs:365
    frame #21: 0x0000555555abea60 winit`std::rt::lang_start at rt.rs:58
    frame #22: 0x00005555555aff8e winit`main + 46
    frame #23: 0x00007ffff6b6cf4a libc.so.6`__libc_start_main + 234
    frame #24: 0x00005555555890da winit`_start + 42
(lldb) 

Add a way to exit the DRM example

Once it is started, TTY switching does not even work, and as it does not react to anything...

Probably fire a simple libinput and exit on <ESC>, or something like that.

Data device handler

We'll need to do it at some point.

For now, I don't really know what it is and how it works, I've never studied it yet. AFAIK it's linked to drag'n'drop behavior, possibly with copy/paste too.

All is still do be done here.

Introduce an abstraction for client's "implicit grab"

The wayland protocol relies on several places on what is called "implicit grabs". They represent temporary exclusivity given to clients to perform some kinds of actions in response to input events.

The general process is that events initiating an implicit grab provide a "serial" (u32) to the client, and this client is required to give back the serial when attempting to do an action requiring an implicit grab. There is a single implicit grab per seat. A client request using a grab serial that is no longer valid will in general be ignored, but is not a protocol error.

As such, we need to introduce some abstraction to manage these implicit grabs and their serial. It would keep track of the current implicit grab for each seat, and allow to check if a client currently ows a grab. So I'd imagine an API like:

impl GrabManager {
    fn new_grab(&self, seat: &Seat) -> u32 { ... }
    fn is_current_grab(&self, serial: u32) -> bool { ... }
}

with GrabManager being some wrapper around an Arc<...>, allowing it to be shared accros various parts of the compositor.

This is likely necessary for #49 and #28 .

cargo build fails on fedora 29

I'm getting: error: failed to run custom build command for libudev-sys v0.1.4
I googled it and one solution was to install pkg-config. Unfortunately, I already had it installed. Any ideas?

winit key repeating

In the winit backend key repeating is enabled, whereas when using libinput no such feature exists.

winit backend should have key repeating disabled to be consistent (or atleast an option to disable it).

Seat manager

We currently have a handler to handle keyboards specifically.

We'll need to see how much abstraction we can provide for a seat handler. We can maybe track focus of windows by integrating it with the surfaces? It feels like most of the job for the seat manager is forwarding inputs to the clients, so I don't know how much we can do here.

Touch event handling

Currently, the seat global does not handle touch events at all, this needs to be done.

GFX-HAL as a graphics backend

Hey there! What about building a gfx-hal based graphics backend for smithay?

In theory, it should be possible to use gfx-hal for headless drawing, mapping the resulting image to the framebuffer via DRM or EGL, right? Sorry, I am still diving deep into this stuff, but seems logical to me.

The backend itself can provide a surface for creation of FrameBuffer, etc.
If it is possible, I would be interested in trying to implement it as soon as I get my GFX-HAL-based 2D renderer running to gain some experience 🤷‍♂️.

Also, maybe there is an option to extend the gfx backends themselves to allow creating surfaces/instances from, for example, EGL streams? Or maybe somehow connect two projects.

Thanks for your time!

Have a reference compositor

Like libweston has weston and wlroots has rootson, we could have a reference basic compositor built using smithay. This would help on several aspects:

• ensure all modules in smithays play smoothly together
• easily test smithay
• provide a kind-of-real-life example of how smithay is used

Handle seat version 6

We currently only handle the wl_seat global up to version 4. Versions 5 and 6 add significant logic needs:

version 5

This one add detailed logic to the axis events for wl_pointer

• wl_seat.release
• wl_pointer.frame
• wl_pointer.axis_source
• wl_pointer.axis_stop
• wl_pointer.axis_discrete

version 6

This one mostly adds touch-related events, and thus is blocked on #48 anyway.

• enum wl_pointer.axis_source.wheel_tilt (thus must not be sent to v5 clients !)
• wl_touch.shape
• wl_touch.orientation

Mouse in anvil is limit to 1920x1080 square at the top left on 4k screen

When starting anvil from a tty with cargo run --features logind -- --tty-udev the mouse is limited to 1080p area in top left corner.

Fix clippy build

Currently, travis is setup to run slippy on a secondary allowed-failure build. Clippy does have a lot to say about smithay, whe should try and fix that, either:

• by correcting our code to be more clippy-approve
• by #[allow(..)]-ing some lints if they are really too bothersome (but with a good reason)

elogind support

As an alternative to systemd-logind, we need to support elogind. It uses the exact same dbus API as logind, so it is just a matter of abstracting this part of the code over the 2 different system libs:

smithay/src/backend/session/dbus/logind.rs

Lines 90 to 93 in 4826492

	// Acquire session_id, seat and vt (if any) via libsystemd
	let session_id = login::get_session(None).chain_err(|| ErrorKind::FailedToGetSession)?;
	let seat = login::get_seat(session_id.clone()).chain_err(|| ErrorKind::FailedToGetSeat)?;
	let vt = login::get_vt(session_id.clone()).ok();

Design of the drm backend

So this will be a small write-up about thoughts I had about writing a drm backend for smithay
mostly for @nshp and for further discussion with everyone.

A drm backend will be the first to yield more then one graphics backends, because there may be multiple outputs for one device and those may also be attached and detached at run time.
Which makes it difficult to do this correctly, as an output is theoretically not owned by anyone and as no specified lifetime, I have no idea, what the best way to handle this in rust is, but I bet there are many solutions (winit suffers from the same problem, as a window might get closed at any time).

Opening the devices will require some session code in the future (systemd, ConsoleKit, etc) to allow launching the compositor as a user process. Right now I would like to handle this case, like the libinput backend does right now, just don't open the device yourself. The drm backend could just assume that the device is already opened. The simple example could just open the device using libc::open and thus require root privileges for now until we provide a nice way to deal with sessions.

This also leaves the problem of choosing the card out of scope for now. In the future we maybe also want to have a handler that uses udev to select the most appropriate graphics card available.

Both of this suggestions flow nicely with smithay's idea of exposing all low-level functionality directly. We can always plug more logic on top of it.

My initial idea was to do something like this:

#[derive(Debug, PartialEq, Eq, Hash)]
pub struct DrmOutput {}

impl EglGraphicsBackend for DrmOutput { .. }

pub trait DrmHandler {
    pub fn on_output_connected(&mut self, output: DrmOutput);
    pub fn on_output_disconnected(&mut self, output: &DrmOutput);
}

pub struct DrmBackend<'a, H: DrmHandler> {
    gbm: Device,
    handler: H,
}

impl<'a, H: Handler> DrmBackend<'a, H> {
    fn new_from_fd(fd: RawFd, handler: H) -> IoResult<DrmBackend<'a, H>> {
        let gbm = Device::new(fd)?;
        ...
        DrmBackend {
            gbm: Device,
            handler: handler,
        }
    }
}

Some inspiration for the implementation can be gathered from:

• wlroots
• wlc
• weston

Please note that wlroots is very new and largely untested in a productive environment
and that wlc still suffers up to this day from issues when attaching/detaching monitors at runtime, possibly related to some race conditions, so it is certainly not bug-free.

Still other implementations can provide some insight and weston's implementation is certainly the most difficult to read (probably for a reason).

Providing a stable solution is our goal here, which will require reading through a lot of docs and probably some suffering during debugging and which also brings us to the next topic: drm bindings.

The are many different libdrm bindings out there:

• modesetting
• drm
• drm-rs
• libdrm-sweet
• libdrm-sys
• drm-sys

Last time I checked non of the rusty ones were complete, which is most likely the reason, why they are so many. While we already have some unsafe c-bindings in rust (egl code) I would like to see a safe wrapper been used.

rusty-desktop will be trying to solve this problem, so it looks like we should try using drm-rs at first and contribute to that repository, when functionality is lacking behind what we need.

SHM helpers

We need a mecanism for basic handling of wl_shm and wl_shm_pools. In the same fashion of the shm helpers of libwayland-server.

This raises a few questions, some of which may need support from wayland-server:

• Be robust to a client advertizing a wrong size for the memory map (see this comment)
• Handle resizing the memory pool (memmap crate) only supports it by unmapping and creating a new mapping)
• Link a &WlBuffer to the underlying mapping, might need to add a user_data mechanism to wayland_server

Support wp_linux_dmabuf

As a new basis for creating buffers. This is supposed to be the way forward for OpenGL/Vulkan.

https://docs.rs/wayland-protocols/0.20.6/wayland_protocols/unstable/linux_dmabuf/v1/server/index.html

This requires:

• Integration of the protocol extension
• Routines for loading data from a dmabuf buffer

Redesign of the CompositorHandler

The current compositor handler is in crash-test of its API, anything wrong with it can be centralized here in the target of a near-future redesign.

Known issues:

• Correct relative ordering of children relative to parents surfaces is not correctly done (currently parents are hard-coded to be behind all their children)
• The internal implementation is unnecessarily robust to cycles in the subsurface graph, weston simply errors if the client attempts to set as parent a surface that is already somewhere in the children tree of a surface. We can probably simplify the code by doing the same thing.

NVIDIA Driver Support

Hey there! As we had a small discussion on the twitter before, this should be a good place for its continuation.

The point of the discussion is: can we have NVIDIA Linux driver support? As far as I know, the problem is in the way NVIDIA allocates and manages memory (using EGLStreams), which is not compatible with the Wayland way of doing things.

Neither Gnome, nor KDE support Wayland on NVIDIA. However, as @levansfr and @Drakulix mentioned on twitter, it is a possibility in Smithay - which is exciting.

Xwayland: investigate fork usage

Forks are used to spawn Xwayland. However, since the application might have created threads prior to spawning Xwayland, fork children must be restricted to async-signal-safe functions, and things like error! and CString::new don't seem particularly async-signal-safe.

This is probably low-priority but I think it's a good idea nonetheless.

Missing systemd default support / warning message for legacy sessions

After launch ./anvil --tty-udev the background appears and the mouse pointer in the upper left corner, but everything hangs, the cursor does not move, Caps Lock does not work, CTRL-ALT-F1-12 does not work, you can exit this state only by pressing the reset button or ALT-SysRq-R
distro: Arch Linux
kernel: 5.0.13-arch1-1-ARCH
video: intel hd graphics
log:

May 14 18:14:14.074 INFO Starting anvil on a tty using udev
May 14 18:14:14.076 INFO Listening on wayland socket, name: wayland-0
May 14 18:14:14.076 INFO Trying to create tty session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.076 INFO Running from tty: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.076 DEBG Opening device: "/dev/dri/card0", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.076 INFO DrmDevice initializing, smithay_module: backend_drm
May 14 18:14:14.076 WARN Unable to become drm master, assuming unpriviledged mode, smithay_module: backend_drm
May 14 18:14:14.098 DEBG Creating gbm device, smithay_module: backend_gbm
May 14 18:14:14.105 DEBG Creating egl context from device, smithay_module: backend_egl
May 14 18:14:14.105 DEBG Trying to initialize EGL with OpenGLES 3.0, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.107 DEBG EGL No-Display Extensions: ["EGL_EXT_device_base", "EGL_EXT_device_enumeration", "EGL_EXT_device_query", "EGL_EXT_platform_base", "EGL_KHR_client_get_all_proc_addresses", "EGL_EXT_client_extensions", "EGL_KHR_debug", "EGL_EXT_platform_wayland", "EGL_EXT_platform_x11", "EGL_MESA_platform_gbm", "EGL_MESA_platform_surfaceless"], smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.107 INFO EGL Initialized, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.107 INFO EGL Version: (1, 4), smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.107 INFO EGL Extensions: ["EGL_ANDROID_blob_cache", "EGL_ANDROID_native_fence_sync", "EGL_EXT_buffer_age", "EGL_EXT_create_context_robustness", "EGL_EXT_image_dma_buf_import", "EGL_EXT_image_dma_buf_import_modifiers", "EGL_IMG_context_priority", "EGL_KHR_config_attribs", "EGL_KHR_create_context", "EGL_KHR_create_context_no_error", "EGL_KHR_fence_sync", "EGL_KHR_get_all_proc_addresses", "EGL_KHR_gl_colorspace", "EGL_KHR_gl_renderbuffer_image", "EGL_KHR_gl_texture_2D_image", "EGL_KHR_gl_texture_3D_image", "EGL_KHR_gl_texture_cubemap_image", "EGL_KHR_image", "EGL_KHR_image_base", "EGL_KHR_image_pixmap", "EGL_KHR_no_config_context", "EGL_KHR_reusable_sync", "EGL_KHR_surfaceless_context", "EGL_EXT_pixel_format_float", "EGL_KHR_wait_sync", "EGL_MESA_configless_context", "EGL_MESA_drm_image", "EGL_MESA_image_dma_buf_export", "EGL_WL_bind_wayland_display", ""], smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.107 INFO Selected color format: PixelFormat { hardware_accelerated: true, color_bits: 24, alpha_bits: 8, depth_bits: 24, stencil_bits: 8, stereoscopy: false, double_buffer: true, multisampling: None, srgb: false }, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.108 DEBG EGL context successfully created, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.109 INFO EGL context created, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.131 INFO Connected: DisplayPort
May 14 18:14:14.131 INFO Initializing EglSurface, smithay_module: backend_egl
May 14 18:14:14.132 INFO Initializing GbmSurface, smithay_module: backend_gbm
May 14 18:14:14.152 DEBG EGL surface successfully created, smithay_module: renderer_egl, smithay_module: backend_egl
May 14 18:14:14.161 DEBG Importing cursor, crtc: Handle(47), smithay_module: backend_gbm
May 14 18:14:14.162 DEBG Commiting new state, crtc: Handle(47), smithay_module: backend_gbm
May 14 18:14:14.162 DEBG Setting screen, crtc: Handle(47), smithay_module: backend_drm
May 14 18:14:14.170 INFO Initializing a xkbcommon handler with keymap query, options: None, variant: , layout: , model: , rules: , smithay_module: xkbcommon_handler, seat_name: seat0, smithay_module: seat_handler
May 14 18:14:14.172 INFO Loaded Keymap, name: English (US), smithay_module: xkbcommon_handler, seat_name: seat0, smithay_module: seat_handler
May 14 18:14:14.173 INFO Creating new wl_output, name: Drm, smithay_module: output_handler
May 14 18:14:14.176 DEBG Opening device: "/dev/input/event2", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.176 DEBG Opening device: "/dev/input/event9", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.176 DEBG Opening device: "/dev/input/event1", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.177 DEBG Opening device: "/dev/input/event0", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.177 DEBG Opening device: "/dev/input/event3", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.177 DEBG Opening device: "/dev/input/event4", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.177 DEBG Opening device: "/dev/input/event5", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.178 DEBG Opening device: "/dev/input/event6", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.178 DEBG Opening device: "/dev/input/event10", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.178 DEBG Opening device: "/dev/input/event11", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.178 DEBG Opening device: "/dev/input/event12", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.178 DEBG Opening device: "/dev/input/event8", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.179 DEBG Opening device: "/dev/input/event7", component: session, vt: 2, session_type: direct/vt, smithay_module: backend_session, session_type: auto, smithay_module: backend_session_auto
May 14 18:14:14.179 INFO Initializing a libinput backend, smithay_module: backend_libinput
May 14 18:14:14.179 INFO New input handler set, smithay_module: backend_libinput

Restore TTY state on exit/panic

While trying to run the DRM example, the first time I had forgotten to set the XDG_RUNTIME_DIR env variable. As a result, the example panicked.

Rather than dropping me back to the shell in my TTY (like what X11 does when it fails to start for example), the screen remained black until I TTY-switched to an other and back.

I don't know at all what is required for this to work, I'll probably only be possible to handle properly once we have the TTY-switching logic.