Brutkey

blinry
@blinry@chaos.social

Next, I thought: Oh I know, I'll write a GTK application! So I fumbled my way through setting one up in Rust, and on adding a custom "widget" that can receive motion events.

Problem is: I know next to nothing about GTK. Do I really need to do:

let wayland_seat: WaylandSeat = seat.downcast::<WaylandSeat>().unwrap();
let wl_seat_ptr = gdk_wayland_seat_get_wl_seat(wayland_seat.to_glib_none().0);

to differentiate the event's seat? At least, this worked as well! But it would really slow me down.

blinry
@blinry@chaos.social

I always had a good time writing games in the LÖVE engine! <3 So I forked LÖVE, and found an easy way to return the mouse device ID when users receive a "mousemoved" callback in Lua!

But… the ID was always 0 – for both devices! :(

LÖVE is built on top of the graphics library SDL, which I knew had introduced some multi-seat features on Wayland recently. So maybe SDL was the culprit?

blinry
@blinry@chaos.social

So I tried it in pure #SDL3! I thought I'd never have to code something in C again, but here we are.

And indeed: The device IDs are always 0 there, as well – making it impossible to differentiate my two mice.

I haven't figured out why yet; might need some deep-dive into the SDL code to find out? Or maybe I'm not passing the events in properly from "above" (my hacked niri compositor). But given that the other approaches worked, it's maybe something in the SDL pipeline…

blinry
@blinry@chaos.social

I figured it out! Mouse IDs for events are only available in "relative mode" for some reason; which you can enable using SDL_SetWindowRelativeMouseMode(true).

Using love.mouse.setRelativeMode(true), it also kinda works in LÖVE! \o/ Still have to "constrain" the other mouse in the window.

But this should be good enough to have some fun with this tomorrow! :3