Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: Ugh. Apparently, I busted our fullscreen handling in metacity=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...) Since I'm on FC4 I can't test latest Metacity releases because it requires newer GTK, and backporting is not really possible since version 2.10 provided with FC4 is too different from 2.15.x series. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: Ugh. Apparently, I busted our fullscreen handling in metacity=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...) Since I'm on FC4 I can't test latest Metacity releases because it requires newer GTK, and backporting is not really possible since version 2.10 provided with FC4 is too different from 2.15.x series. -- Dmitry. You could for instance install Gargnome. It allows you to install a new gnome version without messing up your system. By default this new gnome is installed in your home directory. Roderick -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: wine's fullscreen code has no effect on metacity
On 8/7/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Elijah Newren [EMAIL PROTECTED] wrote: Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state. Ugh. Apparently, I busted our fullscreen handling in metacity=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...) Thanks for all the help! Elijah
Re: wine's fullscreen code has no effect on metacity
On 8/6/06, Vincent Povirk [EMAIL PROTECTED] wrote: The patches in comments #13 and #5 had no effect. I didn't try #2 because firefox doesn't change the screen resolution. #2, #5, and #13 were all alternative versions of patches for the same issue for the Thief game. It's not surprising that these don't affect firefox, as all were just meant to help in the case of screen resolution changing. #6 didn't apply cleanly (I'm using metacity 2.14.3--I tried to get the latest version from cvs, but it requires a newer gtk than I have). After applying it, firefox is fixed, except that when returning from fullscreen mode the window is bigger than it had been (unless it was maximized). Actually, that's because Dmitry was using an older version. The patch actually appiled to head would have also applied to 2.14.3. :) Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Hope that helps, Elijah
Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state. Also I notice that IE when returning from fullscreen state doesn't restore its caption back, while under KDE it does. Let me know whether it's a known/fixed bug, or if further investigation is needed. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
The patches in comments #13 and #5 had no effect. #6 didn't apply cleanly (I'm using metacity 2.14.3--I tried to get the latest version from cvs, but it requires a newer gtk than I have). After applying it, firefox is fixed, except that when returning from fullscreen mode the window is bigger than it had been (unless it was maximized). I didn't try #2 because firefox doesn't change the screen resolution. On 8/4/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: I've attached a couple of patches based on Havoc's suggestions to the bug above. The patches fix Thief game and IE's fullscreen mode for me. Vincent, could you try them and report if any of the patches fixes Firefox for you? -- Dmitry. -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov [EMAIL PROTECTED] wrote: Havoc Pennington [EMAIL PROTECTED] wrote: You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927 They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity. I've added a patch there which fixes the problem for me. I've attached a couple of patches based on Havoc's suggestions to the bug above. The patches fix Thief game and IE's fullscreen mode for me. Vincent, could you try them and report if any of the patches fixes Firefox for you? -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927 They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity. I've added a patch there which fixes the problem for me. Here is a comment I've put there to explain why the patch is needed: The problem appears to not be related to the heuristics Metacity uses to check whether a window may be fullscreened, but rather to a missing update of a window state after screen resolution change so that heuristics can do their work. I've used slightly old Metacity 2.10.0 sources, but hopefully the attached patch is still relevant. Please let me know whether the patch is a right way to fix the bug, or you need further explanations. Thanks. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov wrote: Havoc Pennington [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else? I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution. Anything else I can do to help fixing this problem? Do you need any further testing/logs/investigation on the Wine side? You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927 They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity. The other thing to test I guess is whether apps like e.g. mplayer/xine still get heuristically fullscreened, though for all I know recent mplayer uses the proper hints now. It's best to add further info on the bug so it doesn't get lost. Havoc
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else? I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution. Anything else I can do to help fixing this problem? Do you need any further testing/logs/investigation on the Wine side? Thanks. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: to shift it below the top GNOME top panel by 25 pixels (btw, that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other). Metacity does this with all windows (keeps them below the panel) unless there's some reason not to (such as fullscreen); it's a longstanding UI decision. It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else? Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that? From the metacity log, it looks to me like WINE here withdraws the window, turns on window decorations, then remaps the window. Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do. Thanks for the explanation, now the behavour I see in the log looks reasonable to me: a window gets mapped/unmapped in a succession, and actually Wine handles that correctly since it has an internal visibility state for each window. This answers the question (2) as well. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov wrote: It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else? I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution. Havoc
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: I can't tell enough from this log, because remember things are asynchronous. So we don't know what information metacity already had or did not have at each point in the log. i.e. WINE may think it said hide the window then get a configure notify, but metacity may have sent the configure notify BEFORE the window was hidden. (Just an example.) I'd suggest getting a new WINE log but with metacity verbose logging on also. Then we'll have the exact same run of this app from both sides of the issue and we can tell exactly what happened during that run of the app. Metacity verbose log will mention all the property changes and configure requests and so forth. btw the synchronous vs. asynchronous API impedance mismatch is a big problem; I worked with the Eclipse project on this years ago, where they had it with SWT vs. GTK. Though they did not afaik use the advice we gave them, which was to leave X/gtk working asynchronously but have a write-through cache of the server side state so things looked synchronous from the SWT point of view. I'm attaching 2 logs: 1st one is a Wine log (thief.log.bz2) produced by running WINEDEBUG=+win,+xrandr,+event,+x11drv,+synchronous ~/wine/wine THIEFD.EXE i.e. this log avoids an issue with asynchronous X behaviour, Wine calls 'XSynchronize( display, True );' on startup once it sees '+synchronous' in the debug switches. The 2nd is a metacity log (metacity_verbose.log.bz2) produced by starting X session with METACITY_VERBOSE=1, running Wine with the above debug switches. I've stripped the log by removing everything before 1st appearance of the window id 0x221 in the log and aftre destruction of that window. Please let me know if you need anything else. Thanks. -- Dmitry. metacity_verbose.log.bz2 Description: Binary data thief.log.bz2 Description: Binary data
Re: wine's fullscreen code has no effect on metacity
Something I think I may have suggested long ago is some sort of WINE hints that WMs could implement; in essence, have calls to the WM that map to Windows API calls exactly and try to have the same semantics. IOW implement the windows API in conjunction with the WM. This is probably the only way to make things 100%, 100% always work right; because it gets past the impedance mismatch between how native X apps work and how windows API apps work by giving them different codepaths. I wouldn't know how to do this, but it's an idea. Havoc
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov wrote: At this point WM decides to correct position of an invisible application's window (why?) In the metacity log, this is in the proper order (the window is mapped, metacity sets its position, and the window is withdrawn). I would conclude that this is a race; remember that if the app calls map, unmap then some events that occurred prior to the unmap request can still arrive after the unmap request. This is the asynchronicity I was talking about. to shift it below the top GNOME top panel by 25 pixels (btw, that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other). Metacity does this with all windows (keeps them below the panel) unless there's some reason not to (such as fullscreen); it's a longstanding UI decision. For some reason WM does this in a very inefficient way in multiple steps: trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,0,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (0,0) to (0,25) trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,25 (640x512), flags 0015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,25 640x512 flags 0015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,25 640x512 flags 1815 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 8000 new (0,25)-(640,537) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,25)-(640,537) client (0,25)-(640,537) style 8000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events MapNotify for hwnd/window 0x10024/201 Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that? From the metacity log, it looks to me like WINE here withdraws the window, turns on window decorations, then remaps the window. Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do. Clients and WMs both have to distinguish between maps that are incidental to implementation details and maps that have a meaning in the ICCCM. Essentially you need a withdrawn flag on windows indicating whether you have yourself mapped or unmapped the window. The WM may also map/unmap in order to reparent, manage workspaces, etc. and you should just ignore those map events most of the time. If you need a steady state mapped status that matches the Windows API, then you would need to simulate it on the client side, by e.g. using the client-side withdrawn flag instead of the mapped state. That leads to a lot of confusion later: Wine thinks that a window is not visible and ignores take focus client message below, while WM starts to send focus messages to the window: trace:event:process_events Expose for hwnd/window 0x10024/201 trace:x11drv:X11DRV_Expose win 0x10024 (201) 0,0 640x512 trace:win:RedrawWindow 0x10024 rect (0,0)-(640,512) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN trace:event:process_events FocusIn for hwnd/window 0x10024/201 trace:event:EVENT_FocusIn win 0x10024 xwin 201 detail=NotifyNonlinear X will not send focus events to unmapped windows btw, if it's useful to rely on that behavior. The log above makes me ask several questions: 1. Why the WM thinks that it knows better than the app where to place its window and insists on moving it to another position? That's not a user related interaction related to moving a window using mouse or a keyboard, IMO the WM should not do this kind of things behind applications back. As I mentioned before, there is no way to tell
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov wrote: 1. Why the WM thinks that it knows better than the app where to place its window and insists on moving it to another position? That's not a user related interaction related to moving a window using mouse or a keyboard, IMO the WM should not do this kind of things behind applications back. 2. How that could happen that the WM maps a window to the screen although it clearly was not asked to? I hope that the log above will help to shed some light into the investigated problem and will allow to find a resolution to it. I can't tell enough from this log, because remember things are asynchronous. So we don't know what information metacity already had or did not have at each point in the log. i.e. WINE may think it said hide the window then get a configure notify, but metacity may have sent the configure notify BEFORE the window was hidden. (Just an example.) I'd suggest getting a new WINE log but with metacity verbose logging on also. Then we'll have the exact same run of this app from both sides of the issue and we can tell exactly what happened during that run of the app. Metacity verbose log will mention all the property changes and configure requests and so forth. btw the synchronous vs. asynchronous API impedance mismatch is a big problem; I worked with the Eclipse project on this years ago, where they had it with SWT vs. GTK. Though they did not afaik use the advice we gave them, which was to leave X/gtk working asynchronously but have a write-through cache of the server side state so things looked synchronous from the SWT point of view. Of course the most robust approach is to design any API that has to run on top of X to have async semantics, but that's not an option with exisitng APIs like SWT or win32. Havoc
Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: On 7/7/06, Havoc Pennington [EMAIL PROTECTED] wrote: Currently what appears to be triggering the issue in metacity is that the window's minimum and maximum size are also changed, such that the window is not resizable. There's an exception to this rule if the window is already fullscreen-size, but the exception kicks in only for undecorated windows. I'd try just removing the !decorated line from metacity, or testing this theory by building a version of WINE that disables decorations in this case, just to see if it helps. I'm pretty sure that would fix this issue for WINE apps, since WINE is manually sending a please-put-this-app-in-fullscreen-mode message on behalf of the app. We should probably also fix the heuristics in src/stack.c:window_is_fullscreen_size() as well for other apps. (The difference between the two pieces of code is _allowing_ an app to be fullscreened in the first case, and automatically making an app be fullscreen without it properly requesting it in the second) I filed this pair of issues at http://bugzilla.gnome.org/show_bug.cgi?id=346927. I'll try to provide some investigation based on the todays Wine snapshot running a demo of game Thief: Here the game creates its main window: trace:win:WIN_CreateWindowEx Thief 1.33 LookingGlassTechnologies_WindowsGameShell_v2 ex= style=02ca 0,0 640x512 parent=(nil) menu=(nil) inst=0x40 params=(nil) trace:win:dump_window_styles style: WS_CLIPCHILDREN WS_CAPTION WS_SYSMENU WS_MINIMIZEBOX trace:win:dump_window_styles exstyle: trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (0,0)-(640,512) style 06ca trace:x11drv:create_icon_window created 202 trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 108 27 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (0,0)-(640,512) style 06ca trace:x11drv:X11DRV_sync_window_position setting win 201 pos 3,22,634x487 after 6609462c changes=f trace:x11drv:X11DRV_CreateWindow hwnd 0x10024 cs 0,0 640x512 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (3,22)-(637,509) style 06ca trace:x11drv:X11DRV_sync_window_position setting win 201 pos 3,22,634x487 after 6609462c changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10024 window 0,0,640,512 client 3,22,637,509 whole 3,22,637,509 X client 0,0,634,487 xwin 201 trace:win:WIN_CreateWindowEx created window 0x10024 trace:win:SetForegroundWindow 0x10024 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/201 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 3,22,634x487 (event 3,22,634x487) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:event:process_events processed 1 events trace:win:SetFocus 0x10024 prev (nil) trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 0 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 0 trace:win:alloc_winproc reusing 0x000c for 0x2034b314/(nil) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7ff401a8)-((nil),0008) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock trace:win:alloc_winproc reusing 0x000c for 0x2034b314/(nil) trace:win:WIN_SetWindowLong 0x10024 -20 8 A trace:win:WIN_SetWindowLong 0x10024 -20 8 A Now the game changes style of its man window to WS_POPUP (top level window without any decorations) trace:win:WIN_SetWindowLong 0x10024 -16 8000 A ... and calls ShowWindow(SW_SHOW) on it: trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=5, wasVisible 0 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (0x0), flags 0043 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_SHOWWINDOW trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,0 0x0 flags 0043 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,0 0x0 flags 1843 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 8000 new (0,0)-(640,512) trace:x11drv:SWP_DoOwnedPopups (0x10024) hInsertAfter = (nil) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (3,22)-(637,509) style 9000 trace:x11drv:X11DRV_sync_window_position setting win 201 pos 0,0,640x512 after 6609462c changes=4f window 0x10024 becomes visible and mapped to the screen: trace:x11drv:X11DRV_set_window_pos mapping win 0x10024 trace:win:SetForegroundWindow 0x10024 trace:x11drv:X11DRV_SetWindowPos status flags = 1847 [some unrelated stuff skipped] Now the game calls ShowWindow(SW_HIDE) on its main window to hide it: trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 1 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (0x0), flags 0083 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_HIDEWINDOW trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: Anyway, few WM bugs can be resolved by appeal to specifications alone... Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and doesn't in GNOME :-) If you could point out what Wine is doing in wrong way I'm all ears. Don't get defensive, everyone is completely willing to change metacity. All I'm saying is that there's no point trying to appeal to specs in this case. That's completely understood. There's no question that we need some heuristic try to detect legacy apps code which the spec in no way covers. KDE also has some heuristic code for this sort of thing, as does any reasonable window manager. As with any heuristic it's a little touch-and-go/trial-and-error. I believe several WMs including KDE and metacity have code something like: - if a window resizes itself to fullscreen, assume fullscreen state was intended This heuristic can have various tweaks, such as only assuming fullscreen if the window is undecorated. From other posts, I gather that WINE pretty much has this same heuristic internally, because the windows API doesn't have a fullscreen state, just screen sized + on top That's correct, except that window size may not match the screen size accurately, window size may be larger that screen, because applications sometimes instead of removing window decorations (caption and borders) simply resize a window so that client window area covers the screen. An algorithm in Wine which asks a WM to activate fullscreen state for a window is quite simple: it checks the size of a just resized visible window and if it's equal or larger than screen size sends an event to a WM. We are trying to understand at the moment why metacity sometimes ignores such a request: window size and visibility should not be a reason for it (except if metacity expects a window to have exactly same size as the screen has, not larger than that), probably window decorations or something else do. On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window makes it cover the GNOME dock, but GNOME top panel still remains on the top? Thanks for your help. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Dmitry Timoshkov wrote: An algorithm in Wine which asks a WM to activate fullscreen state for a window is quite simple: it checks the size of a just resized visible window and if it's equal or larger than screen size sends an event to a WM. We are trying to understand at the moment why metacity sometimes ignores such a request: window size and visibility should not be a reason for it (except if metacity expects a window to have exactly same size as the screen has, not larger than that), probably window decorations or something else do. Currently what appears to be triggering the issue in metacity is that the window's minimum and maximum size are also changed, such that the window is not resizable. There's an exception to this rule if the window is already fullscreen-size, but the exception kicks in only for undecorated windows. I'd try just removing the !decorated line from metacity, or testing this theory by building a version of WINE that disables decorations in this case, just to see if it helps. On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window makes it cover the GNOME dock, but GNOME top panel still remains on the top? afaik the top and bottom panels should always be in the same layer (so both above or both below). Elijah would know better though. ABOVE windows can be below the panels if they don't have focus iirc. Havoc
Re: wine's fullscreen code has no effect on metacity
On 7/6/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window. As I understand the above quote it's the WM's responsibility on application's request to remove window decorations and resize a window to fill the screen, then restore its previous state when switching from a fullscreen state. Yes, if it ever switches to a fullscreen state. So, all the checks metacity does for window decorations and window size are contradicting the spec IMO. No, the window would have to be in the fullscreen state in order for checks on window decorations or window size to even have the possibility of breaking the spec. Those checks in src/stack.c were basically meant as a workaround to help legacy applications who don't correctly put themselves into fullscreen mode still get into that mode. Yes, the checks appeared buggy (and we will fix them if I can find some time to verify), but it shouldn't adversely affect any well behaving application. Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically. Feel free to point to anywhere in the ICCCM or EWMH that says so. Of course apps can be resized programmatically -- because the not-resizable hints can be modified programmatically. I disagree with allowing the app or other utilities to modify the size of an unresizable window unless the unresizable'ness is first modified. My $0.02, Elijah
Re: wine's fullscreen code has no effect on metacity
Looking through the code made me notice the meta_verbose function and then the METACITY_VERBOSE environment variable. I set that and logged an attempt to fullscreen and then unfullscreen firefox. I can send the whole log if it might be helpful, but here's what stood out for me. Before firefox attempts to set the fullscreen hint, I see this: GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets max size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 0 fullscreenable = 0 min size 1280x1024 max size 1280x1024 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 0 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0 fullscreenable = 0? What? And before it tries to unset the fullscreen hint, I see this: GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min width to 0, which makes no sense GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min height to 0, which makes no sense GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 1 fullscreenable = 1 min size 1x1 max size 2147483647x2147483647 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 1 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0 What does fullscreenable mean, and is it possible that that's related to the problem? -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
Metacity has some heuristics for fullscreening windows that don't fullscreen themselves. IIRC, it looks to see if the window hits all the screen edges and then pretends that it's fullscreen for stacking constraints, etc. -Rob (metacity fullscreens all x clients that don't fullscreen themselves. Who fullscreens metacity?) On Wed, 2006-07-05 at 21:32 -0400, Vincent Povirk wrote: I do not know if this helps, but on some games, Wine correctly activates fullscreen mode in metacity, but in others, it just resizes the screen and gets stuck that way... For example, Sim City 3000. Ubuntu Breezy and Fedora Core 5 cannot seem to properly go into fullscreen mode. But when running Where in Time is Carmen Sandiego? metacity properly activates fullscreen mode with it. Same thing with ClueFinders, etc. It may help. Unless someone else tries this before me, I'll have to try a demo of this game. Or maybe not. I think I've seen Worms 3D use fullscreen mode properly before Wine ever had that implemented. It might just mean that opengl provides another (but for some reason more compatible with metacity) method for making windows fullscreen.
Re: wine's fullscreen code has no effect on metacity
On 7/4/06, Vincent Povirk [EMAIL PROTECTED] wrote: I've enabled that key combination, and I can now make gedit fullscreen with alt+f11 so I think that's working properly (this is nifty; wonder how I missed it..). Pressing alt+f11 when windows firefox thinks it's in fullscreen mode has no effect. xprop shows no _NET_WM_STATE. What does windows firefox thinks it's in fullscreen mode mean? Does the application try to manually resize itself in addition to sending the state change messages to the root window (perhaps as a workaround for WMs not supporting the _NET_WM_STATE stuff)? Or is there some other notification that the window is attempting to be in fullscreen mode? How are you making firefox try to enter fullscreen mode? (F11?) However, it does work (sort of) if I press it when firefox is not in fullscreen mode, except that I can see part of the bottom panel (but can't interact with it; I assume it's really firefox's window there but firefox hasn't drawn anything). xprop does show _NET_WM_STATE_FULLSCREEN when I do that. You see part of the bottom panel, but not the whole thing and you can't interact with any of it? Sounds like an application bug where Metacity has resized and placed the window on top but the app just hasn't updated from expose events. You could verify by e.g. running sleep 5; xprop | less in a terminal, switching to firefox during the sleep and putting it in fullscreen mode, then after the sleep clicking in the area where you see part of the bottom panel. xprop lists all kinds of crap, but the WM_CLASS or WM_NAME (both near the end) are usually pretty good ways to verify which application you clicked on. Anyway, it appears that the window does actually get placed into fullscreen mode given your comments, which means that we should look closer at the actual setting of the hint from wine. Could you point to the relevant code? Alternatively, I can point you to the source code in metacity. The Alt-f11 keybinding I had you set up is handled in metacity/src/keybindings.c:handle_toggle_fullscreen(). Messages from apps to add/remove/toggle these state properties are handled in metacity/src/window.c:meta_window_client_message() you'll want to search for fullscreen within that function as many other states are handled in that function as well. One other pointer that may assist you in debugging; you can use the command xprop -root | grep ^_NET_CLIENT_LIST_STACKING together with commands like xprop -id 0x22eb54c | grep WM_CLASS (substituting appropriate window ids from the first command) in order to figure out how your WM has stacked the windows.
Re: wine's fullscreen code has no effect on metacity
Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability. In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated. It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it. I don't really know why the !window-decorated is in the check in recalc_window_features but Elijah may well. This would explain why wine fullscreening works sometimes, it probably works when the window is a) full screen size and b) also disables the window decorations. Fullscreen mode would remove the decorations anyhow though, is why I don't know why metacity checks this. Havoc Vincent Povirk wrote: Looking through the code made me notice the meta_verbose function and then the METACITY_VERBOSE environment variable. I set that and logged an attempt to fullscreen and then unfullscreen firefox. I can send the whole log if it might be helpful, but here's what stood out for me. Before firefox attempts to set the fullscreen hint, I see this: GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets max size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 0 fullscreenable = 0 min size 1280x1024 max size 1280x1024 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 0 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0
Re: wine's fullscreen code has no effect on metacity
On 7/6/06, Havoc Pennington [EMAIL PROTECTED] wrote: Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability. In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated. It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it. I don't really know why the !window-decorated is in the check in recalc_window_features but Elijah may well. Nope, but I found this: 2002-08-15 Havoc Pennington [EMAIL PROTECTED] * src/window.c (recalc_window_features): leave has_fullscreen_func set to TRUE if the window is screen sized and undecorated, even if the window isn't resizable. idea from Christian - Manny Calavera - Neumair You didn't state a bug number or anything, so no more details appear to be available. I also don't see why the decoration check is there, but the fact that it is would explain why subsequent fullscreen me messages from the app would be ignored. As Rob pointed out, there are also some heuristics in src/stack.c (see window_is_fullscreen_size()) to try to treat certain windows as fullscreen despite their incorrect methods at attempting to fullscreen themselves (such as what these windows apps with wine are apparently doing). These heuristics, at least at first glance, also look broken to me in the case of windows with decorations since constraints will force the client area of the window away from the upper left corner of the workarea. (This appears to be true for both the old metacity-2.12.x version and the current one)
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability. In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated. It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it. I don't really know why the !window-decorated is in the check in recalc_window_features but Elijah may well. This would explain why wine fullscreening works sometimes, it probably works when the window is a) full screen size and b) also disables the window decorations. Fullscreen mode would remove the decorations anyhow though, is why I don't know why metacity checks this. From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window. As I understand the above quote it's the WM's responsibility on application's request to remove window decorations and resize a window to fill the screen, then restore its previous state when switching from a fullscreen state. So, all the checks metacity does for window decorations and window size are contradicting the spec IMO. Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically. Feel free to point to anywhere in the ICCCM or EWMH that says so. Of course apps can be resized programmatically -- because the not-resizable hints can be modified programmatically. I disagree with allowing the app or other utilities to modify the size of an unresizable window unless the unresizable'ness is first modified. http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507474 A list of atoms indicating *user* operations that the Window Manager supports for this window. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: We used to have a strict spec compliance/disable workarounds mode in metacity and it was unusable unless you ran GTK/Qt apps exclusively, pretty much. While my memory is too fuzzy to point to specific bugs, I'd be willing to bet that I added more than one little hack inspired by WINE, which used to be unaware of EWMH and perhaps a bit sketchier than Qt/GTK on the older ICCCM behaviors too. Anyway, few WM bugs can be resolved by appeal to specifications alone... Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and doesn't in GNOME :-) If you could point out what Wine is doing in wrong way I'm all ears. Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically. In practice the geometry hints are widely treated as strict constraints honored for all configure requests from any source. Most WMs ignore them at least sometimes though, e.g. ignoring the size increments when maximizing is a common choice. If nothing else, in modern desktops it's quite hard to tell which configure requests are user-originated and which are not. That one is simple: if a request is being originated by a user interaction it's a user's request and might be restricted; if it's a result of an API call it's done programmatically and should be executed by all means. -- Dmitry.
Re: wine's fullscreen code has no effect on metacity
On 7/2/06, Vincent Povirk [EMAIL PROTECTED] wrote: Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode). I've mentioned this on wine's bug (http://bugs.winehq.org/show_bug.cgi?id=3312), but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed). So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? If you have properly changed the fullscreen state as it sounds, the only case in which metacity ignores this hint is when the window doesn't have focus and is on the same xinerama as the window that does have focus (this is to allow the user to alt-tab to another window and do something without having the window they alt-tab to just remain covered up). So, if you can run xprop | grep _NET_WM_STATE and click on the relevant window and it shows _NET_WM_STATE_FULLSCREEN as one of the states and then focus that window and observe it to not be on top of all other windows (including panels), then it sounds like you've discovered a bug in Metacity. If so, I would be interested to learn how to reproduce so that I can fix it. Thanks, Elijah
Re: wine's fullscreen code has no effect on metacity
This is forwarded because I forgot to CC it... Sorry-- Forwarded message --From: Neal Gompa [EMAIL PROTECTED] Date: Jul 5, 2006 5:54 PMSubject: Re: wine's fullscreen code has no effect on metacityTo: Vincent Povirk [EMAIL PROTECTED] I do not know if this helps, but on some games, Wine correctly activates fullscreen mode in metacity, but in others, it just resizes the screen and gets stuck that way... For example, Sim City 3000. Ubuntu Breezy and Fedora Core 5 cannot seem to properly go into fullscreen mode. But when running Where in Time is Carmen Sandiego? metacity properly activates fullscreen mode with it. Same thing with ClueFinders, etc. On 7/4/06, Vincent Povirk [EMAIL PROTECTED] wrote: I've enabled that key combination, and I can now make gedit fullscreenwith alt+f11 so I think that's working properly (this is nifty; wonderhow I missed it..).Pressing alt+f11 when windows firefox thinks it's in fullscreen mode has no effect. xprop shows no _NET_WM_STATE.However, it does work (sort of) if I press it when firefox is not infullscreen mode, except that I can see part of the bottom panel (butcan't interact with it; I assume it's really firefox's window there but firefox hasn't drawn anything). xprop does show_NET_WM_STATE_FULLSCREEN when I do that.I'm not aware of anything different about how wine sets fullscreenfrom other programs that I know work with metacity (I've compared the source code and as far as I can tell it's identical, unless wine isdoing something else I'm not aware of). Yeah, that looks really odd.That alone almost certainly means there's either a bug in KWin, metacity, or the EWMH.Could you try something for me to see if we can narrow down the cause?There's a special keybinding in Gnome, disabled by default, for manually setting windows to fullscreen mode.Could you run gnome-keybinding-properties, find the Toggle fullscreen mode item in the list, click on it, press some special key combo (e.g. Alt-F11), then focus your window in question, and press that key combo?That should make the window fullscreen and place it on top.If you could check the xprop thing again at that point just to verify the _NET_WM_STATE, that would also help. After we know that, we can try seeing if you're setting the state in a weird way that KWin accepts but other WMs don't, or are setting it in a valid but slightly different way that Metacity should accept but doesn't, or if Metacity is doing something else weird. Cheers, Elijah--Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
What does windows firefox thinks it's in fullscreen mode mean? Does the application try to manually resize itself in addition to sending the state change messages to the root window (perhaps as a workaround for WMs not supporting the _NET_WM_STATE stuff)? Or is there some other notification that the window is attempting to be in fullscreen mode? Windows does not have a fullscreen mode. In Windows, windows that are Always on Top are on top of panels. Windows applications enter fullscreen mode by positioning themselves take up the whole screen and being always on top (actually, now I'm not so sure they have to be always on top; I'm only basing that on my experience as a Windows user). When the size of a window or the screen resolution changes, Wine marks windows whose client area covers the whole screen as fullscreen. This is done in the update_fullscreen_state function in this file: http://cvs.winehq.org/cvsweb/wine/dlls/winex11.drv/winpos.c?rev=1.5content-type=text/x-cvsweb-markup How are you making firefox try to enter fullscreen mode? (F11?) Yep. You see part of the bottom panel, but not the whole thing and you can't interact with any of it? Sounds like an application bug where Metacity has resized and placed the window on top but the app just hasn't updated from expose events. You could verify by e.g. running sleep 5; xprop | less in a terminal, switching to firefox during the sleep and putting it in fullscreen mode, then after the sleep clicking in the area where you see part of the bottom panel. xprop lists all kinds of crap, but the WM_CLASS or WM_NAME (both near the end) are usually pretty good ways to verify which application you clicked on. That issue is with Alt+F11 (metacity forcing fullscreen mode), and it's not really as important, since Windows can't do anything like that. Alternatively, I can point you to the source code in metacity. The Alt-f11 keybinding I had you set up is handled in metacity/src/keybindings.c:handle_toggle_fullscreen(). Messages from apps to add/remove/toggle these state properties are handled in metacity/src/window.c:meta_window_client_message() you'll want to search for fullscreen within that function as many other states are handled in that function as well. I'll look at that when I have a chance (even though I'm not really an expert on this stuff), thanks. -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
I do not know if this helps, but on some games, Wine correctly activates fullscreen mode in metacity, but in others, it just resizes the screen and gets stuck that way... For example, Sim City 3000. Ubuntu Breezy and Fedora Core 5 cannot seem to properly go into fullscreen mode. But when running Where in Time is Carmen Sandiego? metacity properly activates fullscreen mode with it. Same thing with ClueFinders, etc. It may help. Unless someone else tries this before me, I'll have to try a demo of this game. Or maybe not. I think I've seen Worms 3D use fullscreen mode properly before Wine ever had that implemented. It might just mean that opengl provides another (but for some reason more compatible with metacity) method for making windows fullscreen. -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote: So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? Run metacity from the command line so you can see what it prints; metacity helpfully outputs warnings when applications violate the specs or do something weird. Maybe we can find out what's going on there. thanks -mike
Re: wine's fullscreen code has no effect on metacity
I've tried that; it didn't work in this case. :/ On 7/4/06, Mike Hearn [EMAIL PROTECTED] wrote: On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote: So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? Run metacity from the command line so you can see what it prints; metacity helpfully outputs warnings when applications violate the specs or do something weird. Maybe we can find out what's going on there. thanks -mike -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
running metacity: [EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) = running kwin: [EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN Not that I understood how this was supposed to work to begin with, but this really doesn't make any sense to me. On 7/4/06, Elijah Newren [EMAIL PROTECTED] wrote: On 7/2/06, Vincent Povirk [EMAIL PROTECTED] wrote: Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode). I've mentioned this on wine's bug (http://bugs.winehq.org/show_bug.cgi?id=3312), but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed). So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? If you have properly changed the fullscreen state as it sounds, the only case in which metacity ignores this hint is when the window doesn't have focus and is on the same xinerama as the window that does have focus (this is to allow the user to alt-tab to another window and do something without having the window they alt-tab to just remain covered up). So, if you can run xprop | grep _NET_WM_STATE and click on the relevant window and it shows _NET_WM_STATE_FULLSCREEN as one of the states and then focus that window and observe it to not be on top of all other windows (including panels), then it sounds like you've discovered a bug in Metacity. If so, I would be interested to learn how to reproduce so that I can fix it. Thanks, Elijah -- Vincent Povirk
Re: wine's fullscreen code has no effect on metacity
I've enabled that key combination, and I can now make gedit fullscreen with alt+f11 so I think that's working properly (this is nifty; wonder how I missed it..). Pressing alt+f11 when windows firefox thinks it's in fullscreen mode has no effect. xprop shows no _NET_WM_STATE. However, it does work (sort of) if I press it when firefox is not in fullscreen mode, except that I can see part of the bottom panel (but can't interact with it; I assume it's really firefox's window there but firefox hasn't drawn anything). xprop does show _NET_WM_STATE_FULLSCREEN when I do that. I'm not aware of anything different about how wine sets fullscreen from other programs that I know work with metacity (I've compared the source code and as far as I can tell it's identical, unless wine is doing something else I'm not aware of). Yeah, that looks really odd. That alone almost certainly means there's either a bug in KWin, metacity, or the EWMH. Could you try something for me to see if we can narrow down the cause? There's a special keybinding in Gnome, disabled by default, for manually setting windows to fullscreen mode. Could you run gnome-keybinding-properties, find the Toggle fullscreen mode item in the list, click on it, press some special key combo (e.g. Alt-F11), then focus your window in question, and press that key combo? That should make the window fullscreen and place it on top. If you could check the xprop thing again at that point just to verify the _NET_WM_STATE, that would also help. After we know that, we can try seeing if you're setting the state in a weird way that KWin accepts but other WMs don't, or are setting it in a valid but slightly different way that Metacity should accept but doesn't, or if Metacity is doing something else weird. Cheers, Elijah -- Vincent Povirk
wine's fullscreen code has no effect on metacity
Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode). I've mentioned this on wine's bug (http://bugs.winehq.org/show_bug.cgi?id=3312), but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed). So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? -- Vincent Povirk
