Hello all,
What follows is a proposal for better support for and interaction with
applications which want to use different video resolutions from the
default/current one. This applies to applications such as TV/movie viewers
and games. On with the goods:
--
The EWMH specification has, thus far, done a good job of letting the Window
Manager control the behavior and presentation of the desktop. This has been
done well in hints such as _NET_WM_WINDOW_TYPE, where the Application can only
choose an abstract type and it is up to the Window Manager to decide on how
given types will be displayed and interacted with.
One place where the EWMH is lacking in this regard is video resolutions. At the
present time, applications must set the video resolution themselves. This
presents problems for both the applications and for the Window Manager:
a) Applications must fight for the screen resolution if more than one is
running which wishes to use a non-default resolution. Most likely the one
started last wins, and the one started first can do nothing about it.
b) The Window Manager cannot control presentation to the user, and does not
even know what is going on in regard to the screen resolution.
(side note: The VidMode extension has no events for modeline changes.)
The proposed solution lets the Application control the modeline with the same
detail as provided through the VidMode API. The Application will set the
modeline it wishes to use as a hint on its window. The Window Manger will pick
up this hint and use the requested modeline when the Application's window or
one of its transients is focused.
The decision to keep this separate from the _NET_WM_FULLSCREEN mechanism was
made to allow all use cases that are currently in place with VidMode. Cases may
exist where it is desirable to change the modeline without being a fullscreen
application.
Please note that Window Managers should implement this through the VidMode
extension and not through the RandR extension. I'm not even sure if RandR
provides the same control over the modeline that VidMode does, but RandR is
meant to solve a different problem than that of fullscreen applications.
(side note: VidMode was not entirely designed for this purpose either,
as can be seen by its lack of ability to lock the viewport to a
location. This can be worked around by the window manager, however, to
keep fullscreen applications on screen.)
At the current time, there is no way for applications to follow changes in the
current modeline. Applications require this information. I am also currently
working on adding events to the VidMode extension for this information, but
changes to the XFree86 project are generally slow in coming, if ever. I am
proposing the _NET_CURRENT_VIDMODE property on the root window to solve this
problem. Any application can then easily determine and watch for changes to
the resolution.
Ben
--- wm-spec-1.3.xml.orig 2003-07-26 15:35:11.000000000 -0400
+++ wm-spec-1.3.xml 2003-07-28 03:58:16.000000000 -0400
@@ -619,6 +619,41 @@
The Window Manager may choose to ignore this client message.
</para>
</sect2>
+ <sect2><title>_NET_CURRENT_VIDMODE</title>
+ <programlisting><![CDATA[
+_NET_CURRENT_VIDMODE dotclock, hdisplay, hsyncstart, hsyncend, htotal, hskew,
+vdisplay, vsyncstart, vsyncend, vtotal, flags, CARDINAL[11]/32
+]]></programlisting>
+ <para>
+The current video modeline which has been selected by the Window Manager. This
+MUST be set and updated by the Window Manager.
+ </para>
+ <para>
+The values in this property correspond to the values in a modeline exposed by
+the VidMode extension. The possible flags are:
+ </para>
+ <programlisting><![CDATA[
+_NET_WM_VIDMODE_PHSYNC 0x001 /* positive hsync */
+_NET_WM_VIDMODE_HHSYNC 0x002 /* negative hsync */
+_NET_WM_VIDMODE_PVSYNC 0x004 /* positive vsync */
+_NET_WM_VIDMODE_NVSYNC 0x008 /* negative vsync */
+_NET_WM_VIDMODE_INTERLACE 0x010
+_NET_WM_VIDMODE_DBLSCAN 0x020
+_NET_WM_VIDMODE_CSYNC 0x040
+_NET_WM_VIDMODE_PCSYNC 0x080
+_NET_WM_VIDMODE_NCSYNC 0x100
+]]></programlisting>
+ <para>
+If an Application wants to use a specific modeline for its dislpay, it MUST
+request the modeline via the _NET_WM_VIDMODE property on its window.
+ </para>
+ <para>
+Rationale: There is no meachanism currently available on which to watch for
+changes to the video modeline. By giving control of the modeline over to the
+Window Manager, applications can watch this property to be aware of what
+modeline is being used at the time.
+ </para>
+ </sect2>
</sect1>
<sect1>
@@ -1257,6 +1292,34 @@
for iconified windows.
</para>
</sect2>
+ <sect2>
+ <title>_NET_WM_VIDMODE</title>
+ <programlisting><![CDATA[
+_NET_WM_VIDMODE, dotclock, hdisplay, hsyncstart, hsyncend, htotal, hskew,
+vdisplay, vsyncstart, vsyncend, vtotal, flags, CARDINAL[11]/32
+]]></programlisting>
+ <para>
+This property MUST be set by the Client if it wishes to use a different video
+modeline for displaying its window. This property contains the values for a
+modeline that the Window Manager SHOULD use when presenting the Client's window
+to the user.
+ <para>
+The values in this property correspond to the values in a modeline
+exposed by the VidMode extension. The posible flags are identical as for the
+_NET_CURRENT_VIDMODE root window property.
+ </para>
+ <para>
+The available modelines for the video device can be queried and modified
+through the use of the VidMode extension. However, the current modeline should
+not be adjusted by applications. That should be left up to the Window Manager
+if it supports this hint.
+ </para>
+ <para>
+Implementation note: if a Client requests a video modeline, the Window
+Manager SHOULD switch the video device to the requested modeline when the
+window, or any of its transients, is focused.
+ </para>
+ </sect2>
</sect1>
<sect1>
<title>Window Manager Protocols</title>
Attachment:
pgpZ6AMi98JLZ.pgp
Description: PGP signature