Just pinging about this; anyone have any problems with this draft (besides the one concern about specifying a monitor for the window)? Everyone happy? Everyone already overwhelmed by the upcoming holidays? :)


On 11/13/12 3:54 PM, Ryan C. Gordon wrote:

Just following up, since this is (I think) the only outstanding concern
before I submit a new draft.

We'll talk about this issue more, but for now, I present the second
draft. I've left this specific concern as a TODO note, so we'll
accommodate it in a third (and hopefully final!) draft after this one,
but I'd like to start getting feedback on all the changes in the meantime.

The updated text is pasted into this email. If you want the
change-by-change revision history, take a look over here...

...we'll move this into freedesktop's wm-spec revision control when
everyone is generally happy with the language. Here are the significant
changes since the original draft:


- Added text to allow this to work with both real physical resolution
changes and/or a compositor rescaling a backbuffer.

- Added _NET_RESOLUTIONS root window property, to let WM control
available resolutions and take all need for XRandR out of the app.

- Added an optional _NET_FULLSCREEN_TEMPORARY root window property, so
apps that are listening for XRandR events outside of the Window Manager
can decide if this event is a permanent change or not.

- A lot of MUST language became SHOULD or MAY.

- Added a note that the Window Manager SHOULD maintain aspect ratio.

- Places that discussed the window's "current dimensions" now talk about
the window's size hints.

- Iconification is no longer a hard requirement; WMs can do what makes
sense for their environment.

- Explicitly note that this hint is used when the window is mapped.

- Corrected various typos and trivial details.

Below is the updated text. I've tried to address all voiced concerns,
but if I've missed something, please let me know!


This is an addition to the spec for _NET_WM_STATE:


There are some problems with the current _NET_WM_STATE_FULLSCREEN hint
that we would like to address.

First, it is not explicit in its instructions to Window Managers; for
example, we found some Window Managers required the window to be marked
resizable (Metacity) and others did not (XFCE); it's not clear which is
correct. It doesn't address virtual desktop size verses physical
resolution. This proposal tries to be very clear about exactly what
steps are required.

Second, the window manager needs to be responsible for changing
resolutions. If an app tries to use XVidMode, the virtual desktop will
not be resized and _NET_WM_STATE_FULLSCREEN will size the window
incorrectly. If an app instead tries to use XRandR, the rest of the
desktop may change irreversibly; icons may move around, other app
windows may shrink down. Worse still, if an app changes the resolution
with XVidMode or XRandR and then crashes before cleaning itself up, the
desktop will remain in the wrong state until the user takes heroic
measures to fix it. Moving this operation into the Window Manager and
associating it with a specific window lets the system know that this is
a temporary state change, instead of two discrete actions that may be
unrelated, so that it can protect desktop state appropriately. This also
has the side benefit of centralizing a complex negotiation with X11
extensions and multiple processes into one place--the Window
Manager--instead of every application.

Certainly _NET_WM_STATE_FULLSCREEN still has a place; it still makes
good sense that the example given, a presentation program, use that
hint. For applications like video games, which need more control over
window geometry and specific monitor resolutions, a new hint is
extremely useful.

There are other benefits to moving resolution switches to the window
manager: the desktop environment may want to offer the user a
configuration mechanism that limits desired resolutions outside of what
the X server advertises, and more importantly, they may want to make use
of compositing to transparently emulate a resolution change--that is,
scale a smaller backbuffer that matches the requested resolution up to
the hardware's native resolution. The end result is more centralized
user preference and desktop environment policy.


A Window Manager supporting this specification MUST add
_NET_WM_STATE_FULLSCREEN_RESOLUTION to the list of atoms reported by the
_NET_SUPPORTED property.

(Added to the list of Root Window Properties...)


_NET_RESOLUTIONS x, y, width, height, CARDINAL[4]/32

This array contains a list of all available resolutions that can be used
resolutions offered by the hardware, but it also MAY be an arbitrary
list decided upon by the Window Manager. This property MAY change at any
time, for example as hardware is connected, detached, or reconfigured.
The four values in each element of the array comprise the monitor's
current (x,y) position on the screen, and the dimensions of the given



This array contains a list of all window ids that have temporarily
changed a monitor's resolution with the
_NET_WM_STATE_FULLSCREEN_RESOLUTION hint. This array MAY be updated to
include or remove the window before any resolution change goes into
effect. The intention is that applications that are listening for XRandR
events can view this list and decide if they should ignore this
resolution change.

(Added to the list of _NET_WM_ALLOWED_ACTIONS atoms...)

_NET_WM_ACTION_FULLSCREEN_RESOLUTION indicates that the window may be
brought to fullscreen_resolution state, that is, it may use the

(Added to the list of _NET_WM_STATE hints...)

In relation to _NET_WM_STATE_FULLSCREEN_RESOLUTION, the Window Manager
MAY simulate a physical resolution change by instead scaling the
window's rendering, such as with a compositor, so long as the window is
rendering into its expected dimensions and the given monitor is
dedicated to that window.

_NET_WM_STATE_FULLSCREEN_RESOLUTION indicates that, when mapped, the
Window Manager MUST change the resolution of the window's monitor to one
that most closely matches the window's size hints. If no available
resolution matches exactly, the Window Manager MUST select the closest
available resolution larger than the window's maximum size hint, and
SHOULD attempt to maintain the appropriate aspect ratio. The Window
Manager MUST center the window within the new resolution, remove any
window decorations, maintain its geometry based on its size hints, and
grant it input focus. If the chosen resolution does not exactly match
within the window's size hints, the Window Manager MUST obscure the rest
of the monitor so that the window is the only thing visible. If there is
no resolution that can completely contain the window's undecorated size
hints, the Window Manager MUST refuse to allow this hint.

When a window successfully sets or removes this hint, the Window Manager
MAY update the _NET_FULLSCREEN_TEMPORARY property on the root window
before changing the resolution, to aid applications that are listening
for resolution change events and would want to know that this resolution
change is temporary.

If another window needs the monitor that is currently in use by the
fullscreen window, the Window Manager MAY revert the resolution change
and allow other windows access to the given monitor (for example, the
Window Manager MAY iconify the window). In such a case, the Window
Manager MUST restore the original resolution change when the monitor
becomes available again. The Window Manager SHOULD NOT alter desktop
state (icon positions, geometry of other windows, etc) during resolution
changes, so that the state will be unchanged when the window ceases to
be marked as fullscreen.

hints SHOULD NOT be used together by a window; in such a case, the
Window Manager SHOULD reject the _NET_WM_STATE_FULLSCREEN hint.

If more than one window on the same monitor requests the
choose an appropriate method to manage their access to the monitor (for
example, each window could be iconified until it has regained input focus).

For example, a video game would use this hint.

- multiple fullscreen windows on different monitors.

wm-spec-list mailing list
wm-spec-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]