My new adventure at Collabora involves Wayland, like all the cool kids. I was distraught to learn that, since Wayland only provides clients with pointer position information to the surface currently under the pointer, and only relative to that surface, xeyes no longer works. We’ll see about that…
Watch a phone-cam video of the eyes in action ((with unintentional soundtrack by Marco, Jo and Daniel)) in your choice of WebM or freedom-hating H.264! (I apologise for the shakes, but it yielded smoother results than the GNOME Shell screencast thing.)
The pointer’s position is provided to clients which request it, relative to a surface of their choosing. Thanks to the way surface transformations work in Weston, the eyes still work when rotated without any further effort:
Ready for the desktop!
Joking aside, I don’t really expect my branch to be merged any time soon, not least because it’s very much a proof-of-concept and is pretty easy to break. But it was a useful exercise in learning my way around the Wayland and Weston code-bases. The work involved was actually pretty small in the end:
- Implement a pair of eyes which only work when the cursor is over them;
- Define a protocol extension allowing clients to ask to track the pointer position relative to a surface;
- Plumb it into the compositor and client.
Now onto something a little more useful…
“I apologise for the shakes, but it yielded smoother results than the GNOME Shell screencast thing.”
We fixed that in 3.4 i.e should be much smoother there.
Good to hear!
It’s a good sign that xeyes don’t work.
Wayland seems to have implemented a gui isolation which will stop keylogging (by background user processes; root can most probably continue keylogging).
@alk: AFAIK this isn’t true:
1) Wayland doesn’t really prevent keylogging
2) to the opposite Wayland’s decision to use ‘client side decoration’ allow a malicious client to create a fully transparent window covering the full screen to get all the input events..