acme on wayland via Xwayland

[Henry Donnay]

Hello,

I've got my Linux desktop on a relatively bleeding edge distribution
(Fedora 33) and run using wayland. This works well for me except for
plan9port programs that warp the pointer, namely acme.

Xwayland has limited pointer warping support: the X-side pointer can
be warped, but this change is never communicated to the user's pointer
at the wayland level (there's no "good" way to do that, and Xwayland
doesn't even do the bad ways). This means there's the jarring
experience of repeated mouse actions doing what one would expect (e.g.
repeated M3's will keep searching and the selection changing) but the
visible pointer stays in one spot and X-side pointer effectively warps
to to the visible pointer when the latter moves.

It seems like the only course of action with a chance of getting
things to behave correctly (short of not using wayland) is to port
devdraw to wayland and see if the dirty hacks to do pointer warping
will work. Does anyone know of any efforts along these lines or have
any pearls of wisdom on where to start?

[Ethan Gardener]

On Thu, Jan 7, 2021, at 7:52 PM, Henry Donnay wrote:
>
> Xwayland has limited pointer warping support: the X-side pointer can
> be warped, but this change is never communicated to the user's pointer
> at the wayland level (there's no "good" way to do that, and Xwayland
> doesn't even do the bad ways).

Please excuse my noise, but I have to express my astonishment here. I've used systems besides Plan 9 which relied on pointer warping for efficient practical operation. Does Wayland really implement it so poorly? Does it actually try to disallow it? I guess it's another reason to be happy I ditched the whole POSIX shebang a few years ago.

[Dave MacFarlane]

My understanding of Wayland's architecture is that it's designed such that windows don't know anything about what's going on outside of them. Warping to an absolute coordinate on the screen shouldn't be possible but warping to a location within your own window shouldn't be a problem.

(But my knowledge of wayland is limited to a few days I spent trying to learn enough about it to write a drawterm backend that I never finished, I'm no expert..)

--
- Dave

[Henry Donnay]

I messed up in the gmail UI, so resending to the list.
Sorry Dave.

On Thu, Jan 7, 2021 at 3:55 PM Dave MacFarlane <dri...@gmail.com> wrote:
> My understanding of Wayland's architecture is that it's designed such that windows don't know anything about what's going on outside of them. Warping to an absolute coordinate on the screen shouldn't be possible but warping to a location within your own window shouldn't be a problem.

From my reading, this is mostly correct. Basically, input "flows" one
way from the kernel, into the compositor, then into the program
attached to the focused surface.

There's no (conceptual) problem in the wayland model for a program to
move the pointer around in its own surface, but wayland is implemented
as a pile of extensions onto a protocol that's implemented by a
compositor.
So in order for this to actually work, one would need to design a
protocol to ask the compositor to move the pointer and have enough
compositor authors interested in implementing the extension, which
perhaps explains why this doesn't exist.

For some more context:

The "bad way" to do it I think I found is to use an unstable protocol
(this one: https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml)
to, whenever devdraw is asked to move the pointer, lock the pointer,
warp it, and unlock it.
As far as I can tell from mailing list discussions, this is meant for
games and other things that want to render their own pointer, but have
the compositor's cursor at the correct place when focus changes.

There's also the matter of "how does a remote desktop work?"
It seems like using some RPCs via d-bus to create new input devices
and then ask the compositor to allow access to its surface.
This is clever but not particularly helpful in the case of "I'd like
to move the compositor's pointer."

[Ethan Gardener]

I see, thank you. So it could be done with the right publicity, but it would take a while for all the compositor authors to catch up... assuming you can get people to accept that you've done a good job without holding the protocol in an unstable state for a long time for contributions.