We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug for submitting a patch that adds support for specifying the QtWayland surface content orientation and window flags via the SDL hints mechanism.

QtWayland provides a Wayland protocol extension for telling the compositor the content orientation (in which orientation the application's contents are drawn) and for supplying additional window flags that can be interpreted by the compositor:

https://github.com/qtproject/qtwayland/blob/dev/src/extensions/surface-extension.xml

For SDL on Sailfish OS, we need a way to expose these features to the SDL developer. Looking at how these platform-specific hints are solved in other parts of SDL, SDL Hints seem to be the way to go for exposing this.

The use cases are as follows:

1. Application developer wants to develop a landscape application (the native
   framebuffer orientation on Sailfish OS is portrait mode)

   => Developer renders landscape content rotated into the portrait framebuffer,
      tells window manager that the content is landscape, so the window manager
      can align overlays (e.g. volume bars) and system gestures accordingly.

2. Application developer wants to disable system-wide swipe gestures used to
   switch between applications during gameplay, so that the whole screen can
   be used and no areas of the screen can be used for gestures (the developer
   needs to provide an on-screen way of returning the application to a state
   [e.g. pause menu / main menu] in which the system gestures continue to work)

   => Developer enables the "OverridesSystemGestures" window flags during
      gameplay, and clears the flag when the game enters pause mode / menus

Existing hints (e.g. iOS orientation) cannot be re-used, as the iOS orientation hint specifies which orientations are possible, and the window is (presumably?) rotated into these orientations automatically, whereas with QtWayland, the window is never resized/rotated, and the orientation hint tells the window manager the logical orientation of the drawn content (the framebuffer is always portrait mode).