07:43mareko: the world wouldn't be complete without this guy
08:33colinmarc: people don't join the channel very often, is it possible to require approval to post the first time?
08:34colinmarc: probably about the same amount of total moderator work, but it could be more async
10:58dwt: You can do that by making the channel +m so only voiced users can speak, and I think network services can auto-voice an allowlist of users
11:03ccr: I think the question is more about whether there are resources for managing such moderation (someone would have to presumably manage the allowlist or such), and whether the community wants to disable any casual "drop-by" question asking etc.
11:05colinmarc: it seems like too harsh to disable people dropping by altogether, but it might be a reasonable tradeoff to require people dropping by to wait a little bit before they get approval
11:05colinmarc: (just my 2c)
11:13dwt: the other question is whether a cooldown period or having to message a mod to be voiced would actually dissuade the spammer, or just rate-limit them a bit
11:39MrCooper: experience suggests the latter seems likely unfortunately
11:44dwt: Wonder if I can setup an irssi ignore based on line length...
12:39phasta: I mean, is IRC really the only platform that suffers from spam of this kind? How to the others solve it?
12:40phasta: I'm pretty sure this bla-bla could be categorized by a clever filter. Someone would have to set it up, though <.<
12:44Ermine: more than that, linux graphics related channels are the only ones suffering from this dude
12:46ccr: hmm. I thought his repertoire was floss project channels in general. might've changed his patterns, of course.
12:48Ermine: Also, irc is not very good when it comes to moderation. Channel operators have basically only two tools to restrict access: nickname and ip address, and both are easy to change
12:55bl4ckb0ne: isnit just me or his rants are getting worst recently
12:56ccr: he tends to act periodically. sometimes there are longer periods of "radio silence". I would venture to guess perhaps related to level of psychosis.
12:57Ermine: also his mood changes over time back and forth
12:58Ermine: from "ok you're cool guys after all" to death threats and elaborate slurs
13:02ccr: there is also some evidence that he may be lurking here under some non-spamming identity. sometimes his spam accounts have referenced things that have been said during his apparent absence.
13:02MrCooper: is the channel not logged anymore?
13:02ccr: oh, that is another possibility of course
13:03ccr: silly me :)
13:14tonyk: hey lumag mripard, I think that we should be good to go now? https://lore.kernel.org/lkml/CADnq5_N_SQHbx5zZGyWFJo8FcGbR+mT3aJr1C-uPRJ5Z9m27Vw@mail.gmail.com/
13:20lumag: tonyk, It seems so. If nobody objects and if nobody beats me, I will apply it tonight.
13:21tonyk: thanks!
13:45stsquad: Any idea why I might not be seeing the VK_KHR_display extension while testing Venus?
13:55ccr: and there he is
14:01lumag: mripard, gracious ping for https://lore.kernel.org/dri-devel/20250209-dp-hdmi-audio-v2-0-16db6ebf22ff@linaro.org/ . I'd really like to let that be used for future DP audio submissions too.
14:02stsquad: vulkaninfo --summary is showing two Virtio-GPU Venus devices (one Intel, one llvm pipe) but there is no VK_KHR_display extension - should there be?
14:03stsquad: would this be down to virglrenderer or the backend mesa?
14:03lumag: krh, let me try pinging you here, I've been trying to get https://github.com/krh/vkcube/pull/61 in for ... quite a while :-)
14:10DemiMarie: Ermine: I think this might be why Libera.Chat blocks signups from Tor, and possibly from VPNs as well.
14:11DemiMarie: Another option would be to use some sort of classifier to filter posts as they are being made.
14:14stsquad: digetx any idea? ^
14:41Ermine: DemiMarie: yeah, VPNs and Tor can be used for abuse, so some services ban them
16:26digetx: stsquad: VK_KHR_display is instance extension, it should always present afaict and I have it with venus
16:29stsquad: digetx: sadly I don't have vulkaninfo on my working guest image - but it looks like there was a flurry of updates including this one: https://github.com/vkmark/vkmark/commit/7c3189c6482cb84c3c0e69d6dabb9d80e0c0092a
16:29stsquad: digetx: so can I track it going through QEMU/virglrenderer?
16:30stsquad: the context is I'm packaging up vkmark/mesa3d in buildroot so I can have a reproducible test build in buildroot and people don't rely on my hand crafted binaries
16:31digetx: you mean, you're trying latest vkmark git version and it doesn't work
16:32stsquad: digetx yes
16:32digetx: I'll check if it works for me
16:32stsquad: I figured I should package the 2025.1 release rather than a random commit but it broke
17:01DemiMarie: Would it be useful to have documentation explaining what is needed for shared virtual memory?
17:02DemiMarie: tl;dr: GPU must support page fault handling, and either it must be able to preempt while that is happening or a single process must have exclusive use of the GPU at any given time.
17:03DemiMarie: Without recoverable page faults there is no way to lazily allocate memory, and without preemption there is no way to avoid other users of the GPU being blocked for unbounded amounts of time
17:04DemiMarie: Also, page faults are very expensive, so they should be used only for lazy memory allocation, not overcommit.
17:05DemiMarie: I think this is all pretty well known among the devs here, but I'm willing to send a patch to dri-devel to include it in the kernel documentation.
17:25FL4SHK[m]: I would appreciate that patch
20:56Lyude: lumag: oh! I didn't see this patch series yet
20:56Lyude: I can try to review it either this week or monday next week
21:00lumag: Lyude, thanks!
21:00Lyude: np, feel free to cc me directly with DP stuff too - it makes it come up in my inbox
22:49fufexan: hello! is it allowed to commit vsync'd (not immediate) update(s) to the cursor plane position after committing the main plane but before a vblank?
22:52fufexan: asking about AMS, not legacy
23:09zamundaaa[m]: fufexan: no, there can only be one pending commit at a time