On Thu, Aug 07, 2003 at 03:06:56PM +0200, Lubos Lunak wrote: > > 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. > > Or it can be made that the one that has the focus controls the videomode. As > good as your proposal. This is not as good. Most apps do not touch the resolution at all. When the video player iconifies, I want the WM to switch me back to my normal resolution. > > 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. > > Given that the videomode is usually changed in order to show a window that > covers the whole "screen", I don't think there's any need that the window > manager controls presentation to the user. Two things: 1. Usually does not cover the general case. 2. If the window manager does not get to play this role then apps have to choose when to change the resolution, and they cannot do this half so intelligently as the WM can, and with little to no effort from the applications. > > > > (side note: The VidMode extension has no events for modeline changes.) > [snip] > > 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. > > Given that there still will be applications that won't follow you suggested > specification, I don't see much difference between waiting for XFree86 to get > vidmode notifications, and relying on _NET_CURRENT_VIDMODE. This is only needed for apps that follow the rest of it. Any current app would just set the resolution and then assume that it is in its desired resolution thereafter. This allows them to properly adjust their display for the users. If they dont want to use it they don't have to. For fullscreen apps they can also generally use the size of their window. But I wanted to cover all use cases not just fullscreen windows. > One more thing that interests me: Which applications would benefit from this Apps like totem, mplayer, and tvtime are the ones that come to mind immediately. > You said "This applies to applications such as TV/movie viewers and games." > - games - they usually grab the keyboard/mouse, so the WM won't get any chance Movie players that grab the mouse/keyboard in this situation are doing so to work around X crap. And that is not desirable behavior. I want to be able to alt-tab out of a movie player. I want to be able to control transient dialogs via the WM if it pops any up. Grabbing input is not a good solution. > to do anything, thus there's no advantage to having the app itself changing > the videomode > - tv/movie viewers - what should be the advantage of this proposal when > compared to switching vidmodes by the app itself on focusin/focusout ? (Let's > ignore the fact that mplayer here doesn't seem to do anything with > resolution, so this wouldn't even be for all of them). That's just a race and a half. The apps will be fighting over setting their resolution and restoring the default. Someone needs to manage this for the applications. I don't think we can get a truly user-friendly fullscreen-supporting desktop without a 3rd party managing the resolutions between apps. To leave it up to the apps is like having apps stack themselves on your desktop instead of having the Window Manager enforce its own policies. Ben
Attachment:
pgpgiXuqsnq1q.pgp
Description: PGP signature