I think this is out of KDE's scope, have you tried to report this to Wine developers ?
Regards

Yes, but I thinks it to KDE at do the right resolution, because it have kwin, it can by detect when full screen application with low resolution is closed (bug or not) and restore the right resolution.
Else need adapt: wine, gtk, ... and all lib which use X.

kwin is not responsible for screen resolution management and kwin doesn't know if an application changes the resolution or not and doesn't know if it crashed or not. This is out of scope of kwin and probably out of scope of all KDE workspace applications. This has to be fixed in the offending application and we should not add hackish workarounds for bugs in other parts.

I thinks the event of screen resolution can by detected (plasma detect it for rearange plasmoid?) et list of application can by get (ksysguard) and I thinks it's possible.
It's usefull feature for kde, asked by lot of beginner.

(In reply to comment #4)
> I thinks the event of screen resolution can by detected
Of course it can be detected. But how should an application know which other application caused the resolution to change, how should the application know that the app should return the resolution and how should it detect that the other application crashed?

Just think of a crash in systemsettings? Would the user expect that the resolution is reset just because systemsettings (maybe even in a different module) crashed? An application cannot know if the resolution changed due to an application requesting it or due to a user choice.

It may be a useful feature but it's in my opinion also an impossible feature. And really KDE should not workaround buggy applications. An application which changes the resolution is buggy.

a) Martin is right. You request KWin to determine external intentions.
b) Trying to be smart on this will most likely introduce unwanted side effects (i.e. reverting wanted resolutions) because of a)
c) work around buggy apps like this

-- snip ---
#!/bin/bash

# store resolution id
mode=$(($(xrandr -q | grep -n '*' | cut -d':' -f1) - 3))

# store composite state
composite=$(qdbus org.kde.kwin /KWin compositingActive)

#turn off composite
$composite && qdbus org.kde.kwin /KWin toggleCompositing

#run game etc., must not go to bg
wine broken_app

#restore resolution /before/ starting composition
xrandr -s $mode

# restart composite in case, but don't stop it
$composite && ! $(qdbus org.kde.kwin /KWin compositingActive) &&  qdbus org.kde.kwin /KWin toggleCompositing

-- end snip --

> Of course it can be detected. But how should an application know which other
application caused the resolution to change, how should the application know
that the app should return the resolution and how should it detect that the
other application crashed?

It can by detect my multiple method (dmesg under linux, survey process list).
And change of resolution is detected by plasma because it reorder my desktop icon when application crash under wine.
I thinks I particular of wine application crash, because the application which can by crash easy && change resolution is game.
But it's available too for all X only application (native game under linux).

I hard is detect which application change the resolution, after it's easy should only detect when this application is crashed/closed.
Linux is more structured of other OS (windows), and I thinks it's possible directly or via library. And other OS (windows) do it. I thinks nothing is impossible, the problem it's just detect when application change resolution (talk with X server?).

I thinks too it's the only way for attract the hard gamer under linux (community which can influence on common people)

KDE desktop is not closed environment, it interact with external environment via multiple lib (I thinks particular to hald)

For my the solution is:
1) detect change os resolution, and the the pid linked (of the application)
2) if application crash (see in monitor process list && dmesg for linux) restore the resolution

Add detection of application crash it usefull for informe the user when the application is crash, and can usze kbug for repport the backtrace of other kind os application (gtk, X, ...)

About comment 8, that is a bit offtopic, but I think it can't be achieved without using some hacks like LD_PRELOAD=somelib ...

(In reply to comment #7)
> For my the solution is:
> 1) detect change os resolution, and the the pid linked (of the application)

X11 provides only a loose binding between Wid and pid by NETWM conventions, and i really can't find a pid field in XConfigureEvent

> 2) if application crash (see in monitor process list && dmesg for linux)
> restore the resolution
even /if/ kwin could detect whether some arbitrary application just crashed (definition? sigsev? - my dmesg doesn't log sigsevs. what about bsd? would you want to poll /proc anyway?)
who says that just because the related process got a sigsev, this means that the resolution change was unintended?
e.g. some apps (belive it or not) could sigsev on exit due to bad deconstructors - that does not mean all their actions were invalid.

Sum up:
- I guess we all agree that the orginal bug is external (the res. changing and crashing app)
- The detecion of such incident (if possible at all) would have to be heuristical.
- As soon as KWin takes some action on this, it will be responsible for the outcome, including all side effects -> bugs or annoyances triggered by this workaround would be KWin bugs :-(

- Workarounds should be as tight as possible to prevent any interference/side effects
-> the workaround should happen on the broken process
--> if you /know/ that a bunch of (esp. wine games) apps is "broken" in this and other regards and you cannot fix them you should work towards them by presenting an environment they can deal with and restore the former environment after they exited.

btw:
a) trust me, you want to start all wine games through scripts that prepare a certain environment, disable or force aa or aniso settings - depending on the game... this just is not windows, purchase cedega in doubt
b) i guess "hard gamers" would rather request DX11 support first - or EAX4... ;-P