ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
basemale has joined #wayland
botiapa[m] has joined #wayland
Mershl[m] has joined #wayland
kenrendell[m] has joined #wayland
windowsxp[m] has joined #wayland
hex[m]1 has joined #wayland
j-james[m] has joined #wayland
tzx[m] has joined #wayland
mblenc1 has joined #wayland
YHNdnzj[moz] has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
mrkzboo[m] has joined #wayland
Bran[m] has joined #wayland
FbioPacheco[m] has joined #wayland
ErikReider[m] has joined #wayland
elinor has joined #wayland
gnustomp[m] has joined #wayland
KingoftheElves[m] has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
Kelseyjgilbert[m] has joined #wayland
teaper[m] has joined #wayland
JosExpsito[m] has joined #wayland
rails[m] has joined #wayland
dani-g5x[m] has joined #wayland
PavelNasevich[m] has joined #wayland
Poly[m] has joined #wayland
diamondburned[m] has joined #wayland
swick[m] has joined #wayland
d_ed[m] has joined #wayland
ammen99[m] has joined #wayland
Russ[m] has joined #wayland
neobrain[m] has joined #wayland
bim9262 has joined #wayland
ahmadraniri[m] has joined #wayland
luks2[m] has joined #wayland
Brainium has joined #wayland
yshui` has joined #wayland
furyishere[m] has joined #wayland
zamundaaa[m] has joined #wayland
nazarewk[m] has joined #wayland
hariselldon[m] has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Guest6892 is now known as DemiMarie
mblenc has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
<ErrorNoInternet>
zamundaaa[m]: KWIN_DRM_DEVICES does seem to work! i set the first device as my nvidia GPU and my second as the intel gpu (otherwise it would lock up my display and keyboard). kwin_wayland looks like its running on my nvidia gpu, not 100% sure if its real though
mblenc1 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
sevz has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
gallo has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
gallo has joined #wayland
abeltramo58952 has quit [Ping timeout: 480 seconds]
<ifreund>
the protocol doesn't state explicitly whether compositors are required to send a wl_keyboard.keymap event before the first wl_keyboard.enter event
<ifreund>
is this in fact required or not?
<emersion>
IMHO keymap should be sent on keyboard object creation always
<pq>
...if a keymap exists to begin with
<emersion>
we have NO_KEYMAP
<pq>
what fd do you send?
<emersion>
unfortunately FDs are not nullable so you need to send a /dev/null or something
<pq>
right
<ifreund>
Either way, it would be good to document this in the protocol
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
cmichael has joined #wayland
rv1sr has joined #wayland
Guest6936 has quit [Remote host closed the connection]
Net147 has quit [Remote host closed the connection]
Brainium has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Net147 has joined #wayland
dogukan has joined #wayland
rv1sr has quit []
zamundaaa has quit [Server closed connection]
mupuf has quit [Server closed connection]
mupuf has joined #wayland
bim9262 has joined #wayland
wlb has quit [Server closed connection]
pedrocr has quit [Server closed connection]
pedrocr has joined #wayland
zamundaaa has joined #wayland
cvmn has quit [Remote host closed the connection]
caveman has joined #wayland
GentooPhysicist3935426 has quit [Server closed connection]
GentooPhysicist3935426 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
bim9262 has joined #wayland
<Company>
robertmader[m]: you're aware that mutter's YUV stuff is busted on AMD because of the stride issue?
glennk has joined #wayland
<robertmader[m]>
Company: shouldn't be the case for anything produced by VA-API
<robertmader[m]>
But yeah, for cameras it's difficult.
<Company>
I had thought you importing as RGB would work around it
<robertmader[m]>
Nah, AMD really wants to have stuff aligned. Annoying - but IMO video playback is also way more interesting. I wonder if we can either make the AMD devs add some workaround for dmabufs from sysmem - or if the stride should somehow be negotiable (via pipewire) and if v4l2 could produce stuff accordingly.
benbrown has quit [Server closed connection]
benbrown has joined #wayland
pH5 has quit [Server closed connection]
pH5 has joined #wayland
<Company>
robertmader[m]: the conclusion last time was that everybody should just allocate at strides of 256 by default
<Company>
robertmader[m]: but I didn't talk to v4l people about that idea
<robertmader[m]>
<robertmader[m]> "Nah, AMD really wants to have..." <- I mean - I can see that they want the stride if the buffer comes from the same GPU/driver. But if they have to move the buffer to vram anyway, why not add padding themselves somehow?
<pq>
what do you know, Dr. Charles Poynton is on Mastodon.
mblenc1 has joined #wayland
ivyl has quit [Server closed connection]
ivyl has joined #wayland
<Company>
robertmader[m]: I don't think mapping memory works that way?
<robertmader[m]>
AFAIK dmabufs are some kind of magic where kernel drivers move things around - which is why it's easy to get wrong / super slow.
nerdopolis has joined #wayland
<Company>
it's mostly easy to get wrong because nobody talks to anyone else
<pq>
dmabuf are explicitly not like that, for that very reason
<Company>
and there's no best practices
mblenc has quit [Ping timeout: 480 seconds]
<daniels>
well, with dmabufs you can move the underlying storage, but you can't mutate the data - padding out stride to a different alignment definitely counts as mutation
<daniels>
as soon as you do that, you have a different copy of the data, so it's very much not dmabuf
<pq>
The original dmabuf idea was to share the handle with all involved devices first, and only afterward trigger the actual allocation. But then turned out that everyone just allocate first and export a handle second.
mblenc has joined #wayland
<Company>
that's also hard to pass through the stack
<pq>
yes, I believe convience was a very big reason to not do the original plan.
<Company>
because suddenly the compositor needs to talk to the app so it can tell pipewire to make them all share the involved devices
<pq>
daniels, who is "you" there?
<Company>
another thing I suspect dmabuf is suffering from today is that people on embedded stuff all make their devices compatible
<pq>
maybe the exported can move the data before anyone has imported the dmabuf?
<pq>
*exporter
<Company>
because it's easy - you know what devices are in the soc and can hack the drivers
<daniels>
pq: correct, I believe it's valid for storage to be moved when no-one else has an active attach
mblenc1 has quit [Ping timeout: 480 seconds]
<Company>
but the desktop stack with its random device combinations hasn't used dmabufs much
<pq>
daniels, doesn't that mean that if AMD is importing something allocated by someone else, it cannot move it to make it compatible with AMD hw?
<daniels>
pq: I think you're right to say that
<Company>
everyone dup()s the fds at least
<daniels>
though iirc there is a move callback you can use? or maybe that was just TTM-internal and not usable for dmabufs generically
<pq>
unless maybe if the exporter already dropped all references to it? preventing re-use
<pq>
daniels, moving is a heavy operation. Would that really be semantically ok to do on dmabuf import?
<daniels>
\_o_/
<pq>
I aasumed not.
<emersion>
i would really really like a way to check whether an import will cause a move or not
<Company>
A move is certainly better than not importing
<emersion>
because right now it's… import into KMS, do a test commit, that fails -- too late, time already been spent on moving stuff around needlessly
<pq>
yeah, sometimes even a fallback might be better than a move, I imagine
<pq>
maybe the move forbids re-use because the source device loses usability, or maybe that case would simply refuse to move
<kennylevinsen>
reminds me of the need for being able to do a test commit with a buffer before it is allocated (to try modifiers)...
<kennylevinsen>
(vaguely related to "test a buffer without doing an import")
nerdopolis has quit [Remote host closed the connection]
<emersion>
yeah that too…
<emersion>
if only someone was paid to solve all problems in FOSS
* kennylevinsen
stares at emersion
<kennylevinsen>
:D
* emersion
stares at the wall behind
nerdopolis has joined #wayland
<kennylevinsen>
one person is enough, right? Not that much open source code out there to fix
<emersion>
it's mainly AMD headers anyways
<kennylevinsen>
hah, true
fmuellner has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
<daniels>
emersion: … without creating new problems?
bim9262 has joined #wayland
<emersion>
i don't know what you're talking about
<emersion>
the fact that v3d/vc4 is totally not my fault and i don't know anything about it
<emersion>
is broken is*
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
puck_ has quit [Server closed connection]
puck_ has joined #wayland
Arsen has quit [Server closed connection]
Arsen has joined #wayland
<MrCooper>
robertmader[m]: the drivers can't know when they'd need to copy from the dma-buf to their shadow copy, so they'd have to either pessimize that or risk glitches
<MrCooper>
Company: dma-buf is the central mechanism for hardware acceleration on any non-ancient Linux desktop; presumably you mean specifically for inter-device sharing, which isn't the main use case for dma-buf
<Company>
MrCooper: I also specifically mean same device but different software stack
<Company>
va-api vs GL vs Vulkan vs qemu isn't without problems either
<daniels>
MrCooper: systems with three separate codec/GPU/display devices would violently disagree with you
<Company>
even high0level things like GL handing me DRM_MODIFIER_INVALID and Vulkan not allowing that
<MrCooper>
daniels: didn't say there were no other use cases
<MrCooper>
but the main one is surely passing dma-bufs for the same device between different processes
<Company>
like, I have 4 use cases here, and only one of them seems to work with another one working if I do the right thing
<Company>
and 3 use cases are same device
dogukan has quit [Remote host closed the connection]
<Company>
screencasting, webcam, qemu and video decode
<daniels>
MrCooper: it came out of a Linaro F2F in 2012 (?), so it was hardly a random afterthought …
<Company>
screencasting works, webcam is the stride thing, qemu is busted and video decoding gets stuck in GStreamer somewhere
<MrCooper>
to be clear, I mean main as in "most often used"
<Company>
I have the feeling on desktop, dmabuf is almost exclusively wl_buffer until pretty recently when video decode started happening
<Company>
on embedded, it's a lot more wild what people are doing
<Company>
there are some weird GStreamer pipelines with single-usecase elements
modin has quit [Server closed connection]
modin has joined #wayland
<Company>
that shuffle video between webcams, video decode/encode, and display systems
<daniels>
MrCooper: if you’re counting by number of devices, then same-device is a very very significant minority
ofourdan has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
<Vanfanel>
Hello. I am trying to implement pointer constraints in the CAGE compositor, but if I include "wlr_pointer_constraints_v1.h", I get an error abut "pointer-constraints-unstable-v1-protocol.h" being missing. Where is that "pointer-constraints-unstable-v1-protocol.h" file supposed to come from?
<emersion>
Vanfanel: i'd suggest asking in #wlroots on Libera
Amber_Harmonia has quit [Server closed connection]
Amber_Harmonia has joined #wayland
shoragan has quit [Server closed connection]
shoragan has joined #wayland
DPA has quit [Server closed connection]
DPA has joined #wayland
glennk has joined #wayland
fossdd_ has quit [Server closed connection]
fossdd has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
<JPEW>
We are looking at adding support to the fullscreen shell for a background image (sort of like the desktop shell). Assuming this is even possible, would weston upstream accept this? It would really help with some usability complaints we've had while using weston
<JPEW>
And I hate not upstreaming things first :)
<emersion>
doesn't weston already support fullscreen-shell?
<emersion>
why do you want fullscreen-shell, and not desktop shell?
<JPEW>
emersion: Sorry perhaps not clear, we are using the fullscreen shell as is, we want to add support for a background image to it
<JPEW>
We kinda have to use fullscreen shell because it's an embedded device with multiple monitor support and we need precise control over what gets displayed on what monitor
<daniels>
JPEW: we’re using Weston’s kiosk mode for that these days, with xdg-shell for clients
<JPEW>
daniels: Ya, I've been told to look at that; we're still on some older weston(s) and we have some pretty strict requirements so IDK if kiosk would work (need to look though)
<daniels>
that’s much more actively maintained, and makes the clients less weird :) it does also have support for background colours, and directing specific surfaces to specific outputs
<daniels>
but yeah, if there’s something missing we could look at it
<JPEW>
Ya, it's on our TODO list to look at kiosk shell... I don't think we can get rid of fullscreen shell yet though. I was mostly check to see if we did add support for a background image to the fullscreen shell it wouldn't get outright rejected for some reason :)
mblenc has joined #wayland
mblenc1 has joined #wayland
flom84 has joined #wayland
<daniels>
JPEW: hmm, it is deprecated and scheduled for removal at the next point it stands in the way of some other useful work … but a patch against 8.x wouldn’t apply anyway
<JPEW>
Oh.... well.... that's not good :/
mblenc has quit [Ping timeout: 480 seconds]
flom84 has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]