06:42 wlb: wayland-protocols Issue #177 opened by i509VCB (i509VCB) xdg_shell: xdg_positioner.set_constraint_adjustment does not specify bitflag enum type of `constraint_adjustment` argument https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/177
09:24 krathul[m]: Hi
09:24 bittin: hey
09:29 krathul[m]: This is abou libinput I believe.
09:29 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.
09:29 krathul[m]: I beleive it might be because of some transformation to screen coordinates. But how do I do it precisely?
09:30 krathul[m]: Is this specific to a compositor?
10:08 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.
10:09 pq: There is also libei that might be more appropriate if the compositor integrates with libeis.
12:40 krathul[m]: pq: so if I create a fake touchpad device to do that, are absolute coordinates directly interpreted as screen coordinates?
12:42 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.
12:43 pq: IIRC libinput relies of udev rules to classify evdev devices as pointer, touchscreen, etc.
12:45 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.
12:45 pq: unfortunately I don't really know any details
12:59 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
13:11 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.
13:11 pq: maybe notifications would be better?
13:12 emersion: if you really want to change the cursor, the right way to do it would probably be via a new osc
13:12 pq: that also would work only while the pointer is over the terminal
13:12 emersion: indeed
13:13 emersion: oh hey, this even exists already
13:13 emersion: OSC 22 ; <name> BEL
13:31 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?
13:32 zamundaaa[m]: Does sending them before destruction not work?
13:33 zamundaaa[m]: Compositor side destruction I mean
13:33 pq: the object is already gone client-side, so...
13:33 pq: at most the client has a zombie
13:34 pq: so I *think* it would look like a protocol error originating from an unknown object
13:34 zamundaaa[m]: Gimme a few minutes, I'll just test it
13:36 pq: hmm, maybe it does work...
13:37 pq: but that may also be just an artifact of the libwayland-client implementation?
13:42 pq: yeah, libwayland-client registers the error, but has no idea what interface it's from
13:43 pq: that makes testing for the correct protocol errors awkward
13:50 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.
14:27 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.
14:27 pq: and error code is there, though without knowing the interface it cannot be deciphered
14:30 zamundaaa[m]: Sounds fine to me
15:08 wlb: wayland Issue #441 opened by Nick Yamane (nickdiego) Specify keyboard focus/behavior during drag sessions https://gitlab.freedesktop.org/wayland/wayland/-/issues/441
15:20 MrCooper: if a client passes an invalid / already-destroyed ID as a parameter to a request, does the compositor's request handler still get called?
15:28 pq: MrCooper, I think libwayland catches and stops that with a protocol error.
15:28 pq: server-side, too
15:28 MrCooper: I was hoping so, thanks
15:28 vaxry: libwayland goes HOL UP
15:30 pq: the same does not happen with events, those just get turned to NULL I believe