00:02airlied[d]: do you use https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_cuda_kernel_launch.html ?
00:15rhed0x[d]: any idea why theres two?
00:20sonicadvance1[d]: NVX -> NV but DLSS hasn't been updated to use the non-X variant?
00:21mhenning[d]: The nvx one is more recent
00:21sonicadvance1[d]: 😮
00:22mhenning[d]: maybe they forgot they have one and added another
00:28cubanismo[d]: No, there was some reason, but it wasn't good enough for me to remember it.
00:29cubanismo[d]: I think the semantics of the first one weren't flexible enough or something.
00:35loothelion[d]: VK_NVX_binary_import predates VK_NV_cuda_kernel_launch
00:35loothelion[d]: There was some interest in expanding upon the functionality provided by binary import, but the desire didn’t pan out.
00:36airlied[d]: guess NVK will want VK_MESA_green_kernel_launch at some point
00:37airlied[d]: since I think there was some deficiences in the cuda kernel launch one
00:46mhenning[d]: loothelion[d]: I'm confused by this. https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NV_cuda_kernel_launch.html shows VK_NV_cuda_kernel_launch as first published in 2020 vs https://registry.khronos.org/vulkan/specs/latest/man/html/VK_NVX_binary_import.html as first published in 2021
00:46steel01[d]: gfxstrand[d]: Alright, I'll take a look again. See if I can figure out how to force the paths to target instead of host.
00:48loothelion[d]: We published the binary import spec/API as part of enabling DLSS in Proton which took place in 2021. The extension was supported by the proprietary driver a couple years prior to that.
00:48mhenning[d]: ah, okay
00:49loothelion[d]: I am less familiar with the timeline for VK_NV_kernel_launch but I know it was based off of binary import but the usecase fell through and we never switched to it for DLSS.
00:53cubanismo[d]: All I remember is it used up a lot of meeting time.
01:18HdkR: NVIDIA: The land of meetings.
01:20airlied: we should discuss that statement in a meeting
01:50steel01[d]: But you first have to have the meeting to schedule the meeting.
01:54orowith2os[d]: is there a meeting to schedule that, though?
01:55steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1427837286359236751/mesa_bindgen_cmd.txt?ex=68f05099&is=68eeff19&hm=7225782251340d0c55258a19a22a3623c06940531ce3c097fc9782cbec1c0ca7&
01:55steel01[d]: gfxstrand[d]: Okay, so I tried adding `--no-include-path-detection` to bindgen_clang_arguments. That puts it in the wrong place, but it did cause the build system to spit out the command its calling. First, holy wall of text, batman... That's over 400 parameters. But second, the log also threw a 'can't find stddef.h' error, which got me looking. Whatever generates the clang include list is adding
01:55steel01[d]: `include/c++/v1`, but not `lib/clang/20/include`, where #include_next is looking. I have no idea what meson is doing where to generate that wall of text.
01:56steel01[d]: The issue might just boil down to one of the -I's being missing.
03:57steel01[d]: steel01[d]: https://gitlab.incom.co/CM-Shield/android_external_mesa3d/-/commit/c85a47404df6237d9a9bb3230cb73f06aa003d7c
03:57steel01[d]: Well, I made it compile at least. Whether it's 'correct' or the simplest solution is up for debate, though.
11:05pac85[d]: misyltoad[d]: This is awesome!
12:15mohamexiety[d]: dakr: sorry for ping but just making sure since git send-email can be weird. did you see/receive this thread? https://lkml.org/lkml/2025/10/10/48
12:16dakr: mohamexiety[d], Yes, I've queued this up for review in the next days.
12:16mohamexiety[d]: got it, thanks!
12:17dakr: If you don't hear anything until the end of the week, kindly give me another ping. I've got a lot on my plate currently, sorry. :/
12:18mohamexiety[d]: nah it's fine, fully understandable. good luck! ❤️
13:24chikuwad[d]: Test case 'dEQP-VK.glsl.atomic_operations.add_f16vec2_compute_shared'..
13:24chikuwad[d]: Pass (Pass)
13:24chikuwad[d]: Test case 'dEQP-VK.glsl.atomic_operations.add_f16vec4_compute_shared'..
13:24chikuwad[d]: Pass (Pass)
13:24chikuwad[d]: 🥳
13:24chikuwad[d]: I did not, in fact, have to just use shared lowering 😅
13:24chikuwad[d]: had to implement f16v2 handling in the existing CAS loop
13:32karolherbst[d]: nice
13:32karolherbst[d]: chikuwad[d]: is that any more than using fadd2?
13:32karolherbst[d]: ohh for vec4s probably not
13:33chikuwad[d]: I'm only handling f16v2, f16v4s get lowered into 2x f16v2 anyway
13:36chikuwad[d]: actually, hm
13:36chikuwad[d]: I think there's a cleaner way to do the same thing
13:37chikuwad[d]: :kawaii180Derp:
13:39chikuwad[d]: yeah there probably is, but I think having f16v2 handled entirely in nir_lower_atomics, i.e. in a common way, is more helpful
13:39chikuwad[d]: but anyway, that's for the reviewer to decide
13:39chikuwad[d]: time to clean up this code, CTS it, and submit the MR
13:42karolherbst[d]: keeping the vec2 around if you aren't doing that already would probably help
13:49chikuwad[d]: wdym
13:52chikuwad[d]: like, keeping the original vec2 intact?
13:52chikuwad[d]: er
13:52chikuwad[d]: how do I phrase this fuck
13:52chikuwad[d]: RIGHT
13:52karolherbst[d]: the atomic should operate on a vec2
13:53chikuwad[d]: yeah
14:00gfxstrand[d]: steel01[d]: Pulled. Trying that now
14:05gfxstrand[d]: Okay, let's see if I can repro that silly FF bug...
14:10gfxstrand[d]: mangodev[d]: do we have an issue open for the firefox flicker. I can't find one.
14:36gfxstrand[d]: Also, I'm not able to repro the YouTube thing on ANV+Zink
15:01gfxstrand[d]: steel01[d]: ```
15:01gfxstrand[d]: FAILED: ninja: 'out/target/product/foster/kernel', needed by 'out/target/product/foster/install/mdarcy.dtb.img', missing and no known
15:02gfxstrand[d]: It doesn't help that gitlab.incom.co is having issues today
15:03chikuwad[d]: repost from Discord channel #lounge: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37888
15:24arnoldramsey: I doubt that anyone fails to boot out jewish camp finally from that channel and from our planet. Technically if my alliance fails, i gonna slaughter a list of evil devil people on my own. But my alliance have not shown signs of failure, hollywood was taken care of, all the most dangerous gangster oligarhs as well as success in a war among the winners side. And for the long thought
15:24arnoldramsey: question's answer asked long from the past , I respond, yes Putin is miracle man, one of the most trusted person leading russia to a better position, He is Human with big titles and Human with capital H. The heartest of the best heart. The humanly resources lost in a war will pave it's way for a batter long term goals for Russia, it was likel worth it. Any real human would dream about
15:24arnoldramsey: getting rid of jewish terror.
15:41jja2000[d]: Oh no, pro-russian anti-semitism
15:43gfxstrand[d]: I just wish he weren't so good at avoiding IRC blocks.
15:43karolherbst[d]: it's almost like any tech that allows you to create infinite accounts is a moderation nightmare 🙃
15:50f_: I remember dealing with that kind of troublemaker before
15:51f_: brought a few bots in and they mostly just gave up
15:51f_: but this one has been spamming for years, so I guess not that easy
15:52gfxstrand[d]: He's really dedicated to talking to Linux graphics people for some reason.
15:52gfxstrand[d]: You'd think there would be easier rooms to spam
16:03jja2000[d]: gfxstrand[d]: And HdkR, don't forget HdkR, who I'm definitely pinging right now
16:04jja2000[d]: I've had some terrible experiences on Matrix with regards to moderation
16:04f_: matrix may be not great for moderation
16:05f_: but at the end of the day you can always bypass bans if you're so motivated like this person
16:08marysaka[d]: misyltoad[d]: to even join I think yeah
16:12gfxstrand[d]: Okay, I've filed an NVK Tegra tracker issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14105
16:12gfxstrand[d]: Anything that doesn't have an MR isn't something I'm actively working on and other people are free to help out.
16:13gfxstrand[d]: Probably the #1 thing to fix next is coherent maps (https://gitlab.freedesktop.org/drm/nouveau/-/issues/452). I've got an easy 100% reproducer case described in the issue.
16:21HdkR: jja2000[d]: What who when?
16:22jja2000[d]: Non-markov man mentioning you by first and last name
16:22HdkR: Oh yea, they like doing that. I'm glad I'm memorable to someone at least.
16:23jja2000[d]: gfxstrand[d]: Thanks! I'll forward this to some tegra focussed people
16:27f_: HdkR: heartwarming, isn't it?
16:33mhenning[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13459
16:36zmike[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37894 maybe related
16:42unlikejackerson: yeah entirely clueless ones you are f_ the same dude who gave me lectures about fpga's as well as his totally miserable understandings about graphics where he knows not register files under uniform/generic shader engines work. Where as this puppet with mental illness does not probably know who are semites. Well in cambodia they tried to kill me more then ten times alone without success
16:42unlikejackerson: or me even saying anything from red hat and jack and they had all scum in the world participating in this, so their funeral is justified, no one has dealt with them anymore, and we slaughter jack, and all this crew, right after thais declared a war to khmers, those who bragged how they eat my muscles in mcdonalds and consume my steroids, are not going to make it ever alive again, and
16:42unlikejackerson: all those devils who started this war were jews like jack, it's some are already killed or reported missing , all my fans i turn into your side with visible satisfaction don't worry i am sharperning a knife only for HdkR and airlied and AaronBallmann and all those jews involved in this terror, we castrate all of them, the war has been already started. It will not take long i promise.
16:43unlikejackerson: so they did not keep to any of the rules of engagement and killed me nearly from behind.
16:56karolherbst[d]: https://github.com/tinygrad/tinygrad/pull/12089 ?!?
16:57steel01[d]: gfxstrand[d]: When you pulled, was that by running 'repo sync'? If so, did you re-run the repopicks in the instructions afterwards?
17:00gfxstrand[d]: No, I didn't
17:00gfxstrand[d]: ugh
17:01steel01[d]: Okay, Mmm. What's your head on the vendor/lineage repo?
17:01steel01[d]: Oh, no on which? 😛
17:18steel01[d]: gfxstrand[d]: Not sure what happened here. Restarted gitlab and stuff is happier now.
17:18gfxstrand[d]: Woo
17:20steel01[d]: But yeah, if you run 'repo sync', it'll reset any non-dirty repos to what the manifest says. Which means all cherry-picks, aka repopicks, go poof.
17:26karolherbst[d]: ~~can somebody fix the build system of the vulkan cts~~
17:27zmike[d]: sounds like user error to me
17:29mhenning[d]: karolherbst[d]: I don't know what issues you're running into, but I managed to fix my issues yesterday by deleting and re-cloning the repo
17:30karolherbst[d]: somehow only parts of it pick up my local vulkan headers and other parts do...... weird things?
17:30mhenning[d]: which is weird because I tried a lot of stuff that should have been equivalent to that
17:30karolherbst[d]: mhenning[d]: mhh maybe I should nuke the entire external directory
17:30mhenning[d]: For me, a `git clean -xdf` followed by a re-download of external wasn't enough to fix it
17:31karolherbst[d]: yeah.. those things are gitignored
17:31karolherbst[d]: anyway, the entire thing is aa mess
17:31karolherbst[d]: okay lol
17:32karolherbst[d]: `rm -rfv external; git checkout external` fixed it
17:33mhenning[d]: okay, I suppose I'll try that next time it's broken
17:46gfxstrand[d]: `python external/fetch_sources.py --clean`
17:46gfxstrand[d]: steel01[d]: ```
17:46gfxstrand[d]: FAILED: out/soong/.intermediates/external/chromium-webview/webview/android_common/signed/webview.apk
17:46gfxstrand[d]: rm -f out/soong/.intermediates/external/chromium-webview/webview/android_common/signed/webview.apk && prebuilts/jdk/jdk21/linux-x86/bi
17:46gfxstrand[d]: n/java -XX:OnError="cat hs_err_pid%p.log" -XX:CICompilerCount=6 -XX:+UseDynamicNumberOfGCThreads -Djava.library.path=$(dirname out/hos
17:46gfxstrand[d]: t/linux-x86/lib64/libconscrypt_openjdk_jni.so) -jar out/host/linux-x86/framework/signapk.jar build/make/target/product/security/testk
17:46gfxstrand[d]: ey.x509.pem build/make/target/product/security/testkey.pk8 out/soong/.intermediates/external/chromium-webview/webview/android_common/d
17:46gfxstrand[d]: ex-uncompressed/webview.apk out/soong/.intermediates/external/chromium-webview/webview/android_common/signed/webview.apk
17:46gfxstrand[d]: java.util.zip.ZipException: zip END header not found
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1649)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1495)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:724)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:251)
17:46gfxstrand[d]: at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:180)
17:46gfxstrand[d]: at java.base/java.util.jar.JarFile.<init>(JarFile.java:345)
17:46gfxstrand[d]: at java.base/java.util.jar.JarFile.<init>(JarFile.java:316)
17:46gfxstrand[d]: at java.base/java.util.jar.JarFile.<init>(JarFile.java:296)
17:46gfxstrand[d]: at com.android.signapk.SignApk.main(SignApk.java:1230)
17:47mhenning[d]: gfxstrand[d]: ah, here I was assuming that the script was supposed to do that by default
17:47steel01[d]: 0o I don't know what that script is. What are you trying to do?
17:48steel01[d]: Oh, that's not part of the quote, nm.
17:48gfxstrand[d]: mhenning[d]: Nah. By default it just tries to pull. That one trashes everything and then you can run without `--clean` to pull again.
17:49gfxstrand[d]: But it's slightly nicer than deleting and checking out the folder.
17:49steel01[d]: gfxstrand[d]: I know what that is. The --git-lfs param was missing from the init command. Did I forget to put that in there?
17:49karolherbst[d]: gfxstrand[d]: ohhh.. there is a --clean flag...
17:50steel01[d]: steel01[d]: I did. Blast. Gimme a sec, I'll dig up the command to fix it on an existing tree.
17:53steel01[d]: steel01[d]: ```
17:53steel01[d]: repo init --git-lfs
17:53steel01[d]: rm -rf external/chromium-webview/prebuilt/*
17:53steel01[d]: rm -rf .repo/projects/external/chromium-webview/prebuilt/*.git
17:53steel01[d]: rm -rf .repo/project-objects/LineageOS/android_external_chromium-webview_prebuilt_*.git
17:53steel01[d]: repo sync -j5
17:53steel01[d]: And you'll have to redo the repopicks again. Sorry for missing that in the instructions.
17:54gfxstrand[d]: No worries
18:08orowith2os[d]: gfxstrand[d]: has it been considered to test Tegra with a 64-bit x86 userspace?
18:09orowith2os[d]: It should be fairly easy to set up either with Flatpak (I can help get the CTS into there if need be) or distrobox.
18:09orowith2os[d]: (unsure on distrobox; but any container software in general should work)
18:11gfxstrand[d]: No but it should work
18:12gfxstrand[d]: Well, maybe
18:12gfxstrand[d]: I have no idea how much hell that's going to make for cache flushing. 😅
18:13orowith2os[d]: I subscribed to the main tracker issue, I'll keep an eye on for if anybody explicitly mentions my Shield model. I'll set up testing there once it's working well enough to get a TTY.
18:14orowith2os[d]: It's something that should be tested, since you can expect ARM desktops to make use of an x86 userspace.
18:14orowith2os[d]: I've also tested an ARM userspace on my x86 laptop.
18:14orowith2os[d]: granted, the latter case was with AMD.
18:28gfxstrand[d]: steel01[d]: Okay, built and flashed. Now hoping it boots
18:29steel01[d]: *fingers crossed*
18:34gfxstrand[d]: Second try I have spinny circles
18:36gfxstrand[d]: It's stuck in a boot loop but graphics does come up sometimes
18:38steel01[d]: Mmm. There's probably something in the uart logs. Can you save off like 30 seconds of that log? I can probably pick out the issue from that.
19:05gfxstrand[d]: Do we have a decoder ring for chipset numbers?
20:33airlied[d]: I think I gave the tinygrad folks the ideas about 6 months ago, good to see they followed through
20:33karolherbst[d]: though the way they integrated it is a bit cursed tbh 🙃
20:41vijayminsing: Semites are much larger group of inhabitants than only jewish, it was just that all most rather than all caught doing tyranny documented where orchestrated by jews and i have the accounts intercepted where the traffic was signed by my identity through fraud, which i of course had never signed , so where the estonians swedish and finnish people and estonians came into that fraud what my dad
20:41vijayminsing: and their jewish friends orchestrated? I told you that in sweden i suffered the first superimmunity milkout during sepsis which i resisted for too long refusing to die, and in finland dr Pasanen was rude enough to harvest my muscle in the clinic at my own sight from camera, this is why i call those butchers, it's some type of jewish tradition overall gannibalism and protein folding leaving
20:41vijayminsing: the donor to death. Jewish are monsters, they care nothing if it was a son , friend or anything other, they just betray 666, soon russia declares war to all of those countries altogether, we all know that, by that time we start to knock all from your scammers out, when my dad is dead finally with their fraudgroup. Half of estoni is being feed with my resources, and dad buys everything
20:41vijayminsing: using my money tbh, and he buys out all my friends one after another to commit their fraud, half a million estonians who are devils are involved in that , but we just kill some number of the most horrible monsters from those countries, and then we handle all of you too.
20:46gfxstrand[d]: steel01[d]: I'm writing a nouveau minigbm backend. (I'm almost done, actually.) How do I tell Android to build it?
20:49steel01[d]: gfxstrand[d]: Wow, that was fast. Actually nouveau specific or could work with tegra-drm? For example, to use on xavier with swiftshader where nouveau support doesn't exist?
20:49steel01[d]: I'll go find a link to a simple .bp to use for reference.
20:49gfxstrand[d]: nouveau-specific
20:50gfxstrand[d]: But someone could copy+paste for tegra, probably
20:50gfxstrand[d]: But everything is still building and I know it shouldn't still build so clearly I'm doing something wrong. 😂
20:52steel01[d]: Oh, you've already got the makefile stuff in place? Then you just need to add the name to PRODUCT_PACKAGES somewhere.
20:52gfxstrand[d]: I'm just hacking inside external/minigbm
20:52gfxstrand[d]: But it's currently configured for generic
20:53steel01[d]: Oh. Right, that's a bit of new-ish magic.
20:53steel01[d]: You just need to set the backend to 'nouveau', then?
20:53gfxstrand[d]: I just need to know where the magic is. 😭 😂
20:54gfxstrand[d]:is not an Android OEM engineer
20:54steel01[d]: There's a bit of additional modularization that we're doing on lineage too.
20:55steel01[d]: Okay, so you want to build minigbm and you've add a nouveau backend, yes?
20:55gfxstrand[d]: y
20:55gfxstrand[d]: And I need to set `minigbm.platform=nouveau`
20:58steel01[d]: https://gitlab.incom.co/CM-Shield/android_device_nvidia_tegra-common/-/blob/lineage-23.0/tegra.mk?ref_type=heads#L40
20:58steel01[d]: Okay, so in device/nvidia/tegra-common/tegra.mk, somewhere inside this block, add the lines:
20:58steel01[d]: TARGET_GRAPHICS_ALLOCATOR_HAL ?= minigbm
20:58steel01[d]: TARGET_MINIGBM_PLATFORM ?= nouveau
21:00steel01[d]: Ugh, trying to parse some of this still.
21:00steel01[d]: Then build `android.hardware.graphics.allocator@4.0-service.minigbm_nouveau`, I think.
21:00steel01[d]: Or `gralloc.minigbm_nouveau` if you touched the pre-hidl stuff.
21:01steel01[d]: Alternatively, throw the patch up somewhere and I'll figure out the build system plumbing.
21:01gfxstrand[d]: https://gitlab.freedesktop.org/gfxstrand/minigbm
21:02gfxstrand[d]: It doesn't build yet
21:03steel01[d]: Mmm, okay. Based on that, I think you can just `m gralloc.minigbm_nouveau` without changing any other configs for now. To just build that one piece.
21:04steel01[d]: And once that builds, then we can figure out how to apply that to the newer hidl and aidl stuff that's needed on current android versions. And after that, I'll plumb it to build by default.
21:05gfxstrand[d]: yay! Build errors!
21:16steel01[d]: steel01[d]: Looking a bit further, I *think* this is all that's needed to package the appropriate stuff into a build. You'll probably want to run `m android.hardware.graphics.allocator-service.minigbm` after setting those flags, though. To see if any errors pop up for that variant.
22:32gfxstrand[d]: Well, it built
22:32gfxstrand[d]: Let's flash an image and watch it explode. 😄
22:34steel01[d]: Switching gralloc like that, you probably want to at least run `m installclean` then do another build. To make sure the last gralloc and related configs get cleaned out.
22:35steel01[d]: I tend to be full paranoid, my build scripts do a full clean before every build. Cause I've had far too many weird leftover things from dirty builds. But I've also got ccache enabled and a build machine built specifically for aosp builds. And it still takes about an hour to do a build. >< Ugh. I want my 11 minute clean builds back from the N era...
22:37gfxstrand[d]: It's failing to tar something
22:37steel01[d]: Ah meh. I really need to fix that. I keep forgetting cause I never do dirty builds.
22:39steel01[d]: `rm -f out/target/product/foster/obj/ETC/*_flash_package_intermediates/*_flash_package.txz;` I think that's the right path.
22:40gfxstrand[d]: This is gonna blow up so spectacularly...
22:40steel01[d]: I've got a tar -cJf that globs the entire directory. Including the output of that command.
22:40gfxstrand[d]: How do I boot into Android recovery without re-flashing the TX1?
22:41steel01[d]: If you've got uart console access, then 'reboot recovery'.
22:41gfxstrand[d]: I've got a UART. It's just log spam, though.
22:41steel01[d]: I think there's a button combo that works too. If I could remember which one that was.
22:41gfxstrand[d]: I should also have adb
22:42steel01[d]: It won't be on by default without extra hacks in the build tree.
22:43steel01[d]: I *think* rebooting while holding the vol down button on the board should stop at the bootloader menu.
22:43steel01[d]: There should be three buttons. Power, vol down, and force recovery.
22:43steel01[d]: Oh, and reset.
22:44steel01[d]: It's been a while since I've physically poked button. I've got a ftdi thing plugged up to automate power control.
22:45steel01[d]: And flashing the board takes like 20 seconds, so I'm not so worried about time on my end. Now for the t194+ stuff with qspi that takes 10 minutes to flash... ><
22:48gfxstrand[d]: ADB said it didn't send any data
22:48steel01[d]: In what context?
22:49gfxstrand[d]: adb sideload lineage-23.0-20251015-UNOFFICIAL-foster.zip
22:49gfxstrand[d]: Total xfer: 0.00x
22:49gfxstrand[d]: Is there some sort of version check that's screwing with me?
22:49steel01[d]: There should be something on the screen to explain why.
22:50gfxstrand[d]: I just factory reset and am sideloading again
22:51steel01[d]: That's probably the current answer. I'm guessing it saw some incompatibility on data, like ASB version, and bailed. But given that the last build was from the same tree... Weird.
22:51gfxstrand[d]: Okay. Moment of truth.
22:53gfxstrand[d]: Are we using the tegra module for display?
22:54steel01[d]: What do you mean? Tegra is a mix. Display out is via tegra-drm, nouveau does off-screen rendering.
22:55gfxstrand[d]: I'm wondering if tegra-drm supports modifiers
22:55steel01[d]: I've got no idea. Most of this graphics stuff is greek to me.
22:55mohamexiety[d]: worst case you get wrong tiling, what could go wrong!
22:56steel01[d]: I've got a great picture of that somewhere. My attempt at fixing up the old chromeos tiling gbm driver.
22:56mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1428154664788164668/image.png?ex=68f1782d&is=68f026ad&hm=4b90e421e252e7916039e88b8414130efeefc2b49a9b99be80de4e7df7871229&
22:56mohamexiety[d]: my masterpiece is this so far. pic taken by marysaka[d]
22:57steel01[d]: It was a giant stairstep. Likely meaning the stride got screwed somewhere.
22:57mohamexiety[d]: yeah
22:59gfxstrand[d]: Okay, I need to call it a day and go home. I think something is going wrong with opening the DRM file
23:00steel01[d]: property_set("ro.secure", "0");
23:00steel01[d]: property_set("ro.adb.secure", "0");
23:00steel01[d]: https://github.com/LineageOS/android_device_nvidia_tegra-common/blob/lineage-23.0/init/init_tegra.cpp#L226
23:00steel01[d]: Since this is kinda relevant now. If you want adb on by default, tack the quote to the end of the function in the link. in device/nvidia/tegra-common. That'll turn adb on by default in insecure mode.
23:01steel01[d]: I've got a couple other hacks running around to run the uart console as root and all. But if it gets far enough to where adb can run, then this is probably sufficient.
23:03mhenning[d]: gfxstrand[d]: iirc it does, but don't quote me on that
23:04gfxstrand[d]: 722.903543][ T252] type=1400 audit(722.283:76997): avc: denied { open } for comm="surfaceflinger" path="/dev/__properties__/u:object_r:vendor_default_prop:s0" dev="tmpfs" ino=360 scontext=u:r:surfaceflinger:s0 tcontext=u:object1
23:04gfxstrand[d]: [ 722.928528][ T252] type=1400 audit(722.283:76998): avc: denied { getattr } for comm="surfaceflinger" path="/dev/__properties__/u:object_r:vendor_default_prop:s0" dev="tmpfs" ino=360 scontext=u:r:surfaceflinger:s0 tcontext=u:obj1
23:04gfxstrand[d]: [ 722.953753][ T252] type=1400 audit(722.283:76999): avc: denied { map } for comm="surfaceflinger" path="/dev/__properties__/u:object_r:vendor_default_prop:s0" dev="tmpfs" ino=360 scontext=u:r:surfacef
23:05gfxstrand[d]: That seems bad
23:17jja2000[d]: mohamexiety[d]: "Yeah let me run CTS real quick, it'll be fine"
23:22mohamexiety[d]: oh huh the 25.3 branch point changed. I thought it was the 31st
23:22mohamexiety[d]: jja2000[d]: it did run
23:22mohamexiety[d]: which was funny actually :KEKW:
23:23jja2000[d]: Only 36 fails!
23:35steel01[d]: gfxstrand[d]: One of the repopicks, specifically the one with the -f, sets selinux to permissive. Cause... Yeah, policy is very much not up to snuff.
23:35steel01[d]: Those lines should have a permissive=1 at the end of each line, though. Not seeing that makes me wonder if that pick applied.
23:36gfxstrand[d]: Okay. So unless I missed that I should be fine
23:36steel01[d]: Those lines look cut off, though. Those aren't valid contexts.
23:36gfxstrand[d]: They got cut off because they're long and it wasn't wrapping.