obs-vkcapture
obs-vkcapture copied to clipboard
nowrep
Wayland missing cursor
I'm using Nobara37 and don't have the option to enable cursor capture on wayland. Any suggestions? Thank you.
It requires this protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124 and there is only one implementation currently - patch for sway.
Unless you are capturing native wayland games, you can run OBS under xwayland obs -platform xcb to get cursor capture.
Running obs with xwayland and gamecapture doesn't show anything. I tried using it on AoE and vkcube, nothing is showing up. Any suggestions?
@nowrep am I wrong in thinking that since we're injecting a dll in to the client app, we should be able to ignore compositor support and just straight wire the cursor to OBS?
Or is this more of a "I don't want the extra work" sort of issue?
It would be nice if there was some way to capture games cursors, without opening OBS in X mode, I want to keep using wlrobs, as pipewire always prompts for capture device (at-least it did this last time I tried).
Also why does this plugin need a special wayland protocol when cursor works fine in wlrobs and pipewire capture?
@nowrep am I wrong in thinking that since we're injecting a dll in to the client app, we should be able to ignore compositor support and just straight wire the cursor to OBS?
In theory yes, in practice it's way more complicated. It's pretty simple to get mouse events (I even have a branch with this https://github.com/nowrep/obs-vkcapture/commit/5cd5a4442b5cecc24c10330ba3102558fb3bfebd) but that's where the simple part ends.
It also needs to get the cursor image data, and it's not possible with the proxy approach above. This needs to either hook libwayland (at runtime, not with LD_PRELOAD because Vulkan layer is loaded late) or use private structs from libwayland (this is already used with xlib but there it's not much of an issue since xlib is not in active development anymore).
And even if we get there, it's not a win yet. Wayland cursors are not special, it's just another wl_surface which means it may be shm buffer or it could also be dma-buf. Not every dma-buf can be cpu mapped (and on nvidia, NO dma-buf can be cpu mapped), so this also adds lot of code.
So it definitely is possible and I think this issue should be re-opened. If this approach is implemented, it would also solve the cursor alignment inside game window.
Also why does this plugin need a special wayland protocol when cursor works fine in wlrobs and pipewire capture?
It uses "software" cursor, eg. it asks the compositor to draw the cursor into the captured buffer.
There's also another issue with the cursor image: new protocol https://wayland.app/protocols/cursor-shape-v1
So ideally we would get the cursor image from compositor and read the cursor coordinates inside captured window from the process itself (which is what the wip branch already does).
With this approach, I think there's also the issue of getting the correct cursor image at any given time - when hovering over text inputs, for instance, the cursor should be text. Cursor shape changes work correctly when playing x11 games, of course.
Unless get_pointer() would already let that happen?
