Relative Pointer Motion Patches Published For Wayland's Weston

[Ansla]

Well, now, you should have mentioned SDL. That makes it trickier indeed. The only true solution is moving over to SDL2, you will need to do that for Wayland support anyway. But if that is not an option, make sure you do these on SDL1:

• create the window as resizable (this is also true for SDL2, even the SDL_WINDOW_MAXIMIZED flag will not work without SDL_WINDOW_RESIZABLE)
• use info.x11.gfxdisplay and info.x11.wmwindow values from the SDL_SysWMinfo, not the regular display and window
• call XFlush after XSendEvent (SDL should take care of this but apparently it doesn't)

And now the SDL variant, the most complicated of all:

#include <SDL/SDL.h>
#include <SDL/SDL_syswm.h>

int main() {
        SDL_Init(SDL_INIT_VIDEO);

        const SDL_VideoInfo *video_info = SDL_GetVideoInfo();
        SDL_SetVideoMode(100, 200, video_info->vfmt->BitsPerPixel, SDL_OPENGL | SDL_RESIZABLE);

        SDL_SysWMinfo wm_info;
        SDL_VERSION(&wm_info.version);
        SDL_GetWMInfo(&wm_info);

        Display *dpy = wm_info.info.x11.gfxdisplay;
        Window w = wm_info.info.x11.wmwindow;
        XEvent xev = {0};
        xev.type = ClientMessage;
        xev.xclient.window = w;
        xev.xclient.message_type = XInternAtom(dpy, "_NET_WM_STATE", False);;
        xev.xclient.format = 32;
        xev.xclient.data.l[0] = 2;
        xev.xclient.data.l[1] = XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_VERT", False);;
        xev.xclient.data.l[2] = XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_HORZ", False);
        XSendEvent(dpy, DefaultRootWindow(dpy), False, SubstructureNotifyMask, &xev);
        XFlush(dpy);

        for(;;) {
                SDL_Event event;
                SDL_PollEvent(&event);
                switch( event.type ) {
                case SDL_VIDEORESIZE:
                        SDL_SetVideoMode(event.resize.w, event.resize.h, video_info->vfmt->BitsPerPixel, SDL_OPENGL | SDL_RESIZABLE);
                        break;
                case SDL_QUIT:
                        SDL_Quit();
                        exit(0);
                }
        }
        return 0;
}

SDL2 version for comparison:

#include <SDL2/SDL.h>

int main() {
        SDL_Init(SDL_INIT_VIDEO);
        SDL_Window *win = SDL_CreateWindow("Hello World!", 100, 100, 200, 200, SDL_WINDOW_OPENGL | SDL_WINDOW_RESIZABLE | SDL_WINDOW_SHOWN);

        SDL_MaximizeWindow(win);

        for(;;) {
                SDL_Event event;
                SDL_PollEvent(&event);
                switch(event.type) {
                case SDL_QUIT:
                        SDL_DestroyWindow(win);
                        SDL_Quit();
                        exit(0);
                }
        }
        return 0;
}

[Remdul]

Thanks Ansla, that was very helpful. The code in my application is exactly the same code in your sample. I use the proper display and window handles. The SDL window is resizable and the SDL resize event is handled (manual maximize works properly). I played with XFlush() before and it didn't help. I tried loops, sleep, and flushing, bumping and nudging all things X/XFCE/SDL/GL related with the hope it would somehow trigger X to process the message queue.

However, I did notice something new now. The minimal sample does maximize properly with XFlush(), but if I leave it out it maximizes briefly before it is closed. It is just one 'frame' displayed before the window disappears, so I may have missed it in my earlier tests (perhaps due to having v-sync enabled and it being dropped). The sample also briefly flashes to maximized state when I start to manually resize the window (I guess should rely less on automated tests and be more hands-on!). So whatever happens, the maximize command gets stuck in the pipe somewhere, until another command bumps into it.

In my application even that doesn't happen (the brief flash to maximized state), so the pipe appears to be emptied before it gets processed by X (perhaps due to other OS subsystem interactions going on and delaying X messaging). So again it points to a race condition issue.

But at least I know my code is correct now. Thanks!

[Ansla]

As I said, best option is to move to SDL2.

But I still don't think it's a race, it sounds more like the WM ignores the event. There are 2 common causes for this, either the window you are sending the event for is not the main one or some atributes prevent it from maximizing. If you say you're able to maximixe manually it shouldn't be a problem with the atributes. That leaves sending the event to a subwindow. You can easily test this by adding the following line before sending the event:

XReparentWindow(dpy, w, DefaultRootWindow(dpy), 50, 50);

[Remdul]

You are correct, the commands may just as well be entirely lost or ignored.

I don't currently use SDL2 because there are some minor SDL1.2 features lacking in SDL2. I may port it later, just not at this time.

I only ever have one window in the application; the one spawned by SDL through SetVideoMode. The setup code is effectively the same as your sample. I cannot find any significant differences. AFAICT the only difference is be additional workload when the application is started (which made me suspect a race condition).

With the call to XReparentWindow() added, it now spawns a second window that renders the content. The new second window is maximized, but the SDL resize event is not triggered (even when maximizing/resizing manually).
The original SDL window sits in the background, devoid of content (black), and when I maximize or resize that one, both windows respond to that (after the first resize even, both become the same size). I'm not sure what this tells us.

I'm now suspicious that the window or display handle returned by SDL may be wrong or outdated. I'll try logging them...

[Ansla]

Read point 2 of my previous post again:

use info.x11.gfxdisplay and info.x11.wmwindow values from the SDL_SysWMinfo, not the regular display and window

If you add "printf("window=%x, fswindow=%x, vmwindow=%x\n", wm_info.info.x11.window, wm_info.info.x11.fswindow, wm_info.info.x11.wmwindow);" to your code and compare it with the output of xwininfo -tree you will see that wm_info.info.x11.window is a child of wm_info.info.x11.wmwindow:

window=b40000f, fswindow=b40000d, [B]vmwindow=b40000e[/B]

xwininfo: [B]Window id: 0xb40000e[/B] (has no name)

  Root window id: 0x9d (the root window) (has no name)
  Parent window id: 0x1ad89e5 (has no name)
     1 child:
     0xb40000f (has no name): ()  100x200+0+0  +2652+23

[pal666]

'minimizing' is a core concept of any windowing system

have you seen a smartphone ?

[pal666]

I really don't understand how some things, like minimize, aren't available. How hard could that possibly be?

default gnome setup does not have minimize button on x11. it is not hard, but it is low priority

[pal666]

I'd like to know what the real benefits of wayland are going to be.

"every frame is perfect"

[Ansla]

have you seen a smartphone ?

Did you read the thread?

You are wrong. Going off screen just like minimize is very much an application action. It is requested by the "compositor"(sic), but it still informs the application and often makes specific demands on what the application needs to do, you can't have application not on screen on a phone running pointless animations in the background for instance, for exactly the same reason minimize was invented on desktops in the 80s and 90s.

[Ansla]

"every frame is perfect"

Truth be told, that won't be noticed by 99% of the users out there. The true reason is for finally doing it right. And getting rid of the hacks.