You can probably replace current with foreground in queue_keyboard_message, similarly in queue_mouse_message.
So, that's one instance of `current`, the other is more hidden `send_hook_ll_message(...) -> get_first_global_hook(id) -> get_global_hooks(current)`. Perhaps we can also change this to `get_first_global_hook(thread, id) -> get_global_hooks(thread)` and also pass foreground?
I am not familiar with all the interactions and assumptions in this part of the code. Is it safe to use `foreground` in these cases? Can it happen in practice that `foreground->process != current->process` (for the first case) or `foreground->desktop != current->desktop` (for the second)?
Idk, the request looks good as it is. Is there any concern about keeping it like this?
No concerns, I was just considering what options we have to best integrate with `SPI_(GET|SET)KEYBOARD(SPEED|DELAY)`. The request works fine otherwise, and for the GET part I can change the request to return the current values, so `GET => set_keyboard_repeat(-1, -1, -1) => (enable, delay, period)`, and then map these to the SPI values in a best effort manner (e.g., based on your formulas, and similarly for SET). An alternative would be to express the request in terms of the more limited SPI values, but I think I'd rather keep the higher granularity.