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

[Rémi Bernon]

On 2020-07-03 17:05, Rémi Bernon wrote:
> 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?

So it all ends up being this call in xrandr12_set_current_mode:

>     status = pXRRSetCrtcConfig( gdi_display, resources, resources->crtcs[primary_crtc],
>                                 CurrentTime, crtc_info->x, crtc_info->y, xrandr12_modes[mode],
>                                 crtc_info->rotation, crtc_info->outputs, crtc_info->noutput );

that sometimes take ~100s. I can see it consistently in the Win32 tests, 
when it restores the modes (although it's already in the correct mode), 
but I disabled the individual mode tests to reduce the test timeouts, so 
it may also happen in the other archs with the whole test.

I'm not sure what to do about it...
-- 
Rémi Bernon <rbernon at codeweavers.com>