Bug 14255 - RFE: Temporary configuration changes for RANDR
Summary: RFE: Temporary configuration changes for RANDR
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: All All
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: http://blogs.msdn.com/b/oldnewthing/a...
Whiteboard:
Keywords:
: 5282 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-26 06:14 UTC by Artem S. Tashkinov
Modified: 2019-07-20 00:47 UTC (History)
12 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Artem S. Tashkinov 2008-01-26 06:14:56 UTC
Applications like games change desktop resolution (graphics mode) for their needs. Unfortunately when such applications crash then X.org server doesn't revert the resolution back to its initial mode.

It's a bug.

Please, consult with thus Wine bug for details: http://bugs.winehq.org/show_bug.cgi?id=10115
Comment 1 Sven Arvidsson 2009-01-18 12:45:13 UTC
From my reading of the Wine bug report it doesn't seem clear if this is something which should be handled in the X server, or elsewhere like in the window manager.

Maybe you can bring this up on the xorg mailing list instead? See 
http://lists.freedesktop.org/mailman/listinfo/xorg
Comment 2 Artem S. Tashkinov 2010-03-03 03:37:20 UTC
I suppose this bug could be easily solved by keeping the log of applications which change desktop resolution and if any of them exits abnormally then desktop resolution should be changed to the previous active mode.

However it seems like no one is interested in Linux as a viable gaming platform, so I'm closing this bug.
Comment 3 Luke Benstead 2010-07-29 08:43:41 UTC
I'm gonna reopen this, it's a bug that needs fixing. Where it needs fixing is the real issue...

Let me summarize the problem. Games regularly change the screen resolution, xrandr does this and it works, there are two issues though:

1. ALT+TAB away from the window doesn't restore the default resolution unless the application explicitly does it.
2. If the application crashes the user is left at a bad resolution.

MS Windows has a concept of a temporary resolution change. If a game crashes, and it marked the resolution change as temporary, the default resolution is restored. We really should have this behaviour, we cannot rely on an application to restore the resolution in a crash. 

I started a discussion on the xorg-devel list over a year ago but it stagnated: http://www.mail-archive.com/xorg-devel@lists.x.org/msg00832.html

So, here are the questions. Is this something xrandr could implement? If not is it the window manager's job? If it *is* the window manager's job, how do we go about implementing this in a Freedesktop wm-spec so the window managers implement it across the board?
Comment 4 Artem S. Tashkinov 2010-11-26 10:39:49 UTC
More than 2,5 years in making/thinking/or anything at all(?), well, one can conclude Linux and Open Source based OS'es are not for playing games.

Sigh.
Comment 5 paul.geisler 2012-02-21 03:16:29 UTC
That has nothing to do with gaming, even if games most often expose this behavior. If any application is dealing with unique ressources like the screen configuration, it should not be trusted in its behavior, like it is not trusted in its memory recycling. If a program quits, the kernel ensures it's memory is freed. So should X care about screen settings. 

The only exception would be explicit screen setting tools that still must be able to change the resolution permanently.
Comment 6 Nikos Chantziaras 2012-07-03 08:37:37 UTC
This bug should be closed. X11 is not a platform for fullscreen applications that set their own resolution (like video games.) Please use Microsoft Windows for this kind of stuff.
Comment 7 Oliver Henshaw 2012-07-03 09:19:13 UTC
The discussion linked to from comment #3 certainly suggests that this is in scope for x11/randr.
Comment 8 Daniel Stone 2012-07-04 08:08:34 UTC
(In reply to comment #6)
> This bug should be closed. X11 is not a platform for fullscreen applications
> that set their own resolution (like video games.) Please use Microsoft Windows
> for this kind of stuff.

What are you on about?
Comment 9 gecujoug 2012-07-04 11:21:42 UTC
He writes brilliant "interactive fiction". Or so he thinks :) But nobody wants to play what he makes. He blames the ubiquity of OpenGL. And struggles to spoil if for others. Jealous and selfish.
Comment 10 Nikos Chantziaras 2012-07-04 11:34:12 UTC
(In reply to comment #9)
> He writes brilliant "interactive fiction". Or so he thinks :) But nobody wants
> to play what he makes. He blames the ubiquity of OpenGL. And struggles to spoil
> if for others. Jealous and selfish.

My comment was perhaps a poor attempt at sarcasm.  The point was to hopefully make at least one X.Org dev get interested in coming up with a solution to this very annoying problem.

(Btw, I don't write Interactive Fiction.  I write software tools for it that run natively in Linux in order to avoid having to run the Windows ones in Wine.)
Comment 11 Artem S. Tashkinov 2012-07-04 11:45:22 UTC
I'd like to add that this feature is also a must if you Alt-Tab applications, but I guess it's to early to request it to be implemented since this bug is only 4,5 years of age - it's not yet vintage.
Comment 12 Josh 2017-10-07 17:38:06 UTC
I am very interested in seeing this bug get fixed.
Comment 13 Илья Индиго 2018-04-14 15:48:02 UTC
I am also interested in the fate of this god, who gives me great discomfort.
Comment 14 Adam Jackson 2018-06-13 16:45:31 UTC
*** Bug 5282 has been marked as a duplicate of this bug. ***
Comment 15 Adam Jackson 2018-06-13 16:48:14 UTC
There used to be cases where when the X server would crash it would fail to restore a usable resolution; these are mostly fixed now. But we still don't have temporary configuration changes for RANDR.
Comment 16 Hi-Angel 2018-08-27 13:14:34 UTC
It's XF86VidModeSwitchToMode() that is used to change X resolution, right? I wonder, where is it declared? Grepping through xserver sources gives only this print DEBUG_P("XF86VidModeSwitchToMode");, no declaration.
Comment 17 Hi-Angel 2018-08-28 11:40:24 UTC
A memo to myself: reply for the question above from IRC

> [14:35:16] <ajax> Hi-Angel: the server-side dispatch functions are usually named ProcExtnameRequestname or similar.
> [14:35:34] <ajax> Hi-Angel: in this case, xserver/Xext/vidmode.c:ProcVidModeSwitchToMode()
> [14:36:50] <ajax> of course then you're in c vtable hell, and you need to discover what fills in all the fptrs inside pVidMode... but at least gdb can tell you those answers if you debug it live
Comment 18 GitLab Migration User 2018-12-13 18:35:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/249.
Comment 19 emadyassen1998@yahoo.com (Spammer; Account disabled) 2019-07-20 00:47:35 UTC Comment hidden (spam)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.