On 3/5/21 6:10 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
On 3/5/21 6:03 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
@@ -237,6 +238,34 @@ static NTSTATUS copy_packet_into_buffer(HID_XFER_PACKET *packet, BYTE* buffer, U return STATUS_BUFFER_OVERFLOW; } +static void HID_Device_sendRawInput(DEVICE_OBJECT *device, HID_XFER_PACKET *packet) +{
- BASE_DEVICE_EXTENSION *ext = device->DeviceExtension;
- UCHAR report_id;
- SERVER_START_REQ(send_hardware_message)
- {
req->win = 0;
req->flags = 0;
req->input.type = HW_INPUT_HID;
req->input.hid.usage_page = ext->preparseData->caps.UsagePage;
req->input.hid.usage = ext->preparseData->caps.Usage;
req->input.hid.length = 0;
if (!(report_id = ext->preparseData->reports[0].reportID))
{
wine_server_add_data(req, &report_id, sizeof(report_id));
req->input.hid.length++;
}
wine_server_add_data(req, packet->reportBuffer, packet->reportBufferLen);
req->input.hid.length += packet->reportBufferLen;
wine_server_call(req);
- }
- SERVER_END_REQ;
+}
It would be better to find a way to do this using exported APIs. I don't think we want to have even more modules make direct server calls (the goal is for all server calls to be done on the Unix side of the syscall interface).
Alright, does it include __wine_send_input?
At least for now that would be better, yes.
About that, is there any known use of INPUT_HARDWARE / HARDWAREINPUT type? I tried a few SendInput combination on Windows and it doesn't seem to have any effect.
On Wine it looks like it's plugged and able send fake Wine hardware messages, but it doesn't seem to be tested anywhere, or really used anywhere.
Would it be appropriate to use this structure to send HID rawinput message then? Maybe disable its support from SendInput and only allow it from __wine_send_input?
The INPUT structure doesn't have any explicit variable size member, but SendInput has a size parameter, so I guess we can keep any additional data internally.