[PATCH 4/7] user32: Implement GetRegisteredRawInputDevices

[Francois Gouget]

On Tue, 27 Aug 2019, Rémi Bernon wrote:
[...]
> > === debian10 (32 bit report) ===
> > 
> > user32:
> > msg.c:5145: Test succeeded inside todo block:
> > ShowWindow(SW_SHOWMINIMIZED):overlapped: marked "todo_wine" but succeeds
> > 
> > Report errors:
> > user32:msg prints too much data (35221 bytes)
[...]
> I don't see how this is related. Also, it looks like from the full logs that
> the test is actually failing but is reported as succeeding inside todo, which
> is weird.

There are two issues:
* The "too much data" one is not related to your patch specifically. 
  It's an error that gets added by the TestBot on tests that print 
  too much data, such as user32:msg has been doing for a long time.

  The issue there is that on Linux the WineTest results are already very 
  close to the 1.5 MB limit. With over 600 tests that's about 2.5 KB / 
  test. So tests that print over 32 KB are taking way more than their 
  fair share and get identified as such in the hope that we at least not 
  introduce new hogs and hopefully eventually fix the existing ones 
  (hint, hint).

* The second issue is that if an ok() call succeeds in a todo_wine then that 
  todo_wine should be removed. So the patch is wrong and needs to be 
  fixed. Of course if the specific ok() call fails randomly then... I 
  guess the test needs to be fixed again so back to square one. It does 
  become a real problem when the failure depends on the Unix platform 
  though.

  This specific ShowWindow(SW_SHOWMINIMIZED) ok() call seems to fail 
  pretty systematically and as such should have been treated as a 
  preexisting failure. However it looks like a full WineTest run has not 
  been done since the 23rd, which typically happens when the official 
  WineTest.exe fails to build. Maybe that's why the failure was not 
  detected as a preexisting one.

  (Removing the TestBot's dependency on this external WineTest.exe build 
  is on my todo list)


> When testing on my side the user32 msg tests are triggering a crash in mutter,
> but work fine with openbox (and do not report any failure for this patch).
> Wouldn't it be better to use openbox - or any other WM that doesn't crash
> spuriously - for the automated regression tests?

The Debian TestBot VMs use fvwm precisely because neither the GNOME nor 
the KDE window managers are up to the task (they not only used to crash 
but also mishandled various test cases).

I don't see any evidence that fvwm crashed in the logs and the 
screenshot looks normal barring the tiny window in the top-left corner 
(but that might be a left-over from the test, maybe due to the 
failures?). I'm not a specialist on these things so maybe I missed the 
telltale signs.

Note that the screen being blank is normal, it's a very basic fvwm 
configuration. I guess it can be confusing and does make it harder to 
see if the window manager crashed. Maybe the TestBot should put up a 
window saying 'This screen intentionally left blank' ;-)

-- 
Francois Gouget <fgouget at codeweavers.com>