Ian Douglas Scott

The documentation for `gbm_device_destroy` says "Prior to calling this function all buffers and surfaces created with the gbm device need to be destroyed." Taken literally, simply not running the buffer...

Yeah, storing `Mutex`s of the surfaces and buffers in the `Device` could also handle this. Fixing the issue while maintaining the current API and its (intended) behavior. Personally my inclination...

Ah, I wasn't thinking of that. Yeah, it could make sense for gbm, if it isn't easy to ensure the surfaces and buffers are freed when the compositor wants to...

Seems to panic using `set_anchor(Anchor::BOTTOM | Anchor::TOP)` as well. Presumably that should work without an protocol error (and certainly not a compositor crash).

> Although memmap2 does assume that it can safely deref the mmaped pointer into a slice. As long as it doesn't create a slice unless you call deref, that's not...

Android support seems pretty uncontroversial as far as simply adding `target_os = "android"` to some conditional compilation. In this particular case, `Boottime` isn't used anywhere in Smithay or Anvil, and...

Smithay is a modular library, and you can compile with `default-features=false` and use only the parts you need, so the complexity of porting things depends somewhat on which parts of...

Hm, looking at the clippy error, it seems a change, in particular https://github.com/grovesNL/glow/commit/d62451c7, make `glow::Context` no longer `Send`/`Sync` by adding a raw pointer to it, and not explicitly implementing those...

Yeah, so using it with multiple threads can be unsafe. But `glow` is all unsafe, and it's up to the caller to know what safety constraints apply to their platform...

I guess we're still waiting for glow 0.14 to fix the `Send + Sync` bound? It was changed but not released yet: https://github.com/grovesNL/glow/pull/267