https://bugs.winehq.org/show_bug.cgi?id=38765
Bug ID: 38765 Summary: VMR9 steals focus from within Wine Product: Wine Version: 1.7.38 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs@winehq.org Reporter: jasonwinter@hotmail.com Distribution: ---
When a graph transitions from pause to run with a VMR9 video window present (which has been owned by another window with put_Owner) the Wine window implementing VMR9 is incorrectly given focus. This will steal focus from an active window in a different process, and because the actual owner wasn't active, all focus is lost within the Wine subsystem.
I.E. Task bar says original app is focused, but that window title has gone grey, the VRM9 window title goes blue but nothing actually has focus.
Note, if the graph is run when the app owning the VMR9 is focused, everything works as normal including the Message-Drain API in VMR9, although focus is still lost from the app owner window. This possibly obscures this bug.
Note also, I think "other things" like altering mouse pointer visibility with mouse-move messages also cause the Wine window implementing VMR9 to gain focus, so simply moving the mouse over video output can steal focus from a different active application within Wine.
https://bugs.winehq.org/show_bug.cgi?id=38765
Jason jasonwinter@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
--- Comment #1 from Jason jasonwinter@hotmail.com --- Changing importance to major. Focus loss problems are significant I think, and I've located some of the code in Wine causing this issue.
VMR_OnStartStreaming in vmr9.c contains the functions:
SetwindowPos & ShowWindow
Since I configure VMR9 to be windowless (as I use a clipping window) I would expect these calls to use SWP_NOACTIVATE & SW_SHOWNA respectively in this mode.
Zapping the quartz.dll.so (as it was easy to locate the 0x06200000 flag for SetWindowPos in two locations, the other one being in VideoRenderer_AutoShowWindow in videorenderer.c) to 0x16200000 and the following ShowWindow 0x05000000 flag to 0x08000000, stops the un-pausing of the graph from stealing focus from other unrelated Wine applications.
I'm yet to locate the focus loss that occurs when the mouse moves over the window and I show/hide the mouse pointer. I do alter the renderer window size by 1 pixel and back to fix an issue with the OverlayMixer in Windows (forces a repaint of the overlay passthrough colour) when I do all this - so maybe that's what triggers it. Looking at the code though, those SetWindowPos calls for resize do already use SWP_NOACTIVATE. So it's a bit confusing.
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #2 from Jason jasonwinter@hotmail.com --- Ok, I think I've tracked down the other Wine issue with my hide cursor routine.
None of the 8 SetWindowPos calls made in window.c in strmbase include SWP_NOACTIVATE so those calls made there will in fact activate a window, if another one is already active.
This includes simply altering the size of a window, and also in my case using put_WindowStyle (though not put_WindowStyleEx - I'm not sure why there's a difference between the Wine logic in these two functions, as I don't understand the SetWindowPos call in the WindowStyle version).
I'm fairly certain real-Windows does not activate windows when most of the following are called:
put_WindowStyle put_Left put_Width put_Top put_Height put_Owner SetWindowPosition (This is a tough call, but probably no.)
And
SetWindowForeground (this probably should, but looking at the focus variable it's probably wrong too as it uses Win32's SetForegroundWindow for that instead.)
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #3 from Jason jasonwinter@hotmail.com --- After reading the Win32 doco, I now understand why SetWindowPos is being called in put_WindowStyle, but I now notice that call in strmbase/window.c is missing SWP_NOMOVE in Wine.
The other thing that's confusing is, all these calls have SWP_NOZORDER and the doco isn't clear how this operates without SWP_NOACTIVATE.
The doco says an app can't activate an inactive window without bringing it to the top of the z-order, but SWP_NOZORDER only says it retains the z-order by ignoring the input parameter insert-after.
I don't know how it's meant to work, but perhaps Wine's SetWindowPos is a little bit broken? I.E. Maybe the coder of vmr9.c assumed that no-zorder also meant no-activate, since that makes sense now, but it is being activated.
I give in.
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #4 from Jason jasonwinter@hotmail.com --- Finally, my last comment on all this, in strmbase/window.c put_WindowState & put_Visible should not do anything except return with S_OK when VRM9 is in windowless mode. It is up to the coder to hide their own window if needed.
They currently (and blindly) call ShowWindow which changes focus and was the last thing interfering with my application.
Now, if only sound and video playback was smooth it would all be perfect. But that's a problem for another day. Or month. Or year. I've really had enough of this for a while.
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- Hi, Jason.
I don't know much about quartz system, could you describe a bit way to create it in windowless mode vs windowed, so we can think about a test case?
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #6 from Jason jasonwinter@hotmail.com --- Hi Nikolay,
It's actually non-trivial to set something like this up for a test case.
This link explains the VMR9 (and 7) differences from the normal renderer:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd407299%28v=vs.85%...
(Note the comment: when the VMR is in windowless mode, it does not even expose the IVideoWindow interface, which is no longer needed. I'm not sure Wine hides the interface, as it should. This may be important, since many programs that work with different renderers run through a list of interfaces to set various things, so obtaining this interface when it's in the wrong mode may cause [more] unexpected things to happen.)
There is also a VMR9 Windowless sample in the Direct Show area of the Windows SDK:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd390982%28v=vs.85%...
When I was coding with this stuff (10 years ago now) I used a few audioless .mpg files (you've got to have something to show in the video window) and as few filter objects as I could (trying to use the auto connect feature of quartz to find what's needed in the graph to show the video).
I do remember using that sample though, it helped a lot.
As for tests, I would use a timer to trigger the API calls I've pointed out (so it can all be done without focus) so you can tell what Windows and Wine do differently in this case.
I'd also search the Wine codebase (as I did, as well as my own) so you can see just how many places use SWP_NOZORDER and SWP_NOACTIVATE together. I was surprised that most of my own code and much of Wine uses the flags together, except in vmr9.c where I'm getting so many problems.
Best regards, Jason.
https://bugs.winehq.org/show_bug.cgi?id=38765
--- Comment #7 from Jason jasonwinter@hotmail.com ---
Now, if only sound and video playback was smooth it would all be perfect.
Well, I can't get it smooth in VirtualBox no matter what I do (but nor can I get USB2 DVB-T TV tuners to deliver their TS streaming data without corruptions, even by rebuilding V.Box and setting its Windows priority to Real-Time... Yep, I've jumped through *all* the hoops now... Anyone in the know, just try and alter the priority of a running, hardened, V.Box instance!)
I have had success with Wine on "real hardware" in altering start and end timestamps of samples to -1 after an audio decoder codec in Direct Show has decoded audio into WAV format being passed to the Wine audio renderer. I assume in this mode (looking at the code) Wine doesn't attempt to fix any issues, which causes smoothness issues in playback.
Luckily, I already drop audio to keep sync. since I don't rely on Windows-DX to do so. It's not perfect, but most of the time it's Ok. There's still some tearing in the VMR9 video presentation, on real hardware, despite me using the video refresh signals from DX to coordinate frame painting.
I don't seem to get any fix-me's with the video-retrace interrupt tests... Is that implemented properly? I've not looked... Video tearing is a minor issue. Though it is annoying, given the work I've done to prevent it. :)
https://bugs.winehq.org/show_bug.cgi?id=38765
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
https://bugs.winehq.org/show_bug.cgi?id=38765
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- I think this is a duplicate of bug 10440.
*** This bug has been marked as a duplicate of bug 10440 ***
https://bugs.winehq.org/show_bug.cgi?id=38765
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Duplicate
-
wine-bugs＠winehq.org -
WineHQ Bugzilla