09:24 tzimmermann: lumag, i got a question about the status of this series: https://lists.openwall.net/linux-kernel/2025/12/10/126 is there anything to do? can it be merged?
10:07 mareko: we could also switch to discord
10:14 emersion: we could also not do that
10:17 ukleinek: ..ooOO(https://mastodon.social/@sturmsucht/115508654474968435)
10:17 mareko: the compact style with a black-and-white high contrast theme and no font colors is decent
10:19 pac85: I'd be nice if we had a nice alternative to discord but sadly I don't think we do. Like IRC is the next best thing that's not proprietary...
10:20 emersion: the walled garden and the company behind it is not decent
10:25 linkmauve: I propose hosting an experiment using XMPP, which provides many of the benefits of Discord without the proprietary and centralized parts.
10:25 linkmauve: Would it be possible to do so on fd.o premises?
10:25 llyyr: +1 for xmpp, it's also much easier to self host unlike the mess that is matrix
10:26 linkmauve: I’ve been maintaining XMPP infrastructure for various associations for the past two decades, so I have quite a lot of experience including around expectations.
10:51 karolherbst: linkmauve: how are the accounts managed there? And can we do a SSO login through our gitlab?
10:51 linkmauve: karolherbst, we could use GitLab as the accounts management yes.
10:52 karolherbst: I assume we can have multiple providers or does it need to be one?
10:52 karolherbst: _not_ sure we want to require a gitlab account for users needing help with something
10:53 karolherbst: or might have to rethink how we do gitlab registrations, because atm it needs an email verification and then only arrives a bit later or something?
10:54 linkmauve: It can be multiple providers, but one per domain. We could also have anonymous “accounts” like we have here on IRC.
10:56 linkmauve: So for instance we could have <username>@freedesktop.org for GitLab accounts, and <UUID>@anon.freedesktop.org for anonymous access, which would be much more restricted than the first one.
10:57 karolherbst: mhh, but we could have multiple domains on the same xmpp thing, right?
10:57 linkmauve: Of course.
10:57 karolherbst: I think it's fine to have different domains for gitlab users and non gitlab users
10:57 karolherbst: are there competent IRC bridges available?
10:58 linkmauve: Yes, biboumi.
10:58 karolherbst: like I'd prefer proper puppeting support and such
10:58 linkmauve: That’s what I’ve used since about forever to connect here.
10:58 karolherbst: their webpage doesn't support https 🙃
10:58 linkmauve: You’ve never known I’ve never directly used IRC to talk to you, and I think that’s a good feature.
10:59 linkmauve: Uh? It does: https://biboumi.codeberg.page/
10:59 karolherbst: ahh with biboumi you still need a proper IRC account?
10:59 karolherbst: ohh.. my search engine pointed out their "old" website it seems
10:59 linkmauve: Its IRC integration comes with all IRC issues yes.
11:00 karolherbst: mhhhhh
11:00 karolherbst: I didn't really mean a gateway tho
11:00 karolherbst: like
11:00 karolherbst: users on the XMPP side shouldn't have to do anything additionally to see what's said on the IRC side and should be able to interact with IRC users just fine
11:01 karolherbst: like the channel itself should be bridged
11:01 linkmauve: As long as IRC is kept as the source of truth, I think biboumi is ideal, since you can continue interacting with IRC as you are doing currently.
11:01 linkmauve: And moderation is still kept in one place.
11:02 karolherbst: mhh guess still being on IRC has the issue of not solving anything anyway
11:02 linkmauve: There are also gateways which mirror users on both sides, but it comes with many issues wrt moderation and some users seeing a different view of the same chat state.
11:03 linkmauve: Would you like to experiment with a pure XMPP setup first?
11:03 karolherbst: no, because I think there needs to be a transition period anyway
11:03 emersion: if we hop off OFTC, we need to take care of moderation
11:03 karolherbst: like for now I think just having a properly bridged room to the XMPP side _could_ be viable, just as a starter and to see how the account integration, etc.. works out without missing out on anything
11:04 karolherbst: emersion: spammers and stuff, right?
11:04 emersion: yes
11:04 emersion: just like we do on GitLab
11:04 karolherbst: could use the same infra we have set up for gitlab
11:04 karolherbst: we have a huge domain denylist thing
11:04 emersion: it will necessarily be some work
11:04 karolherbst: and we could put the xmpp reg page behind anubis 🙃
11:04 emersion: i had a different proposal to stay on IRC: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/459
11:05 karolherbst: anubis alone cut spam accounts but like 2/3
11:05 karolherbst: *by
11:05 linkmauve: karolherbst, with GitLab integration there would be no need to register, all GitLab users would automatically have an account already.
11:05 karolherbst: right...
11:05 linkmauve: emersion, speaking of which, biboumi acts as a wonderful bouncer. :)
11:05 karolherbst: though the question is, would it solve our problem
11:06 karolherbst: but that's also a different question...
11:06 emersion: what is our problem?
11:06 linkmauve: This ↑
11:07 karolherbst: emersion: josh mostly
11:07 emersion: nothing will stop him
11:07 karolherbst: yeah.. if we have open sign-up, we'll also have to deal with person like them
11:07 linkmauve: I believe XMPP moderation tools would make it much less painful at least, moderating past messages, or even preventing them from reaching the users in the first place.
11:07 emersion: i don't believe so
11:08 karolherbst: yeah.. so one thing that could help is being able to remove messages, at least a bit
11:08 karolherbst: so fewer people have to see it
11:08 karolherbst: but so would +mz
11:08 karolherbst: just need proper voicing infra set up
11:09 karolherbst: emersion: so one idea I had was to put every channel on +mz and we just auto voice trusted users, and everybody else is seen by ops only until they get voiced
11:09 karolherbst: just need something to regrant voice status after dcs
11:09 emersion: the consequence is that it will raise barrier to entry quite a bit
11:10 karolherbst: why?
11:10 emersion: i don't think it's worth it
11:10 karolherbst: everybody can still write, it's just only seen by ops, though if we op a bunch of people, then it might not help _that_ much
11:10 karolherbst: except that random people won't be confused on what's going on
11:10 karolherbst: but yeah....
11:10 emersion: it's not that big of an annoyance
11:11 emersion: occasionally getting spam, that is
11:11 karolherbst: yeah... maybe
11:12 karolherbst: though then being able to delete messages would also be good, because that's a clear sign that 1. it's not acceptable and 2. it makes fewer people see it
11:12 karolherbst: though I assume IRCv3 has support for message deletion?
11:13 linkmauve: In how many decades will OFTC deploy any IRCv3?
11:13 emersion: it does, yes
11:14 karolherbst: yeah.. found the Message redaction spec
11:15 karolherbst: good question
11:16 karolherbst: though hosting our own infra is work and could also just spend the time to help out oftc instead
11:17 linkmauve: If you don’t want to host it, we provide hosted XMPP infrastructure at JabberFR.
11:17 linkmauve: This would come with no GitLab integration, but might still be good enough maybe.
11:18 karolherbst: nah.. gitlab integration could enable a lot of cool stuff tho
11:18 karolherbst: like project channel permission linking with gitlab and stuff
11:18 linkmauve: Yup. :)
11:19 karolherbst: like if we move to something new, then it should also be worth it for other reasons
11:19 karolherbst: like having every project owner be channel admin, and developer be channel op automatically could be nice
12:55 mareko: there's also WeChat
14:14 alyssa: linkmauve & emersion arguing about XMPP vs IRC is iconic
14:14 linkmauve: alyssa, for me it’s more, anything but Discord.
14:15 linkmauve: And tons of people prefer Discord to IRC because of the terrible experience of the latter.
14:15 alyssa: c'est exactement ce que j'attends de chaque un de vous
14:15 linkmauve: <3
14:15 alyssa: ^.^
14:15 alyssa: personally I think it's important we stay on /some/ open system, just given our values as a project/org
14:16 alyssa: I have no opinions on IRCv2 vs IRCv3 vs XMPP vs Matrix
14:17 alyssa: (...and also if everyone was strongly in favour of going Discord this is not a hill I'm willing to die on.)
14:17 zmike: what if we wrote our own chat protocol ?
14:18 alyssa: i am too old for that
14:18 linkmauve: I am already doing that.
14:18 pac85: there are too many standards meme
14:20 pac85: personally among open things IRC is my least unfavorite platform though I never tried XMPP. I think a lot of it boils down to the quality of the clients in the end though
14:31 ccr: and Matrix tried to "unify" it all, but ..
14:33 alyssa: https://xkcd.com/927/ is Matrix fr.
14:42 zamundaaa[m]: ccr: ... is pretty successful with it? I haven't used IRC directly in years thanks to matrix bridges :)
14:43 ccr: the problems are mostly on the IRC side in that respect. the way the bridge presents things like "long" messages is a bit annoying (e.g. links)
14:43 ccr: but it's not too bad
14:44 ccr: last time I looked at Matrix itself, I didn't find a client that I would have wanted to use
14:44 pac85: My issue with the matrix irc bridge is that it could fail silently such that if the bridge lost connection I would see messages but mine would get blackholed without any sign
14:45 ccr: yeah, and some other integration issues like channel modes such as +m not working very well (or at least used to be problem, not sure if that has been fixed)
14:46 ccr: e.g. Matrix users talked on +m channels, not realizing that their messages would only show to other Matrix users but not on the IRC channel
14:47 pac85: I also found matrix in general to be quite sluggish and had bugs like trying to scroll history resulting in it repeating it in a loop instead of actually showing older messages on element. Things might have improved my given my experience I'd rather use IRC tbh
14:48 pac85: s/my given/but given/
14:57 pq: sima, emersion, for drivers implementing KMS colorops, should writeback functionality be required for ensuring the colorops are actually implemented as specified?
15:03 zamundaaa[m]: pq: most hardware doesn't have writeback afaiu, so that would be bad
15:04 pq: I guess HDMI grabber in a CI farm could do too.
15:04 zamundaaa[m]: I've been told future AMD hardware also won't have it anymore, sadly
15:04 pq: O_o
15:04 pq: Makes it kinda hard to enforce correctness.
15:05 zamundaaa[m]: I mean, it certainly requires some amount of silicon to implement it. So I understand why
15:17 sima: pq, I guess strongly encourage sounds like a good idea, but requirement is probably going to run into some hw that doesn't have any writeback
15:18 sima: and yeah that makes proper testing kinda impossible unless you have a frame grabber somewhere
15:18 alyssa: I doubt apple has writeback hw
15:19 alyssa: given that the display contoller on m1 is the single worst IP block on the soc.
15:20 pac85: what's so bad about it?
15:20 sima: in a way this isn't new, automated testing without grabbers is best effort
15:21 sima: like ensuring hdmi/dp compliance with stuff like infoframes or correct link training sequence is also not something we can test without that
15:21 sima: so sucks, but I guess if the hw doesn't have it, that's just it
15:30 alyssa: pac85: see the first half of https://www.youtube.com/watch?v=ObS6sdfus2w
15:30 pac85: ty!
15:31 jannau: alyssa: I'm not sure. there is a runtime property enablePixelCapture
15:31 alyssa: jannau: ...oh wild
15:53 pq: sima, aren't most problems with testing such that if a feature fails, it's obvious something is broken? Colorops could be broken in subtle ways that is not apparent in isolation but only when comparing to another system.
15:54 pq: That's my worry, noticing problems only after someone relies on wrong behavior.
15:54 karolherbst: ccr: at least with element any ping gets lost more or less, so that's kinda pain
15:54 sima: pq, we kinda have that with everything
15:55 sima: on the plus side if it's only broken in subtle ways, we can also break existing userspace without undue screaming
15:56 sima: and at least if you take into account the combinatorial explosion of sink features I don't think those sink features are that much different
15:56 pq: ok then
16:00 alyssa: sima: we do not break userspace*
16:00 alyssa: * unless they don't notice
16:00 sima: yup, been like that since forever
16:01 sima: I've done stuff like break ums outright with fallback to vesa
16:01 sima: I think I've seen like one bug report for that somewhere and luckily kms worked
16:03 emersion: pq, agreed with sima
16:24 sima: pq, emersion I think the more practical approach here to avoid uapi headaches is to get all the colorops into vkms
16:24 sima: and tell compositors that they really, really should validate against that
16:25 sima: but that's also a ton of work
16:33 emersion: that would be very nice indeed
17:24 macromorgan: so how important is it that a panel run at exactly 60hz? I can get a panel that reports 60hz to run at 59.6hz as-is... if I want to get it to run at 59.99hz (as close as I can get it) I have to add a new PLL frequency to a clock driver.
17:24 macromorgan: I'm wondering how much that extra 0.37hz really matters
17:35 pinchartl: macromorgan: it depends on the panel. its datasheet should indicate the clock tolerance
17:36 macromorgan: it can run with both just fine honestly... and sadly I have no data sheet only an init sequence
17:37 pinchartl: "just fine" as in tested quickly, or "just fine" checking EMC constraints, power consumption and all kind of things that could cause issues in the field in the long run ? :-)
17:37 pinchartl: without information from the manufacturer you can only guess
17:44 macromorgan: that is true in that I can only guess... I'll aim for whatever PLL rate got the panel closest to the timings in the BSP kernel then I guess
21:15 valentine: anholt: do you plan to cut a new deqp-runner release?
21:25 cwabbott: mareko: I've been looking at converting freedreno to use intrinsics (i.e. set nir_io_has_intrinsics) and it seems that when this is set the CSO stream_output state is incorrect
21:25 cwabbott: I assume radeonsi is unaffected because it uses the streamout info in the NIR intrinsics instead
21:29 cwabbott: I think this is because the linker moves around and compacts varyings but the stream_output state comes from the original xfb state via st_translate_stream_output_info
21:30 cwabbott: if !nir_io_has_intrinsics get_stream_output_info_from_nir is called... I don't know why this isn't always called
21:31 cwabbott: is pipe_stream_output_info deprecated?
21:32 anholt: valentine: I'm a little in the weeds on refactoring more to reduce the per-test-type code duplication. should probably pause on that and just ship something.
21:49 alyssa: cwabbott: I vaguely remember Marek & I unilaterally deprecated pipe_so_info yes
21:50 alyssa: the assumption is if you're modern and using semantic i/o, you're also using nir->xfb_info
21:51 alyssa: although if it's easier to call get_stream_output_info_from_nir at least for now.. I don't have an objection. Marek might.
21:54 cwabbott: it's somewhat awkward that the NIR info is based on location instead of driver_location like pipe_so_info
21:55 cwabbott: in ir3 we have a map of driver_location -> { HW register, location } after compiling the shader, and in a few places we need to lookup the output for a given streamout output
21:57 cwabbott: or when emitting code to do the streamout stores manually on a3xx, we need to lookup the value for a given output and that's organized by driver_location
21:57 cwabbott: we can't just translate it in ir3, since we don't know the location -> driver_location mapping (get_stream_output_info_from_nir does because it lives in gallium)
21:58 cwabbott: so I have a lot of extra "find the output with the given driver_location" loops... maybe it should be fixed in ir3
21:58 cwabbott: *with the given location
22:09 anholt: valentine: done
22:10 valentine: thx
22:28 alyssa: cwabbott: party line is that ir3 is holding it wrong since driver_location is deprecated too
22:29 alyssa: and drivers should just use locations everywhere with a location -> HW register map
22:29 alyssa: which ends up being simpler in practice anyway, I think
22:30 cwabbott: https://tenor.com/view/fixing-programming-lightbulb-light-bulb-gif-14960625
22:41 zmike: I link that at least once a week and it's never not relevant
22:43 cwabbott: it's an evergreen meme
22:45 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10948#why-not-driver_location