[PATCH v3 2/6] user32: Implement GetRegisteredRawInputDevices.
rbernon at codeweavers.com
Fri Jul 3 10:05:17 CDT 2020
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
sometimes takes an unusually long time, up to ~100s for a single mode
change for instance, as shown here:
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>
More information about the wine-devel