00:38 <jannau> marcan: just updated https://github.com/jannau/linux/tree/dev/spi-hid-apple

00:39 <jannau> hid-appleft is no more, suppport is integrated in hid-magicmouse

00:42 <jannau> extended report mode is only switched on by request from hid-magicmouse, I added resolution for X and Y based on the j314 trackpad, no idea if the other ones have other dimensions

00:43 <jannau> fixed all report from kernel test robot

02:13 <chadmed> does the ANS driver depend on ARCH_APPLE to be built? i want to test it on my A1708 since im pretty sure its the same nvme controller

02:28 <chadmed> oh its not a platform device on the intel macs anyway rip

04:19 <marcan> chadmed: NVMe support for intel macs has been in mainline for years now

04:19 <marcan> (the quirks they need that is)

04:50 <marcan> jannau: awesome, I'll test it in a bit!

06:08 <chadmed> theres still a bug on the A1708 (and others i believe) where if you let the machine suspend you lose disk access on wake and everything breaks. something to do with d3cold/controller power management

08:03 <j`ey> jannau: awesome

09:24 <kettenis> jannau: the j314 touchpad coordinates seem to roughly match the j293 values I'm seeing

09:30 <kettenis> also, I'm seeing a "read" packet for "device" 0 with "type" 0xe010 and I'm wondering if that provides some sort of identification of the device

09:47 <jannau> kettenis: I see that as well. message payload "e0 10 00 00 00". which doubles the type (ignoring endianess)

09:48 <jannau> touchpad coordinates are rounded away from zero to the next multiple of 100, I should have added the measured values as comment

09:50 <jannau> the first thing I receive is a packet with payload "a0 80 00 00" i.e. too short for the message header

10:13 <kettenis> jannau: I see that one too

11:03 <kettenis> jannau, the ioreg output that marcan pasted at some point has a VendorID and ProductID for the keyboard/touchpad

11:04 <kettenis> "VendorID" = 1452

11:04 <kettenis> "ProductID" = 641

11:04 <kettenis> so it might make sense to use these in the driver

11:11 <kettenis> my j293 with ISO keyboard layout has "ProductID" = 833

11:12 <_jannau_> vendor id is Apple's USB vender id

11:13 <_jannau_> product id's are not yet in linux' hid-ids.h

11:22 <sven> chadmed: the Intel Macs use a related nvme chip running in a different mode fwiw

11:42 <povik> here j314 (14' mbp) with "ProductID" = 834

11:42 <Jamie[m]1> unless I'm being obtuse, the m3 mailbox interface in AVD seems different to the m3 mailbox interface in the kernel

11:46 <kettenis> povik, what keyboard layout is that?

11:48 <povik> i don't know, let's see

11:50 <povik> it's czech localization, don't know if that's ISO or not

11:51 <povik> apple support says i have ISO keyboard

11:51 <povik> https://support.apple.com/en-us/HT201794

12:06 <sven> Jamie[m]1: the m3 mailbox in the kernel is used for the thunderbolt ("CIO") co-processors

12:06 <sven> AVD is probably yet another thing. afaik it also doesn't run rtkit

12:10 <jannau> j314 with iso international has "ProductID" = 834. let's hope there is a way to read the ID's over HID

12:10 <jannau> ioreg output looks like could be possible

12:50 <kettenis> so it seems that apple no longer uses separate product IDs for the ANIS, ISO and JIS keyboard layouts

12:59 <kettenis> s/ANIS/ANSI/

13:00 <ChaosPrincess> can someone help out, i am trying to update a version of m1n1 that is on the apfs volume, but kmutil configure-boot fails with error 'Invalid Mach-O boot properties'

13:03 <_jannau_> ChaosPrincess: check if the m1n1 apfs volume is the actiive startup disk. that's a requirement with macos 12.0 1tr. please continue in #asahi

16:09 <marcan> Jamie[m]1: AVD does not use the m3 mailbox

16:09 <marcan> AVD is just a random hardware block that happens to include a random cortex-m3 that doesn't run RTKit

16:09 <marcan> it is unrelated to anything else

16:10 <marcan> there will be no shared code for it or mailbox driver or anything; it'll talk directly to the hardware

16:11 <ChaosPrincess> what is avd used for?

16:11 <marcan> video decoder

16:12 <dottedmag> ChaosPrincess: FYI useful https://github.com/AsahiLinux/docs/wiki/Accelerator-Engines

18:45 <kettenis> jannau: I added a few comments to https://github.com/jannau/linux/commit/fbf88bb759ce071797c394d8ef4deb11cae5f811

21:10 <tpw_rules> so i am working on a boot flow using https://github.com/kettenis/u-boot/tree/apple-m1-m1n1-nvme/ and the latest linux-asahi kernel as of today. it seems there's an issue where if u-boot starts the nvme by running "nvme scan", the kernel fails to start it and prints "apple-ans-nvme 27bcc0000.nvme: RTKit did not boot". but if i stop u-boot from running that command, the kernel can start the nvme fine and everything works

21:12 <tpw_rules> in both cases i'm booting off a usb disk. i'm not sure if u-boot should be de-initializing something before it starts up the kernel, or the kernel needs better handling of an nvme that's already been initialized. cc: kettenis sven

21:12 <tpw_rules> (to be clear, this is not a new problem caused by recent changes AFAICT. i don't know of a setup that works)

21:15 <sven> yeah, that's known

21:15 <sven> u-boot will eventually need to shutdown the co-processor before handing control over to linux

21:16 <sven> but i think openbsd currently required the co-proc to be already running

21:16 <sven> this is all still very much WIP :-)

21:16 <tpw_rules> is that something u-boot currently doesn't do, or do we not know how to shut it down?

21:16 <sven> uboot just doesn't do it because of this: <sven> but i think openbsd currently required the co-proc to be already running

21:16 <tpw_rules> if you can point me to code that shuts it down, i can probably figure out a patch for my setup

21:17 <sven> https://github.com/AsahiLinux/linux/commit/fd7c0ced9b5e58028c66dde6cb54fa61a19283b9#diff-cb11dae936ab8f8986253db1c60a7cb944b799597d84ba2dbe3f605b604af589R762

21:17 <tpw_rules> on the other hand, it feels like the kernel should be able to either use it if it's already started, or reset it

21:17 <sven> no

21:17 <sven> or, well, unless we find way to actually reset the processor

21:18 <tpw_rules> ok so that's not possible for what we can call hardware limitations

21:18 <sven> yup

21:18 <tpw_rules> just to be sure, the function apple_rtkit_shutdown is defined in a different commit?

21:18 <sven> what do you mean defined?

21:19 <sven> this is no the nvme driver that's in the asahi branch fwiw

21:19 <tpw_rules> i mean i only see its prototype and not a definition

21:19 <sven> uh

21:19 <sven> click the link again?

21:19 <sven> it should take you to the function

21:19 <tpw_rules> it doesn't take me anywhere in particular

21:20 <sven> it's in that commit

21:20 <sven> in rtkit.c

21:20 <sven> line 762

21:20 <tpw_rules> ah, it's behind the "large diffs are not rendered by default" banner

21:20 <tpw_rules> i see it now. cool, thank you!

21:23 <sven> ah, so the link doesn't work unless you already clicked on show more once. annoying :/