Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 26 Oct 2012 12:45:22 +0200 Martin Gräßlin <mgraesslin kde org> said:

> On Friday 26 October 2012 19:01:40 Carsten Haitzler wrote:
> > On Fri, 26 Oct 2012 08:55:18 +0200 Martin Gräßlin <mgraesslin kde org> said:
> > > On Friday 26 October 2012 09:18:04 Carsten Haitzler wrote:
> > > > On Thu, 25 Oct 2012 19:40:49 +0200 Martin Gräßlin <mgraesslin kde org> 
> said:
> > > > > On Thursday 25 October 2012 13:29:13 Ryan C. Gordon wrote:
> > > > > > > Also in the case of KDE Plasma Workspaces the window manager is
> > > > > > > not at
> > > > > > > all
> > > > > > > responsible for handling the resolution. This is done by a daemon
> > > > > > > called
> > > > > > > krandr. I will not add code to change the resolution as that is
> > > > > > > nicely
> > > > > > > handled by krandr. So we would need to announce the support only
> > > > > > > if
> > > > > > > the
> > > > > > > daemon is present - this is something we would most likely not be
> > > > > > > able
> > > > > > > to
> > > > > > > guarantee correctly as in session start KWin should be started
> > > > > > > before
> > > > > > > krandr and it's possible that KWin is run outside a KDE Plasma
> > > > > > > session.
> > > > > > 
> > > > > > To be clear, I don't think _any_ window manager currently has code
> > > > > > to
> > > > > > change resolutions (indeed, the core of the problem is that the app
> > > > > > is
> > > > > > doing that itself without any coordination with the system). I think
> > > > > > it's great that KDE has a clear chain of responsibility for who is
> > > > > > allowed to interact with XRandR, which means this can be cleaner for
> > > > > > you
> > > > > > than it might be for, say, Gnome.
> > > > > > 
> > > > > > How I would envision this working is something like this (I have no
> > > > > > experience with KDE source code, so this might be pure fantasy on my
> > > > > > part)...
> > > > > > 
> > > > > > - krandr sends a notification to KWin once it starts up, and then
> > > > > > KWin
> > > > > > can begin advertising the appropriate atoms. If a fullscreen app
> > > > > > wants
> > > > > > to start up in the very first seconds of the KDE session: too bad,
> > > > > > but
> > > > > > if we're being really fancy, KWin could stall that app until krandr
> > > > > > is
> > > > > > ready.
> > > > > > - If you run KWin outside of a Plasma session--and therefore never
> > > > > > have
> > > > > > krandr--KWin never advertises the atoms and never supports the
> > > > > > extension. That's what you get for not running KDE the way God
> > > > > > intended.
> > > > > > 
> > > > > >  :) - An app requests the _NET_WM_STATE_FULLSCREEN_EXCLUSIVE atom,
> > > > > >  :KWin
> > > > > > 
> > > > > > asks krandr to change resolutions, and does NOT resize any of the
> > > > > > windows or move around desktop icons (etc) when it gets the
> > > > > > resolution
> > > > > > change event. It makes the appropriate window the top of the
> > > > > > Z-order,
> > > > > > etc. Other apps have no idea anything has changed for the most part.
> > > > > > - When the window loses focus (user alt-tabbed out of the game,
> > > > > > window
> > > > > > is legitimately being destroyed, etc), repeat this process, telling
> > > > > > krandr to return to the original resolution.
> > > > > > 
> > > > > > I'm ignoring some of the minutiae here, but that's the basic gist of
> > > > > > it.
> > > > > > Does this sound like a reasonable approach for KWin?
> > > > > 
> > > > > Honestly? No. That would be way too invasive change to the handling of
> > > > > KWin
> > > > > internals. E.g. we currently do not support changing the atom what
> > > > > KWin
> > > > > supports also to not handle the resolution change is not at all
> > > > > trivial.
> > > > 
> > > > errr... ummm... changing that property is a triviality... i fail to see
> > > > how
> > > > you can "not support changing it" withotu actually going ot lots of
> > > > effort
> > > > to make it not possible.
> > > 
> > > Of course changing that property is a triviality, which doesn't change the
> > > fact that right now in KWin we don't have a method to update the property.
> > > So for the source base it's not a triviality and that's all I wanted to
> > > point out. Implementing this proposal is not a trivial task at least for
> > > a window manager like KWin. Of course it's all possible, but that doesn't
> > > mean it's easy or will ever happen.
> > 
> > you have a blob of code that builds an array of property id's and then
> > calls the property set... simply making that a shared method/func or copy &
> > pasting will do the job. :) i'm curious what you level "of "not trivial"
> > is... :) from my pov... this feature is pretty easy to support in e17. we
> > have to add some logic to "suspend adapting to randr/root window/xinerama
> > changes" and double-check everyone is using the correct infra values
> > (container/zone values) and make an exception for this exclusive fullscreen
> > window to use the real screen values. other than that its just some randr
> > fun that we already have code for to switch resolution in (and back) and
> > store it. :) i put that under the "relatively trivial" bucket. :)
> cool for e17 that it's in the trivial bucket, but I think we have a different 
> understand of what is trivial ;-)

i suspect my idea of trivial may be several times more complex than yours. :)

> > > Don't get me wrong: I'm all for improving the situation, I'm just someone
> > > who is very sceptical and am looking for the best solution not from a
> > > theoretical aspect but from a practical one. A few things I understand
> > > better now like why games change resolutions and I see that I can give up
> > > any hope for games doing that.
> > 
> > abandon all hope ye who enter here! :)
> :-( but that really helps to know - as written somewhere in the thread: I'm 
> not a gamer and I will probably just never understand the needs.

it really is performance mostly, so you will get this happening no matter
what, so its better we do it in a way that desktop shells CAN (if they support
the fdo property/protocol) do it without hurting the rest of the desktop
shell. :) this protocol presents such an opportunity. the fact that the game
devs are willing to "work with us here" is great. there is a order of magnitude
better experience to be gained out of it. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com