I'm not very technical, so the screen shots I've provided in the wine bug provided in the url probably says a lot more than my thousand words description. I've noticed with several 3d accelerated wine applications that running them in full screen mode would fail if there was a plasma panel at the top or left-handed edge of the screen (or rather, as this was probably an artefact of running an application in a resolution lower than the desktop, the saliant point is probably any overlap with a plasma panel) and result in the screen assuming the resolution the application should have, but the application would get what looks like an unmanaged window with an attached plasma bar and being pushed off-screen by just as many pixels (as plasma bar+application is naturally wider than application alone). or as Henri Verbeet summarised it "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." Reproducible: Always Steps to Reproduce: this is fairly obviously going to be sorted under "can't reproduce" as it involves non-free software, but as I don't know of any free applications I could try with, it'll have to do. 1. install wine and temple of evil 2. make sure you got a plasma panel, set as always visible, at the left-hand edge of the screen 3. launch Temple of Evil Actual Results: Application will launch, the "screen" will take the dimensions of the introductionary movies (logotypes etc), and it looks like it attaches to the plasma panel (no I don't think it actually sticks, but that's what it looks like..) after this the "window" will not resize even if resolution in game is changed, which may result in a game of 1280x1024 being stuck in a 1024x768 pixels large window. Expected Results: Application will launch, screen take dimensions of introductionary movies, when xrender (which is what I think wine uses) tries to change the resolution as used by the game proper, the window is resized to match the new (higher) resolution. Plasma panel is expected to be excluded. Setting plasma panel to auto hide or moving it to an area where it won't overlap with wine works as a work around. Similar problems (presentation differs slightly) can be observed with Source and Unreal engine games. Manually configuring the desktop to using the same resolution as the application will use before launch is another workaround. Software rendered games are not affected. Composing does not seem to be a factor, as I get the same results with and without it. OpenGL renderer string: AMD Radeon HD 6700 Series OpenGL version string: 4.2.11733 Compatibility Profile Context
please try to obtain "xprop" of the window and "xrandr -q" while the game is running (might not be a simple task) xrandr -q - move to VT0 (ctrl+alt+f1) - login - enter "DISPLAY=:0 xrandr -q 2>1 > xrandr.output" xprop, simple approach: - enter "DISPLAY=:0 xprop -q > xprop.output" - hope that it does not say: "xprop: error: Can't grab the mouse." - move back to VT6 (ctrl+alt+f7) - the cursor should be a cross, click the game window From the description in the wine bug the application neither sets itself to be fullscreen (therefore is not allowed to overlap the panel) nor does it actually chage the screen resolution (but creates a canvas, that is why there's more on the screenshot. There /is/ more, it's just out of bounds of your panel. The legacy fullscreen hack will not help you as the window does not have workspace geometry (the workspace is not resized since the resolution didn't change) what you can try is to run the game through a script that a) sets the wanted resolution via xrandr (xrandr -h) b) starts the game in actual fullscreen mode (kstart --fullscreen wine stuff.exe) if (b) fails (never tried that) you can use "kcmshell4 kwinrules" to set up a rule for the window to be fullscreened (you'll need its classname for this, possibly with similar problems as invoking xprop while the game is running)
Created attachment 72913 [details] xprop of runnint ToEE.exe had to do issue the xprop command from a terminal under x, as it couldn't grab the mouse otherwise - does it matter though?
Created attachment 72914 [details] xrander output while running ToEE.exe this was issued from VT0 as instructed
Thanks for the suggestions, turned out that creating a window rule was the easiest solution, even if it doesn't handle instances where games "suddenly" play a lower resolution movie gracefully. I hope I got those logs right - and that they are helpful in someway, or can be made helpful to someone else.
No, using an xterm is entirely ok - i just thought that could be troublesome while running a fullscreen game. The screen seems correctly resized and since the game does apparently not grab the mouse you'd also notice the canvas by moving the pointer to the edges (since the viewport follows) The window s just maximized/bordeless/keep above. This is "wrong" and a pre-netwm hack (should not be used since more than a decade) You can kwriteconfig --file kwinrc --group Windows --key LegacyFullscreenSupport true qdbus org.kde.kwin /KWin reconfigure but that was disabled for KDE 4.4 and will break eg. plasma-netbook marking as invalid since there's no real bug on our side.