[PATCH 4/5] user32: Implement GetRawInputBuffer.

Alexandre Julliard julliard at winehq.org
Tue Jun 30 06:17:55 CDT 2020


Rémi Bernon <rbernon at codeweavers.com> writes:

> 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.

Sure, if it's going to be variable-size then we have to do something
like this.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list