01:59 wlb: wayland Issue #509 opened by () Looking for advice: What do I do about all the missing functionality? https://gitlab.freedesktop.org/wayland/wayland/-/issues/509
03:02 DemiMarie: Can a Wayland proxy safely implement its own toplevel surface and make the guest-provided surfaces subsurfaces of that?
08:37 kennylevinsen: what you are describing sounds like a rootful nested compositor, and depends on what you mean by "safe"
09:06 MrCooper: fmuellner: please fix your setup
10:47 zzag: whot: do wayland compositors need to handle new tablet tool axis values in LIBINPUT_EVENT_TABLET_TOOL_TIP or LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY? i.e. if the tablet tool tip presses, can a wayland compositor assume that the axis and the tip event will arrive in the same frame?
10:47 zzag: otherwise it seems like the compositor would need to handle new axis values in LIBINPUT_EVENT_TABLET_TOOL_TIP and LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY too, which is not pretty code-wise
10:52 zzag: emersion: jadahl: am I correct that sway and mutter send axis values only after receiving LIBINPUT_EVENT_TABLET_TOOL_AXIS?
10:56 zzag: perhaps this could be the culprit of https://bugs.kde.org/show_bug.cgi?id=475619
10:57 jadahl: zzag: having a quick look, can't say that is the case, it seems to send axis events strategically before some other events, e.g. before tablet tool button
11:09 zzag: https://gitlab.freedesktop.org/libinput/libinput/-/blob/64d1f198fb2764dfb852a19becaf6f7f097fce2c/src/libinput.h#L911-919 ah, I should have looked at the documentation as the starting point
11:09 zzag: so wayland compositors need to check axis values when processing proximity and tip events it seems..