Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for QtWayland content orientation and window flags via SDL hints #1826

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments


Copy link

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2015-04-14 17:46:46 +0000, Thomas Perl wrote:

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:

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).

On 2015-04-14 17:53:06 +0000, Thomas Perl wrote:

Created attachment 2122
Proposed patch implementing the QtWayland SDL hints

Proposed patch attached.

On 2015-04-14 18:51:04 +0000, Ryan C. Gordon wrote:

Tagging this with target-2.0.4 so it's considered for 2.0.4, but I haven't looked at the patch yet, so no promises. :)


On 2015-04-14 18:59:21 +0000, Thomas Perl wrote:

Created attachment 2123
Proposed patch implementing the QtWayland SDL hints

Updated patch, added missing "#include "SDL_hints.h"" to SDL_waylandwindow.c

On 2015-05-28 15:29:38 +0000, Sam Lantinga wrote:

FYI, adding a callback automatically calls it with the current value. You don't need to call it explicitly afterward.

On 2015-05-28 15:30:21 +0000, Sam Lantinga wrote:

I'm removing this from the 2.0.4 ship list because we want to get it out ASAP, but this patch should go in soon afterward.

On 2016-10-08 00:12:56 +0000, Sam Lantinga wrote:

Can you please update your patch for the latest SDL in Mercurial?

On 2016-11-13 09:44:14 +0000, Thomas Perl wrote:

Created attachment 2617
QtWayland SDL hints (Mercurial patchset)

Updated the patch (rebased against Hg tip + removed the explicit call to the callback when adding the hint callback).

On 2016-11-15 09:19:15 +0000, Sam Lantinga wrote:

Patch applied, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant