[PATCH v2 1/6] ntoskrnl.exe/tests: Silent a todo_wine failing test after a while.
Zebediah Figura (she/her)
zfigura at codeweavers.com
Thu Jun 3 10:52:43 CDT 2021
On 6/3/21 10:50 AM, Rémi Bernon wrote:
> On 6/3/21 5:44 PM, Zebediah Figura (she/her) wrote:
>> On 6/3/21 10:42 AM, Rémi Bernon wrote:
>>> On 6/3/21 5:40 PM, Zebediah Figura (she/her) wrote:
>>>> On 6/3/21 7:55 AM, Rémi Bernon wrote:
>>>>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>>>>> ---
>>>>>
>>>>> v2: * Fix spurious failures first.
>>>>>
>>>>> * Don't try NULL preparsed data, it crashes old windows versions.
>>>>>
>>>>> * Squash new HidP_Get*Caps tests together, add a few more with
>>>>> specific caps lookup.
>>>>>
>>>>> dlls/ntoskrnl.exe/tests/driver_hid.c | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/dlls/ntoskrnl.exe/tests/driver_hid.c
>>>>> b/dlls/ntoskrnl.exe/tests/driver_hid.c
>>>>> index 44ec1b09526..79b3e708752 100644
>>>>> --- a/dlls/ntoskrnl.exe/tests/driver_hid.c
>>>>> +++ b/dlls/ntoskrnl.exe/tests/driver_hid.c
>>>>> @@ -103,6 +103,7 @@ static const unsigned char report_descriptor[] =
>>>>> static NTSTATUS WINAPI driver_internal_ioctl(DEVICE_OBJECT *device,
>>>>> IRP *irp)
>>>>> {
>>>>> + static int test_failed = 0;
>>>>> IO_STACK_LOCATION *stack = IoGetCurrentIrpStackLocation(irp);
>>>>> const ULONG in_size =
>>>>> stack->Parameters.DeviceIoControl.InputBufferLength;
>>>>> const ULONG out_size =
>>>>> stack->Parameters.DeviceIoControl.OutputBufferLength;
>>>>> @@ -176,7 +177,7 @@ static NTSTATUS WINAPI
>>>>> driver_internal_ioctl(DEVICE_OBJECT *device, IRP *irp)
>>>>> case IOCTL_HID_READ_REPORT:
>>>>> ok(!in_size, "got input size %u\n", in_size);
>>>>> - todo_wine ok(out_size == 2, "got output size %u\n",
>>>>> out_size);
>>>>> + if (test_failed++ < 10) todo_wine ok(out_size == 2, "got
>>>>> output size %u\n", out_size);
>>>>> ret = STATUS_NOT_IMPLEMENTED;
>>>>> break;
>>>>>
>>>>
>>>> Does this test fail on Windows? Can you provide a link to the test
>>>> results?
>>>>
>>>
>>> It's not failing on windows, but the todo_wine are spamming the test
>>> results, making the test be reported as failing because too much data is
>>> printed.
>>>
>>
>> Shame on me for introducing that test and never fixing it, but maybe we
>> could just fix it the right way instead?
>>
>
> Yes but it's a little bit more complicated than it seems, and I'm a bit
> afraid of the possible unforeseen consequences.
>
> There's apparently several ways to request reports (in polled and
> non-polled modes for instance). and I couldn't test the
> IOCTL_HID_GET_INPUT_REPORT way yet for instance, I don't know if it
> passes a packet with the full report length, including 0 report id or if
> it uses a different length depending on when report ids are used or not.
>
> Also in winebus.sys, both ways are handled by deliver_last_report, which
> expects a full report.
>
> Then there's the question whether reading hidraw devices give us full
> reports or not, which I haven't investigated yet.
>
> I'm perfectly fine with leaving the test unfixed for now, and have the
> spurious failures, it just looked bad for my additional tests ;)
>
Okay, I guess I'm fine with it too, I might recommend really only
incrementing test_failure on failure, though, and maybe there's no
reason to set the limit at 10 instead of 1.
More information about the wine-devel
mailing list