Summary: | Plasma panel seems to have an adverse effect on (wine) application window resizing. | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | goblinstomper |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | minor | ||
Priority: | NOR | ||
Version: | 4.8.4 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
URL: | http://http://bugs.winehq.org/show_bug.cgi?id=31381 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
xprop of runnint ToEE.exe
xrander output while running ToEE.exe |
Description
goblinstomper
2012-08-02 21:12:22 UTC
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. |