13:10wlb: weston Issue #984 closed \o/ (dirty region exist during the process of the weston composition https://gitlab.freedesktop.org/wayland/weston/-/issues/984)
13:35soreau: curious, can a parent client position itself by making a temporary child surface fullscreen, noting the offset from the main surface and then attaching a new parent buffer with an offset based on the information?
13:56d_ed[m]: how would it know it's offset from the main surface?
13:56soreau: well that's kind of the question.. it knows the offset of its subsurfaces, right?
13:57d_ed[m]: it can set the offset of it's subsurfaces
13:57soreau: but can't get
13:57d_ed[m]: or make a subsurface fullscreen
14:22kennylevinsen: if you wanted to do Very Nasty Things, you could make a very large surface and then move a 1x1px subsurface around to probe for output enter/leave events...
14:29zmike: sir this is a sfw channel
14:31soreau: that depends on what kind of w you're doing :P
15:02llyyr: use case for single pixel buffer
15:07soreau: might as well have the client use grim (code), make itself bright green and snapshot the output to do maths
15:36Delicates: Is there a simple way to try to run Wayland at 30 bpp depth (similar to Xorg "startx -- -depth 30")? And then is there a way to verify at what colour depth Wayland is running each display at?
15:37emersion: depends which compositor you're using
15:38emersion: drm_info can be used to check the primary plane pixel format
15:40Delicates: KDE?
15:43llyyr: should be supported? on sway you could do this for a while
15:44kennylevinsen: Delicates: check the display settings. You don't "run wayland at 30 bpp depth", rather you configure a particular monitor to render at that bit depth
15:44kennylevinsen: and your display server is KDE/kwin, so it's all KDE specific - wayland is just a protocol specification
15:51zamundaaa[m]: Delicates: unless you go out of your way to change it, KWin is using a 30bpp framebuffer
15:51zamundaaa[m]: Whether or not that actually reaches the screen is hard to know, there's no driver interface that exposes that information :/
15:57Delicates: :(
15:57Delicates: That's exactly what I am trying to do.
15:59Delicates: My laptop manufacturer is giving me BS that 30-bit depth is an unsupported feature limitation on this laptop model.
15:59Delicates: I want to prove to them that it's BS and they need to fix their Intel driver config.
16:00Delicates: Windows drivers that is
16:00llyyr: why do you think it's bs?
16:00Delicates: Because my 5 year old laptop can drive this monitor at 30 bits, but this new one can't.
16:00kennylevinsen: the internal panel could have that limitation, but idk if the xe driver's debug interface has any sort of info in that regard
16:01Delicates: Same monitor, same cable, newer Intel GPU
16:01llyyr: oh, I thought you meant the laptop display
16:01Delicates: dual GPU actually... Intel CPU + Nvidia.
16:01llyyr: if you're lucky some monitors expose that information hidden somewhere in the OSD
16:02llyyr: it'll tell you if it's getting 10bpc or 8bpc on the wire
16:02Delicates: Drives built-in panel just fine at 30-bits. But Thunderbolt connected monitor - only 8 bits.
16:02llyyr: alternatively, drm_info and check the pixel format for the display
16:02kennylevinsen: I really do hope you mean 24 bits
16:03kennylevinsen: it's 8/10 or 24/30 depending on definition
16:03Delicates: hahah ayes, 24 bits
16:04Delicates: How do I run drm_info?
16:04llyyr: run it in the terminal
16:05kennylevinsen: `sudo mount -t debugfs none /sys/kernel/debug`, `sudo cat cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
16:05kennylevinsen: `
16:05Delicates: I'm trying to use Kubuntu live image, doesn't look like that command is installed. any idea what package it comes with?
16:06llyyr: ^that command is probably more to the point
16:07kennylevinsen: you'd need to edit the path to match yoru dri node and crtc, but you might have a current_bpc thing to check
16:07kennylevinsen: not sure if xe will expose something similar, don't have your hardware
16:07soreau: apt install drm-info && drm_info
16:09kennylevinsen: at least i915 and amdgpu has it
16:11zamundaaa[m]: llyyr: drm_info doesn't tell you anything about this
16:11Delicates: This seems to be using i915 driver
16:12zamundaaa[m]: The buffer format and bpc used on the wire are independent of each other
16:13llyyr: so the "max bpc" property is about the buffer format? i guess that's useless here then
16:13Delicates: Yeah, I don't see anything in drm_info
16:15kennylevinsen: no the driver's max bpc is for the link negotiation
16:15kennylevinsen: but you don't want max bpc, you want current bpc
16:15Delicates: Yeah, I don't see anything in drm_infoIt sgows max bpc range even for HDMI ports that have nothing connected to them
16:15any1: IIRC there is no easy way to check what bpc the driver actually managed to give you
16:16kennylevinsen: hence the debugfs thing I showed earlier, assuming your driver supports it
16:16any1: oh, nm, I guess the debugfs thing tells you what the bpc actually is
16:16Delicates: I like the /sys path... but that is hard to find in there
16:23Delicates: i915_current_bpc is showing 10 for one crtx and is showing 6 for another.
16:23Delicates: makes no sense
16:25kennylevinsen: nothing weird about that
16:26Delicates: Why would it be showing 6?
16:27kennylevinsen: if the driver is telling you that it's using 6 bits per pixel, then it's probably using 6 bits per pixel. There could be a caveat around display-stream compression though
16:28kennylevinsen: the crtc allocations are dynamic, so you'll have to check with drm_info to figure out what connector uses what crtc powers what
16:28kennylevinsen: s/powers what//
16:30Delicates: I think internal panel is the one showing 6
16:40Delicates: Ok doesn't seem there's an easy way... I run Xorg.. Xorg log is showing it is using 24 bits, but /sys still says 6 and 10.
16:40kennylevinsen: the xorg logs are irrelevant in that regard
16:40Delicates: I know only one tool that could do it... nvidia-settings app can show current BPC for each monitor
16:41kennylevinsen: that won't tell you anything about intel
16:41Delicates: actually... I wonder if I can unload Intel driver and load nvidia driver to switch over to using Nvidia GPU?
16:41Delicates: I don't really understand how things work with Dual GPUs
16:42kennylevinsen: either both GPUs have ports and e.g. internal panel is wired to one GPU and some external ports to the other GPU
16:42kennylevinsen: or one GPU has all ports, and the secondary GPU is only used for render - but the output image is transferred back to the primary GPU for display
16:42Delicates: On Windows Intel seems to be driving, unless something changes over to Nvidia... I don't really understand the mechanism.
16:43kennylevinsen: some gaming laptops is #1, most laptops are #2
16:43Delicates: Yeah, it's the same Thunderbolt port
16:43kennylevinsen: (a third configuration exists where there's a mux and each port can be switched, but that's rare)
16:44kennylevinsen: unless you have a mux, a port always goes to the same GPU that GPU and its driver decides the capabilities
16:47Delicates: I think it must be #2
16:47Delicates: any way to check if it's mux?
16:47kennylevinsen: a bit out of scope of #wayland
22:07wlb: wayland-protocols Issue #229 closed \o/ (Proposed additions to ext_idle_notify interface to allow monitoring of user activity https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/229)
22:07wlb: wayland-protocols Issue #213 closed \o/ (We should revisit how idle-notify and idle-inhibit interact, esp. w. respect to RSI https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/213)
22:43Delicates: Thank you for helping me out and going down the HDR rabbit hole.
22:44Delicates: I solved it this morning, just needed to sleep on it and get a fresh head.
22:47Delicates: I remembered that this LG monitor had a "Service Menu". The Service Menu had "Debug Info" section, which showed current mode information, including color depth.
22:49Delicates: Interestingly, looks like Intel GPU is using 10-bit depth even in console.
22:56Delicates: Except I am now struggling to interpret the results... on the old laptop where Windows has no problems driving HDR, it says "COLOR DEPTH 10 BIT" "HDR SOURCE HDR(244)"
22:57Delicates: but on this new laptop it says "COLOR DEPTH 10 BIT" "HDR SOURCE SDR(10000)"