Re: Lots of _NET_WM_STATE_FULLSCREEN issues ...

[Havoc Pennington <hp redhat com>]

Hi,

On Thu, Feb 13, 2003 at 12:30:08PM +0100, Gerd Knorr wrote: 
>  (1) How should I enter fullscreen mode with another physical
>      resolution?  Background: depending on the hardware and/or
>      drivers scaling the TV to fullscreen doesn't work, thats
>      why xawtv can switch to another physical resolution (i.e.
>      1024x768 => 640x480) to avoid having black borders around
>      the TV image.
> 
>      old way:  xawtv can switch via VidMode extention.
>      _NET_WM:  ???

Does FULLSCREEN mode interfere with this? I would expect that xawtv
can still simply switch the resolution and the WM would detect the new
resolution and cope with it. This is what happens with Xrandr.

I don't know how vidmode relates to Xrandr... there may be an
X11-level issue here having two ways to change resolution.

>  (2) Somehow related to (1).  What happens if you enter fullscreen
>      mode with a virtual screen larger than the physical screen?
> 
>      old way:  xawtv can check what the phyical screen size is,
>                again using the VidMode extention, then make the
>                window size match the physical screen.
>      _NET_WM:  ???

This is the "scrolling virtual screen" mode of X? I think that mode is
perhaps a little silly, but the WM could be extended to support it.
I guess another possibility is that xawtv could choose to scale the
video to only draw to the visible area of its window.

>  (3) What happens in xinerama mode?
> 
>      old way:  xawtv figures which real screens exist (there is a
>                X extention for that too) and moves/resizes the window
>                to cover one real screen (i.e. you can watch TV at
>                one screen and work at the other in parallel).
>      _NET_WM:  ???

Metacity at least handles this by making the fullscreen window the
size of only 1 monitor (the current monitor of the window being
fullscreened).

If a WM doesn't handle this then it's a WM bug.

>  (4) According to Havoc Pennington _NET_WM_STATE_FULLSCREEN implies
>      _NET_WM_STATE_ABOVE.  Is that true?  The specs don't say something
>      about this, and it seems not to work.  At least I get complains
>      from users that the gnome panel is still visible in fullscreen
>      mode ...

Saying that it implies _NET_WM_STATE_ABOVE isn't really accurate; I
should say, it implies that the fullscreen window is stacked
appropriately.

Metacity has done various things here, but I believe it works fine at
the moment.

In any case, if the panel is handled poorly, then that is a WM
bug. You should ask users to report it to their WM author.


The basic idea of _NET_WM_STATE_FULLSCREEN is that these bugs all
become WM bugs - if the current WM advertises support for
_NET_WM_STATE_FULLSCREEN then the WM has a policy for how fullscreen
apps behave, and that policy should be honored. If the policy is bad,
users will use another WM or report bugs to get the WM fixed.  You
would not try to implement window maximization or window focus policy
in the application, either.

The reason we wanted to move this to the WM is that keyboard
navigation (e.g. Alt+Tab) requires the WM to control the stacking
order of fullscreen windows, and to know they are fullscreen; also,
the WM needs to know to put the fullscreen window above any panels;
also, for WMs with position constraints, fullscreen windows have to be
treated specially (allowed to move to cover panels).

The fullscreen mode also allows WMs to implement custom policies for
fullscreen windows, for example a WM could choose to keep a panel
visible and not overlapping the fullscreen window, perhaps as a user
preference.

Finally, the WM is only one place we need to get all the
Xinerama/virtual-resolution/etc. logic correct, if we get that right
in the WM then apps won't have to worry about it at all. So it gives
us a single place to handle all the hard parts of fullscreen mode.

Havoc