ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Narrat has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
kts has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has joined #wayland
rv1sr has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
consolers has joined #wayland
<consolers>
so on oct i updated from wayland from 1.21.0 to 1.22.0 and the existing wayland firefox --profileManager starts crashing when exiting the profile
<consolers>
if I LD_PRELOAD=/usr/lib64/libwayland-client.so.0.21.0 from a preserved lib and run firefox it doesn't segfault
<consolers>
how do they manage this
gusnan has quit [Ping timeout: 480 seconds]
Guest10939 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest10993
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
consolers has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
sima has joined #wayland
garnacho has joined #wayland
manuel1985 has joined #wayland
privacy has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
rasterman has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
Company has joined #wayland
narodnik has joined #wayland
narodnik has quit []
alatiera has quit [Quit: Connection closed for inactivity]
narodnik has joined #wayland
narodnik has quit []
i509vcb has quit [Quit: Connection closed for inactivity]
narodnik has joined #wayland
crazybyte7 has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte7 is now known as crazybyte
gusnan has joined #wayland
flom84 has joined #wayland
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
<MrCooper>
if a surface commit changes buffer scale, but doesn't attach a new buffer, is the new scale applied to the existing buffer? And is an invalid_size error generated if the existing buffer size isn't a multiple of the scale?
<emersion>
i think so
flom84 has quit [Quit: Leaving]
<Company>
of, MrCooper is here
<Company>
MrCooper: I've had a thought a few days ago and people thought you ight know the answer
<Company>
Could it make sense for GTK3's Cairo rendering to VkAllocateMemory a dmabuf as a backing store instead of using wl_shm?
<MrCooper>
I don't really see the point: 1) the wl_shm path will always be needed as a fallback, so it results in more code to maintain 2) it's doubtful that it'll make a big difference for performance, and a client with software rendering is kind of a slow path anyway
kts has joined #wayland
<Company>
the main benefit I was wondering about is large redrawn areas that are quick to redraw
<MrCooper>
also, at least with dGPUs, memory which isn't super-slow for CPU rendering is pretty slow for GPU sampling, which might eat up any gains from saving the glTexImage calls
<Company>
so where the limiting factor is the amount of copies
<Company>
for example scrolling in a fullscreen Gimp window
<Company>
Gimp has a backing store, copies it to the cairo surface and then the compositor copies it into the texture again
kts has quit []
<Company>
same thing with a text editor - that's alpha blending, but it's still limited mostly by memory speed
<Company>
at least I think it is
kts has joined #wayland
<Company>
and I know that jadahl is very sensitive about glTexImage2D() performance - it came up in the GLES discussions a lot.
<Company>
so avoiding it seemed like a worthwhile goal to me
<MrCooper>
glTexImage being slow is most likely a bug in Mesa and/or mutter
<MrCooper>
let's just fix those
leon-anavi has joined #wayland
mvlad has joined #wayland
shoragan has quit [Read error: Network is unreachable]
mtretter has quit [Read error: No route to host]
pH5 has quit [Read error: Network is unreachable]
shoragan has joined #wayland
qaqland has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Guest10993 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest11042
narodnik has quit [Quit: WeeChat 4.1.2]
Lyude has joined #wayland
narodnik has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
junaid has joined #wayland
junaid_ has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
junaid_ has quit [Remote host closed the connection]
junaid has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
puck_ has quit [Remote host closed the connection]
puck_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
jtbx has quit [Remote host closed the connection]
jtbx has joined #wayland
kts has quit [Read error: Connection reset by peer]
kts has joined #wayland
vandemar has joined #wayland
leon-anavi has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
sima has quit [Quit: Leaving]
sima has joined #wayland
vandemar has quit [Quit: leaving]
<bwidawsk>
If a client destroys a popup that current has a pointer, what is the expectation for a leave event to be emitted?
Leopold_ has quit [Remote host closed the connection]
Moprius has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest11075
Guest11042 has quit [charon.oftc.net dacia.oftc.net]
dubiousness has joined #wayland
<riteo>
oh boy this is going to be a dumb one
<riteo>
(this is unrelated to the question above)
<riteo>
the dumb question follows: are we supposed to embed the various protocols in the client source code or should we depend on wayland-protocols?
junaid has joined #wayland
<riteo>
(yeah sorry for the suddenness, it makes me look like I was commenting the question above as dumb, which is NOT what I intended)
<emersion>
you mean check in the XML?
<riteo>
yeah
<emersion>
it doesn't really matter too much
<riteo>
I've seen some clients do that and others not
<emersion>
depending on wayland-protocols makes the updates free
<emersion>
and XMLs guaranteed to match upstream
<riteo>
mh
<riteo>
I've noticed that some older wayland-scanner versions complain about DTD though
<riteo>
not sure if that matters
<emersion>
complain about DTD?
<riteo>
yeah because of the new array_flag functions or something like that
<kchibisov>
Usually clients have protocols in source for the ones not in wayland-protocols, e.g. wlr ones.
<emersion>
that sounds orthogonal
<riteo>
emersion: the DTD thing?
<riteo>
kchibisov: if that's the norm I can adapt godot-side
<riteo>
might make the PR smaller
Guest11075 has quit [Remote host closed the connection]
<RobertAyrapetyan[m]>
Is it possible to force wlroots to emit frames even if image remains static?
<emersion>
yeah, depending on w-p is the norm
<bl4ckb0ne>
RobertAyrapetyan[m]: thats a question for #wlroots on libera
<emersion>
RobertAyrapetyan[m]: the client needs to ask for wl_surface.frame
cool110_ has joined #wayland
<emersion>
the compositor can't ask the client to redraw
<riteo>
I see, thanks for the clarification!
cool110_ is now known as Guest11082
<riteo>
I just look for wp with pkgconf, right?
<kchibisov>
emersion: I think it's only _yet_ though?
<kchibisov>
There was a protocol for GPU resets which basically had a concept like that.
<emersion>
riteo: yeah
<emersion>
kchibisov: indeed, not merged
<riteo>
emersion: great!
<riteo>
as long as there isn't some vendoring policy I think that I should manage to shave quite a bit of lines from the PR
<RobertAyrapetyan[m]>
emersion: I'm using wlrtoots -> xdg-desktop-portal-wlr -> pipewire pipeline. Which of these should ask for a frame?
<kchibisov>
vendoring is usually done in the context of non-c stuff.
<kchibisov>
Because you're likely using different scanner, etc.
<emersion>
RobertAyrapetyan[m]: ah, important precision. please ask in #wlroots on Libera
nerdopolis has joined #wayland
<RobertAyrapetyan[m]>
<emersion> "Robert Ayrapetyan: ah, important..." <- do you know if there is a bridge for matrix.org available?
<RobertAyrapetyan[m]>
RobertAyrapetyan[m]: nevermind, found something, thanks
<emersion>
the bridge to Libera has been shut down because it caused too many issues
junaid has quit [Remote host closed the connection]
roussinm has joined #wayland
<roussinm>
I am using Weston(10) as a compositor with Xilinx hardware. We face an issue where rendering falls back to mixed mode instead of using plane-only composition. The Xilinx DRM plane initialization (drm_universal_plane_init) uses a NULL as modifiers. Although the DRM format is compatible (RGB565), the modifiers seem to be the root cause. Weston's drm_fb_compatible_with_plane calls
<roussinm>
indicate format compatibility, but the modifier is not DRM_FORMAT_MOD_INVALID, and weston_drm_format_has_modifier returns false. This leads to the mixed mode. Manually modifying the code to return true for the correct plane resolves the rendering performance (mixed mode is slower). Is this a Weston problem, or is it more likely an issue with the Xilinx DRM driver's handling of
<roussinm>
modifiers during plane initialization?
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
junaid_ has joined #wayland
Leopold_ has joined #wayland
<daniels>
roussinm: it's a Xilinx DRM issue - it needs to support modifiers to have any chance of working correctly
Leopold_ has quit [Remote host closed the connection]
junaid_ has quit []
<roussinm>
daniels: we upgraded from weston 7 to weston 10, and bunch of other libraries libdrm, etc... but not the kernel. Since the upgrade we lost plane-only composition. I guess some checks must have been added in userspace and prevents use of using it again.
<daniels>
roussinm: yeah, if you provide a buffer with an explicit modifier, then we won't try to use implicit modifiers with it ...
<roussinm>
daniels: when you said `explicit modifier`, does it mean how xilinx setup the plane with NULL as the modifiers? I think we it used DRM_FORMAT_MOD_INVALID it would be different.
<daniels>
roussinm: when you said 'but the modifier is not DRM_FORMAT_MOD_INVALID' (presumably it's DRM_FORMAT_MOD_LINEAR), that's an explicit modifier: the client is telling you which modifier the buffer has
<daniels>
DRM_FORMAT_MOD_INVALID is 'who knows what the modifier is, maybe try and guess if you can'
<daniels>
and you can't mix the two worlds: if xilinx-drm is saying it can't handle explicit modifiers, then we can't give it a client buffer which was given to us with explicit modifiers
<roussinm>
daniels: ok so from weston-debug output I can see the modifiers LINEAR. How is that set if xilinx send NULL, is that libdrm ?
<daniels>
roussinm: if it's from a client, it's from ... whatever your client is
<daniels>
be that libmali, or GStreamer, or whatever
<roussinm>
Ok we use Qt, with mesa, kernel is lima driver. So client is mesa.
<roussinm>
if I understand that correctly.
<roussinm>
Oh no, you are right, probably libmali from xilinx
<roussinm>
daniels: I'm all over the place, probably a bit over my head, but actually mesa is the client.
<daniels>
right, in that case it's still the xilinx drm driver which needs to be fixed to handle modifiers to make this work
<roussinm>
daniels: what kind of work does that imply? If I wanted to implement modifiers handling in their driver?
<daniels>
roussinm: tbh it should just be passing { DRM_FORMAT_MOD_LINEAR, DRM_FORMAT_MOD_INVALID } as the supported modifiers, and returning true to both in the format_mod_supported hook
Brainium has joined #wayland
<daniels>
(newer kernels just do this automatically, so I guess the kernel is pretty old)
<roussinm>
daniels: 5.4
<emersion>
daniels: the kernel doesn't use INVALID to mean implicit
<emersion>
KMS cannot say that it doesn't support implicit mods
tlwoerner__ has quit []
tlwoerner has joined #wayland
<daniels>
emersion: hrm?
<emersion>
daniels: "tbh it should just be passing { DRM_FORMAT_MOD_LINEAR, DRM_FORMAT_MOD_INVALID } as the supported modifiers"
<daniels>
emersion: oh right, you mean that it's only LINEAR in the list?
<emersion>
yea
<daniels>
thanks for the correction :)
<emersion>
either way, doesn't matter with the new kernels :)
<roussinm>
Looking at the documentation: * @format_modifiers: array of struct drm_format modifiers terminated by DRM_FORMAT_MOD_INVALID
<roussinm>
shouldn't I add it anyway? Since I'm not gonna upgrade the kernel atm.
<emersion>
oh...
<roussinm>
It is used as a sentinel flag or error code.
<emersion>
so yeah, INVALID should be in the array, however it's not used to indicate support for implicit mods, it's used to end the list
caveman has quit [Remote host closed the connection]