ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
privacy has joined #wayland
<navi>
one could write a compositor and run it under another compositor, i'd think
Brainium has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Brainium has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
navi has quit [Quit: WeeChat 4.1.2]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
guru_ has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
guru__ has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
lockywolf has quit []
Brainium has joined #wayland
lockywolf has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
qaqland_ has quit [Remote host closed the connection]
qaqland has joined #wayland
hendry has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cwegener has joined #wayland
glennk has joined #wayland
mxz has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
privacy has quit [Quit: Leaving]
peeterm has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
garnacho has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
sima has joined #wayland
peeterm has joined #wayland
mart has joined #wayland
leon-anavi has joined #wayland
vincejv has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
rgallaispou has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
rasterman has joined #wayland
Leopold has quit []
Leopold has joined #wayland
navi has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
utsweetyfish has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
utsweetyfish has joined #wayland
glennk has joined #wayland
qyliss has quit [Quit: bye]
qyliss has joined #wayland
cmichael has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
bl4ckb0ne has quit [Remote host closed the connection]
Nefsen402 has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
emersion has joined #wayland
Nefsen402 has joined #wayland
bl4ckb0ne has joined #wayland
cmichael has quit [Remote host closed the connection]
rasterman has quit [Remote host closed the connection]
rasterman has joined #wayland
<swick[m]>
pq: did you know the Colorimetry InfoFrame also influences the default quantization range?
<swick[m]>
so much fun to be had
glennk has joined #wayland
fmuellner has joined #wayland
hendry has joined #wayland
Leopold_ has quit [Remote host closed the connection]
rv1sr has quit []
Leopold_ has joined #wayland
cmichael has joined #wayland
rv1sr has joined #wayland
rv1sr has quit []
<pq>
swick[m], but that's hidden by the kernel driver anyway, right? ;-)
<pq>
no, I didn't
<pq>
or well, I did know that xvYCC can only exist with limited qunatization range
<vsyrjala>
xvycc is a paradox
<pq>
some would call it "engineering" :-)
glennk has quit [Ping timeout: 480 seconds]
<ifreund>
with regards to the tablet-v2 protocol, is it expected that the compositor draws a separate cursor for each tool?
<emersion>
it's compositor policy
<emersion>
mutter does it that way, Sway doesn't, for instance
<ifreund>
does the hardware allow using multiple tools at the same time on the same tablet?
<ifreund>
it seems like not having separate cursors would be very confusing if so
<emersion>
i believe it does (but not all hw supports it)
<emersion>
yeah, i agree that per-tool cursors are better
<emersion>
from UX perspective
<emersion>
a single cursor reminds me of X11 dragging the pointer cursor on touchscreen press…
<ifreund>
it also seems a bit cleaner from a code perspective to me, for example the interaction with pointer-constraints seems non-trivial
<ifreund>
(if they used the same cursor as the pointer)
<davidre>
it depends on the tool probably as well
<davidre>
There are physical pens that become a different tool when you press a button
<davidre>
I have one that switches tools when I rotate it. Like a phyical pencil it has the eraser on top of it
<ifreund>
davidre: maybe I'm missing something, but I don't see how having a separate cursor per tool would be an issue there?
<ifreund>
just hide the tool's cursor on proximity out
<davidre>
Right
<davidre>
I was thinking if I have the same physical thing in my hand I probably expect it to be the same cursor
firewire has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
<ifreund>
I assume a client with good UX wants a different cursor graphic for a pen vs an eraser tool as well
<davidre>
True
<davidre>
The question is what happens if you use the same tool with multiple pads
<davidre>
According to the docs such things are possible but very rare
<ifreund>
davidre: I'm not sure I understand what issue you're referring to when using the same tool with multiple tablets?
<ifreund>
I'd assume the cursor is tied to the tool, not the tablet
<davidre>
yeah
<ifreund>
that's also what the set_cursor request in the protocol suggests
<davidre>
I was confused and thought the tool is not independent in wl protocol
cmichael has quit [Remote host closed the connection]
cmichael has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cmichael has quit []
<swick[m]>
pq: heh, hidden in the sense that none of the drivers ever sets the colorimetry? suuure
<swick[m]>
this is all such a huge shitshow
Leopold_ has quit [Remote host closed the connection]
<JEEB>
I think there were some that supported that DRM extension?
<JEEB>
AMD being one of those that didn't, alas :<
<JEEB>
unless you mean it got set in DRM but not underneath 8)
Leopold_ has joined #wayland
<swick[m]>
every time I look at this mess it seems even more impossible to fix it
<pq>
swick[m], I mean, userspace setting "Colorspace" would limit the choices of quantization range the driver can take.
<swick[m]>
hah, you expect them to take care of the quantization range when you set the Colorspace prop?
<swick[m]>
that's very optimistic
<pq>
it's just bugs if they don't, not a broken spec on that part
<swick[m]>
but hence the idea to say only a few of the Colorspace variants are well-defined and the rest is undefined
<swick[m]>
but I'm failing so hard to even come up with a proper definition for "Default"
<pq>
since userspace is expected to program CRTC to always produce full range, the quantization range is not a problem. Transfer characteristics are a problem.
<zamundaaa[m]>
What do drivers do right now with "Default", when YCbCr is used on the wire?
<swick[m]>
how knows
<swick[m]>
who*
<zamundaaa[m]>
While we won't get any well defined behavior for what the display does, I would hope that drivers at least do something consistent
<swick[m]>
probably a bunch of different things
<swick[m]>
they certainly don't
<zamundaaa[m]>
As an escape hatch, I'd just leave it undefined until we know more at least
<swick[m]>
and even then, what the actual display does is a different matter
<swick[m]>
all I want is that they follow the spec consistently
<zamundaaa[m]>
Yeah, what the display does can be different, but I want to be able to share ICC profiles between PCs
<pq>
what the actual display does is not our worry
<zamundaaa[m]>
That doesn't work if Intel and AMD have different ideas of what they send on the wire
<swick[m]>
exactly
<swick[m]>
yes
<swick[m]>
either way, what we have right now is everyone being broken in different ways
<swick[m]>
and it takes so much effort to even convince people writing the drivers that everything they are doing is broken
<pq>
it's kinda starting to make sense how old-school color management people said that ICC profiles are tied to the machine and the OS and the software.
<swick[m]>
at this point I'd just like to make "Default" undefined as well
<pq>
(and use case, but I'll ignore that for now)
<swick[m]>
give up on the current KMS API
<pq>
default as undefined is fine by me
<JEEB>
even if the current KMS API mirrors the CTA stuff?
<swick[m]>
introduce the colorop CAP and remove all of that crap
<swick[m]>
then give user space props for the output format and the infoframes
<swick[m]>
move all that shit to user space
<any1>
yes please. :)
<swick[m]>
we just can't expect driver developers to get all of that right
cmichael has joined #wayland
<pq>
careful now, "we cannot expect display server to get anything right" ;-)
<JEEB>
just having one central logic which is shared by drivers would prolly be enough
<pq>
JEEB, I think mripard is tring to make that happen in the kernel.
<zamundaaa[m]>
pq: true, but this split color management responsibility stuff is getting pretty annoying
<JEEB>
pq: noice
<mripard>
pq: indeed
<pq>
but of course, the no-regressions policy means that... defaults cannot be fixed
<pq>
or, well, anything?
<JEEB>
wat
<zamundaaa[m]>
You can't change the behavior of the Default enum value, but you could introduce a new one of course
<zamundaaa[m]>
SaneDefault or something :D
<pq>
indeed
<swick[m]>
it's nice that mripard is moving the stuff to core, but really, we're moving the color pipeline to user space, we should also move the color signalling to user space
<pq>
if you fix a driver to behave consistently with others, there is always the possibility that someone will scream "you broke my use case"
<pq>
and if someone screams, the kernel regression policy is to revert the change
<zamundaaa[m]>
In this case it's also not unreasonable - if you've profiled your screen, you would not expect a new kernel version to break it
<pq>
zamundaaa[m], to be honest, I suspect people who care about color have let go of that idea a long time ago :-p
<pq>
so... maybe there is a chance
<any1>
has anyone suggested creating a new "low level" uAPI?
<mripard>
swick[m]: most drivers are broken because there's no real documentation on what drivers are expected to do, no test suite either, they are usually done by small teams that might not have even a full-time person on it, and the ones that have the manpower to understand and get this right largely work in silo
<swick[m]>
right, I don't blame anyone for the situation
<mripard>
so it's about more than just the API
<mripard>
and yeah, getting most of this stuff into the core will at least make it somewhat consistent
<swick[m]>
moving the stuff to user space means the driver developers don't even have to understand all of it
<pq>
new DRM client cap: UAPI generation? :-)
<mripard>
but you'd still have the test that, say, rockchip only ever tested their driver with Android
<mripard>
s/test/problem/
<emersion>
pq, yeah, i've thought about that
<swick[m]>
sure, there definitely also needs to be better documentation and a test suite for the kernel side, even if we move most of the logic to user space
<swick[m]>
I very much want that as well
<emersion>
API_SANITY_LEVEL=1
<emersion>
increase for each sane breaking change :)
<zamundaaa[m]>
Aa long as all drivers support the latest sanity level at the same time
<zamundaaa[m]>
I still have to deal with legacy modesetting from time to time
<zamundaaa[m]>
Having three APIs to support in userspace wouldn't be fun
<pq>
FWIW, Weston configuration will have KMS "Colorspace", EOTF from "HDR_OUTPUT_METADATA" and actual color profile as completely orthogonal things to configure separately. Now I'm starting to question whether KMS HDR static metadata should be derived from the output's color profile (image description).
<zamundaaa[m]>
In KWin I just always use the values from the EDID
<zamundaaa[m]>
Seems to work well so far
<pq>
I'd use sRGB by default, and only give an option to use (parts of) EDID.
<pq>
for defining the output image description that is, when no special KMS settings are made
<zamundaaa[m]>
Oh I just meant for the hdr output metadata
<pq>
if KMS "Colorspace" picks BT2020, then that's different, HDR_OUTPUT_METADA picks another EOTF.
<swick[m]>
zamundaaa: I mean, all combinations of caps are basically separate versions you have to support
<pq>
zamundaaa[m], do you have reports of displays actually responding to the metadata more than just HDR yes/no?
Fischmiep has joined #wayland
<zamundaaa[m]>
I was very pessimistic about that and haven't exposed that functionality to users. HDR_OUTPUT_METADATA is either unset in SDR mode, or set with the values from the EDID in HDR mode
glennk has joined #wayland
<zamundaaa[m]>
On my own screens, I haven't seen a single one react to the primaries. One of them reacts to the brightness values, but really only in ways that would make the user experience worse
<JEEB>
yea for MDCV I expect the gamut is mostly ignored
<pq>
right
<JEEB>
windows does pass the content light level for fullscreen applications
<zamundaaa[m]>
JEEB: I don't think Windows 11 does that anymore?
<JEEB>
I haven't upgraded yet so haven't tested. don't recall what the other people testing the libplacebo implementation noted and with which windows versions
<JEEB>
but I would be surprised if it wouldn't pass it if the application says "ohai this is the CLL"
<zamundaaa[m]>
Apps, more specifically games get it wrong, a lot
<pq>
perhaps because displays have been ignoring a lot
<zamundaaa[m]>
On a very different topic, I've been doing some frame scheduling stuff in KWin, and I've now had a closer look at the timestamps reported by the kernel... They don't make a lot of sense to me
<zamundaaa[m]>
On my 120Hz display, usually the difference between to pageflip timestamps is 8.33ms, as you'd expect
<zamundaaa[m]>
But sometimes, it's 9.35ms instead. Has anyone seen such a thing happen before, or could perhaps explain why it would happen?
<JoshuaAshton>
zamundaaa[m]: Have not seen that before
<MrCooper>
zamundaaa[m]: which driver is that, and what kind of display connection?
<JEEB>
JoshuaAshton: wow re: deprecated
<zamundaaa[m]>
This is with amdgpu, over DisplayPort. Adaptive sync is off ofc
<zamundaaa[m]>
But the issue that lead me to look at the timestamps also happens on Intel
<JoshuaAshton>
SteamOS has some hacks in the kernel for allowing you to commit during vfp, but that would cause you to miss a whole flip, not have the event be delayed by a few ms...
<JoshuaAshton>
How are you getting the time zamundaaa[m]?
<JoshuaAshton>
The timestamp from the handler or clock_gettime on the event
glennk has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
I'm looking at the usec number from the pageflip handler
<JoshuaAshton>
O_O
<zamundaaa[m]>
That was my reaction as well
<zamundaaa[m]>
What's more, there aren't any pageflips that happen "earlier than expected" later to compensate. It just goes back to 8.3ms diff to the previous timestamp
Net147 has joined #wayland
<MrCooper>
that sounds like there might actually be different timings in the GPU for some reason
<pq>
adjtime clock slweing, perhaps?
<pq>
*slewing
<pq>
CLOCK_MONOTONIC is not immune to adjtime
Net147 has quit []
Net147 has joined #wayland
<swick[m]>
ST 2094 is quite interesting. defines transforms from the hdr version to different other display capabilities. the transforms are applied for a specific period on different parts of the content
<swick[m]>
however, I don't think we should ever support that in wayland
<MrCooper>
pq: interesting, I almost joked about it being a leap millisecond, maybe that's not so far from the truth then
<JoshuaAshton>
seems far too much and too common for clock slewing, no?
<JoshuaAshton>
i haven't seen such behaviour on Deck
<MrCooper>
depends how far off the system time might go, doesn't it?
<pq>
how common is it?
<JoshuaAshton>
off by >1ms is huge
<zamundaaa[m]>
pq: sometimes it happens multiple times a second
<zamundaaa[m]>
I've even seen a pageflip being 2ms later
<JoshuaAshton>
zamundaaa[m]: I am curious if you see the same issue with kwin on Deck, or Gamescope on your PC (VBLANK_DEBUG define) and also curious what your clock source is
<JoshuaAshton>
perhaps you accidentally got screwed over and defaulted to hpet and not tsc?
<zamundaaa[m]>
dmesg says "switched to clocksource tsc"
<MrCooper>
and you don't force that via the kernel command line or something?
<MrCooper>
some Ryzen CPUs have unreliable TSC
<MrCooper>
e.g. the one in this laptop, and when I tried forcing TSC anyway, Firefox kept crashing due to the system time apparently moving backward sometimes
<zamundaaa[m]>
Not that I know of, no
tyzef has joined #wayland
<zamundaaa[m]>
But if this is a thing that can happen, then I suppose my scheduling logic will have to deal with it somehow
<zamundaaa[m]>
As long as the pageflips only happen too late, and not too early, it should be doable
<JoshuaAshton>
my scheduling logic would shit the bed at that lolol =)
<JoshuaAshton>
but i also haven't seen it
<MrCooper>
right, just means slightly higher latency than intended
<JoshuaAshton>
1.3ms is like the entire time we have for our redzone... heh
<MrCooper>
well, assuming the timestamps are accurate
<zamundaaa[m]>
With my triple buffering MR, KWin schedules up to two frames in advance, which caused this issue to be visible - as then sometimes two frames can accidentally target the same vblank
<zamundaaa[m]>
Which then resulted in glxgears getting more fps than the screen actually can show
<MrCooper>
ah, because the extrapolated presentation times don't match?
<zamundaaa[m]>
Yeah
junaid has joined #wayland
<MrCooper>
will need to keep that in mind for mutter as well
glennk has joined #wayland
Company has joined #wayland
<YaLTeR[m]>
wait so what's broken now?
Brainium has joined #wayland
rgallaispou has quit [Quit: Leaving.]
guru_ has quit [Remote host closed the connection]
guru_ has joined #wayland
opotin65 has joined #wayland
mart has quit [Quit: Konversation terminated!]
mripard has quit [Remote host closed the connection]
<MrCooper>
YaLTeR[m]: zamundaaa[m] is seeing variable intervals between the timestamps in atomic commit completion events, with fixed refresh rate
<YaLTeR[m]>
exciting
<pq>
could that timestamp be correct but the hardware itself being sometimes late, all the way to the cable?
<MrCooper>
that's what I was thinking, before you pointed out adjtime
kts has joined #wayland
<vsyrjala>
is psr involved?
tzimmermann has quit [Quit: Leaving]
privacy has joined #wayland
Vaughn has joined #wayland
<Vaughn>
Hi,
<Vaughn>
I'm trying to compile xwayland with the explicit sync patches applied, and having some trouble tracking down all the necessary patches.
<Vaughn>
Does anyone know where xDRI3ImportSyncobjReq is supposed to be defined?
nielsdg has joined #wayland
<nielsdg>
Vaughn: jfyi, the patches won't do anything before the NVIDIA driver has implemented the protocol as well
<Vaughn>
Are you sure? I keep hearing about people having success using them.
<Vaughn>
That said, KDE6 seems like it might trigger epileptic fits if we don't get this fixed. So I'd still like to figure out the patches, so that we can patch xwayland in the distro ASAP.
<ofourdan>
Vaughn: you'll need the xorgproto branch as well
<Vaughn>
I see. The overlay must be failing somehow, then.
glennk has quit [Ping timeout: 480 seconds]
<Vaughn>
...oh. I'm overriding pkgs.xorgproto instead of pkgs.xorg.xorgproto
<vsyrjala>
MrCooper: yeah, "panel replay" is the new hotness apparently
<Vaughn>
It's applying properly now. Ok, just one question...
<Vaughn>
How is the patch being tested if there are no drivers that support it?
cmichael has quit [Quit: Leaving]
<zamundaaa[m]>
vsyrjala: this is on a desktop monitor, and not brand new, so it shouldn't have panel replay or whatever
kts has quit [Ping timeout: 480 seconds]
tanty has quit [Quit: Ciao!]
rv1sr has joined #wayland
<MrCooper>
Vaughn: it "works", just has mostly no effect without the corresponding pieces in the nvidia driver and Wayland compositor, except for the glamor_finish workaround
<Vaughn>
That particular workaround already sounds like something I'd want.
<MrCooper>
I suggested multiple times landing that ahead of time, the Nvidia engineers don't seem interested though
<Vaughn>
I'm mostly interested in making sure we don't hurt anyone when plasma6 lands in stable.
<MrCooper>
it could have a performance impact, so it's a tricky call
<Vaughn>
I'm going to push back on that as hard as I can, but if I can't, then anything that might help is good.
<Vaughn>
Switching the default session back to X11 would also work, I suppose.
<zamundaaa[m]>
Regressing the experience for everyone because of this seems a bit bad
<Vaughn>
It's not a matter of performance regressions anymore. Shipping Plasma6 in its current state could cause legal liability.
<zamundaaa[m]>
MrCooper: how complicated would it be to extract the glamor_finish workaround?
<MrCooper>
not very
<Vaughn>
(That aspect would probably come to nothing, since there's no single company to point at. Speaking personally, however, I am not okay with shipping something that can trigger epileptic fits.)
<zamundaaa[m]>
Okay, then I'll look into that on Monday. Even if full explicit sync support lands in time, that would be something to backport to older versions imo
<Vaughn>
Much appreciated.
<Vaughn>
Do you want a video as evidence?
<MrCooper>
Vaughn: FWIW, the glitches happen because the nvidia driver doesn't implement implicit synchronization as required by the Wayland & X11 Present protocols and KMS
<Vaughn>
Oh, I know. That just doesn't really matter.
leon-anavi has quit [Remote host closed the connection]
<MrCooper>
(and BTW the explicit sync support in the protocols won't fix the glitches due to lack of KMS implicit sync)
<Vaughn>
I hope you understand. By the point medical regulations get into play, there's no longer any room for finger-pointing. There are real people on the other side of the screen.
<Vaughn>
If the only solution ends up being "disable Wayland entirely on nvidia", then I guess that's what I'll push for.
<MrCooper>
the issue has been widely known for a long time with GNOME Wayland, so no clue what you're on about
<Vaughn>
Wayland has never been the default before
<daniels>
defaulting to X11 on NV is the most sensible course of action until it’s fixed, yes
<Vaughn>
...and, uh, until recently if I tried to run wayland on nvidia it wasn't an issue, because I could never get far enough into the process to encounter this issue; things failed in a more flagrant manner prior to that.
<MrCooper>
AFAIR it was the default even with nvidia for a long time in Fedora Workstation
<Vaughn>
But it's really about the default, yeah. Sorry; that's not really a wayland issue. I might take that up with KDE.
tanty has joined #wayland
<zamundaaa[m]>
MrCooper: KMS implicit sync missing is fixed in KWin
Sachiel has quit [Ping timeout: 480 seconds]
<MrCooper>
actually IIRC it is the default now in Fedora, unless there are also non-Nvidia GPUs in the system
<zamundaaa[m]>
It just waits for the egl fence before committing buffers
<MrCooper>
I see, mutter doesn't do that quite yet
<MrCooper>
and IN_FENCE_FD doesn't seem hooked up yet in the nvidia KMS driver
nurupo has quit [Quit: nurupo.ga]
nurupo has joined #wayland
<zamundaaa[m]>
Indeed it's not. I've been told it's being worked on, but for now it just rejects the atomic commits
<MrCooper>
oh, it's that broken? :(
<MrCooper>
so it rejects the commit if IN_FENCE_FD has a non-signaled fence? Because mutter always sets a signaled fence for direct scanout
<zamundaaa[m]>
When I tested it, yes. That was with an implicit fence extracted from a dmabuf though, so it could've just been that
<zamundaaa[m]>
I should test it again with a fence from egl... But I just hardcoded KWin to not set it with NVidia, as there's no implicit sync it would disable anyways
mart has joined #wayland
gallo has joined #wayland
<swick[m]>
so is the problem that the fence is not signaled or that it's not from GL/VK, or something else?
<swick[m]>
I mean, in the end it shouldn't matter and they should fix their driver, but still... would be interesting to know
Sachiel has joined #wayland
<zamundaaa[m]>
I looked up some old conversations about this, apparently it was only implemented for Tegra GPUs, and when it was implemented, they chose to reject commits on unsupported GPUs, for reasons that aren't entirely clear
<zamundaaa[m]>
So you really just have to do if (!isNVidia), at least until an updated driver actually supports the property
Brainium has quit [Quit: Konversation terminated!]
<JEEB>
JoshuaAshton: posted that on libplacebo channel and one of the generally-windows-developing people noted regarding win11 > < nevcairiel> was fine last i checked with a hdmi checker
<JEEB>
so it seems to be still passed just fine with fullscreen applications
<JoshuaAshton>
interesting
<JoshuaAshton>
last time I spoke with NV about it they said it didn't do anything anymore
<JoshuaAshton>
maybe the guy was wrong :frog:
<JEEB>
are you talking about colorspace configuration?
<JoshuaAshton>
no, the SetHDRMetadata
<JoshuaAshton>
call
<JEEB>
right
<JEEB>
just wanted to make sure :D
<JEEB>
since MS did apparently tell all vendors to stop auto-switching modes
<JEEB>
so that the windows setting (and vendor driver specific interfaces) would be the only ways to switch modes
junaid has quit [Remote host closed the connection]
floof58 has quit [Ping timeout: 480 seconds]
privacy has quit [Quit: Leaving]
floof58 has joined #wayland
rv1sr has quit []
sima has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]