silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #wayland
boistordu_old has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
blue_penquin is now known as test
<mstoeckl>
observation: sysctl vm.max_map_count reports 65530, and creating that many windows (each shm pool = 1 mmap)...
<mstoeckl>
... leads to memory allocation failure, and crashes; notably weston after an EGL_BAD_ALLOC
test is now known as blue_penquin
blue_penquin has quit [Quit: authenticating]
blue_penquin has joined #wayland
danvet has joined #wayland
DwarfSec has quit []
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
hardening has joined #wayland
SunWuKung has joined #wayland
<emersion>
i've also seen EGL_BAD_ALLOC when creating a shm buffer that is too large
<emersion>
(but haven't seen a wlroots crash)
pochu has joined #wayland
pnowack has joined #wayland
<zzag>
jadahl: how does mutter handle additional state attached to the surface state, e.g. xdg-surface state, in the wp_transactions implementation?
<zzag>
or rather how does mutter associate additional state with the surface state?
<zzag>
I guess it's a better way to put it
<zzag>
in kwin, we keep things such as double-buffered xdg-surface state in the associated xdg_surface object, but I think it won't fly with the wp_transactions protocol
<jadahl>
zzag: kind of. the "ack" serial is part of the cached state
<jadahl>
so when its finally applied, the right configuration (given the ack serial) is picked up
<pq>
mstoeckl, I guess that's just yet another way to get malloc()/calloc() return NULL? Weston mostly pretends to handle that, but there are gaps, I'm sure.
<pq>
mstoeckl, I mean, *alloc a big enough thing, and it's implemented with mmap()'ing something, IIRC. Explicitly called mmap() I'd hope has checks and just disconnects clients when it happens.
<pq>
but, probably has gaps
<zzag>
jadahl: ack's are not universal though, this will not work with pointer constraints (wp_locked_pointer_v1 or wp_confined_pointer_v1), will it?
<pq>
and yes, Weston never checks shm buffer dimensions against maximum texture size in GL ES. But how does that turn into an EGL error?
<pq>
I suppose vm.max_map_count is yet another reason why malloc() failures really should be handled.
<gitlab-bot>
wayland issue (Merge request) 142 in wayland "Draft: macOS and OpenBSD/FreeBSD kqueue(2) support" [Opened]
<jadahl>
zzag: pointer constraints care about the buffer/window geometry like things though I guess? that state will be part of the cache machinery too
st3r4g has joined #wayland
bjorn1 has joined #wayland
letoram has quit [Read error: Connection reset by peer]
bjorn1 has quit []
letoram has joined #wayland
<zzag>
jadahl: correct, so my question is how is the additional state associated with the surface state? is it simply embedded in the surface state? or does mutter do something fancier to avoid wasting ram if the associated surface has no pointer constraints, etc?
<jadahl>
zzag: in mutter there is the "active" state, and a list of pending configurations (with associated serial numbers)
<jadahl>
pointer constraint stuff is using a gobject concept called "qdata" that can attach auxiliary data on objects, i.e. it's "attach" on demand on the cached state/surface state
<zzag>
oh, interesting. is the qdata copied to the cached state or is the qdata and its ownership moved to the cached state?
<jadahl>
zzag: can't remember the details i'm afraid, i wrote that transaction stuff over a year ago