[PATCH v3 2/6] user32: Implement GetRegisteredRawInputDevices.

[Rémi Bernon]

On 2020-07-03 15:48, Rémi Bernon wrote:
> On 2020-07-03 15:32, Francois Gouget wrote:
>> On Fri, 3 Jul 2020, Rémi Bernon wrote:
>> [...]
>>> Ah indeed, I thought I could add more arguments to run them all.
>>>
>>> The monitor test causes a Xephyr segmentation fault locally, but the 
>>> msg test
>>> seems to run fine. I wonder if it could be snowballing from the 
>>> monitor test.
>>
>> I don't see X error messages in the "full task log". But if X segfaulted
>> directly that would probably not be visible there.
>>
>> I never tested it but if X segfaults I suspect we'd get back to the
>> chooser which should reconnect the default user after the standard
>> timeout (<30 seconds) and the tests are likely to continue running in
>> the meantime. It's possible they could be stuck while X is restarting
>> which could explain the string of timeouts.
>>
>> It may be possible to test for this condition by starting an independent
>> windows process displaying a window in an early test
>> (CreateProcess("clock.exe")?) and checking the final screenshot to see
>> if that window is still there.
>>
> 
> I cancelled the remaining tests as it was taking way too long to 
> timeout. I'm also investigating the monitor test, as the other tests run 
> fine separately (at least msg, as shown here: 
> https://testbot.winehq.org/JobDetails.pl?Key=74749). My local Xephyr 
> crash seems actually unrelated (sadly).

It looks like that applying the mode changes by calling

   ChangeDisplaySettingsExA(NULL ...)

sometimes takes an unusually long time, up to ~100s for a single mode 
change for instance, as shown here:

https://testbot.winehq.org/JobDetails.pl?Key=74774&f101=win32.report#k101

With all the modes being iterated, it's no wonder that it ends up timing 
out. I think that it may be possible that the timeout then causes 
additional issues, if the process is killed during the mode change?
-- 
Rémi Bernon <rbernon at codeweavers.com>