ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
xantoz has quit [Remote host closed the connection]
xantoz has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
Dostoevsky has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
<Dostoevsky>
Hey, can anyone see me?
<Dostoevsky>
I have a question about cursors...
Guest5850 has quit [Remote host closed the connection]
<bluetail>
you are supposed to ask, and wait until somebody replies
<bluetail>
please do not ask to ask, cause thats not how it works
<Dostoevsky>
OK, sorry! Q: Is there a way Wayland might include something in the protocol that allows hiding a cursor after a set time without movement? On X11 there was a plugin that did this, but it doesn't like Wayland...
cool110 has joined #wayland
cool110 is now known as Guest5902
<danieldg>
that can be done by the compositor (sway has an option for it, for one)
<danieldg>
an application can also do it by just making a transparent cursor
<Dostoevsky>
So it's more of an implementation thing, and not a protocol thing?
<Dostoevsky>
Ooh, transparent would work too...
<danieldg>
if you do that, keep in mind that it's a usability problem for someone to ask "where's the cursor?"
<Dostoevsky>
Ideally it would reappear on mouse movement. LOL
nerdopolis has joined #wayland
<danieldg>
that's also easy to do (just commit the normal cursor buffer again)
<Dostoevsky>
So for a KDE user, I'd either need a compositor plugin/KWin script or a change in KWin itself?
<Dostoevsky>
I'm trying to narrow down where I need to look for someone else willing to work on this...
fmuellner has quit [Ping timeout: 480 seconds]
<danieldg>
if you want it for all windows, do it in kwin (maybe as a script, dunno how it works internally)
<danieldg>
and yeah, this kind of global thing belongs in the compositor not the application imo
<Dostoevsky>
Alright. I'll look into KWin stuff, then. I just get annoyed by my cursor floating over the text I'm typing. I have typo issues - I need to see every letter...
<danieldg>
sway has 'hide_cursor when-typing', maybe consider that?
<danieldg>
vs a timeout that will often be short/long
<Dostoevsky>
Well, sway is GNOME, right? I mean, if it works with KDE, cool, I'll try it...
<danieldg>
no, sway is not gnome
<danieldg>
it's i3 for wayland
<danieldg>
tiling, based on wlroots
<Dostoevsky>
Oh, oops. I've never used a TWM
<Dostoevsky>
Looks neat, though...
<danieldg>
tiling takes a bit to get used to
<Dostoevsky>
Thanks for the help! I'll keep sway in mind, and go look at KWin's documentation. Maybe there's an easy API call I can make to hide things...
<Dostoevsky>
Probably not, but I can always hope. :-)
<Dostoevsky>
Have a good night!
Dostoevsky has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
carlos_ has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Guest5902 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5912
Brainium has quit [Quit: Konversation terminated!]
davidre has quit [Quit: Client limit exceeded: 20000]
Zeroine has quit []
Zeroine has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
ecloud has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
babyfaceold has quit [Ping timeout: 480 seconds]
axet has joined #wayland
sevz has quit [Quit: WeeChat 4.1.1]
Fxzxmic has quit [Read error: Connection reset by peer]
<swick[m]>
JoshuaAshton_: it's still not clear what you're even arguing for. everyone acknowledges that some metadata coming from videos and windows games might be bad (to the point that if you clip at the MDCV you get banding) or not perfect (specifying a larger MDCV than necessary). should we drop it for everyone because some clients won't be able to use it? if there is a native wayland app which uses bt2020+pq for encoding but limits the color volume,
<swick[m]>
why shouldn't it be able to give compositors that information? should we pass through all the metadata even if it might be bogus? what choices on how to handle the metadata do we have? if one has to assume the metadata is bogus, the only policy one can have is to ignore the metadata.
<swick[m]>
so if you want bogus metadata in the compositor you can't at the same time argue that you want the compositor to be in control. if you don't want to ignore the metadata for proton and arbitrary videos, no one is stopping you, but how do you justify making native apps worse?
<pq>
i509vcb, I would hope that compositor toolkit libraries like wlroots et al. would help the people wanting to write a custom WM to not need to understand everything.
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<swick[m]>
JoshuaAshton_: and if you want to discuss this, you have to do your part as well and behave reasonable
<pq>
haasn, too bad monitors do not advertise what gamut they support. Not in any standard way, anyway.
<JEEB>
yea, that usually comes out of a monitor-side ICC profile
<JEEB>
which was accrued through some sort of testing
glennk has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
<pq>
haasn, DemiMarie, the protocol allows for two fundamentally different ways to achieve color management: client-driven and compositor-driven.
Fxzxmic has joined #wayland
leon-anavi has joined #wayland
<pq>
haasn, DemiMarie, and these two ways can actually co-exists simultaneously on different wl_surfaces.
<pq>
just not on the same surface, obviously
<MrCooper>
JoshuaAshton_: it makes little sense to build a Wayland protocol on the premise that the client-provided data may be bogus and the compositor may do whatever instead, since the result will inevitably be that clients *do* provide bogus data, and the compositors have to scramble to make it work acceptably for the user somehow; the end result is that the data passed over the protocol is mostly meaningless in practice. It's better to handle bogus
<MrCooper>
metadata on the client side, instead of passing it on over the protocol
<pq>
umm, is JoshuaAshton_ talking right now? The last I saw a message from him here was on Friday IIRC.
<pq>
I feel the discussion around "smart" compositors is forgetting the end user here. I'm sure end users want to tune their screen image, and it so happens that many HDR displays simply do not offer many or even any knobs.
<pq>
the compositor doesn't need to be smart, but I do think it needs to offer some knobs.
glennk has joined #wayland
<MrCooper>
yep, e.g. for the SDR white point
<pq>
Ever wondered why monitors and TVs have all these weird "movie mode" and "photo mode" and whatnot image settings? I think we're about to re-invent them, especially if we don't trust any "optional" metadata.
privacy_ has joined #wayland
privacy has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
privacy_ has quit []
<zamundaaa[m]>
swick native apps are the problem though... There is no reason whatsoever for why native Vulkan apps would be any better at using metadata than all the existing games and applications on Windows
<zamundaaa[m]>
So if Mesa has to do the filtering, it's almost guaranteed that we'll end up just not ever sending the primaries at all
<zamundaaa[m]>
Considering that, shouldn't we just completely leave it out of the protocol for now?
pochu has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
<MrCooper>
that's still preventing correct clients from making use of the protocol, because there are broken clients
Fxzxmic has joined #wayland
<MrCooper>
it's possible that Mesa can't make full use of the protocol as a first step, doesn't mean nothing else should be allowed to
<swick[m]>
the whole color management thing is breaking existing clients left and right
<swick[m]>
no matter what we do
<swick[m]>
this has been known from the start and there is nothing we can do about it
<swick[m]>
going from this free-for-all X11 model to a model where things are being enforced necessarily breaks things
<swick[m]>
that's what wayland has been doing for everything
<swick[m]>
so what's the point here. why should we not also enforce the metadata. we're going to break existing stuff anyway no matter what we do.
<swick[m]>
do it once, do it properly
cmichael has joined #wayland
<swick[m]>
also, when there is a new protocol by definition we don't break any user of the protocol
Moprius has joined #wayland
<zamundaaa[m]>
MrCooper Which client would that be though? We have Vulkan, browsers, video players, gamescope, and not a single one of them can trust their inputs... We'll just end up with the same situation that either no client uses the metadata, or that some still get it wrong and compositors end up ignoring it anyways
<swick[m]>
not a single one of them will necessarily be bug free
<swick[m]>
this argument is ridiculous
<MrCooper>
zamundaaa[m]: if they can't trust their input, they shouldn't use it for the protocol
<swick[m]>
trust their inputs...
<swick[m]>
ofc there are apps which can trust the mdcv
<swick[m]>
some apps even generate it themselves
<zamundaaa[m]>
MrCooper: that's my point though
<swick[m]>
what's the point?
<swick[m]>
that some apps deal with inputs that can't be trusted?
<MrCooper>
why prevent clients with valid metadata from using it though?
<swick[m]>
yes, some videos contain garbage
<swick[m]>
some are masted badly and have banding
<swick[m]>
some contain glitches
<swick[m]>
what's the point here?
<zamundaaa[m]>
I'm asking, which apps would be able to get correct metadata. Apps that use the protocol directly, mind you, because Mesa can't forward it
mblenc has joined #wayland
<swick[m]>
ofc mesa can forward it
<swick[m]>
ofc apps can get input they trust
<swick[m]>
ofc apps can generate the metadata themselves
<zamundaaa[m]>
Not if you want metadata to be filtered
<zamundaaa[m]>
Because native games
<swick[m]>
none of them use the colorspace crap because it's not exposed yet
<swick[m]>
if they start using it and they do it wrongly, they get wrong results
<zamundaaa[m]>
The assumption that games are thoroughly tested after being ported to another OS with game engine help is sadly not true though
<swick[m]>
I don't assume anything here
<swick[m]>
if you run an app on another OS the behavior might be different
<swick[m]>
I'm not going to make everything bug-comptabile with windows
<swick[m]>
that's the job of translation layers
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
<zamundaaa[m]>
Mesa is the "translation" layer here...
<swick[m]>
no it's not
<swick[m]>
either someone runs it through wine/proton or someone compiled it for linux with the wayland wsi and must expect different behavior
iomari891 has quit [Read error: No route to host]
<swick[m]>
there are things that vulkan guarantees between the different wsi's and how the MDCV is handled is not one of them
iomari891 has joined #wayland
<swick[m]>
so you want us to implement something the same way as windows because you want windows games to work
<swick[m]>
which were written for the windows wsi
<swick[m]>
or dx stuff
<zamundaaa[m]>
No, I want a request that's incredibly likely to be either not used at all, or worse, used wrongly, to be left out of v1 of the protocol
<swick[m]>
because windows
<swick[m]>
it's well defined and useful
<zamundaaa[m]>
No, because apps and content are what they are. You can't ignore the real world
<swick[m]>
you can stop saying that i'm ignoring the real world?
<swick[m]>
there are apps that are not windows games
<swick[m]>
getting payed by valve doesn't mean that suddenly the only thing that exists are windows games
<zamundaaa[m]>
Like video players? Or browsers? That get tons of wrong metadata
<zamundaaa[m]>
Can we at least agree that the description of the request should mention that clients are required to filter their inputs very carefully because a lot of content is wrong?
mblenc has quit [Ping timeout: 480 seconds]
<swick[m]>
bad content exists in various forms
<swick[m]>
there are also videos which indicate the wrong color space
<MrCooper>
zamundaaa[m]: you're demanding that Linux native clients must be prevented from making use of the metadata, because passing it through from Windows apps would give bad results; just don't pass it through from Windows apps then?
<swick[m]>
should we just scrap the entire color management protocl because of that?
<swick[m]>
it's ridiculous
<swick[m]>
like, the worst thing that can happen is that some videos have a bit of clipping
<swick[m]>
it's not like apps stop working and the world is falling apart
<swick[m]>
and we do say that compositors should use the metadata which gives clients enough warning that setting the metadata actually does something instead of nothing
<swick[m]>
disney want to use the protocol and they rely on clipping at the MDCV
<swick[m]>
they enforce this on displays as well
<swick[m]>
which also answers JoshuaAshton_ question about which monitors do that
<MrCooper>
zamundaaa[m]: do we need to explain the "garbage in, garbage out" principle in every single protocol request?
<zamundaaa[m]>
No, just in the ones where a very large amount of content out there is garbage
Moprius has quit [Quit: bye]
<swick[m]>
nothing forces anyone to set the metadata
<swick[m]>
proton doesn't have to push through the metadata
<swick[m]>
native games don't have to set the metadata in vulkan
<zamundaaa[m]>
Again, I am not talking about apps running in Proton
<swick[m]>
video players don't have to set the metadata
<swick[m]>
I don't exclusively talk about proton either
<swick[m]>
and even if they do it
<zamundaaa[m]>
swick[m]: Don't "have to" and "won't" are entirely different things
<swick[m]>
bugs exist
<swick[m]>
there are monitors with exactly the behavior that we recommend compositors to implement
<swick[m]>
and they are the "good" monitors
<swick[m]>
and even if the data is bogus, it's not a big deal
<MrCooper>
clients who choose to set the metadata get corresponding results; if they don't like them, they can stop setting the metadata
<swick[m]>
the worst case scenario is worse image quality
<swick[m]>
and you're also just repeating what JoshuaAshton_ already said with no new information whatsoever
<swick[m]>
so I'm getting a bit pissed tbh
<zamundaaa[m]>
There is no new information. Clients will provide bad metadata, that's just how it is.
<zamundaaa[m]>
I get that you're trying to make the best out of a bad situation, and I don't disagree that filtering metadata on the client side would be nice. I just don't think it's realistic that client developers will actually adhere to that, and more importantly, that they'll catch the subtle hint of "compositors should apply the metadata" as a warning about blindly passing metadata through.
<YaLTeR[m]>
i mean they will run their impl on a compositor and find out that it looks wrong
<zamundaaa[m]>
I guess we'll just have to wait and see how things actually turn out. I hope that you're right
<MrCooper>
some warning text in the protocol that just passing through metadata may lead to unexpected results might make sense
<haasn>
pq: if you have no information about the monitor gamut then you can’t do gamut mapping on the compositor any better than a client could
<haasn>
But it’s quite obvious wether a monitor supports, for example, bt.2020 signal or not, so provide that information to the client and make it their problem
<JEEB>
yup
<pq>
zamundaaa[m], Krita comes to mind as something that I'd expect to create correct metadata. Darktable too.
gallo has joined #wayland
<pq>
zamundaaa[m], the purpose of the "compositors should use this to improve gamut mapping" is my hint to apps to not set garbage there.
<zamundaaa[m]>
Good point. I would be surprised if those apps would leave mapping from their colorspace to the output up to the compositor though
flom84 has joined #wayland
<zamundaaa[m]>
pq: yes, but that's not a super obvious hint. Maybe I'm a bit pessimistic, but I have doubts that everyone's gonna analyze the details of the spec to figure these things out, especially when most of the clients using the protocol won't even be using it directly
<pq>
zamundaaa[m], yeah, they may well decide to do it themselves. Or, they may offer a preview of what end users not using those apps would see on the compositor at hand. IOW, simple image viewers should simply forward all the metadata they can.
<pq>
This should help image authors to avoid grave problems.
<pq>
Correctly tagged imagery is better for everyone.
<pq>
For the EGL and Vulkan case, after hearing all the arguments I suspect that Mesa is going to have to nerf the MDCV without an explicit "yes, really use it" option.
nerdopolis has joined #wayland
<swick[m]>
it's really an implementation detail of the wsi and I don't see why we shouldn't try to forward it always first
<pq>
yeah, depends on how it'll work out.
<swick[m]>
if windows apps are the biggest issue wine can just drop the info and then we can see how well it works for native stuff
<pq>
certainly need to try with it first
<JEEB>
the windows compositor just passes the info through as far as I can tell
<swick[m]>
yes, big mistake
<JEEB>
looking at my work with the relevant d3d11 APIs
<pq>
JEEB, are you sure it still does?
<swick[m]>
even the people working on the windows compositor say that HDR is utterly broken right now
<JEEB>
pq: I don't have any hardware sniffers to verify what goes over the cable to my 2016 samsung, but I'd expect the stuff you set on the d3d11 swap chain to be passed through if there are no other applications in view
<JEEB>
if other applications are in view, the result gets more complex
<JEEB>
but someone with sniffing access did test this stuff with mpv when I was hacking on this stuff at least.
<pq>
JEEB, I recall JoshuaAshton_ posting a link to some Windows doc that at least recommended apps to not use such API, and do the work themselves for the monitor at hand instead.
glennk has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
<pq>
btw. for monitors that use BT.2100 signalling and simply clip the signal, I've been wondering if we can have a manual profling app: "draw a line where you no longer see a change in color".
<drakulix[m]>
@pq, I mean the windows api to get the equivalent of our output image_description is literally "give me the EDID". So atleast games have no other option than to do everything themselves.
<JEEB>
which basically outlines the two alternatives
<drakulix[m]>
JEEB: hmm, I wonder why DXVK wants an EDID then. This data seems to be trivial to derive from the color-management protocol.
<drakulix[m]>
Thanks for the links!
<JEEB>
basically either floatie extended sRGB (which I use for wide gamut content in libplacebo), or BT.2020+PQ (which I use for HDR content in libplacebo)
<JEEB>
latter being pass-through with the windows compositor
<JEEB>
if your output is configured with that, of course
<JEEB>
floatie might be pass-through as well, but the transfer function etc will be applied by compositor
<pq>
I don't think those are choices I had in mind.
fmuellner has joined #wayland
<JEEB>
and mapping of SDR to HDR graphics white with the floatie sRGB of course
<JEEB>
1.0 to 203 nits
<JEEB>
(plus adjustment possibility in the windows display settings)
<pq>
When you use a standardised signal like BT.2100 PQ, you still have two options: you set up metadata and render for the reference display, or you skip the metadata and render for the actual display.
maxzor has joined #wayland
<zamundaaa[m]>
drakulix: afaik many apps completely ignore the dxgi API and do parse the edid manually. So DXVK uses the EDID just because it already needs to be there
<drakulix[m]>
😩
<pq>
Wayland compositors will be parsing EDID with libdisplay-info too, but they can also have more information about the display that an end user might want to provide or tune. It's not obvious such information can be relayed as EDID, but in Wayland we can.
<JEEB>
pq: something like mpv without further display information would be doing the first (convert to BT.2020+PQ RGB, pass metadata on), and the examples in that MS article then go for the second one since they expect you to have your own rendering app and they have an example to calculate the MaxCLL for metadata to pass on
kts has joined #wayland
<pq>
right
<drakulix[m]>
swick: while I agree that linux-native tools should be able to provide proper metadata, I feel like many cross-platform tools won't get the required amount of testing and might be tempted by the compatible interface to just pass the same (bogus) metadata they do on other platforms.
<pq>
I think the only hints about HDR color gamut in EDID are some vendor extensions.
<drakulix[m]>
While that means those apps are broken, I can see how we could quickly arise at a situation where no compositor trusts metadata, because 80% of clients use it wrong. Making it useless again.
<JEEB>
I've thought of using that D3D11 API to get info and adjust the image accordingly (do some tone mapping already on application side), but the last time I tried that I just got way too much dimmer image :P
<drakulix[m]>
So can we at least put a big warning on that method or try something to try and keep clients from doing this.
<pq>
drakulix[m], we should really have that warning on all the methods of the parametric image description creator.
<drakulix[m]>
Really? Do so many apps get color primaries wrong?
maxzor has quit [Ping timeout: 480 seconds]
<pq>
I dunno, but it's equally important.
<drakulix[m]>
Even if this is meant ironically, I feel the argument that they could provide bogus values everywhere isn't a good one, if it is much more likely from one type of data than for the rest.
<pq>
and primaries were very unimportant in the SDR non-WCG days.
<pq>
no irony, no sarcasm
<pq>
color management is too painful even without them
<drakulix[m]>
My thoughts are mostly with cross-platform apps, that do already use HDR-apis on other platforms. If this is compatible with the same data, I don't see many clients bothering providing different metadata.
<drakulix[m]>
But no metadata might still be on the table, which might be the better option in a lot of cases.
<pq>
drakulix[m], you can certainly propose a wording, but your audience would be people who actually read the spec. I think they would be puzzled why this piece is so much more important that the others.
<pq>
other-platform app developers will never even see our spec, I bet
<pq>
yes, not setting MDCV is always an option.
<drakulix[m]>
Right and I don't expect that this will reach a lot devs either. But I can't help but feel like we should at least try.
carlos_ has joined #wayland
<pq>
sure, so propose a wording
<pq>
maybe not so much as "don't put garbage here" but "beware that existing applications on other platforms have a high possibility of telling this wrong".
<drakulix[m]>
I don't think it would be a good attempt given my humble knowledge on the subject, but sure I'll try to make a PR. 👍️
<pq>
I'm satisfied with the current wording, and you're not, so.
<pq>
drakulix[m], the point is to propose something, and then the others can chime in. It didn't sound likely any of them would file a MR.
flom84 has quit [Ping timeout: 480 seconds]
<pq>
Re: why is the window moving under a pointer not the same as pointer motion; it just happened on Firefox with some web form on a page that likes to dynamically re-layout itself, and simply clicking a point selected a large amount of text unintended. Yes, it's not the window moving, but cleaarly toolkits should have the same concept too.
<pq>
...if we ignore the elephant in the room that is poor web page UI design
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
qaqland has quit [Quit: Ping timeout (120 seconds)]
qaqland has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
crazybyte has joined #wayland
Company has quit [Quit: Leaving]
<kchibisov>
Does anyone know what is the x11 alternative for wl_subsurface and embeding media players type of things?
<i509vcb>
XEmbed?
carlos_ is now known as garnacho
<kchibisov>
I think it's a bit different, no?
<MrCooper>
kchibisov: any X window can be the child of any other one, even from another client
<kchibisov>
can you manipulate Z order?
<MrCooper>
sure
<kchibisov>
Like if I want my window be split into 4 tiles like I can easily with wl_subsurfaces, you just create child windows?
<d_ed[m]>
Yeah. It used to be the case that every single button or label was it's own "window"
<kchibisov>
thx.
<MrCooper>
yes, though note that in contrast to Wayland, X has no mechanism for making atomic updates to all child windows
<MrCooper>
s/all/multiple/
<kchibisov>
The end goal is to whether I can have "bad subsurfaces".
pochu has quit [Quit: leaving]
<kchibisov>
Can I place wl_subsurface below the top-level surface, so underneach the window?
glennk has joined #wayland
<kchibisov>
Because the wording on place_below is "see above" and see above says that changing subsurface tree, etc, but it's a bit unclear whether the client can put something below main surface and expect it to work.
<vyivel>
yes, it's allowed
<vyivel>
you can play with wleird-subsurfaces to check
<kchibisov>
vyivel: I'm mostly researching, since some systems don't allow placing subsurface below main view.
<vyivel>
which ones?
<kchibisov>
macOS disallow it.
<vyivel>
i see
<kchibisov>
I wonder whether you can put X11 child window, below, but I think you can...
<kchibisov>
It's not like it's impossible to do on macOS a thing like that though at all, it's just requires tricks.
<kchibisov>
Like you need to swap main view and subview.
<MrCooper>
AFAICT X child windows are always above their parents; Z order can only be changed between siblings, i.e. children of the same parent
<kchibisov>
I think it's the same for everything other than wayland here.
cmichael has quit [Quit: Leaving]
leon-anavi has quit [Remote host closed the connection]
<JoshuaAshton>
drakulix[m]: The reason DXVK wants the EDID is because DXVK is PE and thus needs to work on Windows. To use a Wayland protocol, Gamescope or Proton is going to have to manufacture an EDID to give to apps.
vsyrjala_ has joined #wayland
trclst_ has joined #wayland
<JoshuaAshton>
On Windows, some games also don't use DXGI and do just read the EDID directly
columbarius has joined #wayland
rv1sr has quit [reticulum.oftc.net helix.oftc.net]
crazybyte has quit [reticulum.oftc.net helix.oftc.net]
babyfaceold has quit [reticulum.oftc.net helix.oftc.net]
co1umbarius has quit [reticulum.oftc.net helix.oftc.net]
gallo has quit [reticulum.oftc.net helix.oftc.net]
caveman has quit [reticulum.oftc.net helix.oftc.net]
yrlf has quit [reticulum.oftc.net helix.oftc.net]
mceier has quit [reticulum.oftc.net helix.oftc.net]
fossdd has quit [reticulum.oftc.net helix.oftc.net]
pobthebuilder[m] has quit [reticulum.oftc.net helix.oftc.net]
glennk has quit [reticulum.oftc.net helix.oftc.net]
emilio[m] has quit [reticulum.oftc.net helix.oftc.net]
hch12907 has quit [reticulum.oftc.net helix.oftc.net]
q234rty[m][m] has quit [reticulum.oftc.net helix.oftc.net]
Coelacanthus[m]1 has quit [reticulum.oftc.net helix.oftc.net]
SeunghunLee[m] has quit [reticulum.oftc.net helix.oftc.net]
elinor has quit [reticulum.oftc.net helix.oftc.net]
ttancos[m] has quit [reticulum.oftc.net helix.oftc.net]
zhxt[m] has quit [reticulum.oftc.net helix.oftc.net]
rajveermalviya[m] has quit [reticulum.oftc.net helix.oftc.net]
drakulix[m] has quit [reticulum.oftc.net helix.oftc.net]
enick_819 has quit [reticulum.oftc.net helix.oftc.net]
Max1 has quit [reticulum.oftc.net helix.oftc.net]
rubo_[m] has quit [reticulum.oftc.net helix.oftc.net]
karmavil[m] has quit [reticulum.oftc.net helix.oftc.net]
zaibon[m] has quit [reticulum.oftc.net helix.oftc.net]
NepNepdmsalwaysopen[m] has quit [reticulum.oftc.net helix.oftc.net]
floki[m] has quit [reticulum.oftc.net helix.oftc.net]
andyrtr has quit [reticulum.oftc.net helix.oftc.net]
zzxyb[m] has quit [reticulum.oftc.net helix.oftc.net]
RomanGilg[m] has quit [reticulum.oftc.net helix.oftc.net]
ErikReider[m] has quit [reticulum.oftc.net helix.oftc.net]
mboudr35[m] has quit [reticulum.oftc.net helix.oftc.net]
[old]freshgumbubbles[m] has quit [reticulum.oftc.net helix.oftc.net]
floof58 has quit [reticulum.oftc.net helix.oftc.net]
trclst has quit [reticulum.oftc.net helix.oftc.net]
TheCaptain8297 has quit [reticulum.oftc.net helix.oftc.net]
alarumbe has quit [reticulum.oftc.net helix.oftc.net]
FbioPacheco[m] has quit [reticulum.oftc.net helix.oftc.net]
gallo_ has joined #wayland
andyrtr has joined #wayland
pounce has quit [reticulum.oftc.net helix.oftc.net]
JoshuaAshton_ has quit [reticulum.oftc.net helix.oftc.net]
m5zs7k has quit [reticulum.oftc.net helix.oftc.net]
mort_ has quit [reticulum.oftc.net helix.oftc.net]
gnoirzox1 has quit [reticulum.oftc.net helix.oftc.net]
rappet has quit [reticulum.oftc.net helix.oftc.net]
fgdfgdfgdfgd has quit [reticulum.oftc.net helix.oftc.net]
shoragan has quit [reticulum.oftc.net helix.oftc.net]
peeterm has quit [reticulum.oftc.net helix.oftc.net]
blathijs has quit [reticulum.oftc.net helix.oftc.net]
noord has quit [reticulum.oftc.net helix.oftc.net]
SardemFF7 has quit [reticulum.oftc.net helix.oftc.net]
marex has quit [reticulum.oftc.net helix.oftc.net]
Prf_Jakob has quit [reticulum.oftc.net helix.oftc.net]
vsyrjala has quit [reticulum.oftc.net helix.oftc.net]
peeterm_ is now known as peeterm
crazybyte5 is now known as crazybyte
caveman has joined #wayland
pounce_ is now known as pounce
mceier has joined #wayland
marex has joined #wayland
rv1sr has joined #wayland
glennk has joined #wayland
yrlf has joined #wayland
ttancos[m] has joined #wayland
pobthebuilder[m] has joined #wayland
zaibon[m] has joined #wayland
NepNepdmsalwaysopen[m] has joined #wayland
floki[m] has joined #wayland
FbioPacheco[m] has joined #wayland
RomanGilg[m] has joined #wayland
zzxyb[m] has joined #wayland
ErikReider[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
floof58 has joined #wayland
rappet has joined #wayland
TheCaptain8297 has joined #wayland
mort_ has joined #wayland
vsyrjala has joined #wayland
blathijs has joined #wayland
SardemFF7 has joined #wayland
Max1 has joined #wayland
Prf_Jakob has joined #wayland
SeunghunLee[m] has joined #wayland
Coelacanthus[m]1 has joined #wayland
q234rty[m][m] has joined #wayland
emilio[m] has joined #wayland
hch12907 has joined #wayland
elinor has joined #wayland
rubo_[m] has joined #wayland
drakulix[m] has joined #wayland
enick_819 has joined #wayland
rajveermalviya[m] has joined #wayland
karmavil[m] has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
vsyrjala has quit [Ping timeout: 480 seconds]
NepNepdmsalwaysopen[m] has quit [Ping timeout: 480 seconds]
ErikReider[m] has quit [Ping timeout: 480 seconds]
fgdfgdfgd has joined #wayland
fabiancodes has quit [Remote host closed the connection]
kindablue has quit [Remote host closed the connection]
cpli has quit [Remote host closed the connection]
tsujp has quit [Remote host closed the connection]
novakane has quit [Remote host closed the connection]
txtsd has quit [Remote host closed the connection]
leon-p has quit [Remote host closed the connection]
ogromny has quit [Remote host closed the connection]
c7s has quit [Write error: connection closed]
WhyNotHugo has quit [Write error: connection closed]
staceee has quit [Write error: connection closed]
sumoon has quit [Write error: connection closed]
pitust has quit [Write error: connection closed]
Guest1248 has quit [Write error: connection closed]
kchibisov has quit [Write error: connection closed]
dnkl has quit [Write error: connection closed]
rosefromthedead has quit [Write error: connection closed]
mainiomano has joined #wayland
cat has quit [Write error: connection closed]
ifreund has joined #wayland
abcdw has joined #wayland
rosefromthedead has joined #wayland
moses has joined #wayland
tsujp has joined #wayland
txtsd has joined #wayland
kennylevinsen has joined #wayland
geemili has joined #wayland
sumoon has joined #wayland
tommybomb has joined #wayland
kindablue has joined #wayland
cat has joined #wayland
WhyNotHugo has joined #wayland
dorkbutt has quit [Write error: connection closed]
elibrokeit has quit [Write error: connection closed]
rpigott has quit [Write error: connection closed]
kennylevinsen has quit [Write error: connection closed]
ifreund has quit [Write error: connection closed]
staceee has joined #wayland
elibrokeit has joined #wayland
fabiancodes has joined #wayland
leon-p has joined #wayland
c7s has joined #wayland
abcdw has quit [Write error: connection closed]
pitust has joined #wayland
cpli has joined #wayland
ogromny has joined #wayland
rpigott has joined #wayland
moses has quit [Write error: connection closed]
tommybomb has quit [Write error: connection closed]
mainiomano has quit [Write error: connection closed]
geemili has quit [Write error: connection closed]
dorkbutt has joined #wayland
kchibisov has joined #wayland
novakane has joined #wayland
dnkl has joined #wayland
raghavgururajan has joined #wayland
mblenc has quit [Ping timeout: 481 seconds]
yrlf has quit [Ping timeout: 534 seconds]
pobthebuilder[m] has quit [Ping timeout: 549 seconds]
elinor has quit [Ping timeout: 529 seconds]
Coelacanthus[m]1 has quit [Ping timeout: 549 seconds]
ttancos[m] has quit [Ping timeout: 519 seconds]
rajveermalviya[m] has quit [Ping timeout: 554 seconds]
drakulix[m] has quit [Ping timeout: 524 seconds]
enick_819 has quit [Ping timeout: 524 seconds]
karmavil[m] has quit [Ping timeout: 529 seconds]
zaibon[m] has quit [Ping timeout: 554 seconds]
floki[m] has quit [Ping timeout: 549 seconds]
zzxyb[m] has quit [Ping timeout: 534 seconds]
FbioPacheco[m] has quit [Ping timeout: 549 seconds]
[old]freshgumbubbles[m] has quit [Ping timeout: 554 seconds]
TheCaptain8297 has quit [Ping timeout: 529 seconds]
rappet has quit [Ping timeout: 544 seconds]
mort_ has quit [Ping timeout: 519 seconds]
raghavgururajan is now known as Guest6048
JosExpsito[m]1 has quit [Ping timeout: 480 seconds]
ujineli[m] has quit [Ping timeout: 480 seconds]
danburd[m] has quit [Ping timeout: 480 seconds]
doras has quit [Ping timeout: 480 seconds]
teaper[m] has quit [Ping timeout: 480 seconds]
unix-supremacist[m] has quit [Ping timeout: 480 seconds]
windowsxp[m] has quit [Ping timeout: 480 seconds]
orowith2os[m] has quit [Ping timeout: 480 seconds]
yshui` has quit [Ping timeout: 480 seconds]
Nico has quit [Ping timeout: 480 seconds]
vchernin[m] has quit [Ping timeout: 480 seconds]
Shimmy[m] has quit [Ping timeout: 480 seconds]
furyishere[m] has quit [Ping timeout: 480 seconds]
j-james[m] has quit [Ping timeout: 480 seconds]
heftig has quit [Ping timeout: 480 seconds]
modelockedcat has quit [Ping timeout: 480 seconds]
joantorres[m] has quit [Ping timeout: 480 seconds]
niecoinny[m] has quit [Ping timeout: 480 seconds]
Sumera[m] has quit [Ping timeout: 480 seconds]
dmitz has quit [Ping timeout: 480 seconds]
teh1[m] has quit [Ping timeout: 480 seconds]
Mershl[m] has quit [Ping timeout: 480 seconds]
cmeissl[m] has quit [Ping timeout: 480 seconds]
basemale has quit [Ping timeout: 480 seconds]
zebrag[m] has quit [Ping timeout: 480 seconds]
nazarewk[m] has quit [Ping timeout: 480 seconds]
YHNdnzj[moz] has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 480 seconds]
mrkzboo[m] has quit [Ping timeout: 480 seconds]
AndrewAylett[m] has quit [Ping timeout: 480 seconds]
d_ed[m] has quit [Ping timeout: 480 seconds]
apol[m] has quit [Ping timeout: 480 seconds]
PavelNasevich[m] has quit [Ping timeout: 480 seconds]
YaLTeR[m] has quit [Ping timeout: 480 seconds]
kenrendell[m] has quit [Ping timeout: 480 seconds]
luks2[m] has quit [Ping timeout: 480 seconds]
akallabeth[m] has quit [Ping timeout: 480 seconds]
dani-g5x[m] has quit [Ping timeout: 480 seconds]
bdaase[m] has quit [Ping timeout: 480 seconds]
Saijin_Naib[m] has quit [Ping timeout: 480 seconds]
q234rty[m][m] has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
Guest5912 has quit [Remote host closed the connection]
<JoshuaAshton>
> <swick[m]> the whole color management thing is breaking existing clients left and right
<JoshuaAshton>
What? On Deck/SteamOS we are breaking nobody with our protocol implementation...
<JoshuaAshton>
*our protocol and implementation
marex_ has joined #wayland
removeert has left #wayland [Leaving]
unix-supremacist[m] has quit [reticulum.oftc.net helix.oftc.net]
bindu has quit [reticulum.oftc.net helix.oftc.net]
rubo_[m] has quit [reticulum.oftc.net helix.oftc.net]
RomanGilg[m] has quit [reticulum.oftc.net helix.oftc.net]
SeunghunLee[m] has quit [reticulum.oftc.net helix.oftc.net]
hch12907 has quit [reticulum.oftc.net helix.oftc.net]
Prf_Jakob has quit [reticulum.oftc.net helix.oftc.net]
emilio[m] has quit [reticulum.oftc.net helix.oftc.net]
Max1 has quit [reticulum.oftc.net helix.oftc.net]
mceier has quit [reticulum.oftc.net helix.oftc.net]
SardemFF7 has quit [reticulum.oftc.net helix.oftc.net]
floof58 has quit [reticulum.oftc.net helix.oftc.net]
glennk has quit [reticulum.oftc.net helix.oftc.net]
blathijs has quit [reticulum.oftc.net helix.oftc.net]
marex has quit [reticulum.oftc.net helix.oftc.net]
bindu has joined #wayland
mceier has joined #wayland
glennk has joined #wayland
SeunghunLee[m] has joined #wayland
emilio[m] has joined #wayland
Max1 has joined #wayland
floof58 has joined #wayland
blathijs has joined #wayland
Prf_Jakob has joined #wayland
rubo_[m] has joined #wayland
unix-supremacist[m] has joined #wayland
SardemFF7 has joined #wayland
<JoshuaAshton>
Breaking existing clients and content seems like your perogative here... I don't think other compositor vendors are in the same boat with you there either. We certainly are not.
floof58 has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<swick[m]>
ah yes, continuing to escalate
<swick[m]>
if you can't have a normal conversation that's it
<swick[m]>
I always give you the benefit of the doubt even though your behavior is the same every time
<swick[m]>
but I'm done
<JoshuaAshton>
ok?
<swick[m]>
I'll just ignore literally everything you say
mblenc has joined #wayland
elinor has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
rasterman has quit []
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
rubo_[m] has quit [reticulum.oftc.net helix.oftc.net]
SeunghunLee[m] has quit [reticulum.oftc.net helix.oftc.net]
unix-supremacist[m] has quit [reticulum.oftc.net helix.oftc.net]
Prf_Jakob has quit [reticulum.oftc.net helix.oftc.net]
emilio[m] has quit [reticulum.oftc.net helix.oftc.net]
Max1 has quit [reticulum.oftc.net helix.oftc.net]
SardemFF7 has quit [reticulum.oftc.net helix.oftc.net]
glennk has quit [reticulum.oftc.net helix.oftc.net]
blathijs has quit [reticulum.oftc.net helix.oftc.net]