Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases.
2011/9/2 Hin-Tak Leung hintak_leung@yahoo.co.uk:
--- On Fri, 2/9/11, Jari Vetoniemi mailroxas@gmail.com wrote:
Hello,
I personally hate when applications decide to change my screen resolution without asking me, or some applications just won't run inside window. So I did fake display interface for the winex11.drv. It allows you to send any display resolution and frequency to the application, but it does not change resolution. It's small and simple patch, and won't probably ever be included into the mainline wine. However I'll post it here as it might be useful for some.
To enable, create string key UseFakeDisp with value Y in H_C_U/Software/Wine/X11 Driver Default fake resolution is 800x600 60HZ, you can change default with registry keys FakeDispHeight, FakeDispWidth, FakeDispFreq You can also use env variable WINE_FAKEDISP=WIDTHxHEIGHT_FREQ (eg. WINE_FAKEDISP=1024x768_60)
Might improve it later to use the same syntax for default resolution and allow multiple fake resolutions to be defined with ; separator. This is also useful for dual head setups where you may want to run game or application fullscreen on other monitor while still keeping the other alive. There is also interesting side effect: While some applications throw error or won't run on resolutions they don't support, some applications that don't support them still run with the resolution specified. Eg. I can run Ys games with 1440x900 resolution where they normally would not run, and they look great.
In winecfg there is a way of configuring wine to run under its own desktop window (and having any window application's windows running inside that), instead of having the unix host's window manager managing the window application's window. Have you tried using that? Granted it is a bit awkward for what you want to do (having to go into winecfg to change the desktop's resolution and resetting it afterwards, instead of passing the resolution in per application), but may be improving on that functionality in winecfg could get your code included eventually somehow.
On 09/02/2011 10:57 PM, Jari Vetoniemi wrote:
Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases.
Please bottom post.
I can't comment your code but I know there is a "wine 1.2" bug requesting this kind of feature : http://bugs.winehq.org/show_bug.cgi?id=11079
Yes, sorry about that.. Gmail does not seem to play nice with some mailing lists which is weird. Anyways, I looked at the bug report. This could work for resolution and frequency, but it does not fake color depth.
2011/9/5 GOUJON Alexandre ale.goujon@gmail.com:
On 09/02/2011 10:57 PM, Jari Vetoniemi wrote:
Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases.
Please bottom post.
I can't comment your code but I know there is a "wine 1.2" bug requesting this kind of feature : http://bugs.winehq.org/show_bug.cgi?id=11079
On Mon, Sep 5, 2011 at 3:14 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
Yes, sorry about that.. Gmail does not seem to play nice with some mailing lists which is weird. Anyways, I looked at the bug report. This could work for resolution and frequency, but it does not fake color depth.
2011/9/5 GOUJON Alexandre ale.goujon@gmail.com:
On 09/02/2011 10:57 PM, Jari Vetoniemi wrote:
Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases.
Please bottom post.
I can't comment your code but I know there is a "wine 1.2" bug requesting this kind of feature : http://bugs.winehq.org/show_bug.cgi?id=11079
Note why don't you just disable XRandr and XVidmode in the registry? Then you don't have any mode switching (this can be done on a per app basis even in the same wineprefix).
Roderick
I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp.
2011/9/5 Roderick Colenbrander thunderbird2k@gmail.com:
On Mon, Sep 5, 2011 at 3:14 PM, Jari Vetoniemi mailroxas@gmail.com wrote:
Yes, sorry about that.. Gmail does not seem to play nice with some mailing lists which is weird. Anyways, I looked at the bug report. This could work for resolution and frequency, but it does not fake color depth.
2011/9/5 GOUJON Alexandre ale.goujon@gmail.com:
On 09/02/2011 10:57 PM, Jari Vetoniemi wrote:
Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases.
Please bottom post.
I can't comment your code but I know there is a "wine 1.2" bug requesting this kind of feature : http://bugs.winehq.org/show_bug.cgi?id=11079
Note why don't you just disable XRandr and XVidmode in the registry? Then you don't have any mode switching (this can be done on a per app basis even in the same wineprefix).
Roderick
On 09/06/2011 02:25 PM, Jari Vetoniemi wrote:
I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp.
IMO, there is a need and your patch is a solution (among other).
Is there a relevant developer able to answer these questions ? - Do we need this feature ? - If so, what is the correct/clean way to add it into mainline ? - Does the patch look good or what is wrong ?
I know there is no [RFC] in the subject of this thread but you're definitely requesting comments.
Well, I did the patch mostly for personal use and dropped here as some might find it useful. If wine ever needs something like this, let's say for testing or for some people wanting to fake display information, or do not want to use XRandR or others for some reason, then it would at least need to support multiple resolutions I guess.
ATM it only supports one, also it would be good to get rid of the useless registry keys and just provide one with same syntax as the environment variable one. Both should be easy to implement, I don't know where wine gets/sends the color depth information, so it could be faked too, but I'm not sure if it's worth it.
But the patch should do the faking clean way, I guess. It's just another interface like the XRandR selector and such.
As for, do we need it? I don't know. I need it :) Correct way to add it? See above, but I highly suspect this ever getting into mainline. It's not correct behavior and is quite niche patch. Does the patch look good? See above, registry keys could be cleaned and multiple resolutions separated with eg ';' letter would be nice.
Also I'm not sure what is the take on defining environment variables.
2011/9/6 GOUJON Alexandre ale.goujon@gmail.com:
On 09/06/2011 02:25 PM, Jari Vetoniemi wrote:
I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp.
IMO, there is a need and your patch is a solution (among other).
Is there a relevant developer able to answer these questions ?
- Do we need this feature ?
- If so, what is the correct/clean way to add it into mainline ?
- Does the patch look good or what is wrong ?
I know there is no [RFC] in the subject of this thread but you're definitely requesting comments.
Hello, I have updated this to support multiple resolutions(&& frequencies) and also made it use only one registry key. If the registry key is empty, or does not exist, or WINE_FAKEDISP environment variable is not defined it won't be used at all.
Syntax is the same, expect you can separate multiple resolutions with semicolon(;) I've been using it for a while now, and find it really useful for applications that might change resolution. Also keeping both monitors alive (Game on other monitor for example, while doing stuff on other). And it can also make games use resolution that is normally unsupported.
Here is screen of Ys Origins running 1440x900 where it normally does not: http://ompldr.org/vYW91NA/YsOrigins.png
Just let you know, if anyone else found the patch useful. Cheers.
2011/9/6 Jari Vetoniemi mailroxas@gmail.com:
Well, I did the patch mostly for personal use and dropped here as some might find it useful. If wine ever needs something like this, let's say for testing or for some people wanting to fake display information, or do not want to use XRandR or others for some reason, then it would at least need to support multiple resolutions I guess.
ATM it only supports one, also it would be good to get rid of the useless registry keys and just provide one with same syntax as the environment variable one. Both should be easy to implement, I don't know where wine gets/sends the color depth information, so it could be faked too, but I'm not sure if it's worth it.
But the patch should do the faking clean way, I guess. It's just another interface like the XRandR selector and such.
As for, do we need it? I don't know. I need it :) Correct way to add it? See above, but I highly suspect this ever getting into mainline. It's not correct behavior and is quite niche patch. Does the patch look good? See above, registry keys could be cleaned and multiple resolutions separated with eg ';' letter would be nice.
Also I'm not sure what is the take on defining environment variables.
2011/9/6 GOUJON Alexandre ale.goujon@gmail.com:
On 09/06/2011 02:25 PM, Jari Vetoniemi wrote:
I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp.
IMO, there is a need and your patch is a solution (among other).
Is there a relevant developer able to answer these questions ?
- Do we need this feature ?
- If so, what is the correct/clean way to add it into mainline ?
- Does the patch look good or what is wrong ?
I know there is no [RFC] in the subject of this thread but you're definitely requesting comments.
Bleh, Forgot to include the updated patch. There we go!
2011/10/6 Jari Vetoniemi mailroxas@gmail.com:
Hello, I have updated this to support multiple resolutions(&& frequencies) and also made it use only one registry key. If the registry key is empty, or does not exist, or WINE_FAKEDISP environment variable is not defined it won't be used at all.
Syntax is the same, expect you can separate multiple resolutions with semicolon(;) I've been using it for a while now, and find it really useful for applications that might change resolution. Also keeping both monitors alive (Game on other monitor for example, while doing stuff on other). And it can also make games use resolution that is normally unsupported.
Here is screen of Ys Origins running 1440x900 where it normally does not: http://ompldr.org/vYW91NA/YsOrigins.png
Just let you know, if anyone else found the patch useful. Cheers.
2011/9/6 Jari Vetoniemi mailroxas@gmail.com:
Well, I did the patch mostly for personal use and dropped here as some might find it useful. If wine ever needs something like this, let's say for testing or for some people wanting to fake display information, or do not want to use XRandR or others for some reason, then it would at least need to support multiple resolutions I guess.
ATM it only supports one, also it would be good to get rid of the useless registry keys and just provide one with same syntax as the environment variable one. Both should be easy to implement, I don't know where wine gets/sends the color depth information, so it could be faked too, but I'm not sure if it's worth it.
But the patch should do the faking clean way, I guess. It's just another interface like the XRandR selector and such.
As for, do we need it? I don't know. I need it :) Correct way to add it? See above, but I highly suspect this ever getting into mainline. It's not correct behavior and is quite niche patch. Does the patch look good? See above, registry keys could be cleaned and multiple resolutions separated with eg ';' letter would be nice.
Also I'm not sure what is the take on defining environment variables.
2011/9/6 GOUJON Alexandre ale.goujon@gmail.com:
On 09/06/2011 02:25 PM, Jari Vetoniemi wrote:
I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp.
IMO, there is a need and your patch is a solution (among other).
Is there a relevant developer able to answer these questions ?
- Do we need this feature ?
- If so, what is the correct/clean way to add it into mainline ?
- Does the patch look good or what is wrong ?
I know there is no [RFC] in the subject of this thread but you're definitely requesting comments.
-
GOUJON Alexandre -
Jari Vetoniemi -
Roderick Colenbrander