01:24 wlb: wayland/main: Simon Ser * ci: bump Meson version to 0.57 https://gitlab.freedesktop.org/wayland/wayland/commit/ad4ed17335e6 .gitlab-ci.yml
01:24 wlb: wayland/main: Simon Ser * build: bump minimum Meson version to 0.57 https://gitlab.freedesktop.org/wayland/wayland/commit/e7df1f2af2cc meson.build
01:24 wlb: wayland/main: Simon Ser * ci: use --fatal-meson-warnings https://gitlab.freedesktop.org/wayland/wayland/commit/37699a98b1eb .gitlab-ci.yml
01:24 wlb: wayland/main: Simon Ser * ci: turn on -Dwerror=true for FreeBSD https://gitlab.freedesktop.org/wayland/wayland/commit/c5d145a60258 .gitlab-ci.yml
01:24 wlb: wayland Merge request !378 merged \o/ (ci: turn more warnings into errors https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/378)
07:15 MrCooper: could be just one of those Phoronix mysteries, e.g. why is there no hit with CS2 at 1080p (gnome-shell even took the overall win there)
07:16 davidre: I wonder how rigurous their setup is
07:17 davidre: How do they control what else the machine is doing in the background
07:18 davidre: Ah I see they take three runs
07:18 davidre: And even state the standard error but don't show it in the graphs
07:19 davidre: But I do wonder that in one case everything is N=3 but gnome shell x11 is N=4
07:20 davidre: IN gravity mark even n=12
07:22 MrCooper: yep, evidence pointing toward something else affecting the test runs
07:34 dwfreed: on most of the results on that page, the SE value is so small that trying to reflect that on the graph is basically meaningless
07:35 dwfreed: but you can see it in the gravitymark 1.82 result for 4k vulkan, on the x11 gnome shell result
08:12 MrCooper: dwfreed: if it takes 12 runs to reach "reasonable" standard deviation, that still points to some of the runs being affected by some unknown factor
08:13 dwfreed: heat throttling, maybe
08:13 MrCooper: for example
08:14 emersion: MrCooper: I think gbm_bo_map undoes the multi plane tiling no?
08:14 emersion: it won't work for YUV ofc
08:15 emersion: iirc minigbm has a thing to map a specific plane
08:15 MrCooper: don't remember seeing anything like that in Mesa code
08:15 MrCooper: swick[m] was struggling with this a while ago
08:17 emersion: it's done on the kernel iirc
08:18 pq: emersion, I don't mind a wayland release. I haven't even kept an eye on what landed or is pending.
08:18 emersion: that's the difference with raw mmap() on dmabufs
08:18 emersion: GBM map is same as Vulkan/GL map
08:19 emersion: s/the difference/a difference/
08:27 MrCooper: emersion: the kernel does special handling for gbm_bo_map?
08:28 emersion: the gbm_bo_map uses a kernel API that maps in a way that undoes the tiling iirc
08:30 vyivel: aside from kde, are there any other more or less updated transactions_v1 compositor implementations? every other impl linked in the MR is from years ago and presumably doesn't reflect newer clarifications wrt. synchronized subsurfaces
08:31 MrCooper: emersion: IIRC Mesa internally uses Gallium transfers for gbm_bo_map, which don't necessarily directly map the buffer storage
08:32 MrCooper: vyivel: the mutter one definitely needs to be mostly redone
08:34 vyivel: right
08:34 vyivel: i'll be testing against kwin then
08:36 emersion: MrCooper: means tiling is undone but not in the kernel?
08:36 emersion: i haven't look at how it work i lust admit
08:36 emersion: looked*
08:36 emersion: must*
08:36 emersion: phone keyboards :(
08:37 kennylevinsen: lust is a bit strong of an emotion here
08:37 MrCooper: haha
08:37 MrCooper: the memory returned by gbm_bo_map is always linear, AFAIK it doesn't handle multiple planes though
08:41 emersion: right, that's my understanding as well
08:41 emersion: well
08:41 emersion: you mean not even the tiling kind of planes?
08:41 emersion: my understanding is that it handles say Intel CCS, but not YUV
08:42 zzag: vyivel: just one thing, I have not actually tested it with a real client yet. my original plan was to test it with gtk later.. but I _think_ that the MR should work
08:43 emersion: vyivel: there was a wl meeting yesterday and more sub-surface related comments are likely to come in
08:43 vyivel: zzag: i have some test clients
08:45 zzag: nice
08:48 MrCooper: emersion: ah, you mean it may use the metadata in a separate plane to handle tiling? What I mean is it can't be used for accessing the contents of additional planes
08:49 emersion: i mean that an XRGB8888 buffer may have 2 or 3 planes on Intel/AMD due to modifiers
08:49 emersion: and that gbm_bo_map() takes care of that
08:49 emersion: but yeah, different story for YUV formats
08:49 emersion: or 3-plane R/G/B
08:50 emersion: hm
08:50 pq: given that YUV formats are the only pixel formats that can have multiple planes that apps might want to access, multiplane support is kinda the same thing as YUV support
08:50 emersion: was thinking of 2-plane RGB_A, not 3-plane R/G/B
08:51 emersion: yeah
08:51 emersion: the minigbm thing https://chromium.googlesource.com/chromiumos/platform/minigbm/+/refs/heads/main/gbm.h#544
09:21 Consolatis: I do have to say that I find it very concerning to host spec bodies like wayland-protocols on a platform that more or less randomly bans people (and by extent projects) based on something that happened outside of that platform.
09:21 Consolatis: I would very much like to read an official statement of FDO regarding the ban of the lead dev of hyprland (which also excludes them from stating their opinion in e.g. the wayland-protocols repo).
09:26 kennylevinsen: Consolatis: #wayland is not the right place to discuss freedesktop code of conduct. Consider #freedesktop, or the CoC email address. Also, please read https://www.freedesktop.org/wiki/CodeOfConduct/ first, "Scope" in particular.
09:27 Consolatis: kennylevinsen: my main point here is about the wayland-protocols spec body
09:29 MrCooper: it can't be hosted in a vacuum, there would be rules anywhere
09:31 emersion: Consolatis: it seems you have misunderstood the reason for the ban
09:31 kennylevinsen: I'd suggest understanding the incident a bit better before suggesting our projects are severed from freedesktop. In particlar, the consideration that we have wayland people on the CoC team...
09:33 kennylevinsen: well, person, but it's a small group and simon *basically* counts as more than one person anyway
09:39 pq: yeah, I'm amazed how emersion finds the time and energy to do everything he does. :-)
09:44 YaLTeR[m]: Is there a client that just destroys some subsurface without any commits or destruction of any other surface? I want to test if my compositor correctly redraws in this case (and other commits or toplevel destroys will cause a redraw on their own)
09:47 pq: YaLTeR[m], I don't know of a stand-alone client doing that, but weston test suite has some, highly weston specific due to screenshooting.
09:47 MrCooper: YaLTeR[m]: looks like https://gitlab.freedesktop.org/vyivel/randfall/-/tree/main has something like that
09:48 YaLTeR[m]: thanks, I'll check this out
09:49 vyivel: not exactly like that, but subsurface_interactive_recreate_without_parent_commit is close, would probably need some roundtrip+sleep to test that specifically
09:55 MrCooper: doesn't it already just wl_subsurface_destroy and then wait for the toplevel to be closed?
09:56 vyivel: it also recreates the subsurface and iirc smithay has a problem with that
09:56 MrCooper: gotcha
09:56 vyivel: it's all immediate so won't be very useful to test rendering
10:04 emersion: Consolatis: with my CoC team hat on, we'll see if we decided to share a detailed public statement, for now here's our explanation:
10:04 emersion: After receiving concerns from FDO community members, we sent a warning to vaxry to make it clear what the Code of Conduct rules are on FDO, since they historically have had some incidents in their community.
10:04 emersion: Unfortunately vaxry didn't acknowledge the warning, reacted by posting a reactionary blog post attacking one of the FDO CoC team members, and stated that they will ignore the FDO CoC team messages.
10:04 emersion: This is not acceptable behavior, so the CoC team has decided to ban vaxry from FDO.
10:04 emersion: we'll see if we decide to*
10:06 emersion: anyways, this is a bit off-topic here, but i understand why people would be confused
10:08 MrCooper: thanks for the clarification
10:08 vyivel: where would that be on-topic btw
10:09 emersion: that's a good question
10:09 emersion: i suggested sending an email to the CoC mailing list
10:09 emersion: but that's not a public list
10:12 emersion: another issue is that in general we don't want to share all of the details of incidents for privacy, so other people are working with partial information (even if here vaxry decided to publish some of the details)
10:12 emersion: it's a balancing act
10:14 vyivel: fair
10:21 Consolatis: just for the record, I've read the mails published by vaxry and while I definitely don't agree to most what has been said there (and how it has been said) I also don't see it as enough of a reason to ban a wayland compositor's lead dev to interact with the wayland-protocols repo. This just leads to even more unnecessary fragmentation.
10:21 ebassi_: Other people from the hyprland community (such as it is) can collaborate
10:21 ebassi_: But, once again: this isn't the right place
10:23 emersion: in general, the CoC team doesn't decide based on the "importance" of people
10:23 emersion: IOW: a kernel maintainer doesn't have more room for CoC violations than a drive-by contributor
10:24 ebassi: that would defeat the point of the code of conduct, indeed
10:24 Consolatis: I agree, but it still raises the question of FDO being the right place for spec bodies like wayland-protocols.
10:24 emersion: i do agree that the outcome is unfortunate in terms of Wayland collaboration, for sure
10:25 emersion: i absolutely do want wayland-protocols to be under a CoC
10:25 Consolatis: even if that CoC expands outside of wayland-protocols?
10:26 pq: I don't think any spec body can function if the members must not be bound by a CoC like the fd.o's.
10:26 emersion: the ban is not directly due to past behavior here
10:27 emersion: and if the FDO CoC doesn't apply the CoC properly, that's a thing to fix in FDO
10:27 emersion: not a reason to go elsewhere
10:36 ifreund: I agree, there's no healthy way to do wayland-protocols development without a CoC
10:37 ifreund: er, the CoC is just a piece of text. There's no healthy way to do it without people behaving kindly and the CoC helps set that standard
10:38 ifreund: one thing I personally believe is important when dealing with bans is to make them long (at least a year) but temporary at first
10:39 ifreund: Ideally this would give people time to grow up and change their ways, worst case they get permanently banned
10:39 davidre: Imho if you need to check the CoC whether what you are writing is ok you are on the wrong track. I didnt read the CoC yet but I hope and assume I didnt violate it! :D
10:39 ifreund: yeah, same sentiment here
10:41 Consolatis: davidre: that seems to depend on how any external project of yours (e.g. not hosted at fdo) sets its moderation guidelines and how you reply to emails.
10:41 alice: i've never read any coc either in my life
10:42 davidre: If people were snesible "dont be an asshole" would be enough
10:42 davidre: alas
10:42 kennylevinsen: if you adhere to that you will be in compliance with pretty much all CoCs
10:42 kennylevinsen: even if you never read them
10:42 ifreund: I do think it's nice explicitly state that we welcome people regardless of race/gender identity/sexual orientation/religion/etc.
10:43 ifreund: s/nice/nice to/
10:44 ifreund: otherwise, yeah the rest might as well be "don't be an asshole"
10:49 kennylevinsen: It also makes sense that horrible behavior outside what is strictly defined as "the platform" also leads to exclusion, as most of our interactions are outside. Having others' play with you is a privilege, not a right, and for others' to bother with you you need to treat others with decency and respect...
10:49 kennylevinsen: although I don't really know a lot about this particular instance
10:50 kennylevinsen: (you can argue that decency/respect is subjective, but I don't think we're dealing with fine print here)
11:04 carbonfiber: fwiw. As an outsider (so you probably don't care). Then I think it is unacceptable that a person gets banned based on something they did on an entirely different platform. You can of course do what you want. But it makes me want to have as little to do with FDO as possible (and it has the same effect on multiple people I know). If you just want to ignore that, then go ahead. But it saddens me if that is the case. Compared to
11:04 carbonfiber: other CoCs then it is really unique behavior from FDOs CoC, and other CoCs do not work in the same way. That should be something that is weighed deeply in when you are analysing this. Are you really so special as so be the only project that has a CoC that also bans people for stuff on other platforms?
11:07 emersion: that's not what happened
11:08 Consolatis: well, it kind of is. The whole thing started only because of the fdo warning due to something that happened outside of the platform.
11:10 emersion: everything would've been fine if they replied with "yeah, i agree with the CoC"
11:12 Consolatis: its still FDO trying to impose its COC on external projects so I kind of understand the resistance to that behavior. (although personally I would never reply / react in such a way and instead likely simply ignore the mail)
11:12 emersion: that's not what it is
11:12 privacy: another power trip in my opinion. Will never willinly use anything related to KDE or mandated acceptance of personally believed immoral behavior. My 2 cents, but agree with Vaxry's rights.
11:13 emersion: since when is it a right to say that you'll ignore the CoC team? and to attack its members personnally?
11:14 privacy: your opinion only
11:14 privacy: don here - exiting channel for a day - don't agree with you - period.
11:16 kennylevinsen: someone should set a quota on their use of hyphens
11:19 Company: Consolatis: no, the coc is for people who participate in fdo - and the ban is only for fdo, no discord ban happened due to fdo
11:20 kennylevinsen: and the appropriate way to reconsider clauses in the CoC is to raise it in a formal (and respectfully executed) discussion with freedesktop
11:20 Company: Consolatis: and that's not really the coc, that's "decent behavior"
11:21 ifreund: honestly, if someone is an intolerant asshole in unrelated public spaces I personally don't want to interact with them as part of an open source project I contribute to
11:22 ifreund: I imagine this feeling would be much more extreme if I was part of a marginalized group this hypothetical asshole publically harrased elswhere
11:27 carbonfiber: So just to be clear. I am genuinely asking because I want to make sure I understand this with complete clarity. Lets say I have a discord channel for my own project (and it is public, but I have never invited any FDO contributors to this channel), and I make a joke about pronouns, or I mention that I like Jordan B. Peterson, or something like that, and I then get an email from a FDO contributor telling me to be sorry about it,
11:27 carbonfiber: then I am not allowed to tell that person that they should mind their own business? And If I do, I will get banned from FDO?
11:29 YaLTeR[m]: well, you're allowed to say whatever you want, but be prepared for others to decide whether or not they want to keep engaging with you after the fact
11:29 davidre: privacy how did KDE involved into this
11:29 davidre: oh they left
11:31 kennylevinsen: carbonfiber: depends on the joke. Try to substitute it for a racist or antisemmetic comment and it might be easier to understand the issue
11:31 Company: carbonfiber: the details matter, but I think if any coc enforcement entity contacts you and you tell them to fuck off, you shouldn't be surprised if you get banned
11:31 kennylevinsen: (heck in that case, you'd also be looking at legal repercussions in some countries where that's flat out illegal)
11:33 ifreund: honestly, this particular case should have been over back in november IMO: https://fosstodon.org/@drewdevault/111363547103465966
11:36 carbonfiber: Company: does that also apply if they contact me by knocking on my door in the middle of the night? because in that case I would definitely tell the person to fuck off, and expect not to be banned over it.
11:36 kennylevinsen: carbonfiber: at the same time, we are not dealing with immediate, zero-tolerance punishment. If you make a distasteful joke, people will mostly just go "wtf". If you behave like that in general, you'll probably get a warning
11:38 ifreund: carbonfiber: CoC rules are inherently flexible. It seems like you're looking for something in the spirit of "if the person says X word 10 times that's a warning, 100 is a ban"
11:38 ifreund: but that's not how moderating a community works
11:39 carbonfiber: ifreund: No I am not. Not at all.
11:40 ifreund: you are literally asking "if hypothetical situation with no context happens do I get banned?"
11:40 ifreund: this is in the same spirit as my absurd 100 words example
11:40 ifreund: there is no context, so there is no way to say what the correct moderation decision is
11:41 carbonfiber: I prefer a CoC that doesn't ban people because you tell someone to mind their own business. Even if you are not banned from FDO, individual developers can still choose not to interact with you (based on whatever they want and from any sources they want), that is fine and something completely different.
11:42 Company: the coc doesn't do anything - this is about people
11:42 ifreund: the CoC doesn't ban anyone, the community leaders/moderators do based on what they think is best for the community
11:43 carbonfiber: well substitute CoC for FDO leaders/moderators then.
11:46 ifreund: again, "FDO leaders/moderators banned someone for being told to mind their own business" completely disregards the larger context
11:46 ifreund: this discussion is obviously going nowhere, so I'm done here o7
13:17 MrCooper: Company: in case you haven't seen it, it's doubtful there's a mutter issue behind those Phoronix numbers, e.g. CS2 didn't take any hit at 1080p, and some tests required 12 runs for standard deviation to drop below some threshold
13:28 feaneron: i'm just looking at the benchs. did phoronix really test a 2-year-old gnome against bleeding edge kde?
13:29 feaneron: that's a little disappointing (and, practically, unactionable)
13:31 mclasen: and yet, 90% of the results were "no difference at all"
13:31 mclasen: like most of the time
13:33 feaneron:doesn't spend more time looking at that
13:39 kennylevinsen: it means you'll get a free headline article when he finally upgrades :P
13:39 jadahl: "yay"
13:40 kennylevinsen: what, phorinix articles isn't part of your KPIs? :O
13:42 jadahl: only if we write them I guess :P
13:42 kennylevinsen: I do give him some credit for running a ton of benchmarks that *sometimes* reveal interesting things...
13:42 jadahl: (blogging etc is encouraged)
13:43 kennylevinsen: ah, nice
14:07 Company: MrCooper: I hadn't, thx
14:07 Company: though I'm still curious what's causing it
14:14 MrCooper: mclasen: no difference is expected with fullscreen benchmarks, since they mostly depend on things between the X server and the app, the Wayland compositor shouldn't really affect the results
14:14 mclasen: right, so he's testing entirely irrelevant things
14:15 MrCooper: so if there's any significant difference, my first suspicion is something went wrong
14:16 Company: mclasen: I think what he's testing is that compositors and applications actually work - which is important to test, though expressing it via fps is kinda useless
14:17 Company: and from the dmabuf stuff, we know how easy it is to make things look like thwy work, but not actually work
14:36 wlb: weston Merge request !1488 opened by Pekka Paalanen (pq) CI: work around LeakSanitizer crashes with use_tls=0 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1488 [CI]
15:06 wlb: weston Merge request !1477 closed (Draft: tests: Attempt to fix LSAN crashes)
15:56 wlb: weston Merge request !1489 opened by Marius Vlad (mvlad) libweston: Reorder paint node destruction before view destruction https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1489 [Backport to Weston 13], [Core compositor]
15:58 wlb: weston Merge request !1488 merged \o/ (CI: work around LeakSanitizer crashes with use_tls=0 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1488)
15:58 wlb: weston/main: Pekka Paalanen * CI: work around LeakSanitizer crashes with use_tls=0 https://gitlab.freedesktop.org/wayland/weston/commit/3179e0f0e0c9 .gitlab-ci.yml .gitlab-ci/leak-sanitizer.supp tests/meson.build
16:15 emersion: pq, are you happy with !369?
16:15 emersion: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369
16:51 Company: that issue is soooo confusing
16:51 Company: and it's really hard to document, because it depends on the mental model I operate under how I read this
16:52 Company: "just try it and if it rotates the wrong way, flip the values around"
16:55 mclasen: there is just so many "upwards" directions to line up: the buffer, the surface, the monitor, all have their own
17:01 emersion: i think giving an explicit example would help
17:02 emersion: buffer with arrow pointing up, what happens when i set 90 degree transform?
17:02 emersion: what happens on an output with a 90 degree rotation?
17:03 mclasen: I think the real confusion sets in when trying to interpret what to do in response to the output rotation
17:04 emersion: simple: nothing!
17:05 emersion: wl_surface.preferred_buffer_transform is the replacement
17:05 emersion: and doesn't require you to second-guess
17:05 mclasen: that is better, indeed
17:05 emersion: but to reply to the question
17:06 emersion: i think with earlier wl_surface versions, clients are expected to use the same transform as the output on their surface
17:06 emersion: wl_output has TRANSFORM_90, that's a hint for clients to use the same transform
17:13 Company: emersion: the explicit example sstill doesn't help, because I need to be sure if that's the transform that is already applied or that will be applied
17:14 emersion: i think it helps if you pick an example with a fixed wl_surface transform and a fixed wl_output transform?
17:14 emersion: describe what's in the buffer and what's on screen
17:14 emersion: no?
17:14 Company: dunno, I know how it works and I'm confusing myself constantly
17:15 Company: I write this code by testing and if it comes out wrong, I use the other value
17:16 Company: because my mental model works by thinking about where dmabuf->pixels[1] ends up
17:16 Company: in the surface coordinate system or the output coordinate system
17:16 Company: but that's not necessarily the model other people use
17:17 vyivel: would be nice to have an interactive example to show how transforms work
17:17 vyivel: maybe as a small web page
17:19 emersion: maybe as a small wayland client
17:19 emersion: oh wait…
17:19 emersion: (but yeah, would be nice!)
17:20 vyivel: does gitlab.fd.o have static pages service?
17:20 emersion: yes
17:21 emersion: it's standard GitLab pages stuff
17:21 vyivel: nice
17:21 emersion: libdisplay-info uses it for docs for instance
17:21 emersion: the URLs are a bit weird
17:21 emersion: not sure the CSP allows JS
17:27 vyivel: well will try to make something anyway
17:28 emersion: maybe there could be a pure non-JS solution with CSS transforms and selectors lol
20:11 vyivel: ah, publishing a website uses ci…
20:15 emersion: yeah
20:15 emersion: you need a special step named with a magic name
20:16 emersion: no way to have no-op CI steps other than use a random container and run "true" in it
20:16 vyivel: the problem is that i "don't have enough privileges", apparently
20:16 emersion: for CI?
20:16 vyivel: yea
20:17 emersion: weird, you're a wlroots member
20:17 vyivel: does this look right https://gitlab.freedesktop.org/vyivel/wl-transform/-/blob/main/.gitlab-ci.yml
20:20 emersion: i don't understand why it works for my personal repo but not yours
20:21 vyivel: emersion: probably because you're in CI-OK group https://gitlab.freedesktop.org/users/emersion/groups
20:22 emersion: i'm not in that group
20:22 emersion: okay, so i think i'm in the group via some other group
20:22 emersion: like, mesa in in CI-OK for instance
20:23 emersion: i've added wlroots there
20:23 emersion: can you try again?
20:23 vyivel: at least it shows that i'm in ci-ok too now
20:24 vyivel: one sec
20:25 vyivel: alright https://wl-transform-vyivel-0b5eece634f851f5178ec0da1ba43582cc889b0952b.pages.freedesktop.org/
20:25 vyivel: that's one weird url indeed
20:25 emersion: no cat? x)
20:25 vyivel: (ui/logic still wip)
20:25 vyivel: good idea
20:25 emersion: ah, i think you're seeing the pipeline preview website
20:26 emersion: in the project settings, in "Pages" you should see the stable URL
20:26 vyivel: i tried vyivel.pages.freedesktop.org/wl-transform and got redirected
20:26 vyivel: nope, that's the link (the first one) it shows in "Pages"
20:27 vyivel: nvm it's "Use unique domain"
20:27 emersion: weird, this doesn't redirect for instance: https://emersion.pages.freedesktop.org/libdisplay-info/
20:27 emersion: aha
20:30 vyivel: thanks for helping!
20:32 emersion: np :)
20:33 wlb: wayland-protocols Issue #188 opened by Eduardo Hopperdietzel (ehopperdietzel) xdg_surface window geometry calculation https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/188