Wayland fixes and cleanup

[diniamo]

The current implementation is a good basis, but off in a few places, which I attempted to fix in this PR.

Tell me if I should explain/revert anything.

Draft because I might still attempt some of the remaining problems. They are:

• Resizes are laggy, because after the resize event is fired, no matter how fast we update the surface, it will be too slow to get to the compositor, before the compositor's next frame. This can be fixed by making the buffer passed to the compositor way bigger (the programs I tested make it the same size as the bounding rectangle of all of the my monitor's, as far as I can tell), so it can display the contents from it while waiting on the surface update (this is still not a full fix, because we would have to choose a base color that is displayed under the user's buffer, instead of the current transparency). Yeah, resizing on Wayland is a pain.
• Monitor scaling is not implemented
• Window flags are not implemented
• Keymaps are not respected
• Key repetition is not implemented (should it even be?)
• Viewports are not implemented (or are they? I'm not sure what the TODO means in the code)

[Darky-Lucera]

Let me know when you finish

[diniamo]

@Darky-Lucera I think I've done all I can. I have 2 questions though:

1. What is WF_FULLSCREEN_DESKTOP meant to do?
2. What is the mfb_set_viewport function meant to do? What does it do currently on Wayland (I'm not sure what the dst function/variables used in it mean)? What does the TODO comment mean?

[Darky-Lucera]

Hello!

Excuse me for the long delay.

• WF_FULLSCREEN_DESKTOP: creates a window as big as the desktop screen with decorators but a normal window.
• mfb_set_viewport: Sets a specific rendering region within the window where the framebuffer content will be displayed.

Best regards!

[anzz1]

Resizes are laggy, because after the resize event is fired, no matter how fast we update the surface, it will be too slow to get to the compositor, before the compositor's next frame. This can be fixed by making the buffer passed to the compositor way bigger (the programs I tested make it the same size as the bounding rectangle of all of the my monitor's, as far as I can tell), so it can display the contents from it while waiting on the surface update (this is still not a full fix, because we would have to choose a base color that is displayed under the user's buffer, instead of the current transparency). Yeah, resizing on Wayland is a pain.

Sounds like Wayland itself needs more work before its ready for prime-time, that sounds ridiculous.
How can resizing be painful that's one of the main features of a window manager, if that doesn't work properly it doesn't sound like it's ready for prod yet.

[Darky-Lucera]

Hello!
Are there any updates on this?
Thanks!

[diniamo]

I didn't manage to make the viewport stuff work, but we could still merge this as is.

Would you like me to revert anything? I think I unnecessarily changed some stuff that's only semantic (e.g., 0x0 -> NULL).

[Darky-Lucera]

Hello!

I've been working to get the MiniFB examples to compile and run on Wayland, which required some code changes. Since these might be relevant to your current work, I'd appreciate it if you could review the modifications.

I apologize for any inconvenience.

[diniamo]

That... was the point of this PR as well.

[Darky-Lucera]

Could you please test the current version and apply you changes if needed?

[Darky-Lucera]

Are there some changes on this?