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
pnowack_ has joined #wayland
pnowack has quit [Ping timeout: 480 seconds]
caveman has quit [Quit: bbl]
sadlerap1 has joined #wayland
sadlerap has quit [Ping timeout: 480 seconds]
c7s has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
pnowack_ has quit []
remanifest has quit [Remote host closed the connection]
remanifest has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
TattooedTech has joined #wayland
maxzor has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
fltrz_ has joined #wayland
fltrz__ has quit [Ping timeout: 480 seconds]
yrlf5 has quit []
yrlf has joined #wayland
maxzor has joined #wayland
zebrag has joined #wayland
zebrag has quit []
danvet has joined #wayland
txtsd has joined #wayland
agd5f_ has joined #wayland
boistordu_ex has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
remanifest has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
dcz_ has joined #wayland
jgrulich has joined #wayland
txtsd is now known as Guest8056
txtsd has joined #wayland
Guest8056 has quit [Read error: Connection reset by peer]
maxzor has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
creich has joined #wayland
tzimmermann has joined #wayland
maxzor has joined #wayland
rasterman has joined #wayland
<pq>
zamundaaa, why do you need to test enabling an extra plane if the CRTC is not active to begin with?
<pq>
zamundaaa, an atomic commit can fail any time for any reason, and when that happens, you need to fall back. Usually that means dropping an extra plane from the state until only the primary plane is left.
<pq>
I'n order to not glitch with that, you *always* do test-only commits first to find out if your current configuration is going to work or not.
pnowack has joined #wayland
<pq>
Once you have found the KMS configuration that works according to a test-only commit, then you can run your rendering pass if there is anything to be composited on the GPU.
<pq>
and then the real commit as "identical" to what you tested with, which then has a good chance of working.
<pq>
If you're trying to figure out which planes you can use before-hand, and then just assume they will work, then I think that is going to be less reliable.
c7s has joined #wayland
<emersion>
pq, i think they're worried about the fallback needing ALLOW_MODESET
<emersion>
ie, once you have a nice multi-plane setup, then it fails for whatever reason (e.g. plane position not supported), to fallback to just the primary plane some drivers may require ALLOW_MODESET?
<pq>
ALLOW_MODESET is irrelevant, they can decide before-hand if they allow modeset or not, and then run through the testing
<pq>
that would be a really unfortunate driver
<emersion>
yeah. i've seen it in practice, but it was a driver bug, now fixed
<emersion>
i wouldn't worry too much about it
<emersion>
already complicated enough as-is :P
<pq>
agreed
<pq>
what annoys me more is pixel format changes on the primary plane might really need a modeset
<daniels>
yeah, that's an actual thing
<emersion>
:S
<pq>
it is, and it is annoying :-)
<daniels>
I haven't seen disabling planes requiring modeset though, even on i.MX which is the absolute poster boy for horribly broken hardware
<pq>
if you want to be able to put fullscreen video on a primary plane opportunsitically, you may need to have your renderer produce NV12 framebuffers to begin with, or such.
<pq>
...maybe we should support that in Weston, actually
<pq>
should be doable with the intermediate composite buffer that color management uses, just make it use 8-bpc RGB format and convert to whatever in the blit pass
<pq>
and the blit pass could be multi-pass or MRT to be able to produce the NV12 as R+RG, whatever
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #wayland
<maxzor>
daniels, thought iMX was the pearl of openness in SOCs, the choice of Purism for a reason
<maxzor>
etnaviv was praised at the time they fundraised
<emersion>
openness and anoying hardware are two orthogonal things
<emersion>
maybe there's a good open driver, but that doesn't prevent the hw from having limitations which are a pain to deal with from a KMS point of view
<pq>
also etnaviv is for GPU while we are talking about display here, right?
<emersion>
indeed
<pq>
GPU and display blocks are often separate and independent in SoCs, driven by different drivers
<emersion>
i don't know a lot about iMX
<pq>
while in PC world you're used to having just "a graphics card" which does both functions and with a shared driver
<daniels>
yeah, the software stack is very open, but unfortunately both the NXP i.MX side and the VeriSIlicon/Vivante GPU side are unbelievably painful to work with in terms of the hardware
maxzor has quit [Ping timeout: 480 seconds]
<daniels>
but then it's been used absolutely everywhere, so everyone's had to deal with the pain of a system where the GPU can only texture from one layout (tiled), only render to another layout (supertiled), and then the display engine can only source from a third layout (linear)
<daniels>
luckily for a system requiring a million copies per frame, they have loads of memory bandw ... no, wait, they also have none of that
<pq>
Is that what happens when hardware architecture approximates the corporation management structures? :-)
flacks has quit [Quit: Quitter]
<daniels>
bonuses determined by the number of IP blocks
<daniels>
'hey, if we make it so the display engine can't source directly from scanout, then we can create a whole new 2D blit engine!'
maxzor has quit [Remote host closed the connection]
st3r4g has joined #wayland
arin0v has quit [Ping timeout: 480 seconds]
immibis is now known as Guest8075
immibis has joined #wayland
Guest8075 has quit [Ping timeout: 480 seconds]
immibis is now known as Guest8076
Guest8076 has quit [Read error: Connection reset by peer]
immibis has joined #wayland
maxzor has joined #wayland
sadlerap1 has quit []
sadlerap has joined #wayland
arin0v has joined #wayland
maxzor has quit [Remote host closed the connection]
conected has joined #wayland
maxzor has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
TattooedTech has quit [Quit: Leaving]
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
agd5f has quit [Read error: No route to host]
agd5f has joined #wayland
arin0v has quit [Ping timeout: 480 seconds]
kenny has joined #wayland
arin0v has joined #wayland
<kenny>
Hello, I just had a crash in libwayland-server from 1.19.0 in fd_source_interface (from wl_event_loop_dispatch). Everything's stripped. Any point in opening an issues?
<pq>
kenny, you might want to open an issue with your compositor first. Often those problems are in the users of the library than in the library itself. And yeah, regardless of where you report, a proper stack trace would help a lot.
rasterman has joined #wayland
<pq>
or if you have a sure way to re-trigger the issue
<kenny>
cool, thanks. I figured it might be something sway/wlroots was doing. I've long had issues with connecting/removing multiple external monitors and getting crashes there (that's what I was doing when this one happened). I'll watch for it to happen again.
<emersion>
yeah, please open a sway issue first with a stack trace
<kenny>
emersion: the stack trace appears mostly useless with only 4 frames, no sway/wayland frames. Maybe sway had an issue before this crash though. I think I was logging sway debug though, so I'll see if there's anything there.
<pq>
since you said wl_event_loop_dispatch(), there probably really isn't much on the stack.
<emersion>
kenny: maybe try ASan or valgrind
<pq>
the compositor was in its main event loop when this one fd signalled as ready, and the event loop attempted to dispatch it. So the actual bug happened some time earlier, leaving the fd event source corrupted.
<kenny>
emersion: Sure. I'll probably set that up again this evening. It requires me to rebuild to master sway/wlroots so take a little bit. In case it helps these types of crashes all end up occurring after the connection/disconnection of my dock, or when using wdisplays and clicking apply to move things around.
<ofourdan>
emersion: I /think/ exposing 0,0 for all wl_outputs is not so much of a problem because wayland clientss do not have access to tglobal coordinates either, so they cannot use location for that
<ofourdan>
(but I could be wrong…)
<emersion>
yup, and same for xdg-output information
<emersion>
hm, seems like i messed up the link on the website
<emersion>
because my message doesn't show up in the archive
<ifreund>
tarball link seems to be correct, the announcement links to the 1.19.93 announcement though
<zamundaaa>
pq: I should explain the situation better. What KWin does is that it always batches all state changes for the next presented frame, even with modesets
<zamundaaa>
when you start KWin it first tests some basic default state for outputs and finds out which it can enable and which crtcs it needs for which outputs
<zamundaaa>
afterwards it looks up the desired state from a config file for the outputs and tests that. If it works, it's committed to an internal state tracker. Once the first frame is rendered a bit later that state is committed to KMS with a modeset
arin0v has quit [Ping timeout: 480 seconds]
<zamundaaa>
Assuming that it could be that an overlay plane would require a modeset to be *dis*abled, testing for whether or not KWin can make use of it would have to wait for after the modeset
<zamundaaa>
If I can't assume that then it's fine, just have to know it...
___nick___ has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
phryk has joined #wayland
zamundaaa[m] has joined #wayland
caveman has joined #wayland
<dottedmag>
Am I reading the spec right that it does not specify when exactly during the message attached file descriptors come, so _all_ bytes from the socket have to be read expecting a fd along?
<dottedmag>
... including the header.
immibis has quit [Ping timeout: 480 seconds]
maxzor has quit []
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
caveman has quit []
caveman has joined #wayland
<daniels>
dottedmag: one FD is sent for every message argument with type==fd
hardening has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
spstarr has quit [Remote host closed the connection]