10:38tzimmermann: javierm, thanks for taking the time to review the patches
10:38javierm: tzimmermann: you are welcome
10:38tzimmermann: i know you usually do that on fridays :)
10:39javierm: yes :) but I still have too much pending email after being out on vacation, so I'm catching up
10:43tzimmermann: :)
10:52bluetail: Hello. I am having an issue where mouse is still able to wake the system despite it being disable from BIOS side. I think it's because of Sep 18 04:30:11 mainrig-MS-7E49 kernel: nvme 0000:04:00.0: platform quirk: setting simple suspend. I tried some kernel arguments but with no luck - just to get a full suspend working.
10:52bluetail: full excerpt https://0x0.st/KTPE.txt
10:53bluetail: my peripherals are on a hub. When I check the reason for wake it would say "Other"
10:54bluetail: generally the suspend does work. But we never get to the point where blacklisting the mouse works, or the hub during suspend. It will always be the mouse. I disabled devices for wake manually but no luck. I am on 6.16.7-arch1-1.1
10:56bluetail: The nvmes are Lexar NM790 NVME ssds - relatively new with NVME 2.0 support.
11:01bluetail: I'll better put it on bugzilla/tracker
11:09bluetail: there... Sorry for the noise. https://bugzilla.kernel.org/show_bug.cgi?id=220585
13:56rodrigovivi: airlied sima: do you have the drm-intel-next pr from drm-intel-next-2025-09-12 in your inboxes? I have it in mine, but I cannot see in lore nor in any mailing list... I tried to bounce and forward and I still can't see that there... but at least the drm-xe-fixes seems to have worked...
13:57rodrigovivi: but well, drm-xe-fixes working only making it more misterious, because it is the same process and same machine and servers, etc... :/
14:35sima: rodrigovivi, yeah it's here in my inbox, but yeah can't find it in lore either
14:35sima: strange ...
14:36sima: did get all 3 of your mails, but nothing seems to have reached lore
14:37sima: rodrigovivi, might be too big? the diffstat looks hilarious, you might want to regen it now that -rc6 is backmerged
14:37sima: unless there's another reason it's so big?
14:41sima: rodrigovivi, if you cant massage the diffstat into something reasonable just resend without that and add a note why you deleted it
14:41sima: so airlied or I can double-check wtf git is up to again, but yeah I vaguely remember that sometimes git gets confused and generates nonsense diffstats in a pr
16:17rodrigovivi: sima wow! that was really long indeed... perhaps I miss-type the baseline... 'since commit 70a9b201cfa893fd0b7125c8f9205d9e12e02ba5' seems pretty weird as well...
16:22sima: rodrigovivi, ah I didn't look into why it happened
16:22rodrigovivi: $ dim pull-request drm-intel-next drm/drm-next drm-intel-next-2025-09-12 generates the same bad output :/
16:23rodrigovivi: I wonder if my backmerge in the middle there messed things up
16:23rodrigovivi: a tig drm/drm-next..drm-intel-next-2025-09-12 seems sane though
16:23rodrigovivi: I'm totally lost now
16:55rodrigovivi: sima it is that backmerge that is making the git totally crazy there... I'm doing another backmerge and then another pull with new tag... that seems to work from my experiments here... just finishing some tests
16:56sima: rodrigovivi, yeah git gets confused
16:56sima: what I've done in the past is do a merge on top of drm-next and then diff against the parent of that merge
16:56sima: that shows you what actually gets merged in, and not git somehow counting commits again that are already there
16:58sima: doing a new backmerge just to finagle git into submission feels a bit too silly
16:58sima: also with the reasonable diff you can just rebounce the old pr and airlied can pick it up (since I'm on a hike tomorrow it's probably not me)
17:31rodrigovivi: sima: that indeed gives a reasonable diff, but the problem is how to format this in a way that dim can pick that up... because the head of that is not pushed... so the pull request line gets messed up
17:45sima: rodrigovivi, I've just done that on a separate branch, saved the resulting diff and then hand-edit the email
17:45sima: the few times it was needed
18:40alyssa: I'm going to regret asking this but
18:40alyssa: why do we have opcodes like b2f at all?
18:49karolherbst: could be for hw not supporting ints
18:50jenatali: But it's just a bcsel
18:51karolherbst: what if all you got are floats
18:51alyssa: it's still just a bcsel
18:52karolherbst: well fcsel then
18:54glehmann: they are useful for algebraic opts because we don't have to both a ? 0 : 1.0 and a ? 1.0 : 0 everywhere
18:54karolherbst: anyway, don't know for sure, but I can imagine that drivers with only float support kinda need it for weird reasons
18:54alyssa: glehmann: hmm, that's fair
19:06rodrigovivi: sima: it worked out, thank you so much and enjoy your hike tomorrow
19:06rodrigovivi: airlied: it is okay now: https://lore.kernel.org/dri-devel/aMxX_lBxm7wd5wmi@intel.com/T/#u
19:14sima: rodrigovivi, yay :-)
20:01airlied: rodrigovivi: cool, it it doesn't hit lore I won't see it btw
21:57karolherbst: I hope our Intel folks are alright..
22:41idr: karolherbst: Have we ever been alright?!?
22:41karolherbst: good question
22:53Kayden: gfxstrand: FWIW nir_def_all_uses_are_fsat is kinda broken. it checks nir_src_is_if(src) but it's using nir_foreach_use(src) which guarantees that it *isn't* an if. so you either have 2 dead lines of code or you want to be using nir_foreach_use_including_if
22:53Kayden: I assume the latter, since an if-use isn't an fsat
22:53Kayden: pretty sure nak is the only user of this
22:56Kayden: karolherbst: we're still here! thanks for thinking of us. always perennial sanity hits and uncertainty. but we're here for now and hope to continue to be around..
22:57zmike: 🙏
23:00karolherbst: glad to hear!