X.org server should keep track of and restore its initial (desktop) resolution and refresh rate

(In reply to comment #0)
> …this bug…
http://bugs.winehq.org/show_bug.cgi?id=10839

You need to file this feature request in the bugzilla of WM of your choice.

Closing.

(In reply to comment #2)
> You need to file this feature request in the bugzilla of WM of your choice.

Well it's not a matter of WM (for instance GNOME), nor of X server. I made a test (with Savage) and I can switch between my game in 1024x768 and my desktop in 1280x800, there is no problem !! Of course, when I switch to my desktop the game is not visible, just like windows !

This feature is called (I believe) "dynamic resolution changing", and as windows support it, Wine should support it. So I reopen this bug.

(In reply to comment #4)
> (In reply to comment #2)
> > You need to file this feature request in the bugzilla of WM of your choice.

I believe he is referring to switching from a windowed virtual desktop, to a full screen virtual desktop.

>
> Well it's not a matter of WM (for instance GNOME), nor of X server. I made a
> test (with Savage) and I can switch between my game in 1024x768 and my desktop
> in 1280x800, there is no problem !! Of course, when I switch to my desktop the
> game is not visible, just like windows !
>
> This feature is called (I believe) "dynamic resolution changing", and as
> windows support it, Wine should support it. So I reopen this bug.
>

How does windows support this? I think you're confused. Windows has nothing like "virtual desktop". It's up to an app to determine how it is full screen or windowed. So if you are filing this bug based on dynamic resolution changing, wine supports it already like windows does.

(In reply to comment #5)

> I believe he is referring to switching from a windowed virtual desktop, to a
> full screen virtual desktop.

No, I do NOT talk about virtual desktop. This bug is not related to this one :
http://bugs.winehq.org/show_bug.cgi?id=10839

I talk about the fact that when I switch between an application in fullscreen run by Wine and my desktop, Wine force my desktop to the resolution of the application in fullscreen. As I made a tested with Savage, it's not a problem of Gnome or X.

> How does windows support this? I think you're confused. Windows has nothing
> like "virtual desktop". It's up to an app to determine how it is full screen or
> windowed. So if you are filing this bug based on dynamic resolution changing,
> wine supports it already like windows does.

Maybe I'm confused, maybe "dynamic resolution changing" refers to something else that I do not understand. But I have a pretty clear idea of what I request : I do not want Wine to force my desktop to have the resolution of a fullscreen application that is running through Wine.

Windows do not force its desktop to have the resolution of a fullscreen application. I can have my desktop in 1280x800 and run a game in 800x600, and if I switch between the both, each one have its own resolution. Of course if the game crashes, the desktop looses its resolution and you will have to restore it (which is an annoying problem, but still less annoying than having to deal with a desktop in 800x600 when a game is running through Wine).

If the program does not restore display resolution when it's loosing focus, then Wine should do that (of course depends on the coop mode for ddraw, and fullscreen mode for d3d). Unless Wine doesn't tell program that they lost device (the d3d DEVICE_LOST).

Wine's x11drv indeed supports dynamic resolution changes. But something needs to ask to do so.

So do not mention virtual desktop - it's irrelevant here. This is about full screen mode only. And _ONLY_ if you have "managed" checked in winecfg (default configuration).

So Sébastien Bertrand <email address hidden> what is the program are you talking about? Is it using OpenGL/DDraw/D3D? What Wine version? What OS?

Vitaliy, this is a rehash of bug 10839. He wants to run warcraft III (probably using opengl) without changing his wide-screen desktop resolution. The game does not officially support wide-screen and has to set a 4:3 resolution. He can get around this by hacking the registry entry for the game which I suggested to him earlier.

Anyway, wine DOES have to set your desktop to the resolution of the game while in the game. You can't get around this.

(In reply to comment #7)
> If the program does not restore display resolution when it's loosing focus,
> then Wine should do that (of course depends on the coop mode for ddraw, and
> fullscreen mode for d3d). Unless Wine doesn't tell program that they lost
> device (the d3d DEVICE_LOST).
>
> Wine's x11drv indeed supports dynamic resolution changes. But something needs
> to ask to do so.
>
> So do not mention virtual desktop - it's irrelevant here.

I assume that I've been very unclear. I apologize for that. Your summary is far better.

> This is about full
> screen mode only. And _ONLY_ if you have "managed" checked in winecfg (default
> configuration).

That's ok, it's what I'm talking about.

> So Sébastien Bertrand <email address hidden> what is the program are you
> talking about? Is it using OpenGL/DDraw/D3D? What Wine version? What OS?

So I mainly use Wine for games. This problem appears with the following games (I'm not sure but I think it's OpenGL games) :
* Steam Games (Half Life, Day of Defeat, Team Fortress Classic)
* Warcraft III and his extension Frozen Throne
* World of Warcraft

Wine version : wine-0.9.51
OS : GNU/Linux (Ubuntu 7.10)

When I switch from the game to the desktop, it seems firstly that the desktop tries to restore its own resolution, but then, after many modification of the resolution (2 or 3), the desktop adopt the resolution of the game. It seems that there is also some differences between "wine Warcraft\ III.exe -opengl" and "wine Warcraft\ III.exe" commands, because with the second command, Warcraft III do not accept to lose focus, unless you switch to another "GNOME virtual desktop" (this time I'm speaking about GNOME virtual desktop, Wine have nothing to do with it). With the -opengl parameter, Warcraft III accept to lose focus inside a GNOME virtual desktop. In both case, the resolution of the desktop is the resolution of the game.

> Anyway, wine DOES have to set your desktop to the resolution of the game while
> in the game. You can't get around this.

Well, but :
"Wine does not restore display resolution when it's looses focus"

Sorry, I've been very unclear. Especially because of what I expressed in the bug 10839. This summary is far better than everything I wrote to explain my problem.

(In reply to comment #6)

> I talk about the fact that when I switch between an application in fullscreen
> run by Wine and my desktop, Wine force my desktop to the resolution of the
> application in fullscreen. As I made a tested with Savage, it's not a problem
> of Gnome or X.

Must be Savage is doing extra work to compensate for the X11/WM deficiency
of managing windows running in different resolution modes. Wine is not
a Window Manager of any kind, in order to properly fix this problem the fix
should be made on the X11/WM/OS side instead. You forget that OS *already*
manages switching display modes between X11 and text consoles, the same
thing should be done for X11 processes.

(In reply to comment #11)
> (In reply to comment #6)
>
> > I talk about the fact that when I switch between an application in fullscreen
> > run by Wine and my desktop, Wine force my desktop to the resolution of the
> > application in fullscreen. As I made a tested with Savage, it's not a problem
> > of Gnome or X.
>
> Must be Savage is doing extra work to compensate for the X11/WM deficiency
> of managing windows running in different resolution modes. Wine is not
> a Window Manager of any kind, in order to properly fix this problem the fix
> should be made on the X11/WM/OS side instead. You forget that OS *already*
> manages switching display modes between X11 and text consoles, the same
> thing should be done for X11 processes.

Well, I do not think so, because when I launch Warcraft III in fullscreen, and switch to my desktop, firstly the desktop tries to restore its own resolution and then it switches to the resolution of the game. I assume that Wine forces the desktop to the resolution of the game. In fact there is a sort of "flash" in 1280x768 and the resolution of the desktop becomes 1024x768.

Nothing like this happens with Savage. I will try to find some open source Windows game to track this bug down.

(In reply to comment #12)

> Well, I do not think so, because when I launch Warcraft III in fullscreen, and
> switch to my desktop, firstly the desktop tries to restore its own resolution
> and then it switches to the resolution of the game.

That's exactly the kind of the bug imposed by a WM.

> I assume that Wine forces
> the desktop to the resolution of the game. In fact there is a sort of "flash"
> in 1280x768 and the resolution of the desktop becomes 1024x768.

Wine doesn't "force" the resolution change, and couldn't do that. Wine
just uses public X11 APIs to switch the resolution on behalf of the Windows
application it runs.

(In reply to comment #13)
> (In reply to comment #12)
>
> That's exactly the kind of the bug imposed by a WM.
>
> Wine doesn't "force" the resolution change, and couldn't do that. Wine
> just uses public X11 APIs to switch the resolution on behalf of the Windows
> application it runs.

Okay. You must have more experience than me on that subject, because I have none. We have to be sure, so I will do some test with others WM (KDE, …). If it's a problem with X, I do not know how to be sure…

Every tests I do will be reported here.

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> >
> > That's exactly the kind of the bug imposed by a WM.
> >
> > Wine doesn't "force" the resolution change, and couldn't do that. Wine
> > just uses public X11 APIs to switch the resolution on behalf of the Windows
> > application it runs.
>
> Okay. You must have more experience than me on that subject, because I have
> none. We have to be sure, so I will do some test with others WM (KDE, …). If
> it's a problem with X, I do not know how to be sure…
>
> Every tests I do will be reported here.

I tested Warcraft III with KDE, IceWM and XFCE (and initially GNOME) : each times, this bug happens. So I think it's pretty sure it's not a WM bug. Why this could not be a bug of Wine ?

(In reply to comment #15)

> I tested Warcraft III with KDE, IceWM and XFCE (and initially GNOME) : each
> times, this bug happens. So I think it's pretty sure it's not a WM bug.

Pretty much strange conclusion. To me it looks like that according to your
test none of the WMs above support X11 processes running in different screen
modes.

> Why
> this could not be a bug of Wine ?

Due to the reasons already explained in this bug.

Dmitry, it might be a WM bug, but nothing stops us from putting a workaround in Wine related to resolution changes. Since all WMs behave the same.

*** Bug 3230 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

According to comment in 3230:
"alt-tab is caught by the window manager and it doesnt know that we switched
the resolution. :/ "

Which would make it tricky for us to solve. We probably should fix this in the window managers.

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

I too am affected by this bug and find it quite annoying since it destroys the current desktop layout, especially with my two-monitor setup. Just some ideas/suggestions:

I find the way dosbox (http://dosbox.sourceforge.net) deals with fullscreen/windowed modes really well done:

. You can switch between fullscreen and windowed modes by hitting <M-Ret>.
. In fullscreen mode, you cannot <M-Tab> out, it seems to circumvent the window manager. BTW: Many games don't allow you to <M-Tab> out in Windows too.
. Fullscreen mode resolution does not affect desktop resolution in any way. It is restored when switching between the modes and after exiting dosbox.
. In windowed mode, <M-Tab> works as expected.

Native linux games work in a similar way (powermanga, neverball, frozenbubble) and do not mess up your workspace. This seems to be pretty standard with most games I've tried so far.

Wine behaves different: It seems it does not provide a real fullscreen mode like native linux games or dosbox. If the wine application crashes, resolution is not restored. But worst: If it ends normally, it does not restore the resolution too. Additionally, if you <M-Tab> out to another application, often the wine window is not restored correctly if you want to switch back to it, though this might be a window-manager related bug.

The current way to deal/workaround with these problems are:

1. Use xrandr to remember and restore the resolution (aka wrapping wine in a script). Sometimes, this still messes up the workspace (e.g. I have to restart conky etc.).
2. Start a separate xserver which you can VT-switch to. I have not tried this yet, however, this certainly would prevent wine messing up your current workspace layout. I guess this would be quite complicated to set up for most users, and dealing with your X configuration is a delicate thing especially when it has been quite a hassle to set up.

This bug appears since i use wine (about 2 years now).
Espacially if a game crashes, which is in "fullscreenmode" with a different resolution as the desktop, wine does not restore the resolution of the desktop.
(If gnome normally has a resolution of 1280x1024, the game 640x480 and the game crashes - the resoultion is still 640x480, so i have to restart gnome or change the resolution manually.

This is still a ugly bug and should be fixed soon. If this isn't caused by wine then this should reported to the x-server, gnome or kde developers. This bug is in my oppinion 1.0 critical !

Support for this being 1.0 crit.

Pretty late to nominate for 1.0, but let's target for 1.2

Probably calling ChangeDisplaySettingsExW(NULL, NULL, NULL, 0, NULL);
on DLL_PROCESS_DETACH in user32 would do the trick, but it's not clear
if that's the right thing to do, especially if an exiting process is not
the one who has changed the resolution, or the resolution has been changed
on behalf of other process.

Also, when you exit a full screen app (not just switch from it to the desktop), the resolution still isn't changed back.

(In reply to comment #26)
> Also, when you exit a full screen app (not just switch from it to the desktop),
> the resolution still isn't changed back.

It would be helpful to at least name that app, Wine version tested, and
whether a demo of it is available.

It seems to happen to all apps that go fullscreen (such as games). I'm using Wine 1.0-rc2.

(In reply to comment #28)
> It seems to happen to all apps that go fullscreen (such as games). I'm using
> Wine 1.0-rc2.

Have a look at the bug 10929 for a possible reason.

So you need wine-tools to fix it? Why can't regular wine be able to switch the resolution back?

(In reply to comment #30)
> So you need wine-tools to fix it? Why can't regular wine be able to switch the
> resolution back?

You are confusing Wine Tools (an external, not WineHQ related Wine wrapper)
with wine-tools - a part of the Wine package. It's pretty questionable practice
of splitting Wine into packages though.

(In reply to comment #28)
> It seems to happen to all apps that go fullscreen (such as games). I'm using
> Wine 1.0-rc2.
>

Looking over/grepping the code, Wine seems to ignore the CDS_FULLSCREEN flag. It *uses* it from within its d3d implementation, but the receiving code in winex11drv.dll doesn't pay any attention to this flag.
A well behaved application should react to loss of focus by restoring the desktop display mode, by calling ChangeDisplaySettings(NULL,0), and it should do the same at termination.
However, when an application switches the display mode using the CDS_FULLSCREEN flag, Windows itself will restore the desktop display mode when the application terminates. This makes it possible for applications that don't really abide by the rules to slip by on real Windows systems, but exhibit this issue on Wine.

I don't know whether your specific games fall into this category, or if there are maybe some other issues at work, but I'm quite sure that Wine's ignoring of the CDS_FULLSCREEN flag is at least a possible cause for the symptoms you're seeing.

http://blogs.msdn.com/oldnewthing/archive/2008/01/04/6973747.aspx describes
CDS_FULLSCREEN behaviour, but says nothing whether Windows restores resolution
on the app's exit.

So wine-tools is a separate package available from WineHQ? Where do I find the Suse version of it then?

(In reply to comment #34)
> So wine-tools is a separate package

Yes.

> available from WineHQ?

No.

> Where do I find the Suse version of it then?

Ask the distributor of the package, not here.

Well I can't find it... but you guys should really consider making this feature part of regular wine.

And bug 10115 is directly related to this one.

I'm adding my vote for fixing this bug. Pressing Alt-Tab (or Meta-Tab on some keyboards) to switch away from a fullscreen game, such as Warcraft 3 or Starcraft, that sets its own resolution, leaves the desktop set at that resolution.

Here are some simple steps to follow:
Legally obtain/borrow a Starcraft CD from someone
Run Starcraft (it uses a 640x480 resolution)
Press Alt-Tab
The GNOME/KDE/etc. desktop is at the resolution set by the game

I liked the behavior way back when Wine used XF86VM instead of XRandR to change resolutions. I don't want wine to change my desktop resolution, which is what XRandR does. I want it to create a window that's the appropriate size, and change the viewport resolution and position to match the window (which is what XF86VM does). When I press Alt-Tab, and the app running under wine loses focus, the resolution should be restored.

If this is a WM problem, and every major WM on the planet has the problem, then it's probably wine's job to work around it.

(In reply to comment #38)
> I liked the behavior way back when Wine used XF86VM instead of XRandR to change
> resolutions. I don't want wine to change my desktop resolution, which is what
> XRandR does. I want it to create a window that's the appropriate size, and
> change the viewport resolution and position to match the window (which is what
> XF86VM does). When I press Alt-Tab, and the app running under wine loses
> focus, the resolution should be restored.
XF86VM is still available. See http://wiki.winehq.org/UsefulRegistryKeys#line-235
But even if I set UseXRandR="N" and UseXVidMode="Y", resolution is not restored on Alt-Tab (Fedora 8, fglrx 8.08, Heroes of Might and Magic III).

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.

World of Goo (demo) also doesn't restore its resolution when it quits.

*** Bug 29826 has been marked as a duplicate of this bug. ***

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.

*** Bug 22700 has been marked as a duplicate of this bug. ***

*** Bug 28637 has been marked as a duplicate of this bug. ***

I finished checking the following games in fullscreen using Ubuntu 11.10 with Unity, Kubuntu 11.10 (KDE) and Ubuntu 11.10 with Gnome3:

+ Trine2
+ Half-Life 2 (PLus Ep1, Ep2 and TF2)
+ World of Goo
+ PLants Vs Zombies
+ Skyrim
+ Left4Dead
+ Left4Dead2
+ Prince of Persia (Sands of Time)
+ Prince of Persia (Warrior Within)
+ Prince of Persia (Forgotten Throne)
+ GTA San Andreas
+ GTA Vice City
+ Spore
+ Hitman: Blood Money
+ Penumbra: Overture
+ Amnesia: The Dark Descent
+ Warcraft 3 Frozen Throne

In ALL cases the problem is the same for all 3 desktops (KDE, Unity, Gnome3)

If you open the game in fullscreen (In this case my resolution is 1680x1050, but the fullscreen was tested in 1280x1024, 1024x768 and 1360x768) after exiting the game, 100% of the time the resolution of the system will turn into the resolution of the game. So if Ubuntu has 1680x1050 and you open a game in fullscreen with a resolution of 1024x768, after exiting the game Ubuntu will have the resolution the game has.

This was tested using an Nvidia 9500 card, Nvidia 440 card and an Intel 945. Did not have an Ati with me but I am guessing it will have the same result.

I spend about a week and half testing this to maybe find some workaround that could fix the problem. No luck. I also tested this on Windows 7 and this does not happen. You can exit the game and the resolution will be the correct one for the desktop.

Tried changing the Windows Version in Wine from XP, to 7, to 2003 and even tested Vista. Same result.

Games were tested with OpenGL if they had the option or DirectX. Same result.

The monitor I used was a Soneview 32' 16:10 TV 1080p just in case this has some influence.

There was also no output error. For what Wine could know after exiting the game, everything was perfect. But of course the resolution after exiting was not.

I also remember having this issue from 1.1.x, 1.2.x, 1.3.x and right now with the official 1.4.

This pretty much sums everything up. If affects any program that uses fullscreen or has the ability to use fullscreen. If any of the games I have mentioned are used in a windows resolution (less than the actual desktop resolution) then no problem shows up. It only reveals itself in fullscreen.

Also like to add that, for some games that change the gamma, after exiting, the desktop apart from taking the games resolution, it also takes its gamma. It may also be taking anything else that was setup in the game.

(In reply to comment #63)
> This pretty much sums everything up. If affects any program that uses
> fullscreen or has the ability to use fullscreen. If any of the games I have
> mentioned are used in a windows resolution (less than the actual desktop
> resolution) then no problem shows up. It only reveals itself in fullscreen.

It's all very interesting but this bug is WONTFIX, as it's an issue in X.org server ( https://bugs.freedesktop.org/show_bug.cgi?id=14255 ). Unfortunately X.org developers just do not care - but you still can summon a petition, create some fund, collect money and hire someone who will hack this feature.

> It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> server ( https://bugs.freedesktop.org/show_bug.cgi?id=14255 ).

This bug isn't WONTFIX, seems that someone has reopened the bug on X.org server…

(In reply to comment #66)
> > It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> > server ( https://bugs.freedesktop.org/show_bug.cgi?id=14255 ).
>
> This bug isn't WONTFIX, seems that someone has reopened the bug on X.org
> server…

I meant that it's WONTFIX concerning Wine (and that has been repeated numerous times by different Wine developers).

(In reply to comment #67)
> (In reply to comment #66)
> > > It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> > > server ( https://bugs.freedesktop.org/show_bug.cgi?id=14255 ).
> >
> > This bug isn't WONTFIX, seems that someone has reopened the bug on X.org
> > server…
>
> I meant that it's WONTFIX concerning Wine (and that has been repeated numerous
> times by different Wine developers).

UPSTREAM is the appropriate resolution. CLOSED UPSTREAM when it is fixed in X.org.

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.

*** Bug 18386 has been marked as a duplicate of this bug. ***

*** Bug 32814 has been marked as a duplicate of this bug. ***

A workaround/hack for this issue: http://michaelb.org/projects/fsgamer/ (FSGamer runs games in their own X server, which can improve the speed, reduce annoying interruptions, and make switching between fullscreen games and your desktop easy and reliable.)

*** Bug 19641 has been marked as a duplicate of this bug. ***

Closing.

Based on http://bugs.winehq.org/show_bug.cgi?id=26630#c13 my closing was wrong, as i didn't check the status at upstream...

Reverting back CLOSED to RESOLVED.

*** Bug 42760 has been marked as a duplicate of this bug. ***

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

Closing.

This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.

Setting back to RESOLVED NOTOURBUG.

Sorry for the spam.

Given the lack of any movement on the relevant feature request of Free Desktop in the almost *11* years since its filing, perhaps it's time to re-evaluate whether Wine should be made to replicate the behavior of Windows using the Free Desktop we have (and seemingly will continue to have for the indefinite future) rather than the Free Desktop we wish we had.

To be clear about the situation:
NOTOURBUG is a bit of a misnomer. This *is* a Wine bug, regardless of the strategy chosen for getting it fixed. Wine's mission is to replicate the behavior of Windows, and this issue represents a failure to do so. It may well be made much easier to fix if Free Desktop implemented a notion of temporary configuration changes like Windows has, but FD's mission is not to replicate Windows behaviors. For them it's merely a feature request. For Wine it remains a bug until the behavior matches that of Windows.

Asking FD to implement a feature rather than doing the work of making Wine mimic it seems to have been a reasonable approach to getting this bug fixed. But can that really still be said after 11 years of waiting?

-- 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.

great post.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com