01:44tokyovigilante: Think I have managed to sort my surface configure code out, but the initial toplevel configure is always (0,0) using Sway. I have to ignore this as resizing my EGL window to zero causes it to not be displayed. If I just force a 640x480 size and ignore the (0,0), then subsequent configure events give me correct sizing. Is this expected behaviour?
02:04zamundaaa[m]: tokyovigilante: yes. Size 0 means that you're supposed to choose a size
03:09tokyovigilante: nice, thanks
08:17riteo: Hi people, I can see that wl_registry::global has its own "ids" (names), which have no formal definition outside of "a number".
08:18riteo: Both sway and weston seem to make them sequential but for the funky compositor I'm doing I'd like to hide certain (potentially "custom") globals and whatnot from specific clients. Can I make them discontinuous without seeing clients explode? I'm afraid that certain clients (including the WSI, libdecor and whanot) might assume sequential, closely-packed global names
08:31zzag: MrCooper: jadahl: emersion: we found an issue with surface transactions that we believe may affect mutter and wlroots too because like kwin they also try to wait on graphics buffers before applying the surface state and they too destroy surface roles asap. https://invent.kde.org/plasma/kwin/-/issues/274
08:31zzag: there are multiple ways how to handle it, e.g. drop transactions D and E (the xdg shell spec already mentions that some state is reset, so it might be okay?), or apply transactions D and E when the surface role is destroyed, or somehow delay processing surface role destruction (it might be easier said than done depending on the compositor implementation)
08:31zzag: either way, this is the kind of stuff that perhaps should be coordinated across the compositors...
08:35davidre: <riteo> "Both sway and weston seem to..." <- you can use wl_display_set_global_filter
08:36davidre: the client will see sequential globals I think
08:37davidre: For example on Plasma here, wayland_info sees 72 globals with the last one being interface: 'xdg_system_bell_v1', version: 1, name: 72
08:38davidre: actually
08:38davidre: I am wrong
08:38davidre: they are not sequential
08:38davidre: riteo: not hhaving sequential global "names" is perfectly fine
08:38vyivel: zzag: "applied according to the client" and "applied according to the server" are different properties of a commit
08:39davidre: It looks like it is oficially supported when using wl_display_set_global_filter
08:39vyivel: not sure if any compositor makes that distinction atm though
08:39davidre: and battle tested under Plasma
08:39MrCooper: zzag: mutter handles surface destruction via transactions and destroys the role object only when the surface object has no references left, so offhand (not having looked at the issue yet) it sounds like we should be fine
08:40zzag: MrCooper: hmm, so does mutter delay processing xdg_surface.get_popup, etc?
08:41davidre: riteo: indeed if you run wayland_info under KWin you will see
08:41davidre: interface: 'wl_compositor', version: 6, name: 1
08:41davidre: interface: 'zwp_tablet_manager_v2', version: 1, name: 3
08:42zzag: MrCooper: I mean delay processing new xdg_surface.get_popup, and so on after the previous surface role has been destroyed
08:42zzag: on kwin side, I am not sure that it will be feasible for us to implement such a object ownership model
08:43MrCooper: zzag: partially, yes; as it happens, just created https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4362 to fix some issues with that
08:44MrCooper: note that mutter always re-uses the same role object if the client destroys the role resource and creates a new one, since switching to a different role isn't allowed
08:45zzag: yeah, kwin doesn't allow switch roles either, but it re-creates the surface role object, i.e. the dynamic part of the surface role
08:46MrCooper: that could be problematic indeed
08:47riteo: aight thank you davidre
08:47riteo: BTW I can't use the global filter thing since I am manipulating the messages manually, due to the extremely weird requirements of my quasi-compositor
08:47davidre: Ah the godot embedding
08:47riteo: ye :D
08:47davidre: I remember
08:48zzag: MrCooper: for kwin, it'd be preferred if it is assumed that all surface state is lost when the surface role is reset, and the client needs to re-initialize everything again
08:49zzag: like set the opaque region, and so on
08:49riteo: well I guess I'll just... literally skip certain wl_registry::global messages. I'll still have to "reorder" things though since I also want to add my own fancy interface and I really don't feel like adding/subtracting random offsets from the "real" names
08:49MrCooper: zzag: hmm, though I guess we might still have an issue in mutter as well, since the xdg_popup role object only has a single state for deferred setup
08:49MrCooper: zzag: not really a fan of such magic resets in general
08:50MrCooper: though I guess it might make sense in this case
08:51riteo: talking about surface roles, MrCooper you mentioned that mutter reuses the surface role if a new one is created because of the constraint imposed by the protocol. Do differently parented subsurfaces count as different roles?
08:51MrCooper: zzag: not sure it really helps though, since the client can queue multiple frames via FIFO / commit-timing before destroying and re-creating the role resource
08:51MrCooper: and those need to presented anyway
08:52MrCooper: riteo: no, wl_subsurface is a role
08:53zzag: hmm, currently, kwin freezes the window when the surface role is destroyed or reset so those frames won't be displayed
08:53riteo: so I can assume that I can reparent a subsurface by destroying its role object and making a new subsurface role object?
08:53MrCooper: zzag: sounds like the freeze needs to be handled via transactions as well
08:54MrCooper: riteo: yes, that's supposed to work per the protocol spec
08:55riteo: yay, thank you MrCooper for the clarification!
08:55MrCooper: (I'm using "role object" to refer to the compositor's implementation and "role resource" to refer to the protocol entity)
08:59zzag: MrCooper: we cannot do that, unfortunately, that will involve massive and disruptive changes around the memory management model. I'm also not sure if it's hyper critical to present those last frames instead of just dropping them and letting the client know about it (if it's still alive)
08:59MrCooper: I pointed out many times that the transaction handling is complex stuff :)
08:59zzag: it is! :(
09:00MrCooper: took me a couple of years to implement the basics in mutter, and there's still fallout left a couple of years later
09:02MrCooper: it's probably not "hyper critical", just something the protocol allows and which some client might do at some point
09:07MrCooper: FWIW, a good mental model is to think of protocol processing and surface state application as completely separate timelines connected only via the transaction queue
09:09wlb: wayland Issue #532 opened by Ivan Linty (ilinty74) wine and microsoft ACCESS https://gitlab.freedesktop.org/wayland/wayland/-/issues/532
09:19wlb: weston Merge request !1708 opened by Marius Vlad (mvlad) input: Switch keyboard keymap layout on the fly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1708 [Input]
09:22jadahl: zzag: I suspect what happens to wl_surface level state (opaque/input) on "reset" is fairly undefined atm
09:24vyivel: i don't think anything happens to it
09:24vyivel: "reset" is xdg-shell specific and doesn't affect core surface state semantics
09:24MrCooper: yeah, can't see anything like that in the core spec
09:25MrCooper: and per above, a reset wouldn't really change anything for this issue
09:26MrCooper: as the reset would just take effect at a certain point of the surface state application timeline, not drop earlier stuff on that timeline
09:28zzag: can you please clarify that? I don't think that I understand it
09:35zzag: but now that I think about it more, I think there's a problem
09:35zzag: https://usercontent.irccloud-cdn.com/file/ZvMKgJOB/20250326_113147.jpg
09:35zzag: if the compositor waits on commits B and C
09:36zzag: and the client makes a new commit C to unset the buffer
09:36zzag: and then re-creates the surface role
09:36zzag: D must not be discarded
09:38zzag: "and the client makes a new commit C to unset the buffer" typo: commit D
09:38zzag:'s head hurts
09:40zzag: one more clarification: commit A is already applied
09:47MrCooper: right, what's the problem? :)
09:48MrCooper: the protocol processing timeline defines a sequence of events, and the surface state application timeline needs to replicate that sequence
09:49zzag: you don't wanna drop the commit D otherwise the surface state can have a lurking buffer, that may result in the comopsitor positing the unconfigured_buffer protocol error
09:49MrCooper: why would it be dropped?
09:49zzag: although if the compositor performs a hard reset, i.e. it cleans up the surface state entries, then it wouldn't be problem
09:50zzag: "although if the compositor performs a hard reset" and not just drops transactions
09:51MrCooper: note that protocol errors should ideally only be sent from the protocol processing timeline, to avoid sending spurious errors
09:51MrCooper: (mutter isn't there yet, getting there though)
09:53MrCooper: *from and based on
10:00zzag: MrCooper: oh, I also forgot to mention the problem in https://invent.kde.org/plasma/kwin/-/issues/274. when kwin applies commit D (in the picture in the issue), it can post a protocol error because commit D contains a buffer and it's illegal for the initial commit to have a buffer (D is not the initial commit for the new role, F is, but given how transactions are applied, it looks otherwise)
10:01jadahl: zzag: do you track "protocol state" and "rendered state" separately?
10:03zzag: jadahl: yes, the rendered state is not always the same the protocol state. it mostly happens when the client shuts down or the window is closed
10:03zzag: the same as*
10:04MrCooper: zzag: that sounds like kwin is sending errors based on the surface state application timeline, see above
10:06MrCooper: to put it differently, mixing up the two timelines for determining error conditions
10:09MrCooper: only the sequence of requests on the protocol processing timeline is relevant for protocol errors
10:14zzag: sure, I guess kwin could check for protocol errors earlier, e.g. when committing transactions, but given the current architecture and that pivoting to another design will be a problem, it'd still be preferred to reset the surface state and discard pending transaction entries to avoid the case where an unconfigured window shows a buffer, etc
10:15MrCooper: we discussed that in length for the FIFO protocol but ended up not doing anything like that, I'm still against it
10:18MrCooper: zzag: "an unconfigured window shows a buffer" means the surface state application timeline doesn't properly replicate the sequence of protocol requests
10:29zzag: MrCooper: well, we're kind of in the hard place then... rewriting large swaths of code so kwin can display last a couple of frames when the window is closed is hard to justify when it's weighted against the cons
10:30zzag: surface state application timeline is mostly fine except when an xdg_surface-based role is recreated
10:31MrCooper: I did try to warn about the complexities involved, to the point where I felt like I was getting on people's nerves
10:40emersion: zzag: i don't have the time to look rn, but i'm interested in the conclusion of the discussion :)
11:35MrCooper: zzag: "reset the surface state and discard pending transaction entries" would be a breaking change to the xdg-shell / core protocol, wouldn't it?
11:48zzag: probably
12:58kennylevinsen: hmm I feel like the Vulkan WSI lacks a way to ask for the preferred VkPhysicalDevice, as it only seems to initialize and get dmabuf feedback after that decision has been made...
13:00daniels: mesa ships a layer which reorders the VkPhysicalDevice to put the device associated with the WSI first in the list
13:02kennylevinsen: aaah
13:02kennylevinsen: yeah can see that in the loader debug
13:02kennylevinsen: now to figure out why the order from that is bad
15:58kennylevinsen: well that explained it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34219
16:15latex: Hey all. I'm having trouble getting my graphics tablet's pad buttons working in Wayland. They are not registered by xev
16:15latex: I mean wevb
16:15latex: wev
16:16latex: On X11, the pad buttons are configurable using xsetwacom and they work
16:16latex: But on Wayland, I'm not getting any events from them
16:16latex: Bus 001 Device 005: ID 256c:006d
16:16latex: That's my tablet
16:16latex: It is supported by DIGImend
16:17latex: Huion H950P
16:17kennylevinsen: note: you're not running X11 or Wayland, but Xorg or <wayland server of choice> - e.g., kwin if you're using KDE, mutter if you're using GNOME
16:18latex: I'm using Hyprland 0.46.2, which is using libinput 1.27.1
16:19latex: The thing is, DIGImend does not recognize 256c:006d out of the box
16:19latex: https://envs.sh/pGT.conf
16:19kennylevinsen: I have no idea what digimend is
16:20latex: This X11 config is required to make 256c:006d work on Xorg
16:20latex: How can I do this for Wayland/libinput?
16:20latex: kennylevinsen: https://digimend.github.io/
16:20latex: https://github.com/DIGImend/digimend-kernel-drivers/issues/427
16:22kennylevinsen: I don't know anything about third-party kernel drivers
16:23Ermine: the answer is probably to ask them to mainline their drivers and make appropriate patches to libwacom and/or libinput
16:23kennylevinsen: libinput has a quirks configuration that can override certain properties, but I have no idea if that's needed - your shared config file doesn't mean too much to me
16:24kennylevinsen: latex: the equivalent of any X11 configuration for you would be hyprland configuration, but if libinput doesn't recognize the device then hyprland won't be able to do much
16:24kennylevinsen: `sudo libinput debug-events` will tell you what libinput is seeing
17:50latex: kennylevinsen: DIGImend is mailined
17:51latex: mainlined
17:52latex: Also, libinput debug-events did recognize my TABLET_PAD_BUTTONs
17:52latex: So how do I get it working in Wayland programs then?
17:52latex: And why won't wev recognize it?
17:53kennylevinsen: latex: no, when mainlined its no longer "digimend", just a device driver
17:54kennylevinsen: digimend are out of tree changes
17:54latex: Yeah but some of their drivers are mainlined
17:54latex: It's not called digimend in-tree
17:54latex: Or maybe I'm confusing something here
17:55latex: Okay so maybe you are right but nearly all distros just include digimend drivers
17:56kennylevinsen: certainly no out of tree drivers by default, but that doesn't matter
17:56latex: Or maybe it's partially mainlined
17:57kennylevinsen: Looking at wev I don't see any tablet handing in it
17:57kennylevinsen: so it wouldn't recognize any tablet behaviors
17:59latex: What about GIMP 3?