http://bugs.winehq.org/show_bug.cgi?id=31381
Bug #: 31381 Summary: Temple of Evil - full screen mode "fail", results in a "borderless window" with wrong dimensions Product: Wine Version: 1.5.9 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: Goblinstomper@gmail.com Classification: Unclassified
Created attachment 41227 --> http://bugs.winehq.org/attachment.cgi?id=41227 x11 settings trace log
First of all, I'm not very technically minded and I know nothing of the techniques or methodology involved so no special/technical meaning should be inferred from the words I use.
Strange interaction between kde Plasma Panel and Temple of Evil full screen.
To trigger, this must be true: -Plasma panel set to: always visible (this does not normally cause problems for full screen applications, it should only prevent windows from covering it while the desktop is visible) -There must be a panel at either the top or the left-hand side of the screen (not strictly true, but these are the areas most likely to overlap with wine).
-Application must be set to run in full screen -Application must use 3d acceleration -Application need to change between high and low resolutions, such as between movies displaying studio logotypes etc. and the game.
My desktop looks like figure 1. then I launch ToEE.exe
What appears to happen: -Desktop and Screen dimensions are set to the resolution the game is intended to have -Taking a screen shot results in a native resolution (that is, it does not reflect what is actually displayed on the screen) image(figure 2) which is probably unrelated, but does make it harder to illustrate the problem. -Application appears to be rendered in the appropriate resolution, while still not occupying the full screen, it appears as an unmanaged window whos' size does not match up correctly with the resolution. Figure 3 depicts ToEE in the resolution of 1280x1024 on a 1920x1080 desktop - as you can see it comes short in all directions, although height is the worst offender. -Once a "window" has been created for the application, re-sizes do not happen to the degree they should, requiring user intervention. -Trying to alt tab leaves ToEE always on top (it doesn't minimize), as long as ToEE is running, desktop resolution is set to the same resolution. (I don't think this is relevant though)
To avoid triggering the behaviour, perform any of: -Use a virtual desktop -Move the plasma panel so that it doesn't cross applications run with wine; change it to auto hide.
Additional: Disabling intro movies (which I think fixes the "window" size of the game to 1024x768) reduces the problem to as shown by figure 4 (what is displayed on screen) and figure 5 (which is a correct rendition of a 1280x1024 window on a 1920x1080 desktop - although it was supposed to be full screen). Figure 3, 4 and 5 have been doctored to show only what is shown on screen, and may as such be slightly off pixelwise.
It seems to me that something goes wrong when changing resolutions, this is especially annoying with applications defaulting to 640x480, and it seem to involve the top left corner of the screen...
OpenGL renderer string: AMD Radeon HD 6700 Series OpenGL version string: 4.2.11733 Compatibility Profile Context KDE 4.8.4
of the different traces I attempted X11 seemed most promising of actually containing anything useful.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #1 from Goblinstomper@gmail.com 2012-08-01 20:32:09 CDT --- Created attachment 41228 --> http://bugs.winehq.org/attachment.cgi?id=41228 my desktop, before full screen application is launched
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #2 from Goblinstomper@gmail.com 2012-08-01 20:34:06 CDT --- Created attachment 41229 --> http://bugs.winehq.org/attachment.cgi?id=41229 Temple of Evil has been launched as full screen
1280x1024 resolution as you can see on the picture - yet large parts of my desktop are visible as it's not actually fullscreen
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #3 from Goblinstomper@gmail.com 2012-08-01 20:35:07 CDT --- Created attachment 41230 --> http://bugs.winehq.org/attachment.cgi?id=41230 Figure 3
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #4 from Goblinstomper@gmail.com 2012-08-01 20:35:31 CDT --- Created attachment 41231 --> http://bugs.winehq.org/attachment.cgi?id=41231 Figure 4
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #5 from Goblinstomper@gmail.com 2012-08-01 20:35:59 CDT --- Created attachment 41232 --> http://bugs.winehq.org/attachment.cgi?id=41232 Figure 5
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #6 from Goblinstomper@gmail.com 2012-08-01 20:36:56 CDT ---
I expect these traces to be totaly useless/out of scope as they contain way to much stuff (and most of it probably caused by a malfunctioning fire effect on the main menu), but I'll link them anyway.
Gigantic d3d trace of "normal" looking Temple of Evil - https://docs.google.com/open?id=0B38pJ-Zt2r1Pb2c3QThINy1vcUE Gigantic d3d trace of "abnormal" looking Temple of Evil - https://docs.google.com/open?id=0B38pJ-Zt2r1PSU1YaDR2NWhxWGc diff abnormal normal results in - https://docs.google.com/open?id=0B38pJ-Zt2r1PNHJxeE10WGNYR0U
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2012-08-02 09:35:48 CDT --- (In reply to comment #0)
It seems to me that something goes wrong when changing resolutions, this is especially annoying with applications defaulting to 640x480, and it seem to involve the top left corner of the screen...
The impression I get from your description and screenshots is that setting the display mode actually work fine, but the application window is never resized from its original size.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #8 from Goblinstomper@gmail.com 2012-08-02 09:41:48 CDT --- (In reply to comment #7)
(In reply to comment #0)
It seems to me that something goes wrong when changing resolutions, this is especially annoying with applications defaulting to 640x480, and it seem to involve the top left corner of the screen...
The impression I get from your description and screenshots is that setting the display mode actually work fine, but the application window is never resized from its original size.
that looks like a fair description, wish I had been able to summarise it in so few words >_< I guess I went over board as I've had "similar but not identical" issues with other applications (but I decided to not try to lump them together).
so, would this be a wine bug or should I file a bug upstream as it seems to be triggered by the location of the panel?
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2012-08-02 09:44:55 CDT --- My guess would be some kind of window manager issue, in particular because the location of the plasma panel seems to make a difference, but it's not always easy to tell.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #10 from Goblinstomper@gmail.com 2012-08-02 09:50:48 CDT --- ok, I think I'll file a bug against kwin as well - can't get any worse than them saying it's not a kwin bug :) Thanks for at least clarifying what the issue probably is.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #11 from Goblinstomper@gmail.com 2012-08-03 12:09:31 CDT --- So, I took a shot at the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=304469) and Martin Lubking there was most helpful, if I understand it correctly his conclusion was that ToEE was trying to use an old way of establishing a full-screen window, failing and only using a canvas which kwin can't or don't manage.
As I doubt wine would be using a method which "should not be used since more than a decade" (and enabling LegacyFullscreenSupport in kwin didn't help either) and no one but me having problems with it/reporting it seems unlikely. So I'm started to think that there was something wrong on my end, either that I had failed to provide accurate information - or drivers were at fault, perhaps causing some kind of fallback? (remembered seeing somewhere that xrandr support was questionable with proprietary drivers).
So I removed fglrx and with the free driver everything looks like it is supposed to.
OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 7.11
I suppose this means it's not a winebug but a fgrlx bug.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2012-08-03 15:52:30 CDT --- (In reply to comment #11)
So, I took a shot at the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=304469) and Martin Lubking there was most helpful, if I understand it correctly his conclusion was that ToEE was trying to use an old way of establishing a full-screen window, failing and only using a canvas which kwin can't or don't manage.
Frankly, what's written in that bug report doesn't make a lot of sense to me. Just so I'm sure I'm understanding this correctly, the application window in http://bugs.winehq.org/attachment.cgi?id=41229 is supposed to be 1280x1024, but actually stays something like 800x600. That e.g. _NET_WM_STATE_FULLSCREEN wouldn't be set in that case isn't all that surprising, it doesn't get set if the resize failed.
One thing I did notice in that screenshot is that the size is actually 1279x1019 instead of 1280x1024. Is that because you cropped the screenshot, or does fglrx actually give you that resolution if you ask for 1280x1024? Either way, if it works with the free driver it's probably not worth worrying too much about.
http://bugs.winehq.org/show_bug.cgi?id=31381
--- Comment #13 from Goblinstomper@gmail.com 2012-08-03 17:15:13 CDT --- (In reply to comment #12)
(In reply to comment #11)
So, I took a shot at the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=304469) and Martin Lubking there was most helpful, if I understand it correctly his conclusion was that ToEE was trying to use an old way of establishing a full-screen window, failing and only using a canvas which kwin can't or don't manage.
Frankly, what's written in that bug report doesn't make a lot of sense to me. Just so I'm sure I'm understanding this correctly, the application window in http://bugs.winehq.org/attachment.cgi?id=41229 is supposed to be 1280x1024, but actually stays something like 800x600.
It's 1024x768, the same resolution as at least one of the movies played at the start of the game, and after which the window isn't resized again. I found out the dimensions when I mucked about with forcing kwin to keep windows certain sizes, but yes that is correct.
That e.g. _NET_WM_STATE_FULLSCREEN wouldn't be set in that case isn't all that surprising, it doesn't get set if the resize failed.
One thing I did notice in that screenshot is that the size is actually 1279x1019 instead of 1280x1024. Is that because you cropped the screenshot, or does fglrx actually give you that resolution if you ask for 1280x1024? Either way, if it works with the free driver it's probably not worth worrying too much about.
that is due to my cropping yes, fglrx has always had the right size of the screen (but not the "game-window") and if I understood Martin correctly that wouldn't have been a problem if the "game-window" had had the right properties letting the panel know it was supposed to get out of it's way. If I hadn't cropped it it would have looked like the game always ran as a window in the upper left corner on a huge desktop as the application I used to take the screen shots somehow manage to get everything.
Frankly it has become apparent that my lacking knowledge of graphics and the terminology involved makes this at least twice as hard to describe as it ought to be. Thank you for your patience.
and yes, as far as I'm concerned this is not a wine bug and will probably get corrected in fglrx one way or another eventually.
http://bugs.winehq.org/show_bug.cgi?id=31381
Goblinstomper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #14 from Goblinstomper@gmail.com 2012-10-01 10:59:10 CDT --- So, perhaps it was a winebug after all ;) I saw the same issue until 1.5.13 where it even seemed to occur in some games which never had the problem before. In 1.5.14 it seems fixed and I've only seen it momentarily in other games while configuring 3d support (ex. BG2Config).
http://bugs.winehq.org/show_bug.cgi?id=31381
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2012-10-12 13:36:01 CDT --- Closing bugs fixed in 1.5.15.