04:59rayquaza: is this channel still active?
05:00dwfreed: it normally is, looks like the discord bridge died
05:00dwfreed: karolherbst: ^^^
05:01rayquaza: ah I see
05:01rayquaza: are the logs only posted weekly then?
05:02dwfreed: the logging bot was broken for a while, I believe
05:02rayquaza: what isn't broken XD
05:02dwfreed: IRC always works
05:04rayquaza: good to know, is the dri-devel mailing list so active cause I could've sworn that I chose the daily digest mail option?
05:05dwfreed: https://lists.freedesktop.org/archives/dri-devel/2024-July/thread.html looks quite active to me
05:05rayquaza: yeah cause I get a new email every couple hour
05:06dwfreed: betting mailman has a cap on how big digest emails can be, and once it hits that, it sends
05:07rayquaza: damn that interesting
05:08dwfreed: I dunno, I don't know a lot about mailman
05:08dwfreed: but it certainly sounds plausible
05:31rayquaza: any recommendations on learning C, for eventually helping develop nouveau or even nova?
09:52karolherbst[d]: apparently when updating the server yesterday, the bridge didn't reconnect, because docker was updated and the container wasn't set to `restart: unless-stopped` :ferrisUpsideDown:
09:52karolherbst: dwfreed: ^^
09:52karolherbst: luckily nobody missed anything substantial
09:52karolherbst[d]: but the bridge also got an update anyway, soo...
11:35ahuillet[d]: any known issue with anongit.freedesktop.org?I get "connection reset by peer"
11:41asdqueerfromeu[d]: ahuillet[d]: I think GitLab is the main way to fetch FDO repositories now
11:42ahuillet[d]: oh, yes, better, thanks
12:10ahuillet[d]: moving on with dumb questions: "vkEnumeratePhysicalDevices failed, unable to init and enumerate GPUs with Vulkan." when starting steam - has anyone seen this before?
12:11ahuillet[d]: vulkaninfo seems OK but I guess I need a 32bit Mesa build?
12:16asdqueerfromeu[d]: ahuillet[d]: This is definitely self-promotion but you can run 32-bit `vulkaninfo` with the `lib32-vulkan-tools` AUR package (the program name is `vulkaninfo32`)
12:41tiredchiku[d]: ahuillet[d]: you do need 32bit mesa to run steam, yes
12:42tiredchiku[d]: though I'm not sure if steam's devicequery itself is 32 bit
12:42tiredchiku[d]: never checked
17:25dwfreed: karolherbst: nice
17:39avhe[d]: Hi all, how could I programatically check whether a device is using nvidia.ko or nouveau.ko? Maybe a pseudo-file in /dev?
17:42asdqueerfromeu[d]: avhe[d]: ~~Just read /proc/modules~~
17:43dwfreed: readlink /sys/bus/pci/devices/<device address>/driver
17:47avhe[d]: Maybe just checking for /dev/nvidiactl is sufficient for the prop driver, I don't know if nouveau has something similar though
17:51asdqueerfromeu[d]: avhe[d]: /dev/nvidiactl is very proprietary driver-specific)
17:52avhe[d]: by similar I just mean something that will tell me unambiguously which driver is in use
17:52tiredchiku[d]: lspci -k
17:52tiredchiku[d]: .-.
17:53tiredchiku[d]: (could look at what lspci does to identify the kernel module)
17:59notthatclippy[d]: Can you have one device using nvidia.ko and another using nouveau.ko at the same time?
18:00avhe[d]: looks like it does `basename $(readlink /sys/bus/pci/devices/<whatever>/driver)`, but in code
18:02tiredchiku[d]: notthatclippy[d]: good question tbh
18:05avhe[d]: notthatclippy[d]: good point, i can probably call NV_ESC_CARD_INFO to confirm whether nvidia.ko actually owns a device
18:12notthatclippy[d]: That's probably safest. Pass 32 card_info structures, see which ones are populated. Others either don't exist or are nouveau.
19:58Lyude: Probably worth mentioning I'm finally on the part of rvkms where I am trying to implement CRC generation :)