On Tue Aug 22 06:34:49 2023 +0000, Stefan Dösinger wrote:
I'm kind of unhappy about these windowing patches. I know that this is
blocking us from turning on d3d tests in the CI, and I agree that's a bad thing. On the other hand, I don't like the way these are working around the failures, because they're *not* working around them—they're crippling the tests. We have been nitpicking around a hand full of test failures for years. Be it on Windows or Wine. While we bother about 5 failing ok lines 158636 (number from the final device.ok output) are staying unused. By delaying enabling the tests on a CI machine that matters for future patches more broken tests will be added and the problem moves on. I don't care how we take care of those handful of failing tests. As you say, my patch changes the test to work around fvwm bugs but, as much as possible, keeping the essence of what we want tested. I am fine to do any of the others:
- Remove the tests
- Mark them flaky
- todo_wine_if(fail) ok(!fail) everything
- Switch fvwm to click to focus. Afaics that eliminates most of the
difference to how Windows behaves, but it won't change its inability to handle mode switches.
- Run them in a virtual desktop
- Switch to KDE (that once passed, but with KDE updates different
failures were introduced. I found kde / kwin the most sensible WM when I wrote those windowing tests) But whatever choice, I think we want the other good 158k tests enabled this month, not next year. Now re switching to some other WM, last time I proposed this a lot of user32 tests were failing elsewhere because the user32 tests were written to make Alexandre's fvwm2 happy. Not something that makes me happy, but keeping Alexandre's preferred WM in his preferred settings is the path of least resistence. I'll reply to the more detailed technical questions separately.
One more option I can think of: Move every test that changes modes to a new file, e.g. d3d9/tests/modeset.c, skip it on gitlab and enable the rest.