> The last thing the X11 server sends is: > > 113.10: Client 1 --> 24 bytes > ............REQUEST: ConvertSelection > requestor: WIN 03c00b9b <--- qemu window > selection: <CLIPBOARD> > target: ATM 00000201 > property: ATM 00000185 > time: TIM 1b3500de > > However, the clipboard owner is an entity inside the guest (due to > ssh -X) and it can never reply because the guest is paused. > > So the GTK waits until IDLE_ABORT_TIME, i.e. 30 iterations of > gtk_selection_retrieval_timeout (1000 ms). > > I'm not familiar with the gtk code, but I understand from the > documentation that we would want to use gtk_clipboard_request_contents, > which allows for a callback when the text is actually available (i.e., > the clipboard owner has eventually replied). > > Naively, I'm thinking we could replace gd_clipboard_request with > gtk_clipboard_request_contents and pass qemu_clipboard_set_data as the > callback. But I haven't experimented with it. Let me know if any of this > makes sense and I could give it a shot.
That goes into the right direction. Replace the blocking calls with callback versions. It probably wouldn't be *that* simple though. I think you need additional state tracking so you can deal with corner cases like clipboard changes happening between gtk_clipboard_request_contents() call and the callback being called. take care, Gerd