-
Notifications
You must be signed in to change notification settings - Fork 341
Make the compositor render software cursors #1363
Comments
+1
It's one of those things I need to look into. My knowledge of how X11 actually handles cursors isn't great, so I'll have to see what's actually possible which would work over every backend. Ideally we'd create another wlr_image that you could draw to with normal renderer commands. |
On X11 we only support software cursors. I don't think it's worth it to do anything more complicated. |
True. Since with wayland and DRM, we can basically just use normal buffers (although allocated with a special parameter for DRM), it should be able to fit pretty easily into wlr_allocator. |
I think this is a good idea. Having the compositor draw software cursors has another advantage as well - wlroots won't be adding damage (AFAIK) so that the compositor is free to track damage in any way it wants to. Currently wlroots forces me to use scaled coordinates for damage which I find, well, quite inconvenient and complicates damage handling in wayfire. |
After this change wlroots would take damage in renderer coordinates (scaled + transformed), so that it can provide it directly to the backend. |
You mean when swapping buffers? If yes, that's not a problem, I need to implement transforming from layout to scaled+transformed coordinates anyway for the final phase of drawing, but coordinate systems will be consistent throughout the rest of the code. |
This is one more step towards [1]. This gives more freedom to the compositor wrt. how it handles damage. [1]: swaywm#1363
Remaining issues to get this closed:
|
This is one more step towards [1]. This gives more freedom to the compositor wrt. how it handles damage. [1]: swaywm/wlroots#1363
I think that we need to remove handling of software cursors entirely from wlroots, including any damage tracking for them.
The |
+1 overall. We might want to keep some helpers for cursors though, but definitely not in Additionally it's not clear how to handle cursors in the Wayland backend, especially with multi-seat.
That could be a good step to push things forwards, yes. |
I agree that we should offer a helper, outside of |
Time for another one of my text dumps: Hardware cursorsIn order to remove a whole bunch of rendering crap from the backends, I think it should be changed to not automatically scale or rotate cursors. When we get a plane interface, I would expect it to not do any of that too, unless it's exposed as a DRM property or Ideally in the future, the interface would be something like void wlr_output_set_cursor_dmabuf(struct wlr_output, struct wlr_dmabuf_attribs *buffer); The DRM backend could scan it out directly on the cursor plane, and the wayland backend can give it straight to the parent compositor with An issue currently is that compositors don't have a way to render to an off-screen buffer (to do rotations and scaling) with the current A possible intermediate interface could be: bool wlr_output_cursor_attach_render(struct wlr_output *output, int *buffer_age); which would work exactly the same as The DRM backend has limitations on buffer sizes, but the Wayland backend doesn't. It's not obvious as to how this should be handled. bool wlr_output_cursor_try_set_size(struct wlr_output *output, int *x, int *y); which will attempt to set the cursor size to *x and *y, and depending on the backend limitations it will leave the actual size used in *x and *y, which the compositor would need to know for their rendering calls. Or perhaps I can just leave this alone for now, and keep the rendering mess inside of the backends. Lines 652 to 789 in bf90474
Hardware+Software rendering helpers(I'm talking about a function that tries to set a hardware cursor and falls back to rendering one if it fails) I've thought about this a bit, but I haven't come up with anything good yet. Maybe As long as we don't have a helper for a scene graph, there really is no good place to put it. I still think leaving it completely up to compositors is the best bet. Although, any suggestions are welcome. On a related note, I think making |
Rather than extending |
Making wlroots responsible for rendering them causes some issues. It adds rendering code when swapping buffers, after
wlr_renderer_end
. It causes issues like #1291, becausewlr_output
is not presentation-time-aware (and shouldn't be).We should probably remove the rendering code from
wlr_output_swap_buffers
and make the compositor do it. We could provide a helper function to render software cursors that could be called by the compositor in its rendering process.Same applies to fullscreen surfaces -- but we should remove
wlr_output_set_fullscreen_surface
altogether, replacing it with something else.@ascent12 How does this interact with the renderer redesign?
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1363
The text was updated successfully, but these errors were encountered: