oh my god auuuugh what the wayland, pygame wont start mollytime fullscreen on my second monitor anymore >:(

lol it works if I tell pygame to use x11 instead of wayland 😭

I hate wayland so much. I thought wayland was supposed to get better when I update my computer not more terrible. The wayland apologists are always saying that wayland is secretly fixed already, and really its YOUR fault for not waylanding harder.

no actually it's good actually that my computer is broken all the time. preferred, even. just think of all the security. it's practically drooling security everywhere now that my stupid touch screen music program doesn't work on my touch screen again

there i fixed it

i hope the municipality of Wayland, Iowa sues free desktop dot org for libel

uuuugh so I thought maybe the way to fix this "properly" would be to start mollytime non-fullscreen when there are multiple screens so I can move it to the correct screen first, but it turns out there's no way to query what display the window is currently on, which means I can't calculate what the correct DPI should be. Mollytime is a touch screen program, and so it needs to know the physical dimensions of the screen it is on to be useful. I assume this too is security.

in theory pygame has a "WINDOWDISPLAYCHANGED" event which would provide the information needed, but none of the other "WINDOW*" events are emitted so I don't know why I should expect that one to work either. The docs also don't mention Wayland at all, so I think the information here may be incomplete.

is there like a wiki or something somewhere that catalogs all of the things that wayland breaks? like I don't give a flying fuck if Actually wayland technically has a protocol for it true wayland has never been implemented, I just want to know what things I can reasonably expect to actually work after I spend several hours switching to a new window management library, and what versions of those things I need to have

if anyone knows of such a resource do tell, it would be extremely helpful

I want to do the following:

1. place a full screen window on a touch screen when one is available, otherwise place a full screen window on the primary display

2. allow the operator to move or recreate the full screen window to a different display

3. query the physical dimensions of the display, and the exact 1:1 pixel density screen resolution (I don't care if the info is occasionally wrong on some hardware)

4. render at a 1:1 pixel density

is *all* of this even possible on wayland?

I'd also like to be able to put different full screen windows on different screens so I do things like put a control surface on the touch screen and have the patch editor on my laptop screen and some kind of cool visualization on a projector or something but I understand that the security needs of corporations come first and I'm wrong to want to do anything fun with my computer.

@aeva so I don't know if this is useful to you, but, I am vaguely aware that this is *supposed* to be allowed for full-screen apps specifically, I believe via https://wayland.app/protocols/fullscreen-shell-unstable-v1#zwp_fullscreen_shell_v1:request:present_surface

@glyph @aeva No, this is the fullscreen *shell*, not something you use on desktops.

However, the regular xdg-shell's xdg_toplevel::set_fullscreen simply takes a wl_output as a parameter. It's not a Wayland's problem at all.

https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_fullscreen

@dos @glyph great how do I make the problem go away then

@aeva @glyph You call set_fullscreen(output) on your surface and it goes fullscreen on selected output.

If you use some middleware to do that for you, then you need to spend some effort to find out how to do the equivalent there. You can use WAYLAND_DEBUG=client to inspect what calls it ends up making below your code.