01:03DemiMarie: robclark: is using Rust in virglrenderer under consideration?
01:40robclark: it is something I'd like, at least for virglrenderer core and nctx, I'm not sure there is a point for vrend/vkr.. but no actual work on it yet..
01:42robclark: the nctx parts are small enough that re-writing them is nbd as far as I am concerned.. but haven't really had time to figure out how to integrate rust with build system/etc
01:42robclark: DemiMarie: ^^^
01:42DemiMarie: robclark: that would be awesome, thanks! Which nctx drivers are used by ChromeOS right now?
01:43robclark: so far, just msm/qc .. but landing mesa and virglrenderer bits for Intel would make it an attractive next target
01:44DemiMarie: More generally, which ones are considered safe for use with untrusted guests (and thus need coordinated disclosure of security issues) and which ones are not?
01:46robclark: I think pepp did some fuzzing on amd... not sure if digetx has done any fuzzing on Intel yet..
01:47DemiMarie: robclark: Meson has Rust support, but not `crates.io` integration last I checked (though this may have changed since). The main part I want to see rewritten (parsers for guest-provided data) don’t need any third-party libraries, or could just vendor a single one that helps do safe casting.
07:44castfromtypeX: Ermine: you ready to deliver your ass now , one guy with AIDS wants buttfuck you, it's that you need to excersize getting anal with your pals cause you are jailed soon to saint Quentin for combined terror acts, try to play a victim there just deliver your ass with other kill off motogangsters, I dunno since 165 people died in domededov blast maybe you get death penalty instead, I hope
07:44castfromtypeX: you get slaughtered in saint Quentin buttpainfully.
08:25tzimmermann: arnd, the naming conflict in https://lore.kernel.org/dri-devel/b9a5068c-8760-4f92-8a1b-bd276532109d@redhat.com/T/#t needs to be fixed in arch/. shall i send a trivial rename of the video.c files, or shall i send something more elaborate?
08:26arnd: tzimmermann: I don't have a strong opinion, I'll trust you to come up with a fix and can forward this to linus for -rc1
08:27arnd: I mean I can forward it
08:29tzimmermann: ok, i'll send a simple rename
08:29arnd: tzimmermann: actually, it appears we have a lucky coincidence that we both screwed up equally, and I have not actually sent the pull request with your broken patch, since I'm still travelling and forgot to push the tag
08:30arnd: so I'll just include your fix in the pull request I send and it actually stays bisectable
08:30arnd: I could even rebase and fold your fix. There is only one other patch on top of your series in my tree
08:31tzimmermann: ha! escaped linus' wrath by accident :)
08:31tzimmermann: i'll send out something today
08:33arnd: sounds good. I will still be travelling tomorrow but should be able to send the PR in the next few days then
13:13pepp: anyone interested in reviewing libdrm Android patches? https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/361
13:14daniels: pepp: is there a matching patchset for AOSP, or is that all in some downstream tree?
13:15emersion: i'm personally not interested
13:15emersion: (i don't think this is something we should have upstream to be completely honest)
13:17pepp: daniels: I don't know enough about Android to answer your question. I'll ask the author
13:21pinchartl: pepp: how did you solve the issue that the newer android build system can't easily generate source code ?
13:21pinchartl: ah, it's libdrm, not mesa
14:41bl4ckb0ne: is it possible to track the command buffer that triggered a mmu fault via the device irq handler?
14:48lynxeye: bl4ckb0ne: The GPU stops execution once it hits the MMU fault. So the current FE address should point at the right command buffer. The FE might make progress until the next semaphore after the command that triggered the fault.
14:52bl4ckb0ne: so whatever's under VIVS_FE_DMA_ADDRESS should be dumpable
14:52ManMower: lynxeye: in this situation we're using ETNA_MESA_DEBUG=draw_stall, and the mmu fault occurs after the FE has returned to the ring buffer.
14:55lynxeye: do you get a valid looking fault address?
14:55bl4ckb0ne: 0x0
15:00lynxeye: That's odd. The most likely cause for a MMU fault after return to the kernel ring would be data stuck in GPU write caches, that gets flushed out later after the buffer might already be unmapped from the MMU. But in this case one would expect to see some valid address that's inside one of the previously used BOs. 0x0 is certainly not valid...
18:45zamundaaa[m]: There's no mechanism to detect that, is there?
18:47bl4ckb0ne: indeed, i looked at panfrost and lima and beside reporting it there's not much to dump
19:00zamundaaa[m]: bl4ckb0ne: I was referring to ids1024's message . Which might not be getting across to IRC I guess?
19:00bl4ckb0ne: seems so, havent seen any message after lynxeye's
19:03guludo: is this a good channel to discuss an issue with dim?
19:36zamundaaa[m]: ids1024: we could add a Wayland protocol for doing this, kind of like surface roles. It would in principle be a good idea, two drivers controlling a single wl_surface would be terrible
19:38zamundaaa[m]: Then again, I don't think this is something that happens in practice. And if some app tries to, it'll likely get killed by one of the various extensions the driver uses - which do have strict rules for this
20:23jrelvas: Is anyone here a special kind of masochist that understands the `tty`/`fbcon` subsystem? I've honestly been left stumped by this
20:23jrelvas: There's a special workaround for console suspending, where the kernel switches VTs before suspending: https://github.com/torvalds/linux/blob/master/kernel/power/console.c#L46
20:23jrelvas: It's governed by a property, which is true by default: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_fb_helper.c#L532
20:24jrelvas: I've only found a single place where it's set to false... the legacy radeon module, which I don't use. Yet i'm still running into the VT switch
20:24jrelvas: Any idea what's up with that?