00:22 <Elias0419> Hello. I'm developing a point of sale application for Linux and facing an issue with my touchscreen monitor, a ViewSonic TD2223. Xinput recognizes it as two devices: "iSolution multitouch mouse" (single-touch) and "iSolution multitouch" (multi-touch), which causes each tap to register as two. Disabling the single-touch device solves this but causes another problem: interactions no longer reset the system idle timer at org.f

00:23 <Elias0419> ...interactions no longer reset the system idle timer at org.freedesktop.ScreenSaver /org/freedesktop/ScreenSaver GetSessionIdleTime(). This affects screen locking/unlocking and monitor events in my application. Any guidance or direction to solve this or escalate appropriately would be appreciated. Thanks!

02:15 <orowith2os[m]> What does this have to do with Wayland? Isn't Xinput for X11?

09:46 <pq> Consolatis, IIRC there have been proposals to print array contents, but none landed so far. Yes, the object type inside an array is completely arbitrary. It's essentially an untyped binary blob at libwayland level. XML has no markup to indicate the type, it's all just doc.

09:51 <emersion> i am not in love with inventing a new type system for array contents specifically

09:51 <emersion> which is what some MR does iirc

09:51 <ifreund> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/300

09:52 <ifreund> I wrote the patches because they were very useful to me while debugging something

09:52 <ifreund> IMO that increased debuggability is worth the complexity

10:16 <wlb> wayland.freedesktop.org Issue #7 opened by Alexander Kanavin (alex.kanavin) releases.html: wayland-protocols 1.33 is missing https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/7

10:56 <jmes> Hi, what type of Unix socket should I use for the wire protocol messages? SOCK_STREAM, SOCK_DGRAM, or what?

10:59 <emersion> SOCK_STREAM

11:00 <jmes> emersion: thanks!

11:03 <jmes> Also, when reading the message length and opcode from the 2nd word of a message, I can't just read 2 bytes for the length then 2 bytes for the opcode sequentially because of endianness, right?

11:03 <jmes> I would have to read the whole word, then split it into the most significant 2 bytes and least significant 2, correct?

11:04 <emersion> you could, but then you need to take host endianness into account when piecing the bytes back together

11:05 <jmes> Right, what I mean is that I can't assume the first 2 bytes are actually the message length and not the opcode

11:05 <emersion> yeah, you need to read the full uint32, and then use bit operations

11:06 <jmes> Okay, thanks for confirmation :)

11:07 <jmes> What happens if you use Wayland over TCP or something and 2 systems with different byte order are communicating?

11:07 <pq> you simply cannot

11:08 <pq> only unix sockets can carry the ancillary messages that are needed to transmit fds

11:08 <emersion> there are tools which do conversion: see waypipe

11:08 <emersion> waypipe doesn't support connecting two hosts with different endianness iirc, it just refuses to connect in that case

11:09 <jmes> pq, emersion: okay interesting, I'll look into that.

11:09 <emersion> it should be possible to implement, but maybe nobody has needed it so far

11:10 <jmes> I don't need it either, but I'm just curious :P

11:10 <pq> fds are mostly used for sharing memory between the two sides.

13:33 <wlb> wayland Merge request !369 opened by Julian Orth (mahkoh) Clarify behavior of buffer transformations https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369

14:59 <zamundaaa[m]> emersion: the two nits on the protocol MR aside, is there anything that still needs doing before linux-drm-syncobj-v1 can be merged?

16:19 <emersion> zamundaaa[m]: missing a formal review

16:22 <zamundaaa[m]> If you fix those nits, I can give my reviewed-by

16:33 <emersion> fixed

18:35 <wlb> weston Issue #881 opened by William Salmon (willsalmon) app_id and title are set after setting surface id https://gitlab.freedesktop.org/wayland/weston/-/issues/881

19:46 <LaserEyess> are we about to be in the explicit sync future we were promised?

22:05 <Ermine> Do I understand that this protocol is about submitting buffer which wasn't completely rendered yet and asking compositor to wait?

22:14 <ManMower> I think the compositor will do other things while it "waits" for the buffer to be ready. It's so the compositor doesn't accidentally try to render with an unfinished buffer and stall.