ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<krathul[m]>
I'm trying to simulate mouse events using evdev, but when I give I ask it to move by certain units, say EV_REL, REL_X, 100. It doesn't actually move 100 pixels horizontally right on the screen.
<krathul[m]>
I beleive it might be because of some transformation to screen coordinates. But how do I do it precisely?
<krathul[m]>
Is this specific to a compositor?
cwegener has joined #wayland
<pq>
krathul[m], relative motion is always subject to acceleration etc. and the units are not pixels at evdev level I think. The behaviour depends on libinput and how each compositor configures libinput. If you want to drive a GUI with fake input instead of actually simulate a mouse, maybe using absolute coordinates helps.
<pq>
There is also libei that might be more appropriate if the compositor integrates with libeis.
cmichael has joined #wayland
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
kts has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
privacy has quit [Quit: Leaving]
fmuellner has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<krathul[m]>
pq: so if I create a fake touchpad device to do that, are absolute coordinates directly interpreted as screen coordinates?
<pq>
touchpad is still a relative pointing device, even if it is absolute in hardware. You'd need more like a touchscreen, but as a pointer device.
<pq>
IIRC libinput relies of udev rules to classify evdev devices as pointer, touchscreen, etc.
<pq>
pointer with absolute motion is a bit strange, until you consider virtual machine viewer applications, where relative motion events would have the same problems as you have.
<pq>
unfortunately I don't really know any details
kts has joined #wayland
naemi has joined #wayland
<naemi>
Hi, is there a way to force a cursor animation from OS-level tools? e.g. I want to force a spinning/loading cursor while a script is running
<pq>
Not in Wayland, no. There must be an application with an open window, and the pointer on the window for the app to be able to control the cursor.
<pq>
maybe notifications would be better?
<emersion>
if you really want to change the cursor, the right way to do it would probably be via a new osc
<pq>
that also would work only while the pointer is over the terminal
<emersion>
indeed
<emersion>
oh hey, this even exists already
<emersion>
OSC 22 ; <name> BEL
nerdopolis has joined #wayland
kts has quit [Ping timeout: 480 seconds]
andreasbackx has joined #wayland
kts has joined #wayland
<pq>
swick[m], zamundaaa[m], a bit of an issue with turning the "create" requests into destrcutors: how do we send protocol errors from it now?
<zamundaaa[m]>
Does sending them before destruction not work?
<zamundaaa[m]>
Compositor side destruction I mean
<pq>
the object is already gone client-side, so...
<pq>
at most the client has a zombie
<pq>
so I *think* it would look like a protocol error originating from an unknown object
<zamundaaa[m]>
Gimme a few minutes, I'll just test it
<pq>
hmm, maybe it does work...
<pq>
but that may also be just an artifact of the libwayland-client implementation?
<pq>
yeah, libwayland-client registers the error, but has no idea what interface it's from
<pq>
that makes testing for the correct protocol errors awkward
<pq>
OTOH... is this anything new - clients could always, they do too, explicitly destroy the object after sending a request that triggers a protocol error.
mvlad has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
calcul0n has quit [Read error: No route to host]
calcul0n has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
<pq>
zamundaaa[m], swick[m], ok, I think sending the error in destructor is fine. On client side it is indistinguishable from the client sending two requests in a burst, where first triggers a protocol error and the latter destroys the object. So it's all business as usual. Just the client has no clue what object generated the error, but the human-readable error message is still there.
<pq>
and error code is there, though without knowing the interface it cannot be deciphered