|
Description
Artem S. Tashkinov
2008-01-26 06:14:56 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 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. 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? 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. 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. 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. The discussion linked to from comment #3 certainly suggests that this is in scope for x11/randr. (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? 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. (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.) 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. I am very interested in seeing this bug get fixed. I am also interested in the fate of this god, who gives me great discomfort. *** Bug 5282 has been marked as a duplicate of this bug. *** 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. 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.
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
-- 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)
great post. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com |
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.