05:39 <repetitivestrain> what happens if wl_pointer_set_cursor is called on pointers belonging to two different seats with the same surface?

05:39 <repetitivestrain> is an error thrown the second time, since the surface already has a role

05:40 <repetitivestrain> or does the surface become the surface on both seats?

05:42 <repetitivestrain> become the cursor*

07:45 <repetitivestrain> also, isn't the pointer undefined upon first entering a surface?

07:45 <repetitivestrain> weston demo programs apparently don't set the cursor at all upon receiving an enter event

07:45 <repetitivestrain> so am i missing something?

07:45 <repetitivestrain> thanks

09:55 <ammen99> Hi all, when I press down on a touchscreen on a view which does not have keyboard focus, and the compositor policy is to focus the view, then should the compositor first send touch.down and then keyboard.enter, or first keyboard.enter and then touch.down? Or should it not make a difference?

09:57 <kennylevinsen> It shouldn't make a difference, keyboard focus is entirely unrelated to touch focus

10:52 <ammen99> kennylevinsen: I see, then what I have stumbled on seems a gtk bug. I try to start drag and drop from an unfocused surface, but gtk tries to start the DnD operation with the serial from the wl_keyboard.enter event which comes after the wl_touch.down event

10:55 <kennylevinsen> but if it starts the drag after the enter event, then that *might* be okay

10:55 <kennylevinsen> "the client must have an active implicit grab that matches the serial"

10:55 <ammen99> well yeah but wlroots' logic does not handle that :P

10:56 <kennylevinsen> if it has a later valid serial then I guess that's fine too. I would agree that it makes more sense to use touch serials for touch drag though.

10:56 <kennylevinsen> what are we expecting? only the touch down or motion serial?

10:57 <ammen99> the touch down serial it seems

11:02 <kennylevinsen> ah yeah so in sway, a pointer serial initiates a pointer grab, a touch serial initiates a touch grab, and a keyboard serial does nothing right now.

11:03 <ammen99> i guess one can't really start drag and drop with the keyboard ...

11:03 <kennylevinsen> which seems sensible, and suggests that gtk is in the wrong here

11:03 <kennylevinsen> if you can I'd like to know how lol

11:03 <ammen99> I'll let you know if I ever figure it out :)

11:04 <ammen99> thanks for the help

11:04 <kennylevinsen> I guess Gtk is being lazy and just storing its last "grab-triggering" serial and using that, irrespective of type

11:05 <kennylevinsen> maybe open an issue towards core to get the text clarified though

11:07 <kennylevinsen> weston also agrees with sway's definition btw

11:07 <kennylevinsen> https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/data-device.c#L1054

11:12 <dottedmag> the protocol is not strict on this though, so if gtk is doing that it would be a breaking change, wouldn't it?

11:16 <kennylevinsen> well, we'll take that in the issue. The alternative interpretation makes it impossible to know what kind of grab should be created, and is incompatible with e.g. weston and sway

11:16 <kennylevinsen> so I don't think it can be considered a valid interpretation

11:17 <kennylevinsen> it would be more up to discussion if both interpretations could coexist

11:18 <kennylevinsen> I also suspect that this is just an unexpected gtk bug rather than planned behavior

11:19 <kennylevinsen> hah, speaking of which: https://gitlab.gnome.org/GNOME/gtk/-/commit/eb0b98d5f2ac551c847981e893b7f2f0ac8cf612

11:29 <kennylevinsen> ammen99: before that commit it used the last of *any* serial (which is pretty likely to be wrong) and instead use the last implicit grab serial (which I guess could still be wrong but less likely?). However, this fix has only been in gtk4 for a month, and is not in gtk3. Maybe test that and suggest a backport?

12:51 <ammen99> kennylevinsen: I am not sure it is worth it, better use this as yet another reason to move to gtk4 ..

16:59 <pac85> I remember talking about direct scanout and how at the time it would only happen if the fullscreen client would happen to use an appropriate format. Recently I've read some xorg and wsi code and things work rather differently in there, tl;dr the xserver exposes wether frames are being flipped directly or copied and wsi uses this information along with other things to decide whether it is appropriate to request the client to reallocate his swapchain by returni

16:59 <pac85> by returning VK_SUBOPTIMAL_KHR from QueuePresent. Now I was wondering whether Xorg's present protocol is just more complete and Wayland will eventually catch up or whether this was somehow by design (perhaps because wayland compositors aren't doing something as bad as blitting to the front buffer so it's not that important to flip frames directly?) (Damn those truncated messages)

17:02 <emersion> pac85: wayland's protocol is more complete

17:02 <emersion> see linux-dmabuf feedback

17:02 <pac85> (I'm assuming Wayland doesn't do something analogous because I've looked at wsi for wayland too and it didn't seem to do soemthinf analogous, correct me if I'm wrong)

17:02 <kennylevinsen> Telling you that you screwed up doesn't really help you pick a format, while dmabuf hints tell you exactly what is preferred

17:04 <pac85> Thx I'll check that out, I was wondering how the case of conditions changing is handled though (such as a window goinf fullscreen though I guess a swapchain would be reallocated anyway)

17:05 <pac85> So direct scanout should now work consistently right?

17:06 <kennylevinsen> Read the protocol, which handles that

20:41 <g000p> What was the conclusion of https://gitlab.freedesktop.org/wayland/weston/-/issues/103? The issue is linked to #117 at the end, which seems to be deleted.

20:42 <g000p> oops, this is a weston issue. I'll look for weston IRC

20:43 <g000p> unless this is the right chat

20:55 <kennylevinsen> weston-launch is no more

20:58 <kennylevinsen> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/663