[RFC] Un-trapping mouse while running fullscreen (SDL limitation/design-flaw)

[RFC] Un-trapping mouse while running fullscreen (SDL limitation/design-flaw) - Printable Version

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+--- Thread: [RFC] Un-trapping mouse while running fullscreen (SDL limitation/design-flaw) (/showthread.php?tid=37377)

Pages: 1 2 3 4 5 6 7

[RFC] Un-trapping mouse while running fullscreen (SDL limitation/design-flaw) - bdallen - 2008-09-19 06:58

This has come up multiple times on the user forums. If you dual-head using separate X screens, and run XBMC fullscreen on one of the displays, the mouse is trapped and you can't do work on the other screen. This is the way the SDL_FULLSCREEN video mode works, so there does not seem to be an easy fix. switchscreen and wmctrl have been suggested as solutions, but switchscreen works poorly and I can't get wcmtrl to work at all - it just puts my windowed XBMC back into fullscreen with mouse grabbing.

In the hope of finding a solution I've been messing around with a simple SDL app. I think that having the ability to map an input command (mouse, lirc, keyboard, etc) to SDL_WM_ToggleFullScreen would go a long way towards alleviating this problem. Still kludgey, but better than the other solutions I've found.

The idea is that you toggle out of fullscreen, which should allow you to move the mouse to the other screen and do stuff, then when done move the mouse back to focus on the xbmc window and toggle back in. This actually seems to happen when I use switchscreen, but it's not reliable, and is actually unwanted in that case. Also I'm not sure if ToggleFullScreen will still work during video playback.

The downside is that if you want to watch video and work on the other monitor at the same time, you will have the window frame junk. I have never actually wanted to use it this way though - typically I will pause a video and then look up something on imdb or check email.

I will try to work up a patch implementing this. However I am not familiar with the XBMC codebase - I would be very grateful for any advice, or if someone with more experience wants implement it themselves.

Here is the demo app:

Code:

#include <SDL/SDL.h>

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char *argv[])

{

    SDL_Surface *screen;

    if(SDL_Init(SDL_INIT_VIDEO) != 0)

    {

        printf("SDL Init failed: %s", SDL_GetError());

        return 1;

    }

    atexit(SDL_Quit);

    screen = SDL_SetVideoMode(1600, 1200, 16, SDL_FULLSCREEN);

    if(screen == NULL)

    {

        printf("Setting video mode failed: %s", SDL_GetError());

        return 1;

    }

    SDL_Event event;

    int quitFlag = 0;

    while(quitFlag == 0)

    {

        while(SDL_PollEvent(&event))

        {

            if(event.type == SDL_KEYDOWN)

            {

                if (event.key.keysym.sym == SDLK_q

                    || event.key.keysym.sym == SDLK_ESCAPE)

                {

                    quitFlag = 1;

                }

                else if (event.key.keysym.sym == SDLK_f)

                {

                    int success = SDL_WM_ToggleFullScreen(screen);

                    printf("Called WM_ToggleFullScreen, returned %d\n",

                            success);

                }

            }

        }

    }

}

Are the same limitations is Simple DirectMedia Layer's latest SVN? - Gamester17 - 2008-09-19 21:27

Does SDL 1.3 (SDL latest SVN) have the same limitation?
http://libsdl.org/svn.php

Confused

- bdallen - 2008-09-19 22:09

Gamester17 Wrote:Does SDL 1.3 (SDL latest SVN) have the same limitation?
http://libsdl.org/svn.php

That is a very good question. Based on my attempts below, some bugs need to be fixed in SDL 1.3 before we can answer that question, at least in terms of a test program. However I will post to the SDL mailing list or IRC to see if I can get an answer.

I compiled my fullscreen test app against the latest SVN (as of Sept 19 around 2:00pm CST US), and I get an error: "Setting video mode failed: No video mode large enough for 1600x1200". When I run the tesvidinfo program (in the test directory of the SDL distribution), I get this output:

Code:

Built-in video drivers: x11, dummy

Video driver: x11

Number of displays: 2

Display 0:

  Current mode: 1600x1200@0Hz, 32 bits-per-pixel

      Red Mask = 0x00ff0000

      Green Mask = 0x0000ff00

      Blue Mask = 0x000000ff

No available fullscreen video modes

Display 1:

  Current mode: 1920x1080@0Hz, 32 bits-per-pixel

      Red Mask = 0x00ff0000

      Green Mask = 0x0000ff00

      Blue Mask = 0x000000ff

No available fullscreen video modes

So it would appear that SDL 1.3 is still very much a work in progress.

It looks like the SDL_SetVideoMode is no longer the standard way to initialize video. Many of the tests still use the old API, but the 'CommonInit' function in test/common.c looks to be updated. This function is called by testgl2, testsprite2, and testwm2. I couldn't find documentation on the new API, but looking at the new SDL_video.h is quite informative. The old API functions (like SDL_SetVideoMode) are now in SDL_compat.h.

- CapnBry - 2008-09-19 22:14

Gamester17 Wrote:Does SDL 1.3 (SDL latest SVN) have the same limitation?
http://libsdl.org/svn.php

No, because there is no SDL_SetVideoMode any more [Image: emot-v.gif]

To be more informative, the mouse is captured when in SDL fullscreen by design and there is no way to turn it off without unfocusing the windows. 1.3 fullscreen windows also capture the mouse and you can ungrab it, however when focus leaves a fullscreen SDL window it is iconified. I'm pretty sure this is going to defeat the purpose of why people want the mouse to leave the capture rect, having XBMC minimize when you try to do something else.

Solution? Don't use fullscreen mode because that's what fullscreen mode does; getting it to not do that would be like trying to get a leopard to change its spots. What you want is a borderless maximized window. SDL 1.2 sucks in that it doesn't allow you to reposition the window with an SDL call, you have to use native calls to do so.

Good news is 1.3 allows you to create the window SDL_WINDOW_MAXIMIZED | SDL_WINDOW_BORDERLESS with input ingrabbed but if XBMC is relying on SDL to do the mode change too, that will have to change, as mode switching is now independent of window creation.

- bdallen - 2008-09-19 22:33

CapnBry Wrote:1.3 fullscreen windows also capture the mouse and you can ungrab it, however when focus leaves a fullscreen SDL window it is iconified. I'm pretty sure this is going to defeat the purpose of why people want the mouse to leave the capture rect, having XBMC minimize when you try to do something else.

Thanks for the reply - it's great to hear from someone who actually knows about SDL! Actually I would not mind if XBMC minimized, since I typically pause the video when I'm doing something else anyway. I think the work and watch scenario is less common, but it would be nice to address both.

CapnBry Wrote:Solution? Don't use fullscreen mode because that's what fullscreen mode does;

Is there a performance hit when running (SDL_WINDOW_MAXIMIZED | SDL_WINDOW_BORDERLESS) vs fullscreen?

patch - bdallen - 2008-09-20 04:30

This patch adds a ToggleFullScreen function to CGraphicContext when HAS_SDL is set. I also modified CXBApplicationEx to call g_graphicContext.ToggleFullScreen() whenever the "f" key is pressed. I realize this is not the proper place (and conflicts with fast-forward). However I had trouble figuring out how to add a command that can be mapped to an LIRC or keyboard event via config files, and wanted to test quickly.

With this patch, I consider the problem "solved", at least well enough for my personal use. First I set XBMC to full resolution, and then (after restarting) it runs in FULLSCREEN with mouse grabbing. Then I can hit "f" to get my mouse back and do work on the other screen, return to the XBMC window and hit "f" again to return to FULLSCREEN. This work even while playing a video, although "f" is also mapped to fast-forward Frown

However as mentioned by CapnBry, if we set XBMC to run maximized but without window decorations, we get "fullscreen" without mouse grab. This can be done in KDE by right clicking on the menu bar and choosing Advanced->No Border (for some reason Fullscreen is greyed out), then using Alt drag to center the borderless window. Having the toggle fullscreen patch allowed me to test this with a full resolution window. Also I'm curious if this incurs a performance hit - it was not noticeable for a ripped DVD, but I have yet to test it with an HD video.

Another question is how to set no-border+maximized programatically (without SDL 1.3/2), and have it work with different window managers. I think wmctrl is designed to do it from the command line, but it doesn't seem to work well with KDE and XBMC beta1. I plan on experimenting with it a bit more, and taking a look at the source code.

Meanwhile I would like to know the proper place to put input-mappable commands. I would really like to get this patch included, because (a) it solves the problem well enough for me and (b) it makes it easier to experiment with other more robust solutions.

Code:

Index: xbmc/XBApplicationEx.cpp

===================================================================

--- xbmc/XBApplicationEx.cpp    (revision 15639)

+++ xbmc/XBApplicationEx.cpp    (working copy)

@@ -399,6 +399,11 @@

       break;

 #endif

     case SDL_KEYDOWN:

+      if (event.key.keysym.sym == SDLK_f)

+      {

+        int success = g_graphicsContext.ToggleFullScreen();

+        //printf("Called WM_ToggleFullScreen, returned %d\n", success);

+      }

       g_Keyboard.Update(event);

       // don't handle any more messages in the queue until we've handled keydown,

       // if a keyup is in the queue it will reset the keypress before it is handled.

Index: guilib/GraphicContext.cpp

===================================================================

--- guilib/GraphicContext.cpp   (revision 15639)

+++ guilib/GraphicContext.cpp   (working copy)

@@ -921,6 +921,13 @@

   return g_settings.m_ResInfo[iRes].fPixelRatio;

 }

+#ifdef HAS_SDL

+int CGraphicContext::ToggleFullScreen()

+{

+  return SDL_WM_ToggleFullScreen(m_screenSurface->SDL());

+}

+#endif

+

 void CGraphicContext::Clear()

 {

 #ifndef HAS_SDL

Index: guilib/GraphicContext.h

===================================================================

--- guilib/GraphicContext.h     (revision 15639)

+++ guilib/GraphicContext.h     (working copy)

@@ -137,6 +137,7 @@

   void SetD3DParameters(D3DPRESENT_PARAMETERS *p3dParams);

   int GetBackbufferCount() const { return (m_pd3dParams)?m_pd3dParams->BackBufferCount:0; }

 #else

+  int ToggleFullScreen();

   inline void setScreenSurface(Surface::CSurface* surface) XBMC_FORCE_INLINE { m_screenSurface = surface; }

   inline Surface::CSurface* getScreenSurface() XBMC_FORCE_INLINE { return m_screenSurface; }

 #endif

Thank you very much! - Gamester17 - 2008-09-20 21:23

Great! Have you submitted this patch upstream to libsdl as well?
http://libsdl.org

PS! Please put all patches to XBMC on trac http://trac.xbmc.org

http://wiki.xbmc.org/?title=HOW-TO_submit_a_patch

Lets all hope that this solves the root cause Big Grin

- althekiller - 2008-09-20 22:38

Maybe I'm missing something here but, what does this do in addition to what the '\' key does already?

- bdallen - 2008-09-21 07:19

althekiller Wrote:Maybe I'm missing something here but, what does this do in addition to what the '\' key does already?

um actually it seems to do almost exactly the same thing. I feel foolish for not looking in the Keymap.xml - I must have really wanted to dig around in the code. Please ignore the above patch.

I'm going to mention this in the user thread. I'm curious to see how many users actually want to continue watching in XBMC while working in another monitor. Maybe it's not worth making a maximized+no-border display mode, at least not until it's easy with a unified API like SDL 1.3/2.

- theuni - 2008-09-21 17:26

Would it be possible to force SDL to not grab the kb/mouse at all? Or is that essentially the same problem?

I think that lots of people that are using xbmc on 2nd screen/monitor in fullscreen may be controlling it with a remote (myself included).

Maybe not having access to kb/mouse in fullscreen mode will be sufficient for us, as long as we don't lose it on the other monitor?