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
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
flacks_ has joined #wayland
flacks has quit [Ping timeout: 480 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
mclasen has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #wayland
zebrag has joined #wayland
zebrag has quit []
rv1sr has quit []
slattann has joined #wayland
Company has quit [Read error: Connection reset by peer]
jgrulich has joined #wayland
danvet has joined #wayland
tzimmermann has joined #wayland
mbalmer has joined #wayland
dcz_ has joined #wayland
hardening has joined #wayland
ppascher has quit [Read error: Connection reset by peer]
ppascher has joined #wayland
mvlad has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
danvet has quit [Remote host closed the connection]
<wlb> weston/main: Derek Foreman * ci: Fix cobertura syntax https://gitlab.freedesktop.org/wayland/weston/commit/0f4b41109171 .gitlab-ci.yml
<wlb> weston Merge request !896 merged \o/ (ci: Fix cobertura syntax https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/896)
danvet has joined #wayland
marex has joined #wayland
marex has quit []
marex has joined #wayland
immibis has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
___nick___ has joined #wayland
<pq> zubzub, err, yeah, you do need to have everything use the same instance of libwayland-server. If Mesa calls the original libwayland-server when obviously that won't run your special libwayland-server code.
wvanhauwaert has joined #wayland
<pq> *then
jimjams has quit [Quit: Connection closed for inactivity]
<wvanhauwaert> Hello, I have this issue, but don't know quiet where or how to start debug it. I'm using wayland on imx53. On top of that, I want to use waylandsink. However, the colors of it seem to be wrong completely
<wvanhauwaert> Is there a known issue using imx53/freedreno/mesa?
<wvanhauwaert> linux 5.15, mesa 22.0.2, weston 10
<pq> wvanhauwaert, hi, nothing comes to my mind unfortunately.
<pq> is it red-blue swap or something more wild?
<wvanhauwaert> it's like there's some shifted red shadow...
<wvanhauwaert> note that kmssink seems to work ok
<pq> wow, that's definitely wild
<wvanhauwaert> I'm using parallel disp-out btw (if that helps)
<pq> it's like Y-plane is ok, but UV planes have a bad offset
<pq> but stride is ok
<wvanhauwaert> I stumbled upon following patch: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/966/diffs, which seems to fix it in one way or another for one video playing, as long as geometry is in boundaries (640x480 is ok, 641x480 makes it bad again)
<pq> so it's weston 10 release?
<wvanhauwaert> also, if it's playing well, with this patch, and I start a second video, second video gets ok, previous (already playing one) gets messed up. Untill I stop the second one, than the first one gets fine again
<wvanhauwaert> I'm building using yocto kirkstone, I guess it's weston 10 release, give me a min
<wvanhauwaert> yes, 10 release
<pq> oh, that sounds even more wild
ahartmetz has joined #wayland
<pq> ok, so here is an equally wild guess:
<pq> without the gst patch to mentioned, the video is going through GL ES in Weston. With the patch, the video starts hitting KMS scanout directly. When you start another video, the new one goes to KMS scanout and the old one reverts to going through GL ES.
<pq> When video goes to KMS scanout, it's ok. When it goes through GL ES, it's broken.
<wvanhauwaert> well, I can try things out and try to debug if I get some direction...
<wvanhauwaert> the idea would be to get video on it's own plane
<wvanhauwaert> imx53 has 2 hw planes
<wvanhauwaert> and laks performance to composite everything through gl
<pq> This could be verified by looking at 'weston --logger-scopes=log.drm-backend'. It's a flood, but we only need to see one frame's worth for each situation.
<pq> that will tell us which windows use KMS direct scanout and which don't
<wvanhauwaert> (final goal is to have a wpe-webkit browser running on one plane, and video on the other one. Thus avoiding gpu composition)
<pq> If indeed only "video composited with GL ES" is broken like that, then it would point at Mesa.
<pq> probably
<pq> that logger-scopes command line will print to the Weston log how it arranges each output frame and the reasons why
<pq> Weston's main branch has a lot of refactoring done to the buffer handling in GL-renderer and all over, but it should not make a difference I think.
<wvanhauwaert> no, last week, I tried main weston, but result was equal
<wvanhauwaert> I'll make some logging
<wvanhauwaert> (did already last week, but forgot what was what ;))
<wvanhauwaert> Ah, here I have it, 2 video's playing, so one with the good colors, one with the bad colors (after applying above patch)
<wvanhauwaert> And this is one video playing, with above patch applied: https://gist.github.com/woutervanh/6ddf0d479d67e3447a880f953e6bca7b
<pq> wvanhauwaert, your two-videos log confirms that the top-most (more recently opened?) of them hits KMS scanout, while the other goes through GL ES.
<wvanhauwaert> yes, the recently opened is always correct
<wvanhauwaert> but now I'll try with an odd geometry single video
<pq> weston probably does not handle odd-dimensions NV12 images correctly
<pq> that's a separate bug
<pq> in the single-video log, the video goes through GL ES
<pq> "renderer composition" means GL ES, because it's GL-renderer doing it
<pq> I suppose that confirms that KMS direct scanout path is good, and the GL-renderer path is broken?
<wvanhauwaert> it's not even "odd geometry"
<wvanhauwaert> just putting it fullscreen already breaks it (fullscreen=1 in waylandsink)
<pq> fullscreen breaks it the same way again? or in a different way?
<wvanhauwaert> same way
<wvanhauwaert> so fullscreen=0 => looks ok, only small window but colors ok. fullscreen=1 => disturbed colors as I showed screenshot before
<pq> ok
<wvanhauwaert> I see there are 3 views generated now for fullscreen. Whereas there were only 2 views for normal video...
<wvanhauwaert> (actually, I also don't understand why there are 2 views for a single video. Makes things more complex, no? wayland needs to give them all a place)
<pq> the video sub-surface fully occludes everything else, so the others should not matter
<pq> "ignoring view 0x... (occluded on our output)"
<pq> in the fullscreen log, the kernel driver rejects all attempts KMS scanout directly, so it goes through GL ES
<pq> wvanhauwaert, looks like you have at least two separate things to look into: why GL ES path causes color problems, and why KMS direct scanout is refused in some cases.
<pq> in the GL ES path, there are two sub-paths: GL-renderer first attempts to import the NV12 buffer as-is into EGL, and if that works, then the GL driver is responsible for NV12->RGB conversion. If it doesn't work, then GL-renderer does NV12->RGB conversion itself in its own shader.
<pq> unfortunately Weston doesn't have debug prints to tell which
<wvanhauwaert> soooo, for my usecase, I need to figure out why kms-scanout to the front-plane is not working, do basically getting into the kernel to check why it's refusing
<pq> pretty much
<wvanhauwaert> GL ES path is to less performant anyway
<wvanhauwaert> and I need my GL for the browser ;-)
<pq> yeah, and the GL ES color bug tells you when you fail to scanout :-D
<pq> Weston also has a green tint mode to tell you which stuff is going through GL ES composition, if you need that.
<wvanhauwaert> and where do I see that in my log? That kernel refuses?
<pq> ...see 'man weston-bindings' for debug bindings
<pq> that's the "[overlay] not placing view 0x1549d90 on overlay 37 in mixed mode: kernel test failed"
<pq> right before that line it prints the KMS state it is attempting
<wvanhauwaert> aha, ok
<wvanhauwaert> thanks
<pq> another of the same is "[view] failing state generation: atomic test not OK"
<pq> so first Weston tries to build planes-only state, which means GL-renderer would not be used at all, and tests all of that in one go.
Dami_Lu has quit [Ping timeout: 480 seconds]
<pq> if that fails, then it assumes GL-renderer puts its buffer on the primary plane, and then tests each added overlay plane one by one.
Dami_Lu has joined #wayland
<mriesch> daniels: just fyi the faulty behavior i encountered could not be reproduced with the vop2/dw_hdmi driver in v5.19-rc1
<mriesch> this version cannot output 4k formats, though. there are a few patches around which seem to trigger these hotplug failures.
mclasen has joined #wayland
<zubzub> 10:22 < pq> zubzub, err, yeah, you do need to have everything use the same instance of libwayland-server. If Mesa calls the original libwayland-server when
<zubzub> obviously that won't run your special libwayland-server code.
<zubzub> yeah I'm currently implement linux-dmabuf-v1
<zubzub> as in c/p wlroots implementation
<wvanhauwaert> pq, thanks for the heads-up, I'll try to dive into a little deeper
Azem has joined #wayland
manuel1985 has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
Azem has joined #wayland
dcz_ has joined #wayland
Company has joined #wayland
devilhorns has joined #wayland
EmetSelch has joined #wayland
Azem has quit [Read error: Connection reset by peer]
EmetSelch has quit [Read error: Connection reset by peer]
EmetSelch has joined #wayland
mclasen has quit []
<wlb> weston Merge request !614 closed (xwayland: Fix a typo and an incorrect xwayland window movement)
<wlb> weston/main: Luigi Santivetti * gitlab-ci: build libdrm version 2.4.108 from source https://gitlab.freedesktop.org/wayland/weston/commit/08a821f291cd .gitlab-ci.yml .gitlab-ci/build-deps.sh .gitlab-ci/debian-install.sh
<wlb> weston/main: Luigi Santivetti * drm-backend: stop parsing IN_FORMATS blobs, use libdrm instead https://gitlab.freedesktop.org/wayland/weston/commit/a62bf5ff487b libweston/backend-drm/kms.c libweston/pixel-formats.c meson.build
<wlb> weston/main: Luigi Santivetti * Revert "backend-drm: add HDR_OUTPUT_METADATA definitions" https://gitlab.freedesktop.org/wayland/weston/commit/8b654c47ebd8 doc/sphinx/doxygen.ini.in libweston/backend-drm/kms-color.c libweston/backend-drm/meson.build libweston/backend-drm/libdrm-updates.h
<wlb> weston Merge request !454 merged \o/ (Use DRM iterators in the drm-backend https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/454)
ahmadraniri[m] has joined #wayland
<dv_> so, in the past, I remember criticisms about wayland regarding near complete lack of colorimetry support, as in "sRGB is enough for everybody"
<dv_> from what I see, this has changed significantly?
<pq> yeah, that is totally not true for a number of years by now
<pq> I'm not sure it has ever been true
nerdopolis has joined #wayland
<swick> it's not only wayland (compositors) which didn't care about color
<swick> the gstreamer GL path also just throws away all colorimetry information
<swick> UI toolkits usually don't even have a notion of colorimetry
<dottedmag> They have a peculiar implicit notion of a single colorspace, I'd say :)
<wlb> weston Merge request !900 opened by () backend-drm: set connector max bpc https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/900 [DRM/KMS backend], [Weston frontend]
mclasen has joined #wayland
<wvanhauwaert> pq, I think I found the cullprit in wayland not addressing kms
<wvanhauwaert> [drm:drm_atomic_helper_check_plane_state] Invalid scaling of plane, src: 640.000000x360.000000+0.000000+0.000000, dst: 1920x1080+0+0
<pq> aha, so the driver doesn't like to scale like that
<pq> if that's a real hardware limitation, then tough luck
<wvanhauwaert> I don't think it's a hardware limitation. imx53 has some scalers inside, so I guess that should be capable
<emersion> this comes from drm_atomic_helper_check_plane_state, which has a min_scale and a max_scale
<pq> yeah, would be odd if it didn't
<emersion> you could check with which args the driver calls this function
<emersion> and make sure they reflect real hw limitations
<emersion> maybe it's just a missing feature in the driver
<wvanhauwaert> yes, I'm checking out now. drm_rect_calc_hscale or drm_rect_calc_vscale would return < 0, which seems odd to me, I'll add some debug
cool110_ has joined #wayland
cool110 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<wvanhauwaert> hm, min_hscale 65536, max_hscale 65536, getting somewhere I guess ;-)
EmetSelch has quit [Ping timeout: 480 seconds]
mclasen has quit []
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
rgallaispou has joined #wayland
rgallaispou has quit []
rgallaispou has joined #wayland
rv1sr has joined #wayland
mclasen has joined #wayland
jimjams has joined #wayland
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #wayland
neonking has joined #wayland
wv_ has joined #wayland
wvanhauwaert has quit [Ping timeout: 480 seconds]
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
wvanhauwaert has joined #wayland
wvanhauwaert has quit []
wvanhauwaert has joined #wayland
andyrtr has joined #wayland
wvanhauwaert has quit []
wv_ has quit []
wvanhauwaert has joined #wayland
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #wayland
Azem has joined #wayland
manuel1985 has quit []
luc4 has joined #wayland
dreda has joined #wayland
marex has quit [Ping timeout: 480 seconds]
devilhorns has quit []
zebrag has joined #wayland
<wlb> weston Merge request !901 opened by () rdp: Prepare for future FreeRDP releases https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/901 [RDP backend]
jgrulich has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
immibis has joined #wayland
neonking_ has joined #wayland
kchibisov_ has joined #wayland
vyivel_ has joined #wayland
ifreund_ has joined #wayland
sumoon has joined #wayland
bookworm_ has joined #wayland
FLHerne_ has joined #wayland
larunbe has joined #wayland
dos1 has joined #wayland
LaserEyess_ has joined #wayland
pounce| has joined #wayland
tzafrir_laptop has joined #wayland
hardening_ has joined #wayland
Lucretia-backup has joined #wayland
dreda_ has joined #wayland
dreda has quit [reticulum.oftc.net helix.oftc.net]
rasterman has quit [reticulum.oftc.net helix.oftc.net]
ppascher has quit [reticulum.oftc.net helix.oftc.net]
hardening has quit [reticulum.oftc.net helix.oftc.net]
pounce has quit [reticulum.oftc.net helix.oftc.net]
Hypfer has quit [reticulum.oftc.net helix.oftc.net]
zebrag has quit [reticulum.oftc.net helix.oftc.net]
neonking has quit [reticulum.oftc.net helix.oftc.net]
ahartmetz has quit [reticulum.oftc.net helix.oftc.net]
Lucretia has quit [reticulum.oftc.net helix.oftc.net]
Lumpio- has quit [reticulum.oftc.net helix.oftc.net]
kchibisov has quit [reticulum.oftc.net helix.oftc.net]
japchae[m] has quit [reticulum.oftc.net helix.oftc.net]
sumoon_ has quit [reticulum.oftc.net helix.oftc.net]
ifreund has quit [reticulum.oftc.net helix.oftc.net]
vyivel has quit [reticulum.oftc.net helix.oftc.net]
tleydxdy has quit [reticulum.oftc.net helix.oftc.net]
al has quit [reticulum.oftc.net helix.oftc.net]
gusnan has quit [reticulum.oftc.net helix.oftc.net]
dos11 has quit [reticulum.oftc.net helix.oftc.net]
dv_ has quit [reticulum.oftc.net helix.oftc.net]
LaserEyess has quit [reticulum.oftc.net helix.oftc.net]
pac85[m] has quit [reticulum.oftc.net helix.oftc.net]
rubo_[m] has quit [reticulum.oftc.net helix.oftc.net]
unrelentingtech has quit [reticulum.oftc.net helix.oftc.net]
cb5r[m] has quit [reticulum.oftc.net helix.oftc.net]
JosExpsito[m] has quit [reticulum.oftc.net helix.oftc.net]
MA[m] has quit [reticulum.oftc.net helix.oftc.net]
gnustomp[m] has quit [reticulum.oftc.net helix.oftc.net]
FbioPacheco[m] has quit [reticulum.oftc.net helix.oftc.net]
varlad[m] has quit [reticulum.oftc.net helix.oftc.net]
jryans has quit [reticulum.oftc.net helix.oftc.net]
deknos82[m] has quit [reticulum.oftc.net helix.oftc.net]
Nico has quit [reticulum.oftc.net helix.oftc.net]
pitsch[m] has quit [reticulum.oftc.net helix.oftc.net]
Kelseyjgilbert[m] has quit [reticulum.oftc.net helix.oftc.net]
emilio[m] has quit [reticulum.oftc.net helix.oftc.net]
i509VCB has quit [reticulum.oftc.net helix.oftc.net]
Sumera[m] has quit [reticulum.oftc.net helix.oftc.net]
cmeissl[m] has quit [reticulum.oftc.net helix.oftc.net]
[old]freshgumbubbles[m] has quit [reticulum.oftc.net helix.oftc.net]
ujineli[m] has quit [reticulum.oftc.net helix.oftc.net]
danburd[m] has quit [reticulum.oftc.net helix.oftc.net]
Eighth_Doctor has quit [reticulum.oftc.net helix.oftc.net]
aplund[m] has quit [reticulum.oftc.net helix.oftc.net]
nielsdg has quit [reticulum.oftc.net helix.oftc.net]
mooff[m] has quit [reticulum.oftc.net helix.oftc.net]
bluepenquin has quit [reticulum.oftc.net helix.oftc.net]
zamundaaa has quit [reticulum.oftc.net helix.oftc.net]
juergbi has quit [reticulum.oftc.net helix.oftc.net]
bookworm has quit [reticulum.oftc.net helix.oftc.net]
emersion has quit [reticulum.oftc.net helix.oftc.net]
FLHerne has quit [reticulum.oftc.net helix.oftc.net]
ofourdan has quit [reticulum.oftc.net helix.oftc.net]
tzafrir has quit [reticulum.oftc.net helix.oftc.net]
alarumbe has quit [reticulum.oftc.net helix.oftc.net]
zebrag has joined #wayland
Hypfer has joined #wayland
emersion has joined #wayland
LaserEyess_ has quit []
rasterman has joined #wayland
gusnan_ has joined #wayland
Lumpio- has joined #wayland
dv_ has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
danburd[m] has joined #wayland
ujineli[m] has joined #wayland
ppascher has joined #wayland
Eighth_Doctor has joined #wayland
bluepenquin has joined #wayland
aplund[m] has joined #wayland
mooff[m] has joined #wayland
juergbi has joined #wayland
al has joined #wayland
cb5r[m] has joined #wayland
deknos82[m] has joined #wayland
i509VCB has joined #wayland
cmeissl[m] has joined #wayland
Nico has joined #wayland
LaserEyess has joined #wayland
ofourdan has joined #wayland
zamundaaa has joined #wayland
pac85[m] has joined #wayland
FbioPacheco[m] has joined #wayland
gnustomp[m] has joined #wayland
slattann has quit []
JosExpsito[m] has joined #wayland
ifreund_ is now known as ifreund
Sumera[m] has joined #wayland
varlad[m] has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
jryans has joined #wayland
pnowack has joined #wayland
pnowack has quit [Quit: pnowack]
pnowack has joined #wayland
larunbe has left #wayland [#wayland]
larunbe has joined #wayland
luc4 has quit []
larunbe is now known as alarumbe
<alarumbe> /g
alarumbe has left #wayland [WeeChat 3.5]
alarumbe has joined #wayland
mvlad has quit [Remote host closed the connection]
gusnan_ has left #wayland [#wayland]
mbalmer has quit []
nielsdg has joined #wayland
bindu_ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
bindu has quit [Ping timeout: 480 seconds]
immibis has quit [Remote host closed the connection]
immibis has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
zebrag has quit [Quit: Konversation terminated!]
vxrer888 has joined #wayland
marex has joined #wayland
<i509VCB> Would wl_shm benefit from adding something like wp_linux_dmabuf_feedback? At the moment most clients assume wl_shm's reported formats will work on all gpus. However different gpus may not be able to work with the same wl_shm formats as some other gpu on your system. I would think something like surface and default feedback for wl_shm would allow clients to allocate wl_shm buffers the gpu would not need to manually convert in software before
<i509VCB> upload.
vxrer888 has quit []
<emersion> i don't think that really makes a difference
<ManMower> I think if you care about performance you probably shouldn't be using wl_shm anyway, so I'm not certain there's value in trying to optimize that path
<emersion> wl_shm is slow no matter what
<emersion> also not sure there are really big differences between drivers
zebrag has joined #wayland
<i509VCB> My question probably relates more to multi-gpu systems. If I launch an app on the dgpu and the dgpu turns on, how would I tell clients that use wl_shm, "hey I'd really prefer you use this subset of wl_shm formats so I don't need to manually convert your buffers before import or in the graphics api".
<i509VCB> of course I could just use a lowest common denominator of shm formats
dcz_ has quit [Ping timeout: 480 seconds]
<i509VCB> but what is said lowest common denominator can vary depending on hw configurations
<emersion> same answer as above: it doesn't vary much, and a manual shader conversion doesn't make a lot of difference
japchae[m] has joined #wayland
pitsch[m] has joined #wayland
cool110 has joined #wayland
cool110_ has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
rubo_[m] has joined #wayland
FLHerne_ is now known as FLHerne
FLHerne is now known as FLHerne_
FLHerne_ is now known as FLHerne
MA[m] has joined #wayland
hardening_ has quit [Ping timeout: 480 seconds]
emilio[m] has joined #wayland
tleydxdy has joined #wayland
unrelentingtech has joined #wayland
Kelseyjgilbert[m] has joined #wayland
ghostbuster has joined #wayland
tzimmermann_ has joined #wayland
tzimmermann has quit [Ping timeout: 480 seconds]