ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
karolherbst has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Calandracas has joined #wayland
garnacho has quit [Read error: No route to host]
garnacho has joined #wayland
Calandracas_ has joined #wayland
karolherbst has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: No route to host]
karolherbst has joined #wayland
karolherbst has quit [Ping timeout: 480 seconds]
shoragan has quit [Read error: Connection reset by peer]
karolherbst has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
shoragan has joined #wayland
shoragan has quit []
yshui has joined #wayland
shoragan has joined #wayland
yshui_ has quit [Ping timeout: 480 seconds]
pH5 has quit [Read error: Connection reset by peer]
pH5 has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Consolatis_ has joined #wayland
Consolatis is now known as Guest5956
Consolatis_ is now known as Consolatis
Brainium has quit [Quit: Konversation terminated!]
Guest5956 has quit [Ping timeout: 480 seconds]
bebop has joined #wayland
bebop has left #wayland [#wayland]
alarumbe has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
lsd|2 has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
tent4051 has quit [Ping timeout: 480 seconds]
tent4051 has joined #wayland
bim9262 has joined #wayland
tzimmermann has joined #wayland
JakeSays1 has joined #wayland
leon-anavi has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
kts has joined #wayland
dviola has quit [Quit: WeeChat 4.5.1]
dviola has joined #wayland
bookworm has quit []
bookworm has joined #wayland
JakeSays has joined #wayland
iomari891 has joined #wayland
JakeSays1 has quit [Ping timeout: 480 seconds]
sima has joined #wayland
garnacho has joined #wayland
kts has quit [Quit: Leaving]
glennk has joined #wayland
atticf has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
rasterman has joined #wayland
kts has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
andyrtr_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
ity has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
rgallaispou has joined #wayland
andyrtr_ has quit [Ping timeout: 480 seconds]
ity has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
Moprius has joined #wayland
fmuellner has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Moprius has quit [Remote host closed the connection]
<soreau>
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?
nerdopolis has joined #wayland
<d_ed[m]>
how would it know it's offset from the main surface?
<soreau>
well that's kind of the question.. it knows the offset of its subsurfaces, right?
<d_ed[m]>
it can set the offset of it's subsurfaces
<soreau>
but can't get
<d_ed[m]>
or make a subsurface fullscreen
peeterm_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
peeterm has quit [Ping timeout: 480 seconds]
peeterm_ is now known as peeterm
<kennylevinsen>
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...
<zmike>
sir this is a sfw channel
<soreau>
that depends on what kind of w you're doing :P
iomari891 has quit [Ping timeout: 480 seconds]
Serus has quit [Ping timeout: 480 seconds]
Serus has joined #wayland
andyrtr_ has joined #wayland
<llyyr>
use case for single pixel buffer
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
<soreau>
might as well have the client use grim (code), make itself bright green and snapshot the output to do maths
iomari891 has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Delicates has joined #wayland
CME has quit []
CME has joined #wayland
<Delicates>
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?
<emersion>
depends which compositor you're using
<emersion>
drm_info can be used to check the primary plane pixel format
<Delicates>
KDE?
<llyyr>
should be supported? on sway you could do this for a while
<kennylevinsen>
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
<kennylevinsen>
and your display server is KDE/kwin, so it's all KDE specific - wayland is just a protocol specification
<zamundaaa[m]>
Delicates: unless you go out of your way to change it, KWin is using a 30bpp framebuffer
<zamundaaa[m]>
Whether or not that actually reaches the screen is hard to know, there's no driver interface that exposes that information :/
<Delicates>
:(
<Delicates>
That's exactly what I am trying to do.
<Delicates>
My laptop manufacturer is giving me BS that 30-bit depth is an unsupported feature limitation on this laptop model.
<Delicates>
I want to prove to them that it's BS and they need to fix their Intel driver config.
<Delicates>
Windows drivers that is
<llyyr>
why do you think it's bs?
<Delicates>
Because my 5 year old laptop can drive this monitor at 30 bits, but this new one can't.
<kennylevinsen>
the internal panel could have that limitation, but idk if the xe driver's debug interface has any sort of info in that regard
<Delicates>
Same monitor, same cable, newer Intel GPU
<llyyr>
oh, I thought you meant the laptop display
<Delicates>
dual GPU actually... Intel CPU + Nvidia.
<llyyr>
if you're lucky some monitors expose that information hidden somewhere in the OSD
<llyyr>
it'll tell you if it's getting 10bpc or 8bpc on the wire
<Delicates>
Drives built-in panel just fine at 30-bits. But Thunderbolt connected monitor - only 8 bits.
<llyyr>
alternatively, drm_info and check the pixel format for the display
<kennylevinsen>
I really do hope you mean 24 bits
<kennylevinsen>
it's 8/10 or 24/30 depending on definition
<Delicates>
I'm trying to use Kubuntu live image, doesn't look like that command is installed. any idea what package it comes with?
<llyyr>
^that command is probably more to the point
<kennylevinsen>
you'd need to edit the path to match yoru dri node and crtc, but you might have a current_bpc thing to check
user21 has joined #wayland
<kennylevinsen>
not sure if xe will expose something similar, don't have your hardware
<soreau>
apt install drm-info && drm_info
<kennylevinsen>
at least i915 and amdgpu has it
user21 has quit []
<zamundaaa[m]>
llyyr: drm_info doesn't tell you anything about this
user21 has joined #wayland
<Delicates>
This seems to be using i915 driver
<zamundaaa[m]>
The buffer format and bpc used on the wire are independent of each other
<llyyr>
so the "max bpc" property is about the buffer format? i guess that's useless here then
<Delicates>
Yeah, I don't see anything in drm_info
<kennylevinsen>
no the driver's max bpc is for the link negotiation
<kennylevinsen>
but you don't want max bpc, you want current bpc
<Delicates>
Yeah, I don't see anything in drm_infoIt sgows max bpc range even for HDMI ports that have nothing connected to them
<any1>
IIRC there is no easy way to check what bpc the driver actually managed to give you
user21 has quit []
<kennylevinsen>
hence the debugfs thing I showed earlier, assuming your driver supports it
<any1>
oh, nm, I guess the debugfs thing tells you what the bpc actually is
<Delicates>
I like the /sys path... but that is hard to find in there
<Delicates>
i915_current_bpc is showing 10 for one crtx and is showing 6 for another.
<Delicates>
makes no sense
<kennylevinsen>
nothing weird about that
<Delicates>
Why would it be showing 6?
<kennylevinsen>
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
<kennylevinsen>
the crtc allocations are dynamic, so you'll have to check with drm_info to figure out what connector uses what crtc powers what
<kennylevinsen>
s/powers what//
<Delicates>
I think internal panel is the one showing 6
<Delicates>
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.
<kennylevinsen>
the xorg logs are irrelevant in that regard
<Delicates>
I know only one tool that could do it... nvidia-settings app can show current BPC for each monitor
<kennylevinsen>
that won't tell you anything about intel
<Delicates>
actually... I wonder if I can unload Intel driver and load nvidia driver to switch over to using Nvidia GPU?
<Delicates>
I don't really understand how things work with Dual GPUs
<kennylevinsen>
either both GPUs have ports and e.g. internal panel is wired to one GPU and some external ports to the other GPU
<kennylevinsen>
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
<Delicates>
On Windows Intel seems to be driving, unless something changes over to Nvidia... I don't really understand the mechanism.
<kennylevinsen>
some gaming laptops is #1, most laptops are #2
<Delicates>
Yeah, it's the same Thunderbolt port
<kennylevinsen>
(a third configuration exists where there's a mux and each port can be switched, but that's rare)
<kennylevinsen>
unless you have a mux, a port always goes to the same GPU that GPU and its driver decides the capabilities
<Delicates>
Thank you for helping me out and going down the HDR rabbit hole.
<Delicates>
I solved it this morning, just needed to sleep on it and get a fresh head.
<Delicates>
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.
<Delicates>
Interestingly, looks like Intel GPU is using 10-bit depth even in console.
<Delicates>
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)"
<Delicates>
but on this new laptop it says "COLOR DEPTH 10 BIT" "HDR SOURCE SDR(10000)"