On Wed, 8 Oct 2014, Stefan Dösinger wrote: [...]
There are many more failures in d3d8:device when the test is not in foreground. Those failures write static lines and I'd prefer the testbot to be changed to run them in foreground instead.
What do you mean by that?
The TestBot runs a command line tool in an iconized console. In turn that tool runs the test binary. However I'm not aware of it preventing test windows from being in the foreground.
Maybe the console windows being iconized somehow gets inherited by the windows created by the test binary, but shouldn't the test just request to bring its windows to the foreground?
On 10 October 2014 08:28, Francois Gouget fgouget@codeweavers.com wrote:
On Wed, 8 Oct 2014, Stefan Dösinger wrote: [...]
There are many more failures in d3d8:device when the test is not in foreground. Those failures write static lines and I'd prefer the testbot to be changed to run them in foreground instead.
What do you mean by that?
The TestBot runs a command line tool in an iconized console. In turn that tool runs the test binary. However I'm not aware of it preventing test windows from being in the foreground.
Maybe the console windows being iconized somehow gets inherited by the windows created by the test binary, but shouldn't the test just request to bring its windows to the foreground?
The way I understand it is roughly that the foreground process is the process that either last received user input, or was launched by the foreground process, and that SetForegroundWindow() mostly just works for the foreground process. It may help if the console window isn't iconized. It's interesting that creating a fullscreen d3d9 device apparently makes us the foreground process, but it's probably not something we can do ourselves from the test in the general case.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I accidentally sent this to Francois only earlier today. Re-sending to wine-devel.
Am 2014-10-10 08:28, schrieb Francois Gouget:
On Wed, 8 Oct 2014, Stefan Dösinger wrote: [...]
There are many more failures in d3d8:device when the test is not in foreground. Those failures write static lines and I'd prefer the testbot to be changed to run them in foreground instead.
What do you mean by that?
The d3d8:device test failures on the w8 testbot, e.g. here http://testbot.winehq.org/JobDetails.pl?Key=9361 . For some reason there are no win8 results for this test on test.winehq.org.
VMs prior to Win8 do not have those failures because they fail device creation.
The TestBot runs a command line tool in an iconized console. In turn that tool runs the test binary. However I'm not aware of it preventing test windows from being in the foreground.
Out of curiosity, why is the console iconized?
Maybe the console windows being iconized somehow gets inherited by the windows created by the test binary, but shouldn't the test just request to bring its windows to the foreground?
They try: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/d3d8/tests/device.c#l2...
This call fails, which later on (2243) leads to a skip, as can be seen on e.g. this testbot result here: http://test.winehq.org/data/a71f25d239ed7dd65f9fa7a3b7baa371e74f2ec9/win7_ne...