X-Git-Url: http://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/blobdiff_plain/e5f68c5091171ee16a6b6bb12a8b63d67fb907ea..8b9cfcd516507d510eaa4df00cad54a4ba099e73:/doc/notes.txt?ds=sidebyside diff --git a/doc/notes.txt b/doc/notes.txt index 0e8bec1..84e2278 100644 --- a/doc/notes.txt +++ b/doc/notes.txt @@ -21,6 +21,7 @@ Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIP 15:26 < tpw_rules> Glanzmann: https://pastebin.com/NzJEQJDW - https://tg.st/u/NzJEQJDW 15:26 < tpw_rules> last i checked the built chromium only worked with the flags --in-process-gpu --no-sandbox --no-zygote but that may have been a kernel config problem Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564 +16:21 < tpw_rules> https://bugs.chromium.org/p/chromium/issues/detail?id=1301788 22:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux @@ -191,6 +192,8 @@ exec /bin/bash 21:56 < povik> that mode of playing in parallel through the speakers and jack has a defect 21:57 < povik> there's noise mixed-in then, at a period 21:57 < povik> don't know how that happens yet +When disabling the speakers, run rm -rf ~/.config/pulse/ and reboot otherwise the jack will be in the future off or 100% (which is too loud). + If you see this in Xorg.0.log, it means that simpledrm has not initialized. ... @@ -258,5 +261,266 @@ blkid curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin +grub-install --removable /boot/efi + exit, umounted everything and rebooted. ------------------------------------------------------------------------------------------------------------- +12:41 < chadmed> https://gist.github.com/chadmed/2c772c8fdac8280cb17846388203a213 <- some notes on the speaker system in the j314s, and an asound.conf that makes them sound... okay-ish for now + +## BEGIN NOTES ## + +# HOUSEKEEPING +# All testing conducted with channels set to 40% in alsamixer, +# with no amp gain. + +# Do NOT try to play sound with the speakers set to 100% in alsamixer, +# you will fry the cones! + +# DRIVER MAPPINGS/ALSA QUIRKS +# The speaker array as set up by the ASoC driver maps like +# this on a J314s: +# 0: Left Woofer 1 +# 1: Right Woofer 1 +# 2: Left Tweeter +# 3: Right Tweeter +# 4: Left (Sub)Woofer 2 +# 5: Right (Sub)Woofer 2 + +# ALSA sets up the speaker array on the J314s as a 4.0 surround system, +# with the RL and RR channels duplicated across the woofers like this: +# 2: Front Left +# 3: Front Right +# 0: Rear Left +# 1: Rear Right +# 4: Rear Left +# 5: Rear Right + +# Obviously this is not correct, but for us it does not matter, since +# we can just tell ALSA to route FL and FR to all drivers, presenting +# it to the rest of userspace as a stereo device. Surround sources +# are downmixed appropriately. + +# SOUND CHECK +# Testing reveals that drivers 4 and 5 are likely +# only there to help with bass and sub bass. They +# are extremely bad at reproducing frequencies above +# ~500Hz, and even with the help of the tweeters sound +# rough/deep fried in the mids. Drivers 0 and 1 are obviously +# intended to be the main woofers in the array. + +# If we weren't intending to mimic whatever macOS does, my ear-only +# testing would have me setting up a xover network like this: + +# Freq Range (Hz) | Drivers +# 0-300 | 0 1 4 5 +# 300-6500 | 0 1 +# 6500-20000 | 2 3 + +# Figures based on typical {LP,BP,HP}F rolloff characteristics. + +# Using all 4 woofers below 300Hz moves more air than just using the +# (sub)woofers alone. 3-way loudspeakers work like this conventionally. + +# The ttable in the j314s-array pcm device tries to compensate for the lack of +# EQ right now by greatly reducing the volume of 4 and 5, and slightly reducing +# the volume of 0 and 1 relative to 2 and 3. I have found this gives an acceptably +# clear sound without being too bright or losing too much out of the mids. Bass is +# nonexistent, though I suspect this is just because we have not applied appropriate +# correction to overcome the machine's housing yet. I will not be applying EQ or filtering +# in ALSA using plugins even in the interim because +# a) it's deprecated +# b) it introduces overhead and chews up CPU time + +# FIRs can be applied to a 6 channel slave PCM which would then feed the routing table +# PCM configured below with all coefficients set to 1 + +## END NOTES ## + +# Create a six channel slave for the audio array +pcm_slave.outputs { + pcm "hw:0,0" + channels 6 +} + + +# We need to map L and R to the correct drivers. We can use +# the coefficients in ttable to roughly tune the sound profile. +pcm.j314s-array { + type route + slave outputs + ttable { + 0.0 = 0.65 + 0.2 = 1 + 0.4 = 0.3 + 1.1 = 0.65 + 1.3 = 1 + 1.5 = 0.3 + } +} + + +# Set up a plug and ctl interface for ALSA defaults +# XXX: Does not work for PipeWire, but does work for JACK +# and PulseAudio +pcm.!default { + type plug + slave.pcm j314s-array +} + +ctl.!default { + type hw + card 0 +} +------------------------------------------------------------------------------------------------- + +# Control what happens after power loss +/sys/devices/platform/soc/23e400000.smc/macsmc-reboot/ac_power_mode + +16k bugs +======== +17:02 < kov> Glanzmann, https://bugs.webkit.org/show_bug.cgi?id=236564 +17:02 < kov> Glanzmann, that is already on the 2.34.6 stable release +17:03 < kov> the gnome one was unrelated and is from a bunch of months ago, I have not seen any crashes in my testing with debian's gnome so I assume the fix is + already in +17:04 < kov> it's this one https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/be8a1dcbfc7edf19ef13a63ddf034dba814ee000 + +17:49 < j`ey> marcan: I learnt a new git command just now: git range-diff asahi/asahi-soc/prev..asahi asahi/asahi-soc/next..asahi/asahi good way to compare the + new/old branches even after a rebase +17:49 < j`ey> (where 'asahi' is my local not-yet-updated branch) + +21:44 < kov> Glanzmann, trying to use the debian installer from your artefacts and getting a blank screen after the boot, any thoughts? (the consoles on tty2 etc come up) +21:55 < kov> Glanzmann, hrm adding vga=normal fb=false to the kernel cmdline made it work + +07:19 < chadmed> Glanzmann: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2210 +07:47 < chadmed> pushed some changes to asahi-audio, should sound better than it did before now. FIRs are also installed to the directory i proposed in the feature request + +15:49 < j`ey> https://github.com/AsahiLinux/asahi-installer/blob/main/src/osinstall.py#L141 +15:49 < j`ey> cat m1n1.bin <(echo 'chainload=$ESP_UUID;$BOOT_OBJ_PATH') > blah.bin + +16:43 < povik> marcan: two fixes on top of 'asahi' that should make it into the release: https://github.com/povik/linux/commits/asahi-fixes + +# boot into 1tr +diskutil list +diskutil info +curl -sLo tg.st/u/m1n1-rust.bin +cat m1n1-rust.bin <(echo 'chainload=;m1n1/boot.bin') <(echo 'chosen.asahi,efi-system-partition=') > object.bin +kmutil configure-boot -c object.bin --raw --entry-point 2048 --lowest-virtual-address 0 -v /Volumes/Linux + +20:29 < Glanzmann> One question though what is difference between chosen.asahi,efi-system-partition=EFI-PARTITION-PARTUUID and chainload=EFI-PARTITION-PARTUUID;m1n1/boot.bin? +20:30 < jannau> chainload tell's the 1st stage m1n1 from where to load the second stage +20:31 < jannau> chosen.asahi,efi-system-partition is added to the dt mostly to allow u-boot to boot from the correct ESP +20:32 < Glanzmann> I see. Thank you for the elaboration. +20:32 < jannau> chosen.asahi,efi-system-partition is passed from the 1st stage forward to the second stage +20:33 < Glanzmann> I see, so the first stage informs the second stage about the uuid of the esp partition which is than passed using dt to u-boot which can than select the right esp to select the efi binary. + +17:25 < Jamie[m]1> I had a dumb idea and had to implement it: using http range requests and DEFLATE trickery to download Wifi firmware from Apple's CDN with only 18MB of transfer (out of a 13GB ipsw) http://github.com/JJJollyjim/firmware-abomination + +23:23 <@jannau> Glanzmann: on the mini vram can fit 5.5 million pixels, would be good for 3440x1600 or 3840x1433 at 32bpp + +11:37 < AdryzzOLEDEdition[m]> https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-03/msg01260.html + +https://gist.github.com/rqou/2dafd40cfe0362cc84c3ee26c68b2b36 + +https://arvanta.net/alpine/install-alpine-m1/ +21:48 < mps> Glanzmann: no, but /etc/local.d/$scriptname.start + +# geekbench +16:08 looks like theres some results https://browser.geekbench.com/v5/cpu/13927518 +16:09 https://browser.geekbench.com/v5/cpu/search?utf8=%E2%9C%93&q=asahi +16:10 jannau: https://www.geekbench.com/blog/2021/03/geekbench-54/ +16:14 jannau: same m1 16 gb, 3000 more in multicore. How? https://browser.geekbench.com/v5/cpu/13856349 +16:18 jannau: does it matter? I mean, it looks like we do have geekbench on arm linux... +16:19 https://www.geekbench.com/blog/2021/03/geekbench-54/ +16:24 https://browser.geekbench.com/v5/cpu/12429267 +16:25 the multicore test doesn't scale well, here are results from a m1 ultra: https://browser.geekbench.com/v5/cpu/13932507 +16:31 Chainfire: it's geekbench issue. kernel compiles are on the m1 ultra twice as fast as on the m1 max + +my air: https://browser.geekbench.com/v5/cpu/13933197 +my mini: https://browser.geekbench.com/v5/cpu/13933401 + +15:58 < kov> Glanzmann, jannau out of curiosity I ran geekbench on my Fedora VM under MacOS (M1 Max - 8 vcpus) https://browser.geekbench.com/v5/cpu/13951703 + +# Browse the devicetree +/proc/device-tree/chosen/asahi,efi-system-partition + +# mps mtrack configuration +Section "InputClass" + MatchIsTouchpad "on" + Identifier "Touchpads" + Driver "mtrack" + Option "Sensitivity" "0.15" + Option "FingerHigh" "10" + Option "FingerLow" "3" + Option "IgnoreThumb" "true" + Option "DisableOnThumb" "true" + Option "DisableOnPalm" "true" + Option "ThumbRatio" "60" + Option "ThumbSize" "15" + Option "IgnorePalm" "true" + Option "TapButton1" "1" + Option "TapButton2" "3" + Option "TapButton3" "2" + Option "TapButton4" "4" + Option "ClickFinger1" "1" + Option "ClickFinger2" "2" + Option "ClickFinger3" "3" + Option "ButtonMoveEmulate" "false" + Option "ButtonIntegrated" "true" + Option "ClickTime" "25" + Option "BottomEdge" "30" + Option "SwipeLeftButton" "8" + Option "SwipeRightButton" "9" + Option "SwipeUpButton" "0" + Option "SwipeDownButton" "0" + Option "SwipeDistance" "700" + Option "ScrollCoastDuration" "500" + Option "ScrollCoastEnableSpeed" "1" + Option "ScrollUpButton" "4" + Option "ScrollDownButton" "5" + Option "ScrollLeftButton" "7" + Option "ScrollRightButton" "6" + Option "ScrollDistance" "250" + Option "EdgeLeftSize" "0" +EndSection + +14:26 < mps> Glanzmann: also github with guide is here https://github.com/p2rkw/xf86-input-mtrack +14:27 < mps> Glanzmann: and this one helped me to understand some things https://int3ractive.com/blog/2018/make-the-best-of-macbook-touchpad-on-ubuntu/ +14:28 < j`ey> mps: what kinda 'swipes'? +14:28 -!- bisko (~bisko@0002be12.user.oftc.net) has quit: Ping timeout: 480 seconds +14:28 < mps> left and right, i.e, next and previous url in firefox +14:28 < j`ey> ah cool +14:29 < mps> this is enough for me (for now at least) +14:30 -!- bisko (~bisko@0002be12.user.oftc.net) has joined #asahi +14:30 < mps> there is also https://github.com/BlueDragonX/dispad which disables touchpad while typing +14:32 < mps> but I have to find some time to learn better about all this touchpad options +14:50 < mps> three fingers swipe left -> previous url, three finger swipe right -> next url + +# Old config: + +Section "InputClass" + Identifier "libinput touchpad catchall" + MatchIsTouchpad "on" + MatchDevicePath "/dev/input/event*" + Option "Tapping" "False" + Option "TappingDrag" "False" + Option "DisableWhileTyping" "True" + Option "AccelProfile" "adaptive" + Option "AccelSpeed" "0.3" + Option "AccelerationNumerator" "2" + Option "AccelerationDenominator" "1" + Option "AccelerationThreshold" "4" + Option "AdaptiveDeceleration" "2" + Option "NaturalScrolling" "0" + Option "TappingButtonMap" "lmr" + Option "ClickMethod" "clickfinger" + Driver "libinput" +EndSection + +luks: https://g3la.de/hedgedoc/s/MIaCyVv1A# + +https://blog.devgenius.io/installing-gentoo-linux-in-apple-macbook-pro-m1-49e163534898 + +07:53 < VinDuv> Glanzmann: I’ll be a bit busy until next week but if you want to play with my patch, it’s here: https://github.com/AsahiLinux/m1n1/pull/183 +07:54 < VinDuv> If you apply both patches and boot with display=wait,3840x2160, it should boot in 4k and m1n1 will say “waiting for monitor disconnect” and then wait 10 seconds +07:59 < VinDuv> btw I’m working on a Python script that detects, from macOS, if a monitor disconnects during wakeup (so it needs m1n1 to wait) as well as its native resolution. If it works well and is integrated into the installer, it + could autoconfigure the display= option in m1n1 during installation.