ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
lucasmsoares96 has quit [Quit: Konversation terminated!]
rpigott has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
shashank1202 has quit [Quit: Connection closed for inactivity]
___nick___ has quit []
___nick___ has joined #wayland
boistordu has joined #wayland
boistordu_ex has quit [Ping timeout: 480 seconds]
hill has joined #wayland
leon-p has joined #wayland
zebrag has quit [Remote host closed the connection]
slattann has joined #wayland
shashank1202 has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
pnowack has joined #wayland
dcz has joined #wayland
danvet has joined #wayland
leon-p has quit []
johnjay has quit [Ping timeout: 480 seconds]
moa has joined #wayland
bluebugs has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
rasterman has joined #wayland
sndb has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
hendursa1 has joined #wayland
johnjay has joined #wayland
mjs_xorg_2 has joined #wayland
hendursaga has quit [Ping timeout: 480 seconds]
mjs_xorg_2 has quit []
shashank1202 has quit [Quit: Connection closed for inactivity]
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
<pq>
jadahl, I mean the last time I fiddled with irssi, terminal, etc. charset settings was probably around 2005?
<jadahl>
wasn't the transition already ongoing by then?
<pq>
it was, so I was set up for the transition and never cleaned up
<jadahl>
oh well,
<jadahl>
(╯°□°)╯︵ ┻━┻
anarsoul has quit [Read error: Connection reset by peer]
jgrulich has quit [Remote host closed the connection]
<jadahl>
yea saw that email. almost thought about mentioning a wiki, but then remebered wikis suk
<pq>
oh, maybe?
<emersion>
yeah, can't do reviews on wikis
<emersion>
not sure a whole new repo is worth it
<jadahl>
w-p branch would work, and could merge it to main when things have been set it stone
<emersion>
but it's also an option
<jadahl>
wayland-docs?
<jadahl>
wayland-musings
<emersion>
i think the point would be not to tie it to wayland
<jadahl>
wayland-protocols seems somewhat saner
<daniels>
wfm
<jadahl>
if it involves windowing system server client interaction, it somewhat ties to wayland though
<emersion>
but also involves KMS, mesa, etc
<pq>
it definitely does have sections on window system protocol, integration and implementations
<emersion>
so it could "almost" be a kernel patch
<jadahl>
putting it in the kernel doesn't seem right either
<pq>
I really don't want the kernel patch workflow, though.
<jadahl>
indeed
<emersion>
what's the issue with the kernel pacth workflow?
<pq>
email
<emersion>
well good thing i haven't said that for the GitLab workflow…
<jadahl>
email, and if we add ci deplay for docs it'd be much easier with e.g. w-p + gitlab
<emersion>
kernel already has docs deployed
<emersion>
but tbh i don't care much where that doc lives
<emersion>
the important thing is to have a place (anywhere)
<pq>
also the whole model of thousands of git trees for changes to trickle through
<pq>
I'm starting to think that a separate repository would be the most "neutral ground" for it, we that under wayland org or not. Then it could have its own CI to publish the doc too, we could perhaps actually use math.
<pq>
*be that
<pq>
a single-purpose repo like wayland/color-doc or a generic repo like wayland/docs?
<emersion>
wayland/docs would be misleading
<emersion>
wayland/color-doc wouldn't be better than wayland-protocols
<pq>
could move wayland docbook there, too
<emersion>
i like that docs are in-sync with the rest of the repo
<pq>
wayland-protocols has the governance rules, and I suppose they would restrict who can have push access - we need push access for people not eligible to wayland-protocols
<emersion>
e.g. a wayland change can land the docs changes in the same MR
<emersion>
if you want neutral grounds, don't use wayland/
<pq>
hm, freedesktop org then?
<jadahl>
pq: the governance is for protocols, it doesn't talk about high level docs
<pq>
jadahl, is it not about merge rights as well?
<pq>
freedesktop gitlab org seems to be for the infrastructure only
<jadahl>
turn your doc into an xdg-spec :P
<pq>
I'm starting to like the idea of gitlab.fd.o / <some suitable org> / color-docs, or something. That would be neutral and allow to manage it freely.
<emersion>
<some suitable org> with kernel, mesa and wayland folks in it? how crazy are you!
<emersion>
:P
<pq>
don't forget color management, TV, and broadcast folks
jgrulich has joined #wayland
<pq>
and X11 folks, should someone want to
<pq>
someone from W3C too, if we're lucky
<jadahl>
gitlab.freedesktop.org/DMZ then
<pq>
pretty much, actually
<pq>
How about a gitlab.fd.o group called... "workgroup"? For cross-everything workgroups, and color stuff as a project under it.
<jadahl>
fine by me
<emersion>
now need ACKs from all of these people ;)
<pq>
I shall file an issue with fd.o infra, so we can have those ACKs from the people currently active on it, and from fd.o maintenance
<emersion>
i wonder if other discussion topics would benefit from it
<emersion>
i guess many WSI related topics would
<pq>
from a workgroups umbrella? I'd hope so.
<jadahl>
e.g. "how to dma buf modifier:y in user space" maybe
<emersion>
daniels has a kernel patch for this
<daniels>
pq: uh, everything on fd.o _is_ a workgroup really
<daniels>
might as well call it project/ :P
<daniels>
creating groups and/or projects is cheap enough as to be free, making sure they don't rot from the instant they're created is the difficult part
<daniels>
to that extent we usually ask people to get something concrete together, so it can at least move with inertia rather than just never get started
xexaxo has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Lucretia-backup has quit []
Lucretia has joined #wayland
<pq>
daniels, you can't create a project in gitlab at the level where groups are, and none of the existing groups seem appropriate for the color doc. What do you suggest?
hill has quit [Remote host closed the connection]
xexaxo has joined #wayland
hill has joined #wayland
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
<daniels>
pq: I guess just a clear plan to make sure it’s useful and long-lived rather than a one-doc dumping ground that rapidly goes out of date? and cultural expectations established so that what’s there can be useful whilst balancing to allow for future development without being a dumping ground of random speculative ideas
<pq>
How do I do that?
<pq>
I literally want to just host one doc for now.
<pq>
and not in anyone's personal repository, not in the kernel tree, and not under wayland umbrella if possible
dcz has joined #wayland
<pq>
seems like a chicken-and-egg problem
hill has quit [Remote host closed the connection]
jgrulich has quit [Remote host closed the connection]
<pq>
daniels, maybe I can create it as a personal project first and deal out Maintainer access?
<pq>
daniels, is it possible to move a personal project under a new group later, without losing any issues or past MRs?
<daniels>
pq: it sure is, yeah
<daniels>
pq: you can give access to anyone you want, and moving later preserves everything (issues, MRs, commits, whatever) as well as giving you automatic URL redirects
<pq>
ooh, nice
ppascher has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
ppascher has joined #wayland
rpigott has joined #wayland
shashank1202 has joined #wayland
rpigott has quit [Ping timeout: 480 seconds]
rpigott has joined #wayland
jgrulich has joined #wayland
lucasmsoares96 has joined #wayland
jgrulich has quit [Remote host closed the connection]
lucasmsoares96 has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
lucasmsoares96 has joined #wayland
rpigott has quit [Ping timeout: 480 seconds]
slattann has quit []
slattann has joined #wayland
rpigott has joined #wayland
lucasmsoares96 has quit [Quit: Konversation terminated!]
<pq>
emersion, eh heh, I was wondering a long time ago if we're going to get into trouble with format/mod lists growing too big. Sounds like that time is now.
lucasmsoares96 has quit [Quit: Konversation terminated!]
<daniels>
yeah, we could do something similar to the KMS protocol, where we ship format + mod lists separately, then relate them to the other with a bitmask
<daniels>
horrible to use tho
<pq>
Does that actually help so much? I'm afraid well just be in the same situation again.
<daniels>
well, what else are you going to do?
lucasmsoares96 has joined #wayland
<pq>
shm
<daniels>
ouch
<daniels>
read-only mapping I hope :P
<pq>
I suspect we can come up with a plan where the same shm area can used read-only with all clients.
<pq>
I just wonder if it would be possible to compute a static set of tranches for dmabuf-hints too, so that protocol would only need to deliver tranche ids.
<daniels>
then all we need is to encode some kind of Lua/eBPF/whatever in the protocol XML so we can autogenerate the required parser helpers for all languages
<pq>
it doesn't need to be that complicated
<pq>
offset in the shm could be the "id"
<emersion>
pq, i've actually done that for the wlroots keyboard keymap
<emersion>
i wonder why nobody else has done it, or why v7 made PRIVATE mandatory
<pq>
or, you can see how far shoveling a KMS-format-blob-thing in a wl_array can go. Except, since it's a single message, you can't exceed 4 kB even if the kernel socket bufs had room.
<emersion>
the trick is as follows:
rpigott has quit [Ping timeout: 480 seconds]
<emersion>
- shm_open(EXCL | RDWR)
<emersion>
- shm_open(RDONLY) with the same name
<emersion>
- shm_unlink()
<pq>
I didn't mean literally shm, just any shared memory thing :-)
<emersion>
this gives you one read-only mapping, and one read-write mapping
rpigott has joined #wayland
<emersion>
write keymap to the latter, send the former to clients
<emersion>
and instead weston uses a linux-specific sealing API… which requires clients to map with PRIVATE…
<pq>
daniels, can't wait to get something new beyond modifiers for negotiating buffer allocation, like some constraints structure :-P
<pq>
emersion, I guess no-one realized they can play with shm_open like that. We can also wonder, why do we create files in $XDG_RUNTIME_DIR instead of using shm_open(), too.
<emersion>
yeah
shashank1202 has quit [Quit: Connection closed for inactivity]
sndb is now known as Guest772
sndb has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
Guest772 has quit [Ping timeout: 480 seconds]
shashank1202 has joined #wayland
rpigott has quit [Ping timeout: 480 seconds]
sndb has quit [Ping timeout: 480 seconds]
lucasmsoares96 has quit [Quit: Konversation terminated!]
<daniels>
'I personally think it's easier to promise a device for now, and release a new interface version which makes the device optional later if we need it.'
<daniels>
^ pragmatically, the only reason I want to have an optional target device is for llvmpipe/pixman-renderer in CI (so we can exercise our dmabuf paths as well as eventually vkms overlay paths as well), so 'send the VGEM device' works well enough for this, so I'd be fine with that resolution
<daniels>
but I'm not quite following why it's easier to always send a device which makes me think there's something I'm missing - is there some particular usecase that's complicated by optional devices?
Seirdy has quit [Quit: exiting 3.2]
<emersion>
hm, so
<emersion>
do we care about the case where the compositor accepts dmabufs, but has no device to import them to?
<emersion>
in this case dmabufs are just the same as shm?
<daniels>
yeah but I also want our test coverage to expand
<daniels>
like I said, pragmatically that means we can just build vgem into our CI kernel and send that as the device node
<daniels>
or given that you no longer have to send DRM devices as a device node, we could send /dev/null as well :P
<daniels>
but the strength of the pushback made me think that I was missing something - that there's some property of the implementation or uses which are important to that I can't see - so I wanted to know what it was so I wasn't missing as much context or making random incorrect guesses as to what you would(n't) be happy with
Seirdy has joined #wayland
<emersion>
well, it's not that much of a big deal
<emersion>
it's just that with wl_drm clients can just do a roundtrip and get the device
<daniels>
nod
<emersion>
well i suppose it's not much different with the current approach…
<daniels>
so you're thinking in terms of ... EGL implementation?
<emersion>
yeah, client impl
<daniels>
getting vgem as a primary_device wouldn't be too useful to them :P
<emersion>
EGL/Vulkan/manual
<daniels>
oh, there is another usecase that I was reminded of last week, which is STB hardware with massively powerful display controllers, and either no GPU at all, or a GPU so useless you're better off avoiding it
<emersion>
i wonder how EGL would be supposed to react with a vgem primary device
<daniels>
so in that case you do actually want dmabuf + planes + pixman
<daniels>
I guess technically your primary_device for that would just be the KMS node
<emersion>
but you need a primary node to allocate dumb buffers?
<emersion>
and clients can't be expected to open primary nodes?
<daniels>
the display controller can still import, e.g. from media codec
<emersion>
ah, that'd be fine
<daniels>
given how special-purpose the whole thing is, clients doing CPU rendering for UI would probably use dmabuf-heaps I'd imagine?
<emersion>
hm yeah KMS node is primary device would make sense
<emersion>
as*
<emersion>
daniels, empty leases don't allow clients to allocate on KMS node, because no FD is passed to clients
<emersion>
only the dev_t
<daniels>
emersion: ah yes
shashank1202 has quit [Quit: Connection closed for inactivity]
<emersion>
you say that we should do the read-only FD, then you say something about sending wl_arrays?
<daniels>
heh, I just opened IRC to ping you to say that I’m walking home to catch the last of the sun, so I’ll be back in 35 :)
<emersion>
ah! enjoy :)
<daniels>
but yes - there are two ways which build on each other: 1) send format+mod in a FD and send indices in an array (1 array per tranche with 1 index per F+M pair), 2) send F+M in an FD, also have the array indices in the FD, then send lookup offset+len in an event
<daniels>
so they’re the same, just whether you inline the whole array in the event or whether you just send the ‘header’ of offset+len
<daniels>
(hope phone-truncated messages are helping rather than hurting clarity …)
<emersion>
oh
<emersion>
i see now
<emersion>
i still don't know where the number 341 is coming from, it seems like the number of 12-byte items in a 4096 byte chunk
<emersion>
and 12 bytes is a format + modifier
<emersion>
but if we go for wl_array filled with indices we don't need 12 bytes
<swick>
do you even have to reference individual modifiers? the mem fd could then be just lists of modifiers that can be referenced
<emersion>
that's the offset/len idea
<swick>
emersion: something different, you tried to explain dma buf heaps the other day. I still don't get it. So a heap is just some memory somewhere with certain properties. If I allocate from that heap how do I know where this memory is located? How do I know what properties it has? How can I specify a modifier? Which modifiers are supported? When I want to share the buffer with another device/heap
<swick>
which has stricter alignment requirements how do I do that?
<swick>
emersion: oh, missed that
<emersion>
hm so i'm not an expert on memory heaps by any mean but
danvet has quit [Ping timeout: 480 seconds]
<emersion>
have a look at /usr/include/linux/dma-heap.h
<emersion>
notice how it only cares about allocation, and doesn't care at all about format/modifier/etc
<emersion>
the only args are (1) which heap (2) which size
<swick>
yeah, exactly
<swick>
I'm probably missing something really fundamental
<emersion>
so, heaps can only be used to describe an opaque "memory location"
<emersion>
users have no way to figure out the properties of the memory location
<emersion>
so the idea would be to have drivers say "i can use heap A, B and C"
<emersion>
then intersect what KMS and EGL say
<emersion>
then allocate there
<emersion>
ofc the real world would be a tad more involved…
<emersion>
in our proposal w/ jajones, we make KMS and EGL report a "constraint set"
<emersion>
basically "to display the buffer i need this and that"
<swick>
okay, let's just say that we use it only to figure out the placing of memory and ignore all the constraints and modifiers etc
<swick>
why does it allow you to allocate?
<emersion>
one of the constraints might be "i want this heap or this heap"
<emersion>
which might mean GART/VRAM/whatever
<emersion>
but then once all of the constraints from all buffer consumers are intersected
<emersion>
i don't even think we'd use the allocation ioctl
<emersion>
instead, you'd pass the intersected constraint set to GBM
<emersion>
and internally the driver will see the list of allowed heaps
<swick>
okay, so how is dma buf heaps any different from any other kind of identifier?
<emersion>
well, it works cross-driver
<emersion>
any shared global counter would work too
<swick>
but you could arbitrarily define numbers for heaps
<swick>
yeah
<emersion>
but two drivers can't use the same ID for different things
<swick>
sure
<swick>
could work pretty much like modifiers with a vendor prefix
<emersion>
if we wanted to have *some day* a generic allocator
<emersion>
we'd add a constraint set arg to dmabuf heap allcoation ioctl
<emersion>
then gbm wouldn't need to have driver specific code anymore
<swick>
at that point I would understand why dma heaps would be useful but right now... it really just seems like an odd way to give a name/identifier to things
<emersion>
pretty much
<swick>
okay, good. thanks!
<emersion>
np
shashank1202 has quit [Quit: Connection closed for inactivity]
rpigott has quit [Remote host closed the connection]
rpigott has joined #wayland
agners has joined #wayland
spstarr has quit []
shashank1202 has joined #wayland
pnowack has quit [Quit: pnowack]
xexaxo has joined #wayland
d42 has quit [Read error: Connection reset by peer]
d42 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
hardening has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
<daniels>
emersion: yeah, 341 is right for 4+8 format+mod; I was thinking 341 for array index as 4+4+4 event with one arg, but a) that's obviously not true of a wl_array, and b) that would make the one-event-per-tuple case 4+4+4+8 204 rather than 341, heh