No cursor in anvil

[AlexD97]

No cursor in anvil

[YaLTeR]

In niri, disabling the cursor plane makes it show up for @AlexD97.

[cmeissl]

@AlexD97 In the linked issue you wrote that the cursor disappears after any actions, so I assume the cursor is initially visible. Is this the same for anvil?

You wrote that you test on Intel iGPU, which gpu exactly?
Can you please also attach the output of drm_info here and take a look if you can spot issues in dmesg.

[AlexD97]

@AlexD97 In the linked issue you wrote that the cursor disappears after any actions, so I assume the cursor is initially visible. Is this the same for anvil?

No, in anvil there is no cursor right from the beginning.

You wrote that you test on Intel iGPU, which gpu exactly?

I have an Intel Core i7-1260P.

Can you please also attach the output of drm_info here and take a look if you can spot issues in dmesg.

I couldn't find any issues in dmesg. The output of drm_info is attached.
drm_info_output.txt

[cmeissl]

Interesting, I also use an i7-1260P. But seems I either have some different configuration or you use a different driver.
drm_info show a different iGPU device on my laptop "Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics]".
Can you also create a trace log of an anvil debug run please?

[AlexD97]

Here is the trace log. Or is there any flag I have to set to get additional debug info?
anvil_debug_trace.txt

[cmeissl]

The default log level is info and only the debug build includes trace messages.
So running a debug build with RUST_LOG=trace should include all trace messages and above.

[AlexD97]

Thanks for the clarification, here is the new log
anvil_debug_trace.txt

[cmeissl]

Thanks for the logs, unfortunately I can't see anything wrong.
Can you re-run the application with the following patch and tell me if you see

• a red square
• blue square
• combination of the both
• or nothing

Thanks!

diff --git a/src/backend/drm/compositor/mod.rs b/src/backend/drm/compositor/mod.rs
index 9b8a175276..0f27d00972 100644
--- a/src/backend/drm/compositor/mod.rs
+++ b/src/backend/drm/compositor/mod.rs
@@ -2977,6 +2977,23 @@ where
             }
         };
 
+        let _ = cursor_buffer.map_mut(
+            &cursor_state.framebuffer_exporter,
+            0,
+            0,
+            self.cursor_size.w as u32,
+            self.cursor_size.h as u32,
+            |mbo| {
+                let buffer = mbo.buffer_mut();
+                for pixel in buffer.chunks_exact_mut(4) {
+                    pixel[0] = 0;
+                    pixel[1] = 0;
+                    pixel[2] = 255;
+                    pixel[3] = 255;
+                }
+            },
+        );
+
         // if we fail to export a framebuffer for our buffer we can skip the rest
         let framebuffer = match cursor_state.framebuffer_exporter.add_framebuffer(
             self.surface.device_fd(),
@@ -3037,7 +3054,7 @@ where
             let mut frame = renderer.render(self.cursor_size, output_transform)?;
 
             frame.clear(
-                [0f32, 0f32, 0f32, 0f32],
+                [0.0, 0.0, 1.0, 1.0],
                 &[Rectangle::from_loc_and_size((0, 0), self.cursor_size)],
             )?;
 
@@ -3076,6 +3093,8 @@ where
             }
         };
 
+        tracing::debug!(data = ?&data[0..100], "rendered cursor buffer");
+
         if let Err(err) = cursor_buffer.write(data) {
             info!("failed to write cursor buffer; {}", err);
             return None;

[cmeissl]

I also added a debug message which should print out the first 100 bytes of the rendered buffer, so a trace or at least debug log would be nice to have again with the patch applied.

[AlexD97]

I applied the patch and I see a red square (which I can move with my mouse).

Here is the log:
anvil_debug_trace.txt

[cmeissl]

That's the outcome that surprises me the most :)
As the log contains the expected data in the rendered offscreen buffer this means that unless we mixed up the format completely, that gbm_bo_write succeeds but does not write the passed data to the bo.
The red square is written to the buffer by mapping the bo, so I refreshed the patch to use that also for copying the
rendered offscreen buffer to verify gbm_bo_write has an issue.
Can you please try this out once again? Thanks!

diff --git a/src/backend/drm/compositor/mod.rs b/src/backend/drm/compositor/mod.rs
index 9b8a175276..86a99008e9 100644
--- a/src/backend/drm/compositor/mod.rs
+++ b/src/backend/drm/compositor/mod.rs
@@ -2977,6 +2977,23 @@ where
             }
         };
 
+        let _ = cursor_buffer.map_mut(
+            &cursor_state.framebuffer_exporter,
+            0,
+            0,
+            self.cursor_size.w as u32,
+            self.cursor_size.h as u32,
+            |mbo| {
+                let buffer = mbo.buffer_mut();
+                for pixel in buffer.chunks_exact_mut(4) {
+                    pixel[0] = 0;
+                    pixel[1] = 0;
+                    pixel[2] = 255;
+                    pixel[3] = 255;
+                }
+            },
+        );
+
         // if we fail to export a framebuffer for our buffer we can skip the rest
         let framebuffer = match cursor_state.framebuffer_exporter.add_framebuffer(
             self.surface.device_fd(),
@@ -3037,7 +3054,7 @@ where
             let mut frame = renderer.render(self.cursor_size, output_transform)?;
 
             frame.clear(
-                [0f32, 0f32, 0f32, 0f32],
+                [0.0, 0.0, 1.0, 1.0],
                 &[Rectangle::from_loc_and_size((0, 0), self.cursor_size)],
             )?;
 
@@ -3076,7 +3093,18 @@ where
             }
         };
 
-        if let Err(err) = cursor_buffer.write(data) {
+        tracing::debug!(data = ?&data[0..100], "rendered cursor buffer");
+
+        let res = cursor_buffer.map_mut(
+            &cursor_state.framebuffer_exporter,
+            0,
+            0,
+            self.cursor_size.w as u32,
+            self.cursor_size.h as u32,
+            |mbo| mbo.buffer_mut().copy_from_slice(data),
+        );
+
+        if let Err(err) = res.unwrap() {
             info!("failed to write cursor buffer; {}", err);
             return None;
         }

[AlexD97]

Now, I see a blue square with the cursor on top (in the upper left corner).

Here is the new log:
anvil_debug_trace.txt

[cmeissl]

Super interesting, thanks for your patience :)

The blue square with the cursor means that the rendering and copy with gbm_bo_map works.
So either gbm_bo_write is broken or we hit some optimization.
Before changing this to just use gbm_bo_map I would like to try out one more thing, exporting the framebuffer
after we have written to the bo.

diff --git a/src/backend/drm/compositor/mod.rs b/src/backend/drm/compositor/mod.rs
index 9b8a175276..cce8e9545a 100644
--- a/src/backend/drm/compositor/mod.rs
+++ b/src/backend/drm/compositor/mod.rs
@@ -2977,29 +2977,6 @@ where
             }
         };
 
-        // if we fail to export a framebuffer for our buffer we can skip the rest
-        let framebuffer = match cursor_state.framebuffer_exporter.add_framebuffer(
-            self.surface.device_fd(),
-            ExportBuffer::Allocator(&cursor_buffer),
-            false,
-        ) {
-            Ok(Some(fb)) => fb,
-            Ok(None) => {
-                debug!(
-                    "failed to export framebuffer for cursor {:?}: no framebuffer available",
-                    plane_info.handle
-                );
-                return None;
-            }
-            Err(err) => {
-                debug!(
-                    "failed to export framebuffer for cursor {:?}: {}",
-                    plane_info.handle, err
-                );
-                return None;
-            }
-        };
-
         let cursor_buffer_size = self.cursor_size.to_logical(1).to_buffer(1, Transform::Normal);
         let offscreen_buffer = match renderer.create_buffer(DrmFourcc::Argb8888, cursor_buffer_size) {
             Ok(buffer) => buffer,
@@ -3081,6 +3058,30 @@ where
             return None;
         }
 
+        // We add the framebuffer after writing to the buffer, doing that before
+        // can result in stalled data (invisbile cursor)
+        let framebuffer = match cursor_state.framebuffer_exporter.add_framebuffer(
+            self.surface.device_fd(),
+            ExportBuffer::Allocator(&cursor_buffer),
+            false,
+        ) {
+            Ok(Some(fb)) => fb,
+            Ok(None) => {
+                debug!(
+                    "failed to export framebuffer for cursor {:?}: no framebuffer available",
+                    plane_info.handle
+                );
+                return None;
+            }
+            Err(err) => {
+                debug!(
+                    "failed to export framebuffer for cursor {:?}: {}",
+                    plane_info.handle, err
+                );
+                return None;
+            }
+        };
+
         let src = Rectangle::from_loc_and_size(Point::default(), cursor_buffer_size).to_f64();
         let dst = Rectangle::from_loc_and_size(cursor_plane_location, self.cursor_size);
 

[AlexD97]

With this, there is no cursor again.

The new log:
anvil_debug_trace.txt

[cmeissl]

Thanks for all that testing, I believe to have finally found the reason why this is happening.

Seems our test for gbm_bo_create_with_modifiers2 fails, this is definitely something we need to look into as mesa-23.1.9 should have it.

warning: [email protected]: In file included from test_gbm_bo_create_with_modifiers2.c:1:
warning: [email protected]: In file included from /nix/store/n0d2gbxcslrgdkiba49y3swvsj78jwfh-mesa-23.1.9-dev/include/gbm.h:34:
warning: [email protected]: In file included from /nix/store/nn2ypjvdr6frc1zrkf2w9hy45kp6cdb6-clang-wrapper-16.0.6/resource-root/include/stdint.h:52:
warning: [email protected]: In file included from /nix/store/jhi4wsbrxfscrf57k46d1lfq1v8d25kx-glibc-2.38-27-dev/include/stdint.h:26:
warning: [email protected]: In file included from /nix/store/jhi4wsbrxfscrf57k46d1lfq1v8d25kx-glibc-2.38-27-dev/include/bits/libc-header-start.h:33:
warning: [email protected]: /nix/store/jhi4wsbrxfscrf57k46d1lfq1v8d25kx-glibc-2.38-27-dev/include/features.h:414:4: error: _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror,-W#warnings]
warning: [email protected]: #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
warning: [email protected]:    ^
warning: [email protected]: 1 error generated.

With gbm_bo_create_with_modifiers2 disabled we fall back to use gbm_bo_create_with_modifiers in our
gbm allocator. Unfortunately we do not check if any flags have been requested and silently drop then as gbm_bo_create_with_modifiers does not take flags. This is problematic for the cursor plane, or more specifically gbm_bo_write, as this is only guaranteed to work when the GBM_BO_USE_WRITE flag is passed to gbm.
When GBM_BO_USE_WRITE is passed to mesa gbm it will actually create a dumb buffer, which implicitly has a
mmap set and which is used in gbm_bo_write.

That leaves the question why gbm_bo_write does not fail. The answer is, it does, but we fail to recognize it :)
cursor_buffer.write has a nested result and we only check the outer result which only
tells us if the gbm device has been destroyed.

So we actually have three issues here:

1. the build script for detecting support for gbm_bo_create_with_modifiers2 has issues (at least in this case here)
2. our fallback silently drops the flags
3. the error check for gbm_bo_write is wrong

2 and 3 should be quite easy to fix, 1 will probably be more work and.

cc @Drakulix

---

For people interested in the mesa gbm stuff.
gbm_bo_create_with_modifiers
gbm_dri_bo_create
gbm_bo_write

[AlexD97]

Thanks for looking into it. (I have to admit that I don't understand most of your comment :))