Rémi Bernon rbernon@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@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.