The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Apologies for resurrecting this thread.


I am currently taking some time to look into UE4 and SDL on Wayland. 


The current mouse situation in UE4 is not great, as there are potentially a few 
issues because Slate "requires" global mouse co-ordinates and also warping the 
cursor. 


I am mainly aiming at getting the Game working fully on Wayland but any solution
needs to be compatible with the Editor and any strange Engine API use-cases 
where a game developer may decide to call GetPosition and SetPosition 
on the cursor.


As discussed before surfaces do not have an x and y co-ordinates. But you can 
create transient and popup surface which will be relative to a parent surface 
(and do not necessarily need to be inside the parent).


Personally looking at all the possible uses across all devices and offscreen 
rendering and rotatable windows, this seems to make sense. Even Mir seems 
to also follow a similar direction.


Once the mouse cursor posts a leave event to the application it could be 
anywhere. It may not even be on any screens (e.g. wii mote/pointer device).
Absolute mouse co-ordinates really do not make sense.




From the SDL point of view I can see a few alternatives:


1. Create a parent/root surface which may (e.g. in the case of GNOME) be created

at 0,0 display co-ordinates. Then any new window created with SDL would create 
a transient surface relative to that root window and report co-ordinates as relative to 
the top left of the root window. 


2. Probing the display with large popup surfaces to check to see if they will clip and
making some assumptions based on that.


3. Create the option for a fully virtualized desktop where SDL is only really
creating one onscreen surface and then handing out offscreen surfaces to the 
application then performing internal compositing. 
I created a test using the Dummy video driver and then internally looping back to
the main driver and forwarding/overriding any calls and hooking getproc address for
glBindFramebuffer to alter calls to bind 0 to a pre-set render to texture framebuffer.




However this brings in the question, what layer is responsible for "simulating" 
a traditional x,y mouse-based desktop?


SDL, UE4 Engine, Slate, Application developer, XWayland, etc.


Is it really SDL's job to be a desktop GUI toolkit or compositor?

Currently I have SlateViewer working on GNOME Shell Wayland Session using Intel Mesa OpenGL 3.3.  
https://youtu.be/FkZnPDuLBp0



The hittest api works great to allow the user to move the window about.



Drop-down/popup windows are working somewhat by making them transient and relative to a parent surface. 


It would be good for SDL to have some kind of parent/child/transient/sub window/surface support.
Some assumptions like it would not show in the taskbar and be guaranteed to be in that relative place always (even when using either a tiling or exposé/GNOME activities view).