ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
PavelNasevich[m] has quit [Quit: Client limit exceeded: 20000]
alatiera has quit [Quit: Connection closed for inactivity]
luna has joined #wayland
Leopold_ has quit [Remote host closed the connection]
luna has left #wayland [#wayland]
Leopold_ has joined #wayland
lyudess has quit []
Lyude has joined #wayland
kts has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
rv1sr has joined #wayland
kts has quit [Quit: Leaving]
flom84 has joined #wayland
kts has joined #wayland
sima has joined #wayland
AnuthaDev has joined #wayland
flom84 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
mvlad has joined #wayland
glennk has joined #wayland
garnacho has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
leon-anavi has joined #wayland
Dami_Lu has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
<YaLTeR[m]>
I've got a question about popup constraints. Flip constraints say: "If the adjusted position also ends up being constrained, the resulting position of the flip_x adjustment will be the one before the adjustment." What does this mean? Other constraints don't say this. What happens if flip is combined with other adjustments?
kts has joined #wayland
leon has joined #wayland
leon-anavi has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
<vyivel>
YaLTeR[m]: iirc you first try to flip, if the popup is still constrained, you undo the flip and try other options
<YaLTeR[m]>
Hmm
<YaLTeR[m]>
So no combining flip and others then
<YaLTeR[m]>
How do X and Y adjustments interact? In the case when both axes adjustments are needed to remove constraints?
<vyivel>
you apply both then?
<YaLTeR[m]>
Say I try to flip X, then I need to try the whole range of Y adjustments to see if it's possible to remove constraints? Or I try to flip X and then only try to flip Y before proceeding to other X adjustments?
<vyivel>
if flipping x succeeds in removing constraints, you don't need to do anything else with the x axis
<vyivel>
if it doesn't, you don't flip
<vyivel>
x and y are independent from each other
<vyivel>
that's how i see it at least
<YaLTeR[m]>
If the popup is in a corner, it may need two adjustments at once to remove the constraint, and any single-axis adjustment will keep it constrained
<vyivel>
i mean, flip x and check if x constraints are removed
<vyivel>
if they are, keep the x flip
<vyivel>
same with y
<YaLTeR[m]>
This is getting edge casy, but if the popup is wider but not taller than the screen, then it cannot be unconstrained, and you won't know that if you only look at the Y axis
<YaLTeR[m]>
so when applying flip y you will succeed, but actually the popup is still constrained, so you should've reverted it
<YaLTeR[m]>
I was about to ask about slides, because as far as I can tell, all this wording about which sliding direction to try first does not actually result in any behavior difference, if applied as currently worded
<YaLTeR[m]>
regardless of whether you try to slide left or right first, you will hit the same edge eventually and end up with the same position
<YaLTeR[m]>
unless I'm misunderstanding
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Guest10820 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
Moprius has joined #wayland
cool110 is now known as Guest10854
Brainium has joined #wayland
blathijs has quit [Quit: WeeChat 4.0.5]
blathijs has joined #wayland
Leopold__ has joined #wayland
alatiera has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
Leopold_ has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
fmuellner has joined #wayland
kts has joined #wayland
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<kennylevinsen>
If the popup cannot be unconstrained with sliding, I think the order sliding is attempted will affect the final position (whether you align the edge closest to or furthest from gravity)
<kennylevinsen>
the undo is only for flip IIRC, because it isn't productive to stack, but sliding + resize means you align the surface before crop
kts has quit [Quit: Leaving]
<kennylevinsen>
and yeah, I think you should treat each axis independently - even if you can't solve a Y constraint, it's still better UX to solve the X constraint rather than bail
Leopold_ has quit [Ping timeout: 480 seconds]
Hypfer is now known as Guest10871
Hypfer has joined #wayland
Guest10871 has quit [Remote host closed the connection]
<pq>
Oh boy, my old HDR monitor definitely does *something* with "Colorspace" KMS property. Switching it from default to bt2020rgb makes thing... psychedelic - but of course, I'm feeding it plain old sRGB data, so of course it'll be wrong, but this is wild.
<pq>
black becomes mid green, gray becomes pink...
<ManMower>
that's just using RGB values as YUV?
nerdopolis has joined #wayland
<pq>
no, RGB as RGB
<pq>
just telling the monitor that my color gamut is waaay beyond what it can display
<kennylevinsen>
When "vivid" is turned all the way up to 11
<pq>
What's even funnier is that I cannot even take a photo of the screen with my phone. What I see as saturated green in reality, is cyan in the photo.
<ManMower>
never had this problem with film!
* ManMower
shakes fist at clouds
<zamundaaa[m]>
pq: yeah taking photos of HDR content is hard. I managed to take a decent one of an HDR video with nature content, but games always look like shit
Leopold_ has joined #wayland
<pq>
uh oh
<pq>
something in the display system broke
<pq>
timestamps from amdgpu are out of whack
<emersion>
anything in dmesg?
<pq>
nope, aside from a couple dozen kernel: HDR SB:3d 02 00 d0 84 80 3e c2 33 c4 86 4c 1d b8 0b 13 kind of lines
<pq>
monitor complains of no signal, and Weston gets abnormal repaint delays 150k secs in the past.
Leopold__ has joined #wayland
<pq>
hmm, turning the monitor off and on fixed it, which means hotplug
<pq>
I think Weston was going to sleep mode, turning the output off, when it broke.
<pq>
Anyway, at least I can confirm one thing I got wrong: setting "Colorspace" really matters, even if you already set "HDR_OUTPUT_METADATA".
Leopold_ has quit [Ping timeout: 480 seconds]
<pq>
looks like the absence of HDR static metadata HDCP infoframe does *not* reset this monitor to SDR. But setting colorimetry to "default RGB" does.
<pq>
also, fbdev does not reset colorimetry when taking over :-P
cborah1 has joined #wayland
shankaru1 has joined #wayland
<zamundaaa[m]>
<pq> "looks like the absence of HDR..." <- It's not that specific monitor, it happens with all of them
cborah has quit [Ping timeout: 480 seconds]
<pq>
hmm, I thought I read in spec somewhere that it should reset.
<pq>
but I also have a vague recollection that one should also send HDR static metadata just to ensure HDR is off when the sink supports it...
<zamundaaa[m]>
pq: I think it's an amdgpu bug actually, not necessarily the displays behaving badly
<zamundaaa[m]>
It does reset after a modeset
<pq>
or, it's an amdgpu bug - I'm just using drm_info to see what I'm supposedly sending to the monitor.
shankaru has quit [Ping timeout: 480 seconds]
<pq>
hmm, so getting HDR_OUTPUT_METADATA property to none does not propagate on amdgpu without a modeset?
<pq>
any bug filed about that?
<pq>
or maybe even already fixed and we're just behind in kernels?
<pq>
hwentlan__, ^
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
there is a modeset, surely, though? When fbdev returns, and definitely once Weston starts again.
<zamundaaa[m]>
pq: maybe it's not a modeset that triggers the change, but switching between drm masters or something
<pq>
fbdev is a different master...
<zamundaaa[m]>
For me if I log out of the session with HDR enabled, SDDM shows SDR interpreted as HDR, and if I log into a session with SDR, then it's correct again
<pq>
what fixed it for me was starting Weston with "Colorspace" set to default
<pq>
I would guess that SDDM does not touch "Colorspace" nor "HDR_OUTPUT_METADATA", and fbdev does not either. But your HDR-capable compositor might ensure they are correct for SDR sRGB, too. I certainly hope it does.
<zamundaaa[m]>
yeah that also does it for me. That's part of the reason for why the GUI only exposes both properties as one "HDR" toggle
<zamundaaa[m]>
pq: I *think* I made KWin 5.27 reset the properties actually. Let me check
<pq>
well... I get a very reasonable image with PQ and default RGB, and also WCG monitors without HDR exist.
<zamundaaa[m]>
ah, KWin 5.27 only resets HDR_OUTPUT_METADATA. It doesn't touch Colorspace
<zamundaaa[m]>
So it's not too surprising it still looks weird in SDDM
<pq>
Weston sets HDR_OUTPUT_METADATA to 0 instead of the SDR blob.
<pq>
What's most exciting about my experiments is that I think an end user tool to figure out the color gamut of a HDR monitor without any measurement equipment seems very possible.