ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has joined #wayland
vincejv has quit [Remote host closed the connection]
kode54 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
vincejv has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
vincejv has quit [Remote host closed the connection]
vincejv has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
<tokyovigilante>
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?
<zamundaaa[m]>
tokyovigilante: yes. Size 0 means that you're supposed to choose a size
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
feaneron has quit [Remote host closed the connection]
kasper93 has quit [Remote host closed the connection]
Company has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<tokyovigilante>
nice, thanks
akimoto has quit [Remote host closed the connection]
Company has joined #wayland
Company has quit [Quit: Leaving]
garnacho has quit [Ping timeout: 480 seconds]
vincejv has quit [Remote host closed the connection]
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
aelius has quit [Remote host closed the connection]
aelius has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
danieldg has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
vincejv has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
danieldg has joined #wayland
crazybyte4 has quit [Quit: Bye]
crazybyte4 has joined #wayland
karenw_ has joined #wayland
glennk has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
sima has joined #wayland
coldfeet has joined #wayland
akimoto has joined #wayland
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
coldfeet has quit [Quit: Lost terminal]
yrlf has joined #wayland
mvlad has joined #wayland
leon-anavi has joined #wayland
MrCooper__ has joined #wayland
MrCooper__ is now known as MrCooper
MrCooper_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
<riteo>
Hi people, I can see that wl_registry::global has its own "ids" (names), which have no formal definition outside of "a number".
<riteo>
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
fmuellner has joined #wayland
MrCooper_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
<zzag>
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
<zzag>
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)
<zzag>
either way, this is the kind of stuff that perhaps should be coordinated across the compositors...
MrCooper has quit [Ping timeout: 480 seconds]
<davidre>
<riteo> "Both sway and weston seem to..." <- you can use wl_display_set_global_filter
<davidre>
the client will see sequential globals I think
<davidre>
For example on Plasma here, wayland_info sees 72 globals with the last one being interface: 'xdg_system_bell_v1', version: 1, name: 72
<davidre>
actually
<davidre>
I am wrong
MrCooper_ is now known as MrCooper
<davidre>
they are not sequential
<davidre>
riteo: not hhaving sequential global "names" is perfectly fine
<vyivel>
zzag: "applied according to the client" and "applied according to the server" are different properties of a commit
iomari891 has joined #wayland
<davidre>
It looks like it is oficially supported when using wl_display_set_global_filter
<vyivel>
not sure if any compositor makes that distinction atm though
<davidre>
and battle tested under Plasma
<MrCooper>
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
<zzag>
MrCooper: hmm, so does mutter delay processing xdg_surface.get_popup, etc?
<davidre>
riteo: indeed if you run wayland_info under KWin you will see
<MrCooper>
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
<zzag>
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
<MrCooper>
that could be problematic indeed
<riteo>
aight thank you davidre
<riteo>
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
<davidre>
Ah the godot embedding
<riteo>
ye :D
<davidre>
I remember
<zzag>
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
<zzag>
like set the opaque region, and so on
<riteo>
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
<MrCooper>
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
<MrCooper>
zzag: not really a fan of such magic resets in general
<MrCooper>
though I guess it might make sense in this case
<riteo>
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?
<MrCooper>
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
<MrCooper>
and those need to presented anyway
<MrCooper>
riteo: no, wl_subsurface is a role
<zzag>
hmm, currently, kwin freezes the window when the surface role is destroyed or reset so those frames won't be displayed
<riteo>
so I can assume that I can reparent a subsurface by destroying its role object and making a new subsurface role object?
<MrCooper>
zzag: sounds like the freeze needs to be handled via transactions as well
<MrCooper>
riteo: yes, that's supposed to work per the protocol spec
<riteo>
yay, thank you MrCooper for the clarification!
<MrCooper>
(I'm using "role object" to refer to the compositor's implementation and "role resource" to refer to the protocol entity)
<zzag>
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)
<MrCooper>
I pointed out many times that the transaction handling is complex stuff :)
<zzag>
it is! :(
<MrCooper>
took me a couple of years to implement the basics in mutter, and there's still fallout left a couple of years later
<MrCooper>
it's probably not "hyper critical", just something the protocol allows and which some client might do at some point
<MrCooper>
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
<zzag>
and the client makes a new commit C to unset the buffer
<zzag>
and then re-creates the surface role
<zzag>
D must not be discarded
<zzag>
"and the client makes a new commit C to unset the buffer" typo: commit D
* zzag
's head hurts
<zzag>
one more clarification: commit A is already applied
<MrCooper>
right, what's the problem? :)
<MrCooper>
the protocol processing timeline defines a sequence of events, and the surface state application timeline needs to replicate that sequence
<zzag>
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
<MrCooper>
why would it be dropped?
<zzag>
although if the compositor performs a hard reset, i.e. it cleans up the surface state entries, then it wouldn't be problem
<zzag>
"although if the compositor performs a hard reset" and not just drops transactions
vincejv has quit [Ping timeout: 480 seconds]
<MrCooper>
note that protocol errors should ideally only be sent from the protocol processing timeline, to avoid sending spurious errors
<MrCooper>
(mutter isn't there yet, getting there though)
<MrCooper>
*from and based on
vincejv has joined #wayland
<zzag>
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)
<jadahl>
zzag: do you track "protocol state" and "rendered state" separately?
iomari891 has quit [Ping timeout: 480 seconds]
<zzag>
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
<zzag>
the same as*
abeltramo5895238271976 has joined #wayland
<MrCooper>
zzag: that sounds like kwin is sending errors based on the surface state application timeline, see above
mclasen has joined #wayland
<MrCooper>
to put it differently, mixing up the two timelines for determining error conditions
<MrCooper>
only the sequence of requests on the protocol processing timeline is relevant for protocol errors
abeltramo589523827197 has quit [Ping timeout: 480 seconds]
abeltramo5895238271976 is now known as abeltramo589523827197
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
<zzag>
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
<MrCooper>
we discussed that in length for the FIFO protocol but ended up not doing anything like that, I'm still against it
<MrCooper>
zzag: "an unconfigured window shows a buffer" means the surface state application timeline doesn't properly replicate the sequence of protocol requests
fmuellner has joined #wayland
<zzag>
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
<zzag>
surface state application timeline is mostly fine except when an xdg_surface-based role is recreated
<MrCooper>
I did try to warn about the complexities involved, to the point where I felt like I was getting on people's nerves
fmuellner has quit [Remote host closed the connection]
kts has joined #wayland
CME_ has quit [Ping timeout: 480 seconds]
<emersion>
zzag: i don't have the time to look rn, but i'm interested in the conclusion of the discussion :)
CME has joined #wayland
kts has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #wayland
kts has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
larunbe has joined #wayland
Moprius has joined #wayland
MrCooper_ is now known as MrCooper
<MrCooper>
zzag: "reset the surface state and discard pending transaction entries" would be a breaking change to the xdg-shell / core protocol, wouldn't it?
alarumbe has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
<zzag>
probably
mclasen has joined #wayland
yrlf has joined #wayland
mvlad is now known as Guest12189
mvlad has joined #wayland
exkc has quit []
exkc has joined #wayland
MrCooper_ has joined #wayland
Guest12189 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
Company has joined #wayland
rasterman has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
kts has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
Brainium has quit []
iomari891 has joined #wayland
kasper93 has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
<kennylevinsen>
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...
<daniels>
mesa ships a layer which reorders the VkPhysicalDevice to put the device associated with the WSI first in the list
<kennylevinsen>
aaah
<kennylevinsen>
yeah can see that in the loader debug
<kennylevinsen>
now to figure out why the order from that is bad
feaneron has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
DodoGTA has left #wayland [#wayland]
MrCooper__ has joined #wayland
karenw_ has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
DodoGTA has joined #wayland
MrCooper_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
iomari892 has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
kts has joined #wayland
iomari891 has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
FreeFull has joined #wayland
MrCooper__ is now known as MrCooper
kts has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
kts has joined #wayland
DodoGTA has joined #wayland
kts has quit [Quit: Konversation terminated!]
iomari891 has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
dri-logg1r has quit [Ping timeout: 480 seconds]
user21 has joined #wayland
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
mclasen has quit [Remote host closed the connection]
<latex>
Hey all. I'm having trouble getting my graphics tablet's pad buttons working in Wayland. They are not registered by xev
<latex>
I mean wevb
<latex>
wev
<latex>
On X11, the pad buttons are configurable using xsetwacom and they work
<latex>
But on Wayland, I'm not getting any events from them
<latex>
Bus 001 Device 005: ID 256c:006d
<latex>
That's my tablet
<latex>
It is supported by DIGImend
<latex>
Huion H950P
<kennylevinsen>
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
<latex>
I'm using Hyprland 0.46.2, which is using libinput 1.27.1
<latex>
The thing is, DIGImend does not recognize 256c:006d out of the box
<kennylevinsen>
I don't know anything about third-party kernel drivers
<Ermine>
the answer is probably to ask them to mainline their drivers and make appropriate patches to libwacom and/or libinput
<kennylevinsen>
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
<kennylevinsen>
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
<kennylevinsen>
`sudo libinput debug-events` will tell you what libinput is seeing