01:59 Dostoevsky: Hey, can anyone see me?
02:00 Dostoevsky: I have a question about cursors...
02:02 bluetail: you are supposed to ask, and wait until somebody replies
02:03 bluetail: please do not ask to ask, cause thats not how it works
02:05 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...
02:06 danieldg: that can be done by the compositor (sway has an option for it, for one)
02:07 danieldg: an application can also do it by just making a transparent cursor
02:07 Dostoevsky: So it's more of an implementation thing, and not a protocol thing?
02:07 Dostoevsky: Ooh, transparent would work too...
02:08 danieldg: if you do that, keep in mind that it's a usability problem for someone to ask "where's the cursor?"
02:08 Dostoevsky: Ideally it would reappear on mouse movement. LOL
02:09 danieldg: that's also easy to do (just commit the normal cursor buffer again)
02:10 Dostoevsky: So for a KDE user, I'd either need a compositor plugin/KWin script or a change in KWin itself?
02:11 Dostoevsky: I'm trying to narrow down where I need to look for someone else willing to work on this...
02:11 danieldg: if you want it for all windows, do it in kwin (maybe as a script, dunno how it works internally)
02:12 danieldg: and yeah, this kind of global thing belongs in the compositor not the application imo
02:13 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...
02:15 danieldg: sway has 'hide_cursor when-typing', maybe consider that?
02:15 danieldg: vs a timeout that will often be short/long
02:16 Dostoevsky: Well, sway is GNOME, right? I mean, if it works with KDE, cool, I'll try it...
02:17 danieldg: no, sway is not gnome
02:17 danieldg: it's i3 for wayland
02:17 danieldg: tiling, based on wlroots
02:17 Dostoevsky: Oh, oops. I've never used a TWM
02:18 Dostoevsky: Looks neat, though...
02:18 danieldg: tiling takes a bit to get used to
02:21 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...
02:21 Dostoevsky: Probably not, but I can always hope. :-)
02:22 Dostoevsky: Have a good night!
08:45 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,
08:45 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.
08:47 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?
08:48 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.
08:50 swick[m]: JoshuaAshton_: and if you want to discuss this, you have to do your part as well and behave reasonable
08:57 pq: haasn, too bad monitors do not advertise what gamut they support. Not in any standard way, anyway.
08:58 JEEB: yea, that usually comes out of a monitor-side ICC profile
08:58 JEEB: which was accrued through some sort of testing
09:02 pq: haasn, DemiMarie, the protocol allows for two fundamentally different ways to achieve color management: client-driven and compositor-driven.
09:08 pq: haasn, DemiMarie, and these two ways can actually co-exists simultaneously on different wl_surfaces.
09:08 pq: just not on the same surface, obviously
09:08 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
09:08 MrCooper: metadata on the client side, instead of passing it on over the protocol
09:10 pq: umm, is JoshuaAshton_ talking right now? The last I saw a message from him here was on Friday IIRC.
09:11 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.
09:12 pq: the compositor doesn't need to be smart, but I do think it needs to offer some knobs.
09:14 MrCooper: yep, e.g. for the SDR white point
09:15 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.
09:59 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
10:00 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
10:00 zamundaaa[m]: Considering that, shouldn't we just completely leave it out of the protocol for now?
10:05 MrCooper: that's still preventing correct clients from making use of the protocol, because there are broken clients
10:06 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
10:10 swick[m]: the whole color management thing is breaking existing clients left and right
10:10 swick[m]: no matter what we do
10:10 swick[m]: this has been known from the start and there is nothing we can do about it
10:11 swick[m]: going from this free-for-all X11 model to a model where things are being enforced necessarily breaks things
10:11 swick[m]: that's what wayland has been doing for everything
10:12 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.
10:12 swick[m]: do it once, do it properly
10:14 swick[m]: also, when there is a new protocol by definition we don't break any user of the protocol
10:15 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
10:16 swick[m]: not a single one of them will necessarily be bug free
10:16 swick[m]: this argument is ridiculous
10:16 MrCooper: zamundaaa[m]: if they can't trust their input, they shouldn't use it for the protocol
10:17 swick[m]: trust their inputs...
10:17 swick[m]: ofc there are apps which can trust the mdcv
10:17 swick[m]: some apps even generate it themselves
10:17 zamundaaa[m]: MrCooper: that's my point though
10:17 swick[m]: what's the point?
10:17 swick[m]: that some apps deal with inputs that can't be trusted?
10:18 MrCooper: why prevent clients with valid metadata from using it though?
10:18 swick[m]: yes, some videos contain garbage
10:18 swick[m]: some are masted badly and have banding
10:18 swick[m]: some contain glitches
10:18 swick[m]: what's the point here?
10:18 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
10:18 swick[m]: ofc mesa can forward it
10:19 swick[m]: ofc apps can get input they trust
10:19 swick[m]: ofc apps can generate the metadata themselves
10:19 zamundaaa[m]: Not if you want metadata to be filtered
10:19 zamundaaa[m]: Because native games
10:19 swick[m]: none of them use the colorspace crap because it's not exposed yet
10:20 swick[m]: if they start using it and they do it wrongly, they get wrong results
10:22 zamundaaa[m]: The assumption that games are thoroughly tested after being ported to another OS with game engine help is sadly not true though
10:22 swick[m]: I don't assume anything here
10:22 swick[m]: if you run an app on another OS the behavior might be different
10:22 swick[m]: I'm not going to make everything bug-comptabile with windows
10:22 swick[m]: that's the job of translation layers
10:24 zamundaaa[m]: Mesa is the "translation" layer here...
10:24 swick[m]: no it's not
10:25 swick[m]: either someone runs it through wine/proton or someone compiled it for linux with the wayland wsi and must expect different behavior
10:26 swick[m]: there are things that vulkan guarantees between the different wsi's and how the MDCV is handled is not one of them
10:27 swick[m]: so you want us to implement something the same way as windows because you want windows games to work
10:27 swick[m]: which were written for the windows wsi
10:27 swick[m]: or dx stuff
10:28 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
10:28 swick[m]: because windows
10:29 swick[m]: it's well defined and useful
10:29 zamundaaa[m]: No, because apps and content are what they are. You can't ignore the real world
10:29 swick[m]: you can stop saying that i'm ignoring the real world?
10:30 swick[m]: there are apps that are not windows games
10:30 swick[m]: getting payed by valve doesn't mean that suddenly the only thing that exists are windows games
10:30 zamundaaa[m]: Like video players? Or browsers? That get tons of wrong metadata
10:30 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?
10:31 swick[m]: bad content exists in various forms
10:31 swick[m]: there are also videos which indicate the wrong color space
10:31 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?
10:31 swick[m]: should we just scrap the entire color management protocl because of that?
10:31 swick[m]: it's ridiculous
10:32 swick[m]: like, the worst thing that can happen is that some videos have a bit of clipping
10:32 swick[m]: it's not like apps stop working and the world is falling apart
10:33 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
10:33 swick[m]: disney want to use the protocol and they rely on clipping at the MDCV
10:34 swick[m]: they enforce this on displays as well
10:34 swick[m]: which also answers JoshuaAshton_ question about which monitors do that
10:37 MrCooper: zamundaaa[m]: do we need to explain the "garbage in, garbage out" principle in every single protocol request?
10:37 zamundaaa[m]: No, just in the ones where a very large amount of content out there is garbage
10:38 swick[m]: nothing forces anyone to set the metadata
10:38 swick[m]: proton doesn't have to push through the metadata
10:38 swick[m]: native games don't have to set the metadata in vulkan
10:38 zamundaaa[m]: Again, I am not talking about apps running in Proton
10:38 swick[m]: video players don't have to set the metadata
10:39 swick[m]: I don't exclusively talk about proton either
10:39 swick[m]: and even if they do it
10:39 zamundaaa[m]: swick[m]: Don't "have to" and "won't" are entirely different things
10:39 swick[m]: bugs exist
10:40 swick[m]: there are monitors with exactly the behavior that we recommend compositors to implement
10:40 swick[m]: and they are the "good" monitors
10:40 swick[m]: and even if the data is bogus, it's not a big deal
10:41 MrCooper: clients who choose to set the metadata get corresponding results; if they don't like them, they can stop setting the metadata
10:41 swick[m]: the worst case scenario is worse image quality
10:42 swick[m]: and you're also just repeating what JoshuaAshton_ already said with no new information whatsoever
10:42 swick[m]: so I'm getting a bit pissed tbh
10:53 zamundaaa[m]: There is no new information. Clients will provide bad metadata, that's just how it is.
10:53 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.
10:54 YaLTeR[m]: i mean they will run their impl on a compositor and find out that it looks wrong
10:54 zamundaaa[m]: I guess we'll just have to wait and see how things actually turn out. I hope that you're right
10:58 MrCooper: some warning text in the protocol that just passing through metadata may lead to unexpected results might make sense
11:24 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
11:25 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
11:26 JEEB: yup
11:30 pq: zamundaaa[m], Krita comes to mind as something that I'd expect to create correct metadata. Darktable too.
11:32 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.
11:32 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
11:34 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
11:39 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.
11:40 pq: This should help image authors to avoid grave problems.
11:40 pq: Correctly tagged imagery is better for everyone.
11:41 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.
11:43 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
11:44 pq: yeah, depends on how it'll work out.
11:44 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
11:44 pq: certainly need to try with it first
11:45 JEEB: the windows compositor just passes the info through as far as I can tell
11:45 swick[m]: yes, big mistake
11:45 JEEB: looking at my work with the relevant d3d11 APIs
11:45 pq: JEEB, are you sure it still does?
11:45 swick[m]: even the people working on the windows compositor say that HDR is utterly broken right now
11:46 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
11:46 JEEB: if other applications are in view, the result gets more complex
11:47 JEEB: but someone with sniffing access did test this stuff with mpv when I was hacking on this stuff at least.
11:47 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.
11:49 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".
11:51 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.
11:52 pq: drakulix[m], yes they did: set HDR metadata
11:52 pq: and pray the monitor uses it
11:52 pq: we know the result :-/
11:52 JEEB: this is what the d3d11 API is for getting the monitor info https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_6/ns-dxgi1_6-dxgi_output_desc1
11:52 JEEB: which probably internally parses the EDID
11:52 drakulix[m]: @pq Right, but that kinda expects, that windows will pass the metadata through. Otherwise the whole EDID is pointless.
11:53 pq: drakulix[m], I think you're confusing things.
11:53 JEEB: the MS HDR rendering article is https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range
11:53 JEEB: which basically outlines the two alternatives
11:53 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.
11:53 drakulix[m]: Thanks for the links!
11:54 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)
11:54 JEEB: latter being pass-through with the windows compositor
11:55 JEEB: if your output is configured with that, of course
11:55 JEEB: floatie might be pass-through as well, but the transfer function etc will be applied by compositor
11:55 pq: I don't think those are choices I had in mind.
11:56 JEEB: and mapping of SDR to HDR graphics white with the floatie sRGB of course
11:56 JEEB: 1.0 to 203 nits
11:56 JEEB: (plus adjustment possibility in the windows display settings)
11:57 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.
11:58 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
11:58 drakulix[m]: 😩
11:59 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.
12:00 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
12:01 pq: right
12:01 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.
12:01 pq: I think the only hints about HDR color gamut in EDID are some vendor extensions.
12:02 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.
12:02 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
12:02 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.
12:05 pq: drakulix[m], we should really have that warning on all the methods of the parametric image description creator.
12:05 drakulix[m]: Really? Do so many apps get color primaries wrong?
12:06 pq: I dunno, but it's equally important.
12:06 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.
12:06 pq: and primaries were very unimportant in the SDR non-WCG days.
12:07 pq: no irony, no sarcasm
12:07 pq: color management is too painful even without them
12:08 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.
12:08 drakulix[m]: But no metadata might still be on the table, which might be the better option in a lot of cases.
12:09 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.
12:09 pq: other-platform app developers will never even see our spec, I bet
12:10 pq: yes, not setting MDCV is always an option.
12:10 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.
12:11 pq: sure, so propose a wording
12:11 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".
12:12 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. 👍️
12:13 pq: I'm satisfied with the current wording, and you're not, so.
12:20 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.
12:27 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.
12:27 pq: ...if we ignore the elephant in the room that is poor web page UI design
14:16 pq: thank you swick[m] and leandrohrb5 !
14:18 pq: a new compositor doc has landed: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md
16:20 kchibisov: Does anyone know what is the x11 alternative for wl_subsurface and embeding media players type of things?
16:21 i509vcb: XEmbed?
16:24 kchibisov: I think it's a bit different, no?
16:26 MrCooper: kchibisov: any X window can be the child of any other one, even from another client
16:26 kchibisov: can you manipulate Z order?
16:26 MrCooper: sure
16:26 kchibisov: Like if I want my window be split into 4 tiles like I can easily with wl_subsurfaces, you just create child windows?
16:28 d_ed[m]: Yeah. It used to be the case that every single button or label was it's own "window"
16:28 kchibisov: thx.
16:29 MrCooper: yes, though note that in contrast to Wayland, X has no mechanism for making atomic updates to all child windows
16:29 MrCooper: s/all/multiple/
16:29 kchibisov: The end goal is to whether I can have "bad subsurfaces".
16:32 kchibisov: Can I place wl_subsurface below the top-level surface, so underneach the window?
16:34 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.
16:37 vyivel: yes, it's allowed
16:37 vyivel: you can play with wleird-subsurfaces to check
16:39 kchibisov: vyivel: I'm mostly researching, since some systems don't allow placing subsurface below main view.
16:39 vyivel: which ones?
16:39 kchibisov: macOS disallow it.
16:39 vyivel: i see
16:40 kchibisov: I wonder whether you can put X11 child window, below, but I think you can...
16:40 kchibisov: It's not like it's impossible to do on macOS a thing like that though at all, it's just requires tricks.
16:41 kchibisov: Like you need to swap main view and subview.
16:48 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
16:49 kchibisov: I think it's the same for everything other than wayland here.
17:16 wlb: weston Merge request !1383 opened by Marius Vlad (mvlad) build: bump to version 12.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1383
17:22 wlb: weston/main: Marius Vlad * build: bump to version 12.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/commit/f2f7560fac57 meson.build
17:22 wlb: weston Merge request !1383 merged \o/ (build: bump to version 12.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1383)
17:24 wlb: weston New tag: 12.0.93 https://gitlab.freedesktop.org/wayland/weston/tags/12.0.93
18:26 wlb: weston Merge request !1384 opened by Derek Foreman (derekf) Fix cursors with overlapping outputs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1384 [Core compositor], [DRM/KMS backend], [libweston API], [VNC Backend]
19:16 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.
19:17 JoshuaAshton: On Windows, some games also don't use DXGI and do just read the EDID directly
20:12 wlb: wayland.freedesktop.org Merge request !69 opened by Marius Vlad (mvlad) releases: add weston 12.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/69
20:12 wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 12.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/8f84160028e9 releases/weston-12.0.93.tar.xz releases/weston-12.0.93.tar.xz.sig releases.html
20:12 wlb: wayland.freedesktop.org Merge request !69 merged \o/ (releases: add weston 12.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/69)
21:10 JoshuaAshton: > <swick[m]> the whole color management thing is breaking existing clients left and right
21:10 JoshuaAshton: What? On Deck/SteamOS we are breaking nobody with our protocol implementation...
21:10 JoshuaAshton: *our protocol and implementation
21:16 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.
21:29 swick[m]: ah yes, continuing to escalate
21:32 swick[m]: if you can't have a normal conversation that's it
21:32 swick[m]: I always give you the benefit of the doubt even though your behavior is the same every time
21:32 swick[m]: but I'm done
21:32 JoshuaAshton: ok?
21:32 swick[m]: I'll just ignore literally everything you say