[PATCH 4/5] user32: Implement GetRawInputBuffer.

[Rémi Bernon]

On 2020-06-30 10:33, Rémi Bernon wrote:
> On 2020-06-30 10:24, Alexandre Julliard wrote:
>> Rémi Bernon <rbernon at codeweavers.com> writes:
>>
>>> +DECL_HANDLER(get_rawinput_buffer)
>>> +{
>>> +    struct thread_input *input = current->queue->input;
>>> +    data_size_t size = 0, next_size = 0;
>>> +    struct list *ptr;
>>> +    char *buf, *cur;
>>> +    int count = 0;
>>> +
>>> +    if (!req->buffer_size) buf = NULL;
>>> +    else if (!(buf = mem_alloc( get_reply_max_size() )))
>>> +        return;
>>> +
>>> +    cur = buf;
>>> +    ptr = list_head( &input->msg_list );
>>> +    while (ptr)
>>> +    {
>>> +        struct message *msg = LIST_ENTRY( ptr, struct message, entry );
>>> +        struct hardware_msg_data *data = msg->data;
>>> +
>>> +        ptr = list_next( &input->msg_list, ptr );
>>> +        if (msg->msg != WM_INPUT) continue;
>>> +
>>> +        next_size = req->rawinput_size;
>>> +        if (size + next_size > req->buffer_size) break;
>>> +        if (cur + sizeof(*data) > buf + get_reply_max_size()) break;
>>> +
>>> +        memcpy(cur, data, sizeof(*data));
>>> +        list_remove( &msg->entry );
>>> +        free_message( msg );
>>> +
>>> +        size += next_size;
>>> +        cur += sizeof(*data);
>>> +        count++;
>>> +    }
>>> +
>>> +    reply->next_size = next_size;
>>> +    reply->count = count;
>>> +    set_reply_data_ptr( buf, cur - buf );
>>> +}
>>
>> Since you are simply returning an array of hardware_msg_data it would be
>> better to code it that way, using appropriate types instead of char* and
>> explicit sizes. Also it seems the server shouldn't need to worry about
>> the size of the client-side structures.
>>
> 
> Indeed, I should have indicated that somewhere, but I wrote that with 
> some future changes in mind. I intend to send some additional patches to 
> implement HID rawinput (for gamepad input, required to support 
> DualShock4 on some games), where the HID report is stored as a variable 
> sized data in the hardware_msg_data.
> 
> So it could be done with fixed size data here, and the variable size 
> added later but it'd also be more change.

Regarding the client-side structure size, the server has to know how 
much messages it can remove depending on the client buffer size and 
RAWINPUT structure size, and leave the rest in the queue. Otherwise 
there's a possibility of removing too much messages (or too little).

And given that the messages will eventually be variable sized, it will 
not be possible to compute it on the client size.
-- 
Rémi Bernon <rbernon at codeweavers.com>