ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
aknot has joined #wayland
nerdopolis has joined #wayland
Arnavion has quit [Ping timeout: 480 seconds]
Arnavion has joined #wayland
aknot has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
tent405 has quit [Quit: tent405]
Moprius has joined #wayland
Moprius has quit []
tent405 has joined #wayland
Moprius has joined #wayland
Moprius has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
kts has joined #wayland
Moprius has quit []
sevz has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Guest1699 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1906
Warr has joined #wayland
Warr has quit []
cptaffe has quit [Remote host closed the connection]
cptaffe has joined #wayland
bodiccea has joined #wayland
tent405 has quit [Quit: tent405]
cptaffe has quit [Remote host closed the connection]
mblenc has quit [Read error: Connection reset by peer]
AnuthaDev has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
jtbx_ has quit [Remote host closed the connection]
crazybyte1 has joined #wayland
mblenc1 has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte1 is now known as crazybyte
mblenc has quit [Ping timeout: 480 seconds]
daz has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
crazybyte5 has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte5 is now known as crazybyte
rasterman has joined #wayland
leon-anavi has joined #wayland
AnuthaDev has quit []
cmichael has joined #wayland
AnuthaDev has joined #wayland
junaid has quit [Remote host closed the connection]
AnuthaDev has quit []
Company has joined #wayland
AnuthaDev has joined #wayland
<Company>
swick[m], pq: So this fancy HDR monitor I got has this energy booklet on it and it says the monitor takes 27kWh/1000h in normal operation and 55kWh/1000h in HDR mode
<Company>
and 28W is a pretty big difference if you multiply it by the amount of people who are going to use HDR monitors
<Company>
which made me think: How hard is it to only switch the compositor to HDR mode when there's actually HDR content on screen?
<Company>
and does that even safe those 28W?
<Company>
(also: this probably influences laptop battery life?)
<emersion>
when displaying a given color at a given luminance, does the SDH/HDR mode even matter?
<emersion>
what does the energy consumption even mean? how has it been measured?
dv_ has joined #wayland
<Company>
you'll have to look that up with the EU energy people
<dv_>
is there a way to get more information on how touch is calibrated? I have two screens, both are controlled by weston. the actual displaying of content works just fine. but touch input is messed up. the first touchscreen works correctly. the second one though behaves as if it had the shape and relative position of the first screen.
<emersion>
this was not a real question, it was more of way to reply "well hard to tell"
<dv_>
the first screen is 70mm x 70mm in size, and has a resolution of 480 x 480 pixels. the second screen (the one with the touch problems) is 27mm x 68mm in size, and has a resolution of 376 x 960 pixels
<dv_>
and the second screen's xy position, according to `wayland-info`, is x 480 y 0
junaid has joined #wayland
<Company>
emersion: I could just buy a power meter and measure it if I have to
rgallaispou has quit [Remote host closed the connection]
fmuellner has joined #wayland
<MrCooper>
I guess with LCD the backlight might draw more power in HDR mode, even if the resulting luminance is the same (some of the additional power will just be absorbed by the LCD)
<kennylevinsen>
Company: I imagine it's not HDR mode itself but bright HDR scenes
<Company>
I can imagine both
<Company>
that the monitor regulates power draw pretty effectively and that it fails to do so entirely
<Company>
which is why I was wondering if anyone knows about how it is in reality
<Company>
this thing certainly turns a lot brighter when I turn on HDR in Windows
<Company>
of course, that also means that switching HDR on and off is not a smooth transition
<pq>
JoshuaAshton, FWIW, Weston makes no difference between wl_surface roles when it attempts to put everything it can on KMS planes. Sub-surfaces included.
<pq>
Company, if HDR mode looks brighter, then it naturally must consume more power. But HDR mode should *not* look much brighter on average, that would be detrimental to HDR appearance.
<pq>
Company, other than that, I have no actual knowledge, I can just speculate what was already said here.
<Company>
pq: do you have an opinion if it's worth supporting dynamic switching inside compositors?
<pq>
Company, the power consumption comparison between SDR and HDR modes should be done with an image that looks like the same average brightness on both.
<pq>
Company, I suspect dynamic SDR/HDR switching will take too long and/or be too glitchy to be really useful on-demaand, but maybe if you only ever switch with fullscreen switching it might be ok.
aknot has joined #wayland
<Company>
it's also a technical question: If software supports dynamic switching, building hardware that can make use of it makes more sense
<pq>
or maybe if you give the end user a button or infer it from some other state like battery vs. mains power, so that the glitch is rare and tolerable
<pq>
btw. I don't know about laptop screens specifically, I believe they usually have less hardware that needs to adapt to the new signal format than external displays, so maybe they can be faster.
<Company>
first we need to have drivers for those screens...
<pq>
or maybe laptop screens don't event have a SDR vs. HDR mode the same way really
<Company>
because I have that neat laptop right here, but turning on HDR on the GPU does not turn it on on the monitor
<pq>
Company, yeah, you filed that intel driver issue, and still no-one is allowed to tell how drive such panel.
<Company>
which is why I got sent one of the monitors from the HDR hackfest
<Company>
and now I ask questions about power draw etc... ;)
<pq>
Unfortunately it seems knowing about one does not say anything about the other.
<Company>
they all have interesting problems unique to them
<Company>
the interesting part about automatic switching is knowing if it's worth implementing
<pq>
if you have automati backlight dimming, that could make SDR vs. HDR power draw be similar, but only if the HDR image does not look any brighter and has no HDR highlights.
<Company>
because if it's worth it, putting it in the API docs for application developers would be important
<Company>
I am mostly assuming that I have SDR content only
<Company>
for like 90% of the time
<Company>
but sometimes I encounter HDR content
<Company>
like when taking a break from hacking and opening a Youtube video
<Company>
or having to analyze a screenshot from an HDR user
<pq>
I see no technical reason why HDR mode should eat more power emitting the same SDR image than in SDR mode.
<pq>
but of course it is possible to design display hardware that does eat more power
<Company>
yeah, exactly
<Company>
I can also see that power saving is a lot more important on laptop panels than on those 32" desktop monitors
<Company>
but also, 25W * 1 million users * 8h/day would be a pretty big number where it's worth investing time to reduce it
<pq>
Reminds me of vacuum cleaners a bit. Many years ago "moar watts" was "better". There were over 2 kW hoovers. Now you get more suck with much less than half the power.
<Company>
Google says that's roughly the starting power of 1-2 747s
<Company>
25W * 700k monitors
<pq>
We need to somehow know what the end user wants. That's an UX designer question.
<pq>
dynamic switching could very well be an option there
<pq>
but how much of that should be communicated to Wayland clients?
<Company>
it's also a question about if it's worth it
<Company>
I don't think it's that much of a question for Wayland clients - they either have HDR content or they don't
<pq>
I don't think the cost of implementing it in a compositor is considerable, but somehow I feel you are thinking of something else or more.
<Company>
it's more a question of design
<pq>
compositors have to manage image description changes anyway due to hotplug
<Company>
ie "don't make your theme use HDR icons and colors"
<pq>
ah yes, that's "more"
<pq>
the protocol does have wl_surface preferred image description, and that can dynamically change.
<Company>
compositors (and toolkits) just need to implement it, but the ultimate source of the data is the application data and the UI design
nerdopolis has joined #wayland
<Company>
yeah, I expect GTK to dynamically pick the best colorspace for the content it is asked to render
<pq>
actually, I'm not sure that "HDR icons" even make sense.
<Company>
sometimes they exist by accident
<pq>
how's that?
<Company>
since GTK 4.8 or so we automatically switch to 16bit float buffers if content is 16bit
<pq>
and?
<Company>
and some icons of some apps were accidentally saved as 16bit
<Company>
so when you went through your apps in gnome settings or gnome software, it would randomly switch to 16bit
<pq>
bit depth says nothing about colorspace
<Company>
I would expect a similar thing to happen with colorspaces
kts has joined #wayland
<pq>
not really
<Company>
unless you tell people to check that they don't do that
<pq>
If there is no colorspace indicated, you assume its sRGB SDR.
<pq>
If there is a colorspace indicated, and it says HDR, you can map it to down to SDR to make sure it cannot be accidentally HDR.
<Company>
sure, but sometimes people start with a photo and then overdraw it
<Company>
then they delete the photo layer but the iamge's colorspace remains
<Company>
stuff like that
<pq>
all that doesn't matter, if GTK itself is producing an SDR image
<Company>
the libreoffice guys had 16bit pngs and somebody had copy/pasted an imagemagick conversion line that had the flag in there
<Company>
GTK will not do that though - GTK tries to draw the image as well as possible
<pq>
Does GTK not know it is an icon?
<selckin>
enabling hdr on my monitor disables a bunch of other features, so it only turning on with games and full screen video is nice
<pq>
selckin, good point. What features do you lose?
<pq>
dv_, you need udev rules to tell Weston which touch device is associated with which output.
<Company>
pq: GTK does not know it's meant to be SDR - it also technically doesn't know it's an icon, all it knows is that you're trying to draw a 16x16 image
cmichael has quit [Quit: Leaving]
<pq>
dv_, once you get that sorted, then it's a question of calibration if the positions are still off somehow.
<Company>
it could just decide that 16x16 pixels is not important enough to switch to HDR of course, but that would need to be defined somewhere
<pq>
dv_, the udev property is "WL_OUTPUT" which you should set to the head name picked by Weston.
<pq>
dv_, libinput has deprecated the API libinput_device_get_output_name(), but Weston still has no replacement for it. Hence it's all very undocumented.
<pq>
Company, what if GTK had an API for "this widget *really* wants HDR support"? Then smash everything else down to SDR, regardless of what colorspace is chosen for the rendering?
<pq>
*for the rendering target
<pq>
ultimately, "user errors" like copy-pasta colorimetry cannot be autocorrected. At some point you just have to trust the given colorimetry. This applies to WCG as well, not just HDR, though HDR has the power consumption consequences.
<Company>
GTK generally tries not to have such APIs, because all that happens is people use it wrong
<pq>
right
<Company>
we could optionally have that so that gnome-settings could say "please make sure all the icons are SDR"
<Company>
but even that would only be useful if it's actually worth staying in SDR mode
<JEEB>
I would hope that GNOME would just have a switch on the display settings side for output colorspace or so, and that would be what the desktop would be configured to. then possibly having something for fullscreen clients or whatever.
<JEEB>
since switching the colorspace all the time dynamically according to "largest currently open window" or something does not sound like good time
<pq>
So you'd need something somewhere to check that an image actually makes use of the colorspace it claims to have. You can check that by inspecting the pixels, if you have a place for the inspection and to show complaints.
<Company>
JEEB: everybody would turn HDR to "on" and then spend 90% of their time looking at SDR content
<JEEB>
and that's fine. that's what they've picked then
<JEEB>
you're still showing ~203 nits then
<JEEB>
since SDR graphics white in HDR is around that
<Company>
JEEB: that may be a massive waste
<JEEB>
is it? I would expect that to be possibly even lower than the SDR brightness knob value
<pq>
I think we can assume that there will be monitors where HDR mode is eating considerably more power for a long time to come.
<JEEB>
at least on my screen SDR graphics white in HDR mode is actually greyer than SDR graphics white in SDR mode
<JEEB>
HDR only should use more power if you actually go higher nits
<Company>
JEEB: but does it use more power to draw the HDR gray?
<Company>
it *should*, sure
<pq>
eating more power for dumb or cheaper design decisions
<Company>
but does it?
<JEEB>
I would be deeply surprised if it does if you are actaully not utilizing those higher nits
<JEEB>
the reason why > 55kWh/1000h in HDR mode is most likely noted is due to that being calculated over XYZ nits. if you have tested it with a watt-meter and it does that with SDR graphics white, then ooff
<Company>
I think it's likely that it does that
<pq>
JEEB, it was said that the HDR picture is brighter in Windows.
<Company>
but that's just gut feeling
<JEEB>
Company: I don't disagree with the notion of "expect the worst so you're not too disappointed in case that is true". Just noting that I would be surprised if that was the case.
<Company>
and I would be surprised if that was *not* the case
<pq>
we don't know what waas measured and how, do we?
<Company>
I didn't try to find out
nerdopolis has quit [Ping timeout: 480 seconds]
<JEEB>
pq: it really depends on your SDR brightness knobs and monitor behavior, for me SDR graphics white in HDR seems to actually be mapped a bit lower or whatever. that's why compositors (and often games) have a tweaking thing that you can tweak the graphics white level to your display's behavior.
<dv_>
pq: it is weird. playing around with LIBINPUT_CALIBRATION_MATRIX seems to indicate that for some reason, the first screen (the 480x480 pixel one) is used as a reference for touch events. that is: logical length 1.0 means 480
<dv_>
instead of (480+372)
<pq>
dv_, do not try to play with the calibration matrix until you have the input-output device assignments right.
<pq>
dv_, weston even logs those assingments if you can decipher which device is which.
<dv_>
okay
<dv_>
existing udev rules seem to assign the outputs correctly, but I'll recheck
nerdopolis has joined #wayland
<pq>
dv_, yes, if udev has no WL_OUTPUT, then all touch devices get associated with an arbitrary output, and since you have two touchscreens, it guarantees one of them is wrong.
<dv_>
ah, yeah, maybe I overlooked something
Moprius has joined #wayland
AnuthaDev_ has joined #wayland
<dv_>
pq: indeed, that seemed to fix it
<dv_>
btw, `wayland-info` showed me the `WL_OUTPUT` names, but only in the `xdg_output_v1` interfaces, not in the `wl_output` ones - is this normal?
<pq>
I don't recall, but the udev property should be set to the head name which you can find in the Weston log.
<pq>
Weston's head names are not truly persistent if you have multiple KMS-capable cards, so that's why they may be omitted from some interfaces.
<pq>
IIRC
<dv_>
this is an embedded device with hardwired displays
<pq>
then you have no problem, but Weston doesn't know that.
AnuthaDev has quit [Ping timeout: 480 seconds]
<pq>
the problem is about driver instance initialization race
Moprius has quit [Quit: bye]
Moprius has joined #wayland
<dv_>
the names are `DSI-1` and `LVDS-1`
<pq>
right
<dv_>
and, is there a way to assign manual names?
<dv_>
I mean, I identify the devices through other means already in the udev rule
<pq>
For heads, no. For outputs, yes IIRC, but that I think is only used in weston.ini and nowhere else.
Moprius has quit []
<pq>
well, udev rules identify the input devices, and heads are output devices.
<dv_>
ah ... right
Moprius has joined #wayland
<dv_>
so I can assign an output name, but that assignment will only really exist within weston.ini
<pq>
output devices practically don't exist in udev, they come through KMS API instead
<pq>
yeah, so you'd only benefit of it in the weston logs
<dv_>
so right now this is not really solved fully
Moprius has quit []
<pq>
custom naming, no, not at all
Moprius has joined #wayland
<pq>
People might use a boot-up or other service to generate the udev rules, if hardware is not fixed.
<pq>
nothign better exists AFAIK
<dv_>
do any proposals exist?
<dv_>
(just asking out of pure interest ... the discussed solution works fine here)
<pq>
not that I know of, other than making weston use reliably persistent head names but still not custom names.
<pq>
maybe mutter uses some better heuristics to match a touchscreen's input and output?
<pq>
it's difficult though, because you essentially need to match EDID with some USB device, and I don't of any standard for that.
<pq>
*don't know
<dv_>
true
<pq>
vendor drivers can just hardcode arbitrary matching rules that work for them on Windows
Moprius has quit [Remote host closed the connection]
<pq>
another solution is to label the display and USB ports, and demand that end users plug the cables belonging together in a specific pair of ports.
<pq>
I mean physically label in the machine chassis.
Moprius has joined #wayland
<pq>
the physical ports can then be identified in software, and if something is in there, associate them together.
Moprius has quit []
Moprius has joined #wayland
Moprius has quit []
<pq>
Company, I could not find any technical description of the power measurement video sequences in there.
<Company>
is that because the website is so hard to search or is that because none exists?
<zamundaaa[m]>
pq: KWin tries to match output and touchscreen by looking at their physical sizes. Doesn't always work out though ofc
<zamundaaa[m]>
My portable touchscreen display pretends to be twice as big as it really is for some reason for example
kts has quit [Ping timeout: 480 seconds]
<emersion>
sway detects built-in USB/displays
<emersion>
er
<emersion>
built-in touchscreens
<emersion>
IOW: if there's exactly one internal DRM connector and one internal touch input device, likely the same
agd5f has joined #wayland
<emersion>
zamundaaa[m]: i suppose there's no good way to match make/model/serial?
<emersion>
i mean, they can be different?
<pq>
Company, I've no idea. I saw the spec on how to measure the HDR power, but it had no reference to what would define the video used.
<pq>
zamundaaa[m], the touch input device has a physical size? Hmm, I guess touchpad may have too, so why not.
<zamundaaa[m]>
emersion: I think it's not often that they're the same
<zamundaaa[m]>
pq: it does. It's also often sometimes slightly off from the display size. As always, you can't really rely on anything :/
<zamundaaa[m]>
But for finding the default touchscreen mapping it's at least something
<pq>
clearly we need a database for matching... and then someone buys two of the same kind.
<pq>
s/buys/plugs in/
<pq>
hmm
<pq>
recommend that people do hotlug for the first time, assume hotplugged output and touch input go together, record the association, and remember it for the future?
<pq>
along with the built-in devices heuristics
<pq>
likely needs some automatic UX to pop up to verify the association is ok
<pq>
weston't touch calibrator can tell if you are poking a wrong screen
<pq>
but then you have to tell the touch calibrator which screen you want to calibrate via a cryptic and long name first
junaid has quit [Remote host closed the connection]
carlos_ has joined #wayland
gspbirel5687340886706131448762 has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
<Company>
emersion, jadahl: Would it make sense to delete the master branch of wayland-protocols?
<Company>
I've just had people read the protocols in that branch because of some web links instead of from main
<Company>
and ending up with a 2 year old outdated version
<emersion>
that could break some people's stuff
<Company>
otoh, those people's stuff may be broken already because it uses 2 year old protocols
<emersion>
no
<emersion>
if some code compiled fine with an old checkout, it will not break
<emersion>
if we delete the branch, we may break builds
<ebassi_>
What you usually do is delete everything in the branch, and drop a README.md as a tombstone, to let people know they need to move when they pull
<Company>
yeah, but if somebody tracks master, they might want to track tip of development
<Company>
and that would be broken now
<emersion>
not necessarily
<ebassi_>
emersion: Ostensibly, if people are pulling from master and not from a specific commit/tag, they are signing up for a lot of pain
ebassi_ is now known as ebassi
* Company
checked and Gnome seems to have deleted the master branches - at least GTK, gnome-shell and glib don't have one
<Company>
I guess I'll file a bug about it
<ebassi>
Company: We deleted the master branch after a few months
<ebassi>
To let people move
<Company>
yeah, that makes sense
<Company>
wayland-protocols master is >2 years old - April 2021
junaid has quit [Remote host closed the connection]
paulk has quit [Read error: Connection reset by peer]
paulk has joined #wayland
<ebassi>
emersion: I'm not sure what that has to do with anything, to be honest
<emersion>
ebassi: i routinely checkout the master branch of my close deps in my CI
<ebassi>
"Some code compiled with an old checkout" either means nothing pulled from a branch, or every time something pulls from a branch the possibility of a breakage is factored in
<ebassi>
And on master the possibility of a breakage is higher
<ebassi>
The tombstone on a branch is specifically meant for the case when there's a human pulling stuff, because CI scripts don't read a README file
kts has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
<Company>
good job saving 154 bytes on the wire there
<Company>
I guess it's probably twice that now that YUV has landed
<robert_mader>
I'm surprised that it's only 11 entries, given that each index points to a format+modifier pair. On this system it's up to 9 modifiers per format - and then there's scanout and default tranche. And we resend those tranches relatively often.
Moprius has quit [Quit: bye]
<emersion>
yeah, we've run the numbers in the MR introducing this, and we concluded we really needed to save some space to avoid overflowing the connection in the future
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Company: re: the hdr/energy talk, you can't use the energy rating here: they are established with "representative" SDR and HDR content loops and auto brightness disabled. Monitors that can go brighter, or for LCDs have low dimming resolution get worse ratings.
<kennylevinsen>
but wasting power by burning the backlight ruins contrast, so LCDs try not to do that. Your exmaple monitor have a low-resolution edge zone dimming for example, which should kick in for low brightness in HDR mode.
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<kennylevinsen>
so like the others, I'd be very surprised if power profile was significantly different for the same optical output. Maybe some bad monitors without dimming, but you'd see the image degrade then.
AnuthaDev_ has quit []
mblenc has quit [Ping timeout: 480 seconds]
<Company>
kennylevinsen: that sounds like you think there's no need to switch to SDR and keep monitors in HDR mode all the time is fine?
rv1sr has quit []
sima has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<swick[m]>
there are good reasons for not wanting hdr mode: less predictable colorimetry, less panel adjustment, higher bandwidth requirements, ...
<swick[m]>
the biggest power issue is going to be the required color conversions which will stress the gpu more and makes plane offloading impossible right now