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
maxzor has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
TattooedTech has joined #wayland
Seirdy has quit []
Seirdy has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
arinov has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has quit []
nerdopolis has joined #wayland
slattann has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
danvet has joined #wayland
tzimmermann has joined #wayland
hardening has joined #wayland
maxzor_ has joined #wayland
jgrulich has joined #wayland
maxzor has joined #wayland
pnowack has joined #wayland
rasterman has joined #wayland
boistordu_ex has quit []
arinov has joined #wayland
dcz has joined #wayland
<zamundaaa[m]>
What are the specifics for the "max bpc" drm property?
<zamundaaa[m]>
I know what it does in principle. I'm more interested in what it's actually useful for (power savings?) and whether or not it could degrade the image if set to what I render with
<pq>
I'm setting it, because I've seen it being 8 for whatever reason, and I want to go up to max possible instead.
<emersion>
there was a discussion about adding more props to have more control
caveman has joined #wayland
<emersion>
current bpc, desired bpc…
<pq>
yeah, "max bpc" doesn't really guarantee much on its own
<pq>
zamundaaa[m], I'm not sure... power saving and link stability under borderline conditions I guess
<emersion>
zamundaaa[m]: with max bpc > 8, you might not be able to light up as many CRTCs, or high resolutions
<emersion>
well
<pq>
emersion, really? why?
<emersion>
it's max, so i'm probably wrong
<pq>
emersion, I would not think the bpc on the wire would have any effect on e.g. memory bandwidth requirements, if that's what you're thinking.
<emersion>
pq, DP-MST
<pq>
ooh, MST
<pq>
yeah, that could be a thing
<emersion>
also i guess bad cables in general
<zamundaaa[m]>
As it's a maximum I would hope that the drivers manage that stuff on their own
<pq>
right, link stability - link negotiattion should work what out, but I guess it could be too optimistic sometimes
<zamundaaa[m]>
At least on my AMD hw it seems to be set to 16 by default. If that would cause problems that would be a pretty bad default
<pq>
drivers/hardware should indeed
<pq>
zamundaaa[m], don't forget that other KMS clients (display servers) could set their own values if you happen to switch, so you may not always be getting the driver default.
<zamundaaa[m]>
If they don't adjust automatically that's one more variable to the already near infinite mess of combinations to test with outputs :/
<pq>
they do adjust automatically
<zamundaaa[m]>
Okay then the old question left is: if I set it to exactly what my buffers are rendered with, can that cause the image to degrade?
<pq>
but when you want to display HDR, you do want to know what they actually adjusted to, to know if HDR is reasonable - this UAPI we do not have yet
<zamundaaa[m]>
In other words, if the cable/panel/whatever only supports discrete steps like 6 and 10bpc, and I set it to 8, would it go down to 6? Or is that just a hypothetical I don't have to care about
<pq>
zamundaaa[m], I guess that depends on how you use the KMS color pipeline.
<pq>
yes, it would go down to 6 - but I don't recall < 8 being an option in the specs...
<emersion>
it is an option, at least on some drivers
<pq>
okay
<emersion>
but yeah i'd expect 8 to always be an option and the default
<emersion>
s/default/baseline/
<pq>
emersion, so the "specification" on that web page is the union over all report driver ranges?
<emersion>
yes
<pq>
*reported
<emersion>
this should be made clearer
<emersion>
also this page should link to devices supporting the prop
<pq>
nice - too bad I can't click forward to the individual reports
<emersion>
yeah…
<pq>
:-)
<MrCooper>
zamundaaa[m]: bpc on the wire isn't directly related to bpc of the source framebuffer format
boistordu has joined #wayland
<pq>
...but I do wonder if drivers use the source FB format as a hint in choosing the bpc on the wire...
<pq>
like, no CSC, no LUTs, FB is 8 bit → don't bother with more than 8 bpc on the wire?
<MrCooper>
doubtful, the output of LUTs has >= 10 bpc on non-ancient GPUs
<emersion>
maybe your fancy monitor can say?
<pq>
my fancy monitor says "this is not HDR" and I'm not sure why :-p
<MrCooper>
I'll try to remember checking next time I'm in front of that
<pq>
in one specific HDR mode that it claims to support and I try to use - another HDR mode works
<pq>
I'm just wildly guessing that the monitor could do similar inference: you have 8 bpc signal, and you tell me it's HDR? ha ha ha, funny. No way.
<pq>
sure, it doesn't make much sense, but I wanted to see what it looks like :-)
<zamundaaa[m]>
The context of my question is that I wanna bump KWin to 10bpc (by default), with dmabuf feedback suggesting to clients that they should use it, too.
<zamundaaa[m]>
The implementation is done, the only thing left is what to do with the max bpc property
<pq>
in that case I'd recommend setting it to at least 10
<emersion>
so you put 10bpc in a separate tranche?
<zamundaaa[m]>
Yes
<emersion>
not sure it's a good default
<pq>
in Weston, when I want maximum quality, I just bump it to the maximum allowed by the driver.
<MrCooper>
is there any reason for lower "max bpc" other than avoiding wire bandwidth limits?
<pq>
I don't know what bad could come from this, but if there is something, I guess I'll learn in a year or two :-)
<zamundaaa[m]>
emersion: I'm not sure about that either yet but there's still about 1-2 months of testing in git master, plenty of time to change it back
<emersion>
MrCooper: power consumption maybe? i'm not sure
<MrCooper>
e.g. if the wire link doesn't have enough bandwidth for the monitor's maximum resolution at full bpc
<emersion>
zamundaaa[m]: interested in any feedback you have after you get more field testing :)
<pq>
MrCooper, that's an interesting question, which one has priority: max negotiated wire bpc, or enabling the requested mode even if it means lowering wire bpc?
<MrCooper>
pretty sure making it dependent on framebuffer format bpc makes little sense
<pq>
I think that just depends on what you do in the KMS color pipeline.
<pq>
If the pipeline is all pass-through, *and* the wire is in full range RGB mode, then the FB pixels go out as-is... don't they?
<MrCooper>
ok, makes little sense for anything but pass-through
<pq>
zamundaaa[m], so it depends ^ :-)
<pq>
if you program a gamma LUT, then you already deviate from FB format, or if you use limited range, or if you use YUV signal (not FB)
<MrCooper>
and I'd expect pass-through to be rare, normally there's at least a monitor profile being applied, not to mention things like Night Light
<pq>
Night Light maybe, but a profile or a non-identity calibration might be rare... but then those people who actually have them, do really care about precision, so.
<pq>
IOW, I don't know why one would not bump "max bpc" just to the maximum allowed by a driver.
<MrCooper>
GNOME seems to apply a monitor profile based on EDID by default
<pq>
also ignore what kind of FB you have
<zamundaaa[m]>
pq: KWin always applies a LUT, even if its internal calculations result in passthrough
<zamundaaa[m]>
So there's that
<pq>
MrCooper, are you sure it's a profile and not VCGT?
<pq>
zamundaaa[m], btw. using an identity LUT vs. setting no LUT might lead to different driver behavior. >_<
<jadahl>
MrCooper: "apply" is a bit much of a word for what it does. on X11 it sets the profile name as an atom on the root window
<pq>
so I've been told, I haven't tested it myself
<jadahl>
if there is a VCGT it uses it set the gamma though
<jadahl>
if there is no VCGT, the profile doesn't affect gamma
<pq>
Right, VCGT is said to be calibration, and it is included in ICC files only as a convenience, because the ICC file is not valid if the VCGT is not applied. Usually VCGT is applied by loading it into a gamma LUT.
<MrCooper>
the profile for this HP E242 says "Display Correction: No", I guess that means no gamma LUT then
<pq>
perhaps, I'm not sure what "display correction" means there
<pq>
FYI, an ICC file is invalid also if you change your monitor settings away from what that profile was created with.
<pq>
I mean the in-monitor knobs you fiddle with via OSD.
<jadahl>
MrCooper: you get a VCGT by profiling the monitor with a colorimeter
<jadahl>
sprofiling/calibrating/
<jadahl>
s/
<MrCooper>
I see
<pq>
jadahl, maybe... one can also come up with a VCGT by just eye-balling. Creating a profile OTOH needs a colorimeter mostly.
<jadahl>
sure, the colorimeter used can be ones eye balls :P
<pq>
weeelll... the colorimeter doesn't know what you think looks right. :-)
<pq>
everything depends on what you are going to use the display for
<pq>
In the end, the goal is to make the picture good for what you want to use it for. It's human eyes that look at it.
<pq>
If your goal is to preview prints, then you want the picture to match what a print would look like. That's totally different from wanting to be entertained with impressive visuals.
<zubzub>
but what if you, a human, identify as a printer? <o>
<pq>
then you use print profile, d'uh!
<zubzub>
ah ofcourse _o>
<SardemFF7>
careful with that kind of joke
slattann has quit []
<kennylevinsen>
I don't think we offended any printers with it. They're too busy with paper jams and driver issues to notice.
<SardemFF7>
please, really, don’t…
<pq>
These are weird jokes, but what is offending about them?
<daniels>
one reason is 'but what if you identify as $contrivedthing?' is often used to ridicule the concept of identifying as anything other than your birth sex/gender and marginalise people who do otherwise
<pq>
Thanks. I just read it as "what if you're a printer?".
<SardemFF7>
thanks daniels (I really need to work on this kind of FAQ material ^^)
<pq>
takes some really elaborate thinking to realize that connection
<SardemFF7>
or just not being cis :-)
<pq>
sure
<SardemFF7>
btw, guess it’s as good a time as any: hi there, I’m Morgane :-)
<pq>
hi, and that totally makes the line I was going to say next completely inappropriate. >_<
<jadahl>
it's a variant of the "i identify as a attack helicopter" meme that mocks non-cis identification
<daniels>
SardemFF7: o/
<pq>
I don't know memes. I also try to not know anything personal about anyone, and expect the same in return.
<jadahl>
pq: something something surströmming
<jadahl>
SardemFF7: hi morgane!
<SardemFF7>
FTR, I’m still learning myself which jokes or behaviour to avoid, and I know it’s hard to see it by yourself, so let’s just all learn together shall we? :-)
<daniels>
if we were all perfect at stuff then wl_buffer wouldn't be stuck at v1 would it
<SardemFF7>
that’s a deep one, I’m sad only people in here can understand it, I would have shared it
<psykose>
if we were all perfect wl_buffer would never need to leave v1
<pq>
well said
<daniels>
psykose: touché
SardemFF7 has quit [Quit: WeeChat 3.0-dev]
SardemFF7 has joined #wayland
TattooedTech has quit [Quit: Leaving]
fmuellner has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit []
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
ppascher has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
pnowack has quit [Quit: pnowack]
reillybrogan_ has joined #wayland
caseif_ has joined #wayland
Cwiiis_ has joined #wayland
Lightsword_ has joined #wayland
LaserEyess_ has joined #wayland
wangledorf___ has joined #wayland
hwentlan__ has joined #wayland
WhizzWarlock has joined #wayland
panzeroceania_ has quit [Ping timeout: 480 seconds]
<cphealy>
With the wayland protocol, is there a way to communicate the color encoding and color range of a YUV buffer? YUV buffers can be BT.601, BT.709, BT.2020, and probably other color encodings, each with somewhat different requirements for conversion to RGB.
<caveman>
is there any python bindings available already to allow the creation of a sway-like window manager, but using python? then use some pythong modules to do the calls to c functions to do the expensive parts?
<emersion>
i wouldn't recommend writing a compositor in python
<caveman>
why?
<emersion>
it's way too slow
<emersion>
would be fine for the WM stuff, but not for anything else
<caveman>
i'm wondering if it's possible to do the expensive parts in c libraries using some python calls, and then do only the human intetraction part in python, such as scaling windows, etc.
soreau has quit [Read error: Connection reset by peer]
<psykose>
qtile is one example
<caveman>
psykose: neat.
<caveman>
thanks
ratcat has joined #wayland
ratcat has quit [Remote host closed the connection]
zebrag has quit [Quit: Konversation terminated!]
fmuellner has quit [Ping timeout: 480 seconds]
<kennylevinsen>
caveman: could also take a look at river, it's designed to have window management controlled entirely over IPC
darkpeople has joined #wayland
slattann1 has quit []
darkpeople has quit []
<caveman>
thanks
<caveman>
kennylevinsen: neat.
arinov has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
somkls^ has joined #wayland
arinov has joined #wayland
cvmn has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
tzimmermann has quit [Quit: Leaving]
___nick___ has joined #wayland
tarnsformers has joined #wayland
nwv1eeb has joined #wayland
tarnsformers has quit []
nwv1eeb has quit []
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
arinov has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
reillybrogan has joined #wayland
reillybrogan_ has quit [Ping timeout: 480 seconds]