10:13 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
10:14 Company: and 28W is a pretty big difference if you multiply it by the amount of people who are going to use HDR monitors
10:15 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?
10:15 Company: and does that even safe those 28W?
10:17 Company: (also: this probably influences laptop battery life?)
10:18 emersion: when displaying a given color at a given luminance, does the SDH/HDR mode even matter?
10:19 emersion: what does the energy consumption even mean? how has it been measured?
10:22 Company: you'll have to look that up with the EU energy people
10:23 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.
10:24 emersion: this was not a real question, it was more of way to reply "well hard to tell"
10:24 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
10:24 dv_: and the second screen's xy position, according to `wayland-info`, is x 480 y 0
10:31 Company: emersion: I could just buy a power meter and measure it if I have to
10:35 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)
10:37 kennylevinsen: Company: I imagine it's not HDR mode itself but bright HDR scenes
10:38 Company: I can imagine both
10:38 Company: that the monitor regulates power draw pretty effectively and that it fails to do so entirely
10:39 Company: which is why I was wondering if anyone knows about how it is in reality
10:39 Company: this thing certainly turns a lot brighter when I turn on HDR in Windows
10:40 Company: of course, that also means that switching HDR on and off is not a smooth transition
10:45 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.
10:54 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.
10:54 pq: Company, other than that, I have no actual knowledge, I can just speculate what was already said here.
10:55 Company: pq: do you have an opinion if it's worth supporting dynamic switching inside compositors?
10:55 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.
10:56 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.
10:57 Company: it's also a technical question: If software supports dynamic switching, building hardware that can make use of it makes more sense
10:58 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
10:59 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.
10:59 Company: first we need to have drivers for those screens...
10:59 pq: or maybe laptop screens don't event have a SDR vs. HDR mode the same way really
11:00 Company: because I have that neat laptop right here, but turning on HDR on the GPU does not turn it on on the monitor
11:01 pq: Company, yeah, you filed that intel driver issue, and still no-one is allowed to tell how drive such panel.
11:02 Company: which is why I got sent one of the monitors from the HDR hackfest
11:03 Company: and now I ask questions about power draw etc... ;)
11:03 pq: Unfortunately it seems knowing about one does not say anything about the other.
11:03 Company: they all have interesting problems unique to them
11:04 Company: the interesting part about automatic switching is knowing if it's worth implementing
11:05 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.
11:05 Company: because if it's worth it, putting it in the API docs for application developers would be important
11:05 Company: I am mostly assuming that I have SDR content only
11:05 Company: for like 90% of the time
11:06 Company: but sometimes I encounter HDR content
11:06 Company: like when taking a break from hacking and opening a Youtube video
11:06 Company: or having to analyze a screenshot from an HDR user
11:07 pq: I see no technical reason why HDR mode should eat more power emitting the same SDR image than in SDR mode.
11:07 pq: but of course it is possible to design display hardware that does eat more power
11:07 Company: yeah, exactly
11:08 Company: I can also see that power saving is a lot more important on laptop panels than on those 32" desktop monitors
11:09 Company: but also, 25W * 1 million users * 8h/day would be a pretty big number where it's worth investing time to reduce it
11:10 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.
11:11 Company: Google says that's roughly the starting power of 1-2 747s
11:12 Company: 25W * 700k monitors
11:14 pq: We need to somehow know what the end user wants. That's an UX designer question.
11:15 pq: dynamic switching could very well be an option there
11:15 pq: but how much of that should be communicated to Wayland clients?
11:15 Company: it's also a question about if it's worth it
11:16 Company: I don't think it's that much of a question for Wayland clients - they either have HDR content or they don't
11:16 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.
11:17 Company: it's more a question of design
11:17 pq: compositors have to manage image description changes anyway due to hotplug
11:17 Company: ie "don't make your theme use HDR icons and colors"
11:17 pq: ah yes, that's "more"
11:18 pq: the protocol does have wl_surface preferred image description, and that can dynamically change.
11:18 Company: compositors (and toolkits) just need to implement it, but the ultimate source of the data is the application data and the UI design
11:19 Company: yeah, I expect GTK to dynamically pick the best colorspace for the content it is asked to render
11:19 pq: actually, I'm not sure that "HDR icons" even make sense.
11:19 Company: sometimes they exist by accident
11:20 pq: how's that?
11:20 Company: since GTK 4.8 or so we automatically switch to 16bit float buffers if content is 16bit
11:20 pq: and?
11:20 Company: and some icons of some apps were accidentally saved as 16bit
11:21 pq: bit depth says nothing about colorspace
11:21 Company: so when you went through your apps in gnome settings or gnome software, it would randomly switch to 16bit
11:21 Company: I would expect a similar thing to happen with colorspaces
11:21 pq: not really
11:21 Company: unless you tell people to check that they don't do that
11:22 pq: If there is no colorspace indicated, you assume its sRGB SDR.
11:22 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.
11:22 Company: sure, but sometimes people start with a photo and then overdraw it
11:22 Company: then they delete the photo layer but the iamge's colorspace remains
11:22 Company: stuff like that
11:23 pq: all that doesn't matter, if GTK itself is producing an SDR image
11:23 Company: the libreoffice guys had 16bit pngs and somebody had copy/pasted an imagemagick conversion line that had the flag in there
11:24 Company: GTK will not do that though - GTK tries to draw the image as well as possible
11:24 pq: Does GTK not know it is an icon?
11:24 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
11:25 pq: selckin, good point. What features do you lose?
11:26 pq: dv_, you need udev rules to tell Weston which touch device is associated with which output.
11:26 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
11:27 pq: dv_, once you get that sorted, then it's a question of calibration if the positions are still off somehow.
11:27 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
11:34 pq: dv_, the udev property is "WL_OUTPUT" which you should set to the head name picked by Weston.
11:35 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.
11:37 pq: dv_, there is an example hidden in https://wayland.pages.freedesktop.org/weston/toc/running-weston.html if you search for WL_OUTPUT.
11:39 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?
11:40 pq: *for the rendering target
11:43 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.
11:44 Company: GTK generally tries not to have such APIs, because all that happens is people use it wrong
11:44 pq: right
11:45 Company: we could optionally have that so that gnome-settings could say "please make sure all the icons are SDR"
11:45 Company: but even that would only be useful if it's actually worth staying in SDR mode
11:45 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.
11:46 JEEB: since switching the colorspace all the time dynamically according to "largest currently open window" or something does not sound like good time
11:46 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.
11:46 Company: JEEB: everybody would turn HDR to "on" and then spend 90% of their time looking at SDR content
11:46 JEEB: and that's fine. that's what they've picked then
11:46 JEEB: you're still showing ~203 nits then
11:47 JEEB: since SDR graphics white in HDR is around that
11:47 Company: JEEB: that may be a massive waste
11:47 JEEB: is it? I would expect that to be possibly even lower than the SDR brightness knob value
11:47 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.
11:47 JEEB: at least on my screen SDR graphics white in HDR mode is actually greyer than SDR graphics white in SDR mode
11:48 JEEB: HDR only should use more power if you actually go higher nits
11:48 Company: JEEB: but does it use more power to draw the HDR gray?
11:48 Company: it *should*, sure
11:48 pq: eating more power for dumb or cheaper design decisions
11:48 Company: but does it?
11:48 JEEB: I would be deeply surprised if it does if you are actaully not utilizing those higher nits
11:49 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
11:50 Company: I think it's likely that it does that
11:50 pq: JEEB, it was said that the HDR picture is brighter in Windows.
11:50 Company: but that's just gut feeling
11:51 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.
11:51 Company: and I would be surprised if that was *not* the case
11:52 pq: we don't know what waas measured and how, do we?
11:52 Company: I didn't try to find out
11:53 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.
11:53 Company: https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/energy-label-and-ecodesign/energy-efficient-products/electronic-displays-including-televisions_en
11:54 Company: most of the HDR monitors are "F" and "G" - I think the Apple ones manage "E"
11:54 pq: Maybe they measured true consumed watts, but the HDR test case did have a considerably brighter looking picture.
11:55 pq: Maybe HDR is sold to consumers as "brighter picture"? Which it shouldn't be, but makes a nice difference in brightly lit stores?
11:56 JEEB: that's how it's demoed and marketed. better blacks and BRIGHTER.
11:56 pq: so it makes sense to say that giving consumers what they (wrongly) expect consumes more power.
11:58 Company: https://eprel.ec.europa.eu/screen/product/electronicdisplays/1420497
11:58 Company: is what you get for my monitor
11:58 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
11:59 dv_: instead of (480+372)
12:00 pq: dv_, do not try to play with the calibration matrix until you have the input-output device assignments right.
12:00 pq: dv_, weston even logs those assingments if you can decipher which device is which.
12:00 dv_: okay
12:01 dv_: existing udev rules seem to assign the outputs correctly, but I'll recheck
12:01 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.
12:02 dv_: ah, yeah, maybe I overlooked something
12:11 dv_: pq: indeed, that seemed to fix it
12:11 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?
12:12 pq: I don't recall, but the udev property should be set to the head name which you can find in the Weston log.
12:13 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.
12:13 pq: IIRC
12:14 dv_: this is an embedded device with hardwired displays
12:14 pq: then you have no problem, but Weston doesn't know that.
12:15 pq: the problem is about driver instance initialization race
12:18 dv_: the names are `DSI-1` and `LVDS-1`
12:18 pq: right
12:18 dv_: and, is there a way to assign manual names?
12:19 dv_: I mean, I identify the devices through other means already in the udev rule
12:19 pq: For heads, no. For outputs, yes IIRC, but that I think is only used in weston.ini and nowhere else.
12:20 pq: well, udev rules identify the input devices, and heads are output devices.
12:20 dv_: ah ... right
12:21 dv_: so I can assign an output name, but that assignment will only really exist within weston.ini
12:21 pq: output devices practically don't exist in udev, they come through KMS API instead
12:21 pq: yeah, so you'd only benefit of it in the weston logs
12:21 dv_: so right now this is not really solved fully
12:22 pq: custom naming, no, not at all
12:23 pq: People might use a boot-up or other service to generate the udev rules, if hardware is not fixed.
12:23 pq: nothign better exists AFAIK
12:23 dv_: do any proposals exist?
12:24 dv_: (just asking out of pure interest ... the discussed solution works fine here)
12:24 pq: not that I know of, other than making weston use reliably persistent head names but still not custom names.
12:25 pq: maybe mutter uses some better heuristics to match a touchscreen's input and output?
12:25 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.
12:26 pq: *don't know
12:26 dv_: true
12:26 pq: vendor drivers can just hardcode arbitrary matching rules that work for them on Windows
12:27 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.
12:28 pq: I mean physically label in the machine chassis.
12:28 pq: the physical ports can then be identified in software, and if something is in there, associate them together.
12:40 pq: Company, I could not find any technical description of the power measurement video sequences in there.
12:42 Company: is that because the website is so hard to search or is that because none exists?
12:43 zamundaaa[m]: pq: KWin tries to match output and touchscreen by looking at their physical sizes. Doesn't always work out though ofc
12:44 zamundaaa[m]: My portable touchscreen display pretends to be twice as big as it really is for some reason for example
12:50 emersion: sway detects built-in USB/displays
12:50 emersion: er
12:50 emersion: built-in touchscreens
12:51 emersion: IOW: if there's exactly one internal DRM connector and one internal touch input device, likely the same
12:52 emersion: zamundaaa[m]: i suppose there's no good way to match make/model/serial?
12:52 emersion: i mean, they can be different?
12:54 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.
12:56 pq: zamundaaa[m], the touch input device has a physical size? Hmm, I guess touchpad may have too, so why not.
12:57 zamundaaa[m]: emersion: I think it's not often that they're the same
12:58 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 :/
12:58 zamundaaa[m]: But for finding the default touchscreen mapping it's at least something
12:59 pq: clearly we need a database for matching... and then someone buys two of the same kind.
12:59 pq: s/buys/plugs in/
12:59 pq: hmm
13:00 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?
13:01 pq: along with the built-in devices heuristics
13:01 pq: likely needs some automatic UX to pop up to verify the association is ok
13:02 pq: weston't touch calibrator can tell if you are poking a wrong screen
13:03 pq: but then you have to tell the touch calibrator which screen you want to calibrate via a cryptic and long name first
13:44 wlb: weston/main: Marius Vlad * 6 commits https://gitlab.freedesktop.org/wayland/weston/compare/c93a54ece38d86a18808feb619893bba7c65ebbd...4f17af4691a1ad1c1651a48ab4ae2a21742e7125
13:44 wlb: weston Merge request !1362 merged \o/ (fix up launcher-logind removal https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1362)
14:55 Company: emersion, jadahl: Would it make sense to delete the master branch of wayland-protocols?
14:56 Company: I've just had people read the protocols in that branch because of some web links instead of from main
14:56 Company: and ending up with a 2 year old outdated version
14:57 emersion: that could break some people's stuff
14:58 Company: otoh, those people's stuff may be broken already because it uses 2 year old protocols
14:59 emersion: no
14:59 emersion: if some code compiled fine with an old checkout, it will not break
14:59 emersion: if we delete the branch, we may break builds
15:00 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
15:00 Company: yeah, but if somebody tracks master, they might want to track tip of development
15:00 Company: and that would be broken now
15:01 emersion: not necessarily
15:01 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
15:03 Company:checked and Gnome seems to have deleted the master branches - at least GTK, gnome-shell and glib don't have one
15:04 Company: I guess I'll file a bug about it
15:04 ebassi: Company: We deleted the master branch after a few months
15:04 ebassi: To let people move
15:04 Company: yeah, that makes sense
15:05 Company: wayland-protocols master is >2 years old - April 2021
15:12 wlb: wayland-protocols Issue #160 opened by Benjamin Otte (company) Please delete the master branch https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/160
15:17 emersion: ebassi: not everyone follows the "reproducible CI" paradigm (i don't)
15:28 wlb: weston Merge request !1365 opened by Marius Vlad (mvlad) main: Create a no-op color manager for the remoting plug-in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1365 [Weston frontend]
16:17 ebassi: emersion: I'm not sure what that has to do with anything, to be honest
16:18 emersion: ebassi: i routinely checkout the master branch of my close deps in my CI
16:18 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
16:19 ebassi: And on master the possibility of a breakage is higher
16:20 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
17:59 wlb: wayland Issue #410 opened by fredvs (fredvs) https://wayland-book.com/ https://gitlab.freedesktop.org/wayland/wayland/-/issues/410
19:38 Company: oh look, WAYLAND_DEBUG claims my GPU supports these formats: array[22]
19:38 Company: is there a way to make WAYLAND_DEBUG expand that?
19:39 bl4ckb0ne: iirc wayland-info lists those
19:40 vyivel: yeah wl_arrays are opaque for libwayland
19:43 ifreund: Company: you might be interested in https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/301
19:44 Company: oh excellent, the array[22] is indexes into fd 28, 176
19:45 ifreund: fun :/
19:46 Company: I was trying to understand what linux-dmabuf-unstable-v1 is actually doing
19:47 Company: things like why I have 11 formats but there's an array[22]
19:49 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml?ref_type=heads#L456
19:52 Company: bl4ckb0ne: that doesn't explain the mystery of why there's 22 entries in the array though
19:52 vyivel: maybe it's 22 bytes?
19:54 bl4ckb0ne: wl array is 32 or 64?
19:54 Company: oh yeah, it may be 22 bytes
19:54 Company: it's 16 bit integers
19:54 vyivel: bl4ckb0ne: aligned to 32 bits iirc
19:54 robert_mader: the indexes are send as uint16_t / two bytes each
19:54 bl4ckb0ne: 32 indeed
19:55 Company: I hought it prints the array length
19:56 Company: as in number of elements
19:56 Company: but it might print number of bytes
19:56 robert_mader: The formats should only be aligned in the format table, not for the traches
19:56 robert_mader: see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml?ref_type=heads#L549
19:59 Company: good job saving 154 bytes on the wire there
20:00 Company: I guess it's probably twice that now that YUV has landed
20:05 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.
20:35 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
21:22 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.
21:25 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.
21:29 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.
22:01 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?
23:19 swick[m]: there are good reasons for not wanting hdr mode: less predictable colorimetry, less panel adjustment, higher bandwidth requirements, ...
23:20 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
23:43 wlb: wayland Issue #411 opened by Evert Vorster (evertvorster) External Monitor is not detected on nVidia Advanced Optimus https://gitlab.freedesktop.org/wayland/wayland/-/issues/411