TLDR; more things working. More confidence of this being a permanent go-forward solution.

USB-C 2nd port now working

Both USB-C ports are working now, and also with hubs (both USB3 and USB2 hubs) with devices off of them. I wish I could say it was up to my diligent work, but what seemed to do the trick was just a reboot. I’ve rebooted multiple times since that one time for other reasons and both USB-C ports continue to work. My USB-C (USB3) gigabit NIC is also consistently working, which is great.

Display

Still with my old DL-165 based Displaylink adapter, I’ve revered back to the default resolution of 1680x1050 at 60Hz. At the display adapters limit of 1920x1080 the desktop stitching seems to be unreliable where there will be overlap between the left and right displays by about 30 pixels. Additionally video performance is noticeably impacted for full motion video at the max res. The overlap is likely fixable, but I’m just going to source a modern Displaylink adapter instead of trying to get this one from 2009 working solid on a machine from 2022. The current config is still sufficient with the old adapter for my needs right now.

I’ve also dug quite a bit more into Displaylink technology in general to understand what is going on under the hood. It can be very CPU and RAM hungry. At one point I had a kworker thread taking 48% of the total system CPU and as soon as I unplugged the Displaylink adapter that thread disappeared. I’m also seeing much of the 24GB of RAM in this laptop being used by something and I suspect a its also Displaylink. I don’t know if its because of this old model, or if all Displaylink adapters would have equal resource consumption on the host system.

I want to figure out how to see how much of the shared memory is being consumed for the integrated graphics, and for the Displaylink frame buffer but having found a measurement point for either yet.

Power Management

I’ve done some work with ACPI and power configuration on x86 systems and assumed much would be the same. That was NOT a good assumption. At least Mac silicon doesn’t use anything like BIOS, EUFI, or ACPI. Instead it uses a Device Tree initialization which is something I’ll have to do a lot of reading on. Further, I’ve read some of the documentation from the m1n1 developers regarding the SMC where I’m guessing all of the power management sensors, data, and many of the controls reside to improve the power management of the hardware under Linux. The 1400 different values, with many being read/payload returns show me that the folks working on this have already done a HUGE amount of work, and there is still so much left to uncover with no documentation from Apple.

General

I’m doing more tweaks to the desktop environment. Learning the keyboard shortcuts, and uncovering small nice features (like “limit battery charging to X%”). I now have the unit only charge to 80% before stopping to save wear and tear on the battery from deep cycling.

The unit is plenty fast for my need and I have room to grow in it. My thanks again to the Asahi developers both past and present as well as the Fedora Remix maintainers!