$ uname -a
Linux ayrtonslaptop 6.3.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 14 Jun 2023 20:10:31 +0000 x86_64 GNU/Linux

Is causing a segmentation fault on my system when the gbm::Device is dropped before the buffer object. I'm not using any unsafe code so I don't think this should be allowed to happen.

Let me know if you need any more details.

I'd like to use this library for a GBM backend for softbuffer, but I would need to be able to get a Device from an *const gbm_device in order to interface with raw_window_handle.

Notably BufferObject is not Debug.

Using #![warn(missing_debug_implementations)] can help spotting them all.

cc Smithay/smithay#319

Why does mapping require a function to be passed instead of mapping then unmapping on drop?

I want to use code in dev branch of drm-rs (which seems to be far ahead from master) with gbm.rs lib. It should be pretty straightforward I beleive (given that the draft already exists on gmb page), but just in case: is there any example that already does this?

I'm trying to use gbm.rs on an i.mx 8 series device with a Vivante GPU and corresponding drivers (6.4.3.p4.4). These come now with DRM support and a GBM backend (libgbm_viv.so).

C/C++ based programs like Weston, kmscube, mutter, or Qt's eglfs renderer work perfectly well on the device, but I noticed that using gbm.rs always fails in one spot:

Surface::lock_front_buffer() works the first time it is called, but the second time it is called it always fails. I tracked it down to the call to gbm_surface_has_free_buffers failing.

I noticed that the above mentioned never call gbm_surface_has_free_buffers before calling gbm_surface_lock_front_buffer but go straight to gbm_surface_lock_front_buffer and check the return value.

If I change gbm.rs to do the same, i.e. omit the explicit call to gbm_surface_has_free_buffers, everything works expected (acquisition of buffers from the surface, rendering into it, posting, waiting for page flip event, etc.).

My feeling is that that has_free_buffers should return true (so this might be a driver bug), but it's hard to find exact document semantics, and it's strange that nobody else is calling it.

I'd be happy to make a PR to remove the call (and enum variant), but I wanted to check with you first.