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...
It looks complicated... :)
Frankly, is there really a need for such thing ? For the last year or so
I've been using Qubes I had to copy/paste from dom0 to VMs only a few times.
Granted, the qvm-run --pass-io command line stuff is a bit convoluted
for new users who want to publish a HCL report or send some debugging
info, but what is the problem of simply easing the process while keeping
it simple ? Something like:
- select something in dom0 and copy it to the clipboard (ctrl-c, right
click/copy, ...) like you would do in any VM
- use a specific shortcut (*not* ctrl-shift-v), or a tray button, or a
menu entry, ..., to send the content of the clipboard to a given VM
(would require a popup list to choose the VM). A terminal command in
dom0 could trigger it too.
- ctrl-v / paste in the chosen vm.
Or am I missing something ?
Ivan
- --
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/7a1af455-7c0c-dbd0-55d7-fdbf207a6584%40c3i.bg.
For more options, visit https://groups.google.com/d/optout.
