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
carbonfiber has quit [Quit: Connection closed for inactivity]
wroathe has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
wroathe has joined #wayland
naveenk2 has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: Bouncer restarting]
hardening has joined #wayland
Lyude has joined #wayland
tzimmermann has joined #wayland
wroathe has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
naveenk2 has left #wayland [#wayland]
markbolhuis has joined #wayland
markbolhuis has quit []
kts has joined #wayland
kts has quit []
chipxxx has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
danvet has joined #wayland
cvmn has quit []
caveman has joined #wayland
rasterman has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
fmuellner has quit [Read error: Connection reset by peer]
fmuellner has joined #wayland
chipxxx has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
rgallaispou1 is now known as rgallaispou
kts has quit [Quit: Leaving]
MajorBiscuit has joined #wayland
<pq>
i509VCB, well, OpenGL does not support rendering into YUV directly, but there are ways to do it, usually more costly than rendering to ARGB framebuffer. I don't know about Vulkan. The common thing to do is to render ARGB and use the display hardware to convert to YUV on scanout, if you didn't get a KMS framebuffer already in YUV format from e.g. video decoder. And assuming the display sink requires YUV signal.
<pq>
dottedmag, the more specific Wayland spec is right.
<pq>
dottedmag, because a Wayland extension can modify the behavior of another Wayland interface.
devilhorns has joined #wayland
<pq>
i509VCB, another thing to notice is that KMS drivers probably do not support YUV in -> YUV out directly. They always convert to RGB in between anyway, AFAIU. ISTR a similar problem with quantization range, where input range is always full, so you cannot send limited-range sub-blacks or super-whites.
<pq>
(this has nothing to do with HDR, these are SDR concepts)
<pq>
i509VCB, IOW, no, I would not expect compositors to be able to produce YUV framebuffers in general.
<pq>
not via composition
<pq>
emersion, that extension seems to almost nail it. Only chroma siting is missing. :-)
<vsyrjala>
and the constant bt.2020 variant
<pq>
right
<pq>
vsyrjala, actually, it doesn't even seem to recognize the non-constant vs. constant luminance BT.2020
<vsyrjala>
i'm just assuming it means the non-const version. but who knows
<pq>
I've also forgot the definition of constant luminance by now, maybe doing that requires information that not available at that level.
<vsyrjala>
iirc it just made the maths nasty. but shouldn't need any extra info iirc
<pq>
definitely nasty, that I recall
<pq>
or right, it needed the TF
<vsyrjala>
oh, i don't remember that part. i should re-read it one day
<pq>
IIRC the difference between non-const and const lum is that to do const lum, you have undo and redo the TF
<pq>
while non-const lum you just push the pixel values through a matrix as-is
<pq>
...or was undo one TF and do another TF...
<vsyrjala>
ah indeed. yc is derived from linear rgb
<vsyrjala>
i might have missed that entirely when i first read it
<zubzub>
is there any way to get more info about this Xwayland message: EGL setup failed, disabling glamor
kts has joined #wayland
<zubzub>
fwiw it does work on intel driver, but not on nvidia (515.76) even though all other wayland clients work just fine
<zubzub>
(it's running inside a container, /var/log is emtpy and journalctl has no log)
<ofourdan>
zubzub: this is because init_egl() failed for the given backend (could be either xwl_glamor_gbm_init_egl() or xwl_glamor_eglstream_init_egl() depending on what your compositor supports with NVIDIA)
<ofourdan>
but failure cases should raise an error (ErrorF()) as well, so I woudl expect to have some more message in the logs
<ofourdan>
for GBM with NVIDIA proprietary driver, yes
<ofourdan>
but it's not Xwayladn itself that requires it
<pq>
Xwayland does not write log files, does it?
<ofourdan>
nope
<pq>
it's all just stdout/stderr, so check you didn't miss either
<ofourdan>
it writed to stderr, so in journactl it shows up as teh compositor who started it actually
<ofourdan>
*writes
<zubzub>
ic, I've based my compositors code on wlroots and things get initialized through EGL_PLATFORM_DEVICE_EXT (so that's different than using the gbm path I understand?)
<ofourdan>
I think you still need to have the libnvidia-egl-gbm glue installed for gbm to work with nvidia
<ofourdan>
"A GBM EGL external platform library is also included to enable the use of GBM objects in EGL."
<ofourdan>
that's what egl-gbm is about
<ofourdan>
(and iirc, there was also a config file required)
<ofourdan>
found it, it's /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json here
<zubzub>
yeah
<zubzub>
currently fighting the debian container image to include it ;)
<ofourdan>
(but this ships in a different package here, in fedora, that's very confusing unfortunately…)
<ofourdan>
i.e. the json file for egl-gbm ships in the package egl-wayland :)
<ofourdan>
even though we do have an egl-gbm package
<zubzub>
"Error getting buffer"
<zubzub>
A different error message! Progress! :p
<ofourdan>
hehe :)
<zubzub>
hmm
<zubzub>
libGL error: glx: failed to create dri3 screen
<ofourdan>
so it looks like you got it initialized but it does nto work
<zubzub>
libGL error: failed to load driver: nouveau
<zubzub>
o_O
<zubzub>
hmmm I guess XWayland needs the glx specific parts of the nvidia driver to work?
<ofourdan>
libglx yes
<ofourdan>
or does it…?
Company has joined #wayland
fmuellner has quit [Remote host closed the connection]
<ofourdan>
I mean, it's mesa which tries to load nouveau, not the nvidia libs, so glvnd is probably not correctly configured for the nvidia driver
<zubzub>
pretty sure it is as I explicitly log that & added the 10_nvidia.json to /usr/share/glvnd/egl_vendor.d
<zubzub>
EGL vendor: NVIDIA
<zubzub>
EGL driver name: nvidia
<zubzub>
Using EGL 1.5
<zubzub>
Using EGL device /dev/dri/renderD129
<zubzub>
Using EGL_PLATFORM_DEVICE_EXT
<zubzub>
but I am pretty sure that the libglx-nvidia library is present but as you said, why would it need that?
<zubzub>
*is not present
<zubzub>
no wait
<zubzub>
the logs tricked me, the error is from the glxgears client
<ofourdan>
ah, that makes ore sense then
<ofourdan>
*more
<zubzub>
Xwayland just says: Error getting buffer
<ofourdan>
so error getting buffer comes from a failure in the *_pixmap_get_wl_buffer()
<ofourdan>
typically xwl_glamor_pixmap_get_wl_buffer() in this case
<ofourdan>
which, assuming this is gbm and not eglstream, is implemented in xwl_glamor_gbm_get_wl_buffer_for_pixmap()
<zubzub>
hmmm do I need the 10_nvidia.json also for the client? It's currently only in the compositor container
<ofourdan>
I would say, you need it for xwayland, but I also assume xwaland runs in the same container as the compositor, I do not think the X11 client needs that (but I could be wrong)
<zubzub>
correct, I just added it to the client, didn't fix it :p
<zubzub>
indeed xwayland is in the same container as the compositor
<ofourdan>
I think the "Error getting buffer" is the root cause of the rest
<ofourdan>
you may want to add an error message for each failure case in xwl_glamor_gbm_get_wl_buffer_for_pixmap(), that might help
<zubzub>
ok I managed to reproduce it on my stock ubuntu install as well
<zubzub>
that is, when using my compositor
<zubzub>
so no containers involved
<ofourdan>
at least that takes containers out of the equation :)
<zubzub>
ok I'll guess I'll start compailing xwayland 🥲
<ofourdan>
it's fast, not very big :)
<zubzub>
anyway, thanks for the assistance!
<ofourdan>
np!
inisider has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
<inisider>
hi there. I would like to ask if an example of animation ( drawing serial of png files ) exists somewhere for libwaylind client. I tried to use OpenGLES + EGL for that and I cann't draw textures on a screen...
cvmn has joined #wayland
cvmn has quit []
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<pq>
inisider, OpenGL is no way related to Wayland. You can look for any OpenGL tutorials for that.
<pq>
for texturing, that is
<pq>
inisider, or do you mean you cannot get anything up on a screen, not even a black window?
<inisider>
pg: I can see black window plus if just color it to one color (glClearColor(0.5, 0.3, 0.0, 1.0); glClear(GL_COLOR_BUFFER_BIT)) all looks fine but when trying to display something different than I see just black screen
<inisider>
window*
fmuellner has joined #wayland
<pq>
inisider, that means all your Wayland bits work just fine. Only OpenGL parts have problems.
<pq>
inisider, or, what you mean "when trying to display something different"? If you change the clear color in a loop, only the first iteration shows up on screen?
kts has quit [Read error: Connection reset by peer]
<inisider>
pg: I mean for example if i try to draw triangle (copy/paste from book) than I am not able to see it.
<pq>
I can't guess why that could be, but I do think it's likely not related to Wayland.
<inisider>
yeah, i agree that this is not related to Wayland. thanks
jgrulich has quit [Remote host closed the connection]
<glennk>
a black screen is the natural state of an opengl app during its development
<bl4ckb0ne>
depending on what you're trying to draw, yes
jgrulich has joined #wayland
lanodan_ has joined #wayland
lanodan has quit [Read error: No route to host]
nerdopolis has joined #wayland
<drakulix[m]>
Cool, apparently the nvidia 520 driver does report some formats with `eglQueryDmaBufFormatsEXT`, that throw an InvalidArgument error, when trying to query their modifiers with `eglQueryDmaBufModifiersEXT`…
<drakulix[m]>
Not sure, if that is in spec, but it crashes smithay/anvil/cosmic-comp on EGLDisplay creation… So we need another workaround for that.
<emersion>
proprietary drivers ftw
<drakulix[m]>
*BAD_ARGUMENT (not invalid, not sure where that did come from).
<drakulix[m]>
The spec doesn’t explicitly mention this case. Any opinions about this being valid? I wonder, if that should be a report on their egl-wayland repo…
<elibrokeit>
pq, emersion, daniels: with regard to the Meson "error if unsupported" MR, I would understand if it's something you don't want to bother with...
<elibrokeit>
truth be told, the reason the WrapDB checks for this is because my threat model is "I do not trust one of the people with a commit bit", I added that check in a fit of pique after yet another case where the honor system failed.
kts has quit [Read error: Connection reset by peer]
<emersion>
to me, wrapdb is a downstream like debian or fedora is
<emersion>
if debian came and said that their tool checks for a string in an error message, my reaction would be the same
<emersion>
"keep your workarounds downstream"
<emersion>
+please
<emersion>
i really don't want to litter this kind of stuff into all of my meson projects
<pq>
elibrokeit, if the patch submitter wants to revise the patch according to feedback, I see nothing wrong with that. Otherwise, I'm not bothering anyway.
<elibrokeit>
really I just want people with a commit bit to stop pushing changesets that include "CI fails on Windows, it's supposed to work but idk why not, let me just claim that the project doesn't support windows anyway, so that CI doesn't run on Windows". :/
<pq>
not going not formulate error messages for programmatic consumption in any case
<pq>
elibrokeit, sorry, but that's not our problem.
<pq>
elibrokeit, besides, isn't that true then? The wrap doesn't work on windows.
<emersion>
can you force everything to go through PRs?
<emersion>
and add CI checks, reveiwer checks?
<emersion>
reviewer*
<elibrokeit>
yeah, I know it's not your problem, that's why I emphasize I understand if you don't want to bother with it
<elibrokeit>
emersion: the flip side is that I also like trusting people a little bit, and allowing PRs to be merged with failing CI if the result is at least better than before.
<pq>
you mean, a patch can be an improvement even if it regresses CI?
<emersion>
i think they mean, a patch is an improvement if CI still fails like before, but fails a bit later
<elibrokeit>
more like if CI already failed due to changes in dependencies, meson version, or just because we only recently added Darwin support to CI, and many wraps even predate originally adding Windows support.
<pq>
ok
<elibrokeit>
the eternal collaboration question: how much is too little trust, vs. too much trust...
<elibrokeit>
all that being said though, if a project does some basic probes to check that preconditions are met (like checking if the OS has an io uring kernel interface, or something) and erroring out with "unsupported OS, you need XXX functionality in your OS" is not a negative thing to have.
<elibrokeit>
worst case is it helps an inexperienced Windows user realize their mistake faster.
<pq>
elibrokeit, I still didn't understand what's wrong with marking a wrap to not work on Windows if it doesn't work on Windows? Do you require that a wrap must supports all OSs the original project does?
<elibrokeit>
there's also cases where adding an *optional* dependency as a wrap fallback can be somewhat confusing when building on OSes with --wrap-mode=forcefallback when suddenly that optional dependency actually gets built instead of just not being found on OSes where you don't want to build that feature.
<elibrokeit>
pq: well, yes. if the original project has a non-meson build system that builds on Windows, there's no real reason to not have the wrap do so as well, imo
<elibrokeit>
and generally when it doesn't, it's because some define wasn't added to meson.build, so I'd rather that be debugged and fixed instead of ignored.
<pq>
That seems to be at odds with your earlier opinion, that even a broken improvement can be a good improvement. E.g. adding Linux support in a wrap should be good even without Windows support, no?
andyrtr has joined #wayland
devilhorns has quit []
<elibrokeit>
"even a broken improvement" == let's merge even with failing CI, to me :D
<pq>
but the CI is not failing, if it's disabled for that OS
<elibrokeit>
when you disable CI, you forget it exists
<pq>
I guess the question is, if CI is disabled for that OS, would Meson still attempt to build on that OS? Maybe it should just abort at start.
<pq>
that way unlucky people won't see cryptic errors of not found io_uring symbols, but the build dies with a clear error "unsupported OS in wrap" before it even configures.
<pq>
so either you fix the CI, or the wrap simply refuses to run at all on that OS
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
gschwind has joined #wayland
bodiccea has joined #wayland
wroathe has joined #wayland
fahien has joined #wayland
fmuellner has quit [Remote host closed the connection]
anarsoul|2 has quit [Read error: Connection reset by peer]
<mntirc>
hey, i have a bizarre problem after upgrading debian unstable today (on mnt reform laptop). wayland is completely broken, regardless of compositor (weston, sway, wayfire)
<mntirc>
all clients basically exit with "wl_shm@10: error 1: invalid size (0)"
bookworm has joined #wayland
<mntirc>
i'm currently on Xorg on dumb framebuffer to be able to google things... but not really sure how to attack this. any ideas?
<mntirc>
weston with WAYLAND_DEBUG=server:
<mntirc>
[ 61031.521] wl_shm@10.create_pool(new id wl_shm_pool@3, fd 22, 4096)
<mntirc>
clients get disconnected after first surface commit
<bl4ckb0ne>
mmap issue maybe?
<mntirc>
hmm
<bl4ckb0ne>
strace it
<mntirc>
weston-info (running against sway which is able to show a blank screen and cursor, but no clients), shows bizarre data
<mntirc>
like wl_output physical_height: -101 mm
<mntirc>
refresh: -0.104 Hz
<mntirc>
and the formats and modifiers also all look like garbage, mostly zeroes with one byte set
<bl4ckb0ne>
doesnt look good
<mntirc>
seems like something fundamental is broken, maybe corrupted kernel image or something like that?
<bl4ckb0ne>
maybe something missing or a connector not plugged appropriately
<bl4ckb0ne>
you said its the mnt reform, did you assembled it yourself?
<mntirc>
bl4ckb0ne: well, i designed it
<soreau>
where are you getting these clients, self compiled or debian repos?
<mntirc>
debian unstable
<soreau>
have you tried compiling a client yourself to see if it works?
<bl4ckb0ne>
oh my bad
<mntirc>
everything was fine until i rebooted after an apt upgrade in the morning
<mntirc>
soreau: i haven't tried running a self built client against a wl server today, no
<mntirc>
will do
wroathe has joined #wayland
<mntirc>
i built https://github.com/christianrauch/weston_image and after commenting out 1 assertion (it looks for display->xdg_shell) it crashes with the same error, wl_shm@4: error 1: invalid size (0)
<mntirc>
well, guess i have to build the whole stack from source incl wayland, the server etc