]> git.zerfleddert.de Git - m1-debian/blame_incremental - doc/notes.txt
drop small font
[m1-debian] / doc / notes.txt
... / ...
CommitLineData
109:10 < j`ey> Glanzmann: `git rev-list 6f59bc24287..smc/work` that might work, not sure how it deals with merges. git rebase is the better way. but if you do that youre on your own!
209:19 < _jannau_> Glanzmann: git rebase --onto 5.17-rc3 6f59bc24287
309:23 < j`ey> if you add -p it can also preserve the merges
4
519:13 < j`ey> but there's also CONFIG_OF_DMA_DEFAULT_COHERENT, which makes of_dma_is_coherent always return true
6
721:02 < jannau> mps: you need https://lore.kernel.org/u-boot/20220208210215.8612-1-j@jannau.net/ for extlinux
8
9ARCH: 23:29 < ah-[m]> yep, exactly. I had to grub-mkconfig -o /boot/grub/grub.cfg, and move my Image.gz to /boot, otherwise it was just what was on the wiki page
10
11https://lore.kernel.org/linux-arm-kernel/20211011165707.138157-1-marcan@marcan.st/
1219:02 < jannau> I think based on this branch https://github.com/AsahiLinux/linux/tree/cpufreq/v1
13
1423:41 < kov> Glanzmann, hmm interesting, I'll try upgrading libinput firs then, see if that fixes it
1523:42 < kov> it's weird because I remember the trackpad working a while ago
1623:45 -!- mtjzh (~mtjzh@2a02:8388:1742:9b80:658f:93d3:ec68:d60e) has joined #asahi
1723:46 < kov> yep, just upgrading to testing's libinput makes it work heh thanks Glanzmann!
18
19Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIPS-archtec.patch
2010:10 < jannau> see the commit message for 64k on ppc64 https://chromium.googlesource.com/chromium/src.git/+/445c099c6486b8e5ff8dafaefcd812a7ea4bdfff%5E%21/
2115:26 < tpw_rules> Glanzmann: https://pastebin.com/NzJEQJDW - https://tg.st/u/NzJEQJDW
2215: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
23Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564
2416:21 < tpw_rules> https://bugs.chromium.org/p/chromium/issues/detail?id=1301788
25
2622:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux
27
2819:11 < Glanzmann> axboe: Could you explain how to mark a device as write-through? Does that mean if I issue a sync in Linux that no flush will happen. Because this would be helpful for the m1 notebook owners to improve performance.
2919:11 < axboe> I just do: `echo "write through" > /sys/block/nvme0n1/queue/write_cache"` for now...
3019:11 < axboe> Glanzmann: ^^
3119:12 < axboe> Glanzmann: and yes, that's what it means
3219:12 < Glanzmann> axboe: Thanks.
3319:12 < axboe> Glanzmann: it'll bump your test case from 56 iops to 14k or something like that :)
3419:12 < axboe> alternatively, some sort of time based hack might make sense
3519:13 < axboe> "only issue flush if X seconds has passed since last issue"
3619:13 < axboe> kinda nasty, but safer
37
3815:50 < mps> axboe: Glanzmann: `libinput Disable While Typing Enabled (268): 1` is set in my case and it works fine
3915:51 < mps> though I built latest beta of libinput and rebuilt xf86-input-libinput with it
4015:52 < mps> i.e. libinput-1.19.901
4115:52 < axboe> mps: promising
4215:53 < mps> but still didn't got it to detect thumb
4316:07 < mps> Glanzmann: `libinput quirks list /dev/input/event1` will show you features of input device
4416:09 < mps> and `libinput quirks list /dev/input/event1` will show quirks from libinput database
45
46From mps:
47#!/bin/sh
48echo 2 > /sys/module/hid_apple/parameters/fnmode
49echo 1 > /sys/module/hid_apple/parameters/swap_fn_leftctrl
50echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd
51
5219:19 < Glanzmann> sven: Do you know why axboe set the admin queue to 2 instead of 8?
5319:19 < sven> yes
5419:19 < sven> almost all commands go through the io queue, no need to waste that space for the admin queue
55
56# j`ey on deleting efi and Linux partitions from the gui in macos
5720:46 < j`ey> Glanzmann: I didnt figure it out at the diskutil cli, but I managed to do it from the GUI, I think you have to erase/reformat as APFS before you can delete the volumes
5810:53 < j`ey> Glanzmann: for your notes: < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
5921:07 < tpw_rules> you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
60
6108:54 < mixi> Glanzmann: the command you're looking for should be "dtc -I dtb -O dts /sys/firmware/fdt"
6208:57 < jannau> Glanzmann: dtc -I fs -O dts -o - /proc/device-tree
63
64# j`ey on hack to hookup lid close/open
6523:19 < j`ey> apple_smc_event_received in drivers/platform/apple/smc_core.c is a good place to start looking
66
67# kettenis on the same issue using existing infrastructure
6823:20 < kettenis> so the lid is hooked up to gP01
6923:24 < kettenis> looks like you could try hooking that up using gpio-keys-polled
7023:27 < Glanzmann> kettenis: So gpio-keys-polled would poll gP01 and send a key event and than I could use my window manager to do something when that key event is received?
7123:29 < kettenis> look at arch/arm/boot/dts/imx6q-novena.dts
72
73# How to subscribe to smc events
7423:45 < j`ey> Glanzmann: if youre still interested in looking: drivers/power/supply/macsmc_power.c apple_smc_register_notifier(power->smc, &power->nb);
7523:46 < j`ey> so this driver gets called, when an SMC notification happens. looks like all registered handlers would be called and its up to the callback to figure out if it needs to do something
76
77# More background
7823:54 < kettenis> if the interrupts are hooked up correctly for thise SMC gpios, gpio-keys instead of gpio-keys-polled should work
7923:54 < j`ey> no irq_chip in the current driver
80
8117:34 <marcan> the image as built will have a real grub config with static UUIDs
8217:35 <marcan> well, a systemd early unit but yes
83
84{
85 "os_list": [
86 {
87 "name": "Asahi Linux reference distro (Arch Linux ARM)",
88 "default_os_name": "Asahi Linux",
89 "boot_object": "m1n1_uboot.bin",
90 "package": "asahi-alarm.zip",
91 "partitions": [
92 {
93 "name": "EFI",
94 "type": "EFI",
95 "size": "512MB",
96 "format": "fat",
97 "volume_id": "0x03f103f1",
98 "copy_firmware": true,
99 "copy_installer_data": true,
100 "source": "esp"
101 },
102 {
103 "name": "Root",
104 "type": "Linux",
105 "size": "5GB",
106 "expand": true,
107 "image": "root.img"
108 }
109 ]
110 },
111 {
112 "name": "UEFI environment only (m1n1 + U-Boot + ESP)",
113 "default_os_name": "UEFI boot",
114 "boot_object": "m1n1_uboot.bin",
115 "partitions": [
116 {
117 "name": "EFI",
118 "type": "EFI",
119 "size": "512MB",
120 "format": "fat",
121 "copy_firmware": true,
122 "copy_installer_data": true
123 }
124 ]
125 },
126 {
127 "name": "Tethered boot (m1n1, for development)",
128 "default_os_name": "m1n1 proxy",
129 "expert": true,
130 "boot_object": "m1n1.bin",
131 "partitions": []
132 }
133 ]
134}
135
136cloud-initramfs-growroot
13716:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd.
138tune2fs -U random /dev/whatever
139
14007:54 < VinDuv> So I’ve been looking at how macOS installation from USB works on M1 Macs and I think it might be interesting for the Asashi installer. The way it works is that there’s a hidden plist file on the USB drive that references a macOS
141 application on the drive; if this file is present, the USB drive will show up in the power-button-held boot menu, and when selected, it will run the application. It doesn’t seem to care about file signature
14207:54 < VinDuv> (it works even if the app is just a shell script) and it looks like it’s in 1TR mode.
14307:56 < VinDuv> So the installation workflow from 1TR could be “plug in a USB stick, hold the power button, select Install Asahi” instead of having to manually open the terminal and run curl | sh. The installer doesn’t even need to be graphical since
144 it’s possible for the launched shell script to start the recovery environment’s Terminal and giving it an arbitrary command to run.
14507:59 < VinDuv> This is also not limited to external USB drives; it also works if the files are in an APFS volume in internal storage, which I guess might be useful to have a Asahi Recovery boot option in the boot menu or something.
146
147---- .IAPhysicalMedia ---------------------------------------------------------
148<?xml version="1.0" encoding="UTF-8"?>
149<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
150<plist version="1.0">
151<dict>
152 <key>AppName</key>
153 <string>Some App.app</string>
154 <key>ProductBuildVersion</key>
155 <string>00A191</string>
156 <key>ProductVersion</key>
157 <string>12.2.1</string>
158</dict>
159</plist>
160
161---- Some App.app/Contents/Info.plist -----------------------------------------
162<?xml version="1.0" encoding="UTF-8"?>
163<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
164<plist version="1.0">
165<dict>
166 <key>CFBundleDisplayName</key>
167 <string>Some App</string>
168 <key>CFBundleExecutable</key>
169 <string>SomeApp</string>
170</dict>
171</plist>
172
173---- Some App.app/Contents/Resources/<lang code>.lproj/InfoPlist.strings ------
174"CFBundleDisplayName" = "Some App";
175
176---- Some App.app/Contents/MacOS/SomeApp (executable) -------------------------
177#!/bin/bash
178exec /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal "${0%/*}/../Resources/myscript.command"
179
180---- Some App.app/Contents/Resources/myscript.command -------------------------
181#!/bin/sh
182
183echo "Hello, world!"
184exec /bin/bash
185
186
18719:14 <VinDuv> marcan: I have done a bit more testing with the .IAPhysicalMedia file and it looks like ProductBuildVersion can be any value including blank. ProductVersion seems to be checked against the minimal macOS version supported by the Mac; on my mini the icon shows up in the boot menu only if it’s >= 11.3.
18819:15 <VinDuv> Maybe it should be set to a higher value for forward compatibility with future Macs that will require 13.0? I’ve tested setting it to 99 and it works.
189
19021:46 < povik> with pulse, you can get the jack by getting into pacmd
19121:46 < povik> and running: load-module module-alsa-sink device=hw:0,1
19221:56 < povik> that mode of playing in parallel through the speakers and jack has a defect
19321:57 < povik> there's noise mixed-in then, at a period
19421:57 < povik> don't know how that happens yet
195When 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).
196
197
198If you see this in Xorg.0.log, it means that simpledrm has not initialized.
199...
200[ 4.259] (EE) open /dev/dri/card0: No such file or directory
201...
202[ 4.278] (EE)
203[ 4.278] (EE) Backtrace:
204[ 4.278] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x188) [0xaaaad26e0398]
205[ 4.278] (EE) unw_get_proc_info failed: no unwind info found [-10]
206
207An initialized simpledrm looks like that:
208
209(air) [~] dmesg | grep -i simpledrm
210[ 2.215718] [drm] Initialized simpledrm 1.0.0 20200625 for be2120000.framebuffer on minor 0
211[ 2.218952] simple-framebuffer be2120000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device
212
213This is probably because someone forgot to enable one of the following kernel options:
214
215CONFIG_BACKLIGHT_CLASS_DEVICE=y
216CONFIG_BACKLIGHT_GPIO=m
217CONFIG_DRM=y
218CONFIG_DRM_SIMPLEDRM=y
219CONFIG_FB_EFI=n
220
221-------------------------------------------------------------------------------------------------------------
222Howto convert from the old bootchain to the m1n1 chainloaded bootchain:
223
224(air) [~] parted /dev/nvme0n1 print
225Model: APPLE SSD AP0512Q (nvme)
226Disk /dev/nvme0n1: 500GB
227Sector size (logical/physical): 4096B/4096B
228Partition Table: gpt
229Disk Flags:
230
231Number Start End Size File system Name Flags
232 1 24.6kB 524MB 524MB iBootSystemContainer
233 2 524MB 400GB 399GB Container
234 3 400GB 402GB 2501MB
235 4 402GB 403GB 513MB fat32 boot, esp
236 5 403GB 495GB 91.8GB ext4 primary
237 6 495GB 500GB 5369MB RecoveryOSContainer
238
239I deleted partition 4 and 3, run the asahi installer again.
240
241Than I booted debian from the live stick and mounted the root filesystem and the efi file system:
242
243mount /dev/nvme0n1p5 /mnt
244mount /dev/nvme0n1p4 /mnt/boot/efi
245
246Than I bindmounted the rest of it:
247
248mount -t sysfs none /mnt/sys
249mount -t efivarfs none /mnt/sys/firmware/efi/efivars
250mount -t proc none /mnt/proc
251mount -o bind /dev /mnt/dev
252mount -o bind /dev/pts /mnt/dev/pts
253
254Than I changerooted into it:
255
256cd /mnt
257chroot . bin/bash
258
259blkid
260# Than I updated /etc/fstab with the new id of the efi partition
261
262curl -sLo /boot/efi/m1n1/boot.bin tg.st/u/u-boot.bin
263
264grub-install --removable /boot/efi
265
266exit, umounted everything and rebooted.
267-------------------------------------------------------------------------------------------------------------
26812: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
269
270## BEGIN NOTES ##
271
272# HOUSEKEEPING
273# All testing conducted with channels set to 40% in alsamixer,
274# with no amp gain.
275
276# Do NOT try to play sound with the speakers set to 100% in alsamixer,
277# you will fry the cones!
278
279# DRIVER MAPPINGS/ALSA QUIRKS
280# The speaker array as set up by the ASoC driver maps like
281# this on a J314s:
282# 0: Left Woofer 1
283# 1: Right Woofer 1
284# 2: Left Tweeter
285# 3: Right Tweeter
286# 4: Left (Sub)Woofer 2
287# 5: Right (Sub)Woofer 2
288
289# ALSA sets up the speaker array on the J314s as a 4.0 surround system,
290# with the RL and RR channels duplicated across the woofers like this:
291# 2: Front Left
292# 3: Front Right
293# 0: Rear Left
294# 1: Rear Right
295# 4: Rear Left
296# 5: Rear Right
297
298# Obviously this is not correct, but for us it does not matter, since
299# we can just tell ALSA to route FL and FR to all drivers, presenting
300# it to the rest of userspace as a stereo device. Surround sources
301# are downmixed appropriately.
302
303# SOUND CHECK
304# Testing reveals that drivers 4 and 5 are likely
305# only there to help with bass and sub bass. They
306# are extremely bad at reproducing frequencies above
307# ~500Hz, and even with the help of the tweeters sound
308# rough/deep fried in the mids. Drivers 0 and 1 are obviously
309# intended to be the main woofers in the array.
310
311# If we weren't intending to mimic whatever macOS does, my ear-only
312# testing would have me setting up a xover network like this:
313
314# Freq Range (Hz) | Drivers
315# 0-300 | 0 1 4 5
316# 300-6500 | 0 1
317# 6500-20000 | 2 3
318
319# Figures based on typical {LP,BP,HP}F rolloff characteristics.
320
321# Using all 4 woofers below 300Hz moves more air than just using the
322# (sub)woofers alone. 3-way loudspeakers work like this conventionally.
323
324# The ttable in the j314s-array pcm device tries to compensate for the lack of
325# EQ right now by greatly reducing the volume of 4 and 5, and slightly reducing
326# the volume of 0 and 1 relative to 2 and 3. I have found this gives an acceptably
327# clear sound without being too bright or losing too much out of the mids. Bass is
328# nonexistent, though I suspect this is just because we have not applied appropriate
329# correction to overcome the machine's housing yet. I will not be applying EQ or filtering
330# in ALSA using plugins even in the interim because
331# a) it's deprecated
332# b) it introduces overhead and chews up CPU time
333
334# FIRs can be applied to a 6 channel slave PCM which would then feed the routing table
335# PCM configured below with all coefficients set to 1
336
337## END NOTES ##
338
339# Create a six channel slave for the audio array
340pcm_slave.outputs {
341 pcm "hw:0,0"
342 channels 6
343}
344
345
346# We need to map L and R to the correct drivers. We can use
347# the coefficients in ttable to roughly tune the sound profile.
348pcm.j314s-array {
349 type route
350 slave outputs
351 ttable {
352 0.0 = 0.65
353 0.2 = 1
354 0.4 = 0.3
355 1.1 = 0.65
356 1.3 = 1
357 1.5 = 0.3
358 }
359}
360
361
362# Set up a plug and ctl interface for ALSA defaults
363# XXX: Does not work for PipeWire, but does work for JACK
364# and PulseAudio
365pcm.!default {
366 type plug
367 slave.pcm j314s-array
368}
369
370ctl.!default {
371 type hw
372 card 0
373}
374-------------------------------------------------------------------------------------------------
375
376# Control what happens after power loss
377/sys/devices/platform/soc/23e400000.smc/macsmc-reboot/ac_power_mode
378
37916k bugs
380========
38117:02 < kov> Glanzmann, https://bugs.webkit.org/show_bug.cgi?id=236564
38217:02 < kov> Glanzmann, that is already on the 2.34.6 stable release
38317: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
384 already in
38517:04 < kov> it's this one https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/be8a1dcbfc7edf19ef13a63ddf034dba814ee000
386
38717: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
388 new/old branches even after a rebase
38917:49 < j`ey> (where 'asahi' is my local not-yet-updated branch)
390
39121: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)
39221:55 < kov> Glanzmann, hrm adding vga=normal fb=false to the kernel cmdline made it work
393
39407:19 < chadmed> Glanzmann: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2210
39507: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
396
39715:49 < j`ey> https://github.com/AsahiLinux/asahi-installer/blob/main/src/osinstall.py#L141
39815:49 < j`ey> cat m1n1.bin <(echo 'chainload=$ESP_UUID;$BOOT_OBJ_PATH') > blah.bin
399
40016:43 < povik> marcan: two fixes on top of 'asahi' that should make it into the release: https://github.com/povik/linux/commits/asahi-fixes
401
402# boot into 1tr
403diskutil list
404diskutil info <identifier of esp>
405curl -sLo tg.st/u/m1n1-rust.bin
406cat m1n1-rust.bin <(echo 'chainload=<ESP Partition UUID>;m1n1/boot.bin') <(echo 'chosen.asahi,efi-system-partition=<ESP Parition UUID>') > object.bin
407kmutil configure-boot -c object.bin --raw --entry-point 2048 --lowest-virtual-address 0 -v /Volumes/Linux
408
40920: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?
41020:30 < jannau> chainload tell's the 1st stage m1n1 from where to load the second stage
41120:31 < jannau> chosen.asahi,efi-system-partition is added to the dt mostly to allow u-boot to boot from the correct ESP
41220:32 < Glanzmann> I see. Thank you for the elaboration.
41320:32 < jannau> chosen.asahi,efi-system-partition is passed from the 1st stage forward to the second stage
41420: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.
415
41617: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
417
41823:23 <@jannau> Glanzmann: on the mini vram can fit 5.5 million pixels, would be good for 3440x1600 or 3840x1433 at 32bpp
419
42011:37 < AdryzzOLEDEdition[m]> https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-03/msg01260.html
421
422https://gist.github.com/rqou/2dafd40cfe0362cc84c3ee26c68b2b36
423
424https://arvanta.net/alpine/install-alpine-m1/
42521:48 < mps> Glanzmann: no, but /etc/local.d/$scriptname.start
426
427# geekbench
42816:08 <j`ey> looks like theres some results https://browser.geekbench.com/v5/cpu/13927518
42916:09 <j`ey> https://browser.geekbench.com/v5/cpu/search?utf8=%E2%9C%93&q=asahi
43016:10 <j`ey> jannau: https://www.geekbench.com/blog/2021/03/geekbench-54/
43116:14 <bluetail[m]> jannau: same m1 16 gb, 3000 more in multicore. How? https://browser.geekbench.com/v5/cpu/13856349
43216:18 <bluetail[m]> jannau: does it matter? I mean, it looks like we do have geekbench on arm linux...
43316:19 <bluetail[m]> https://www.geekbench.com/blog/2021/03/geekbench-54/
43416:24 <psydroid[m]1> https://browser.geekbench.com/v5/cpu/12429267
43516:25 <jannau> the multicore test doesn't scale well, here are results from a m1 ultra: https://browser.geekbench.com/v5/cpu/13932507
43616:31 <jannau> Chainfire: it's geekbench issue. kernel compiles are on the m1 ultra twice as fast as on the m1 max
437
438my air: https://browser.geekbench.com/v5/cpu/13933197
439my mini: https://browser.geekbench.com/v5/cpu/13933401
440
44115: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
442
443# Browse the devicetree
444/proc/device-tree/chosen/asahi,efi-system-partition
445
446# mps mtrack configuration
447Section "InputClass"
448 MatchIsTouchpad "on"
449 Identifier "Touchpads"
450 Driver "mtrack"
451 Option "Sensitivity" "0.15"
452 Option "FingerHigh" "10"
453 Option "FingerLow" "3"
454 Option "IgnoreThumb" "true"
455 Option "DisableOnThumb" "true"
456 Option "DisableOnPalm" "true"
457 Option "ThumbRatio" "60"
458 Option "ThumbSize" "15"
459 Option "IgnorePalm" "true"
460 Option "TapButton1" "1"
461 Option "TapButton2" "3"
462 Option "TapButton3" "2"
463 Option "TapButton4" "4"
464 Option "ClickFinger1" "1"
465 Option "ClickFinger2" "2"
466 Option "ClickFinger3" "3"
467 Option "ButtonMoveEmulate" "false"
468 Option "ButtonIntegrated" "true"
469 Option "ClickTime" "25"
470 Option "BottomEdge" "30"
471 Option "SwipeLeftButton" "8"
472 Option "SwipeRightButton" "9"
473 Option "SwipeUpButton" "0"
474 Option "SwipeDownButton" "0"
475 Option "SwipeDistance" "700"
476 Option "ScrollCoastDuration" "500"
477 Option "ScrollCoastEnableSpeed" "1"
478 Option "ScrollUpButton" "4"
479 Option "ScrollDownButton" "5"
480 Option "ScrollLeftButton" "7"
481 Option "ScrollRightButton" "6"
482 Option "ScrollDistance" "250"
483 Option "EdgeLeftSize" "0"
484EndSection
485
48614:26 < mps> Glanzmann: also github with guide is here https://github.com/p2rkw/xf86-input-mtrack
48714: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/
48814:28 < j`ey> mps: what kinda 'swipes'?
48914:28 -!- bisko (~bisko@0002be12.user.oftc.net) has quit: Ping timeout: 480 seconds
49014:28 < mps> left and right, i.e, next and previous url in firefox
49114:28 < j`ey> ah cool
49214:29 < mps> this is enough for me (for now at least)
49314:30 -!- bisko (~bisko@0002be12.user.oftc.net) has joined #asahi
49414:30 < mps> there is also https://github.com/BlueDragonX/dispad which disables touchpad while typing
49514:32 < mps> but I have to find some time to learn better about all this touchpad options
49614:50 < mps> three fingers swipe left -> previous url, three finger swipe right -> next url
497
498# Old config:
499
500Section "InputClass"
501 Identifier "libinput touchpad catchall"
502 MatchIsTouchpad "on"
503 MatchDevicePath "/dev/input/event*"
504 Option "Tapping" "False"
505 Option "TappingDrag" "False"
506 Option "DisableWhileTyping" "True"
507 Option "AccelProfile" "adaptive"
508 Option "AccelSpeed" "0.3"
509 Option "AccelerationNumerator" "2"
510 Option "AccelerationDenominator" "1"
511 Option "AccelerationThreshold" "4"
512 Option "AdaptiveDeceleration" "2"
513 Option "NaturalScrolling" "0"
514 Option "TappingButtonMap" "lmr"
515 Option "ClickMethod" "clickfinger"
516 Driver "libinput"
517EndSection
518
519luks: https://g3la.de/hedgedoc/s/MIaCyVv1A#
520
521https://blog.devgenius.io/installing-gentoo-linux-in-apple-macbook-pro-m1-49e163534898
522
52307: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
52407: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
52507: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.
526
52714:34 < mps> Glanzmann: I use 'export MOZ_USE_XINPUT2=1' in system wide /etc/profile
52814:35 < mps> and checked out (disabled) smooth scroll in firefox
Impressum, Datenschutz