-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Nov 23, 2016 at 10:53:27PM -0500, Jean-Philippe Ouellet wrote: > On Wed, Nov 23, 2016 at 7:47 PM, HW42 <[email protected]> wrote: > > Marek Marczykowski-Górecki: > >> Maybe, that could be combined with some dedicated indicator about that > >> clipboard in general - like from which VM the current content is? > >> But still the UX would be inconsistent... > > May be desirable even out of context of this proposal, idk. > > >>> I'd like to solve this cleanly if possible. > > > > Another option is to take Jean-Philippe's original approach a little > > step further. Have a single process running in dom0 which binds to > > Ctrl-Shift-{C,V}. > > > > On a key event the focused VM is determined (like you suggested [0]) > > and the request is passed into a queue. > > > > Another thread reads from this queue. On a copy request it calls > > qubes.GetClipboard on the VM (with a timeout of maybe 1 s); saves the > > response and shows a notification. On a paste request it calls > > qubes.SetClipboard on the VM with the clipboard data (also with a short > > timeout). > > > > The rpc services are simple 'xclip' one liners. > > > > This should be much simpler and if I'm not mistaken should ensure the > > correct ordering of the requests and the correct VM association. > > Seems correct at first to me too, but I will sit on this and try to > convince myself more strongly before agreeing.
Ok, my turn ;) Consider quickly pressing Ctrl+Shift+V, then Ctrl+V - something I think happen very often. If those two will be handled asynchronously, there is no guarantee for actual ordering. And if Ctrl+Shift+V will involve calling some qrexec service, it will be slower than Ctrl+V. Result: quick Ctrl+Shift+V, then Ctrl+V will not work anymore. Actually we have considered something very similar before. Clipboard operations for Windows VMs are handled using qrexec calls. But exactly for the above reason, we've kept calling it still in gui-daemon and handle it synchronously (wait for qrexec service completion, before processing any further events). Generally, I think if different key combinations will be handled by different processes asynchronously, then there will also be some place for race condition. Alternative, less risky, but also less elegant solutions I see: 1. Intercept all the keys, filter them in one place and release (if desired) for original application after processing special action. This way order of events will be preserved. But this will also introduce single point of failure, or at least bottleneck for input events. Technically, I believe it can be done at X11 API level (maybe using XGrabKeyboard?), but will not be easy. 2. Asynchronously handle Ctrl+Shift+C from dom0, _without_ intercepting it. So gui-daemon (or any other application) will receive it as before. But then handling application will need to check if any gui-daemon have handled it (check current focus and check xevent counter stored besides clipboard file). This is also not ideal, because still is racy (Ctrl+Shift+C in dom0 and Ctrl+Shift+V in VM can be reordered), but I think the risk of such race is somehow smaller - user needs to change focus in between, so there is more time in between. The other downside of this approach is that non-gui-daemon application will also receive Ctrl+Shift+C, so in practice it will trigger two actions at the same time: one from original application, and clipboard-copy-from-dom0. In undefined order. I don't like neither of those... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYNu7oAAoJENuP0xzK19csgzQH/0HtD9FR+vlMWsH7IwEtloxe /qmCi3pldZ8bjtpwlLQv9xt0Zmx7PV/eNdlQTIHiEwByYQyH6yAmr5Sl37OtvDsA 4H6Ru8rdSyICk/u5blwvnyL+wdaKMeDCXPR9urwU3sIAyWHHL59ci17gaivAfrGc xhF68+ZCwy0yUApnuH7u4YvGYKnQLMcONM051os6vDM2Xpj5Zn2vIuVmDDL7rHUS 4VWoT30/E9QNMmy3moBbrl4iiPZJRstNIoQ/MFyumxPegOhUR9gsXNTLEQL3y5hs gLSjJCn1xolkJtQH3gwvKluj7Jyt+MhEao05oG1EAMkh+7Ue0pf2fjZsZCtJ9sE= =fe4z -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161124134511.GS1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
