From af9cb772bb3debe49486cc9e7bade017d9ebbebe Mon Sep 17 00:00:00 2001 From: Janne Grunau Date: Sun, 21 Sep 2025 17:31:33 +0200 Subject: [PATCH 1/3] project: help-wanted: Update usb-c vdm task USB-PD vdm support on linux should work with Linux' userspace i2c client driver. Replace the the current implementation using cd321x sysfs files. Add a task to debug the spotty samsung_tty driver resetting the port (`/dev/ttySAC0`) on the host within seconds. Signed-off-by: Janne Grunau --- docs/project/help-wanted.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/project/help-wanted.md b/docs/project/help-wanted.md index fb83e9c0..dd94294c 100644 --- a/docs/project/help-wanted.md +++ b/docs/project/help-wanted.md @@ -12,6 +12,7 @@ any questions or are in need of assistance. | Task | Status | Description | Contact | | ---- | ------ | ----------- | ------- | | libgnome-volume-control fixes | Unclaimed | GNOME's volume mixer is implemented in the `libgnome-volume-control` plugin. Unfortunately, this interacts poorly with WirePlumber/Pipewire and does not seem to respect node graph permissions. This leads to the default sink being the "raw" hardware device on GNOME, bypassing our DSP, which is completely unsupported. `libgnome-volume-control` needs to be fixed so that it hides the raw hardware sink and selects the correct default sink. | chadmed | -| Extend tipd driver | **Unclaimed** | Add support to reset other Apple Silicon machines, and to enable serial, to [tipd](https://github.com/AsahiLinux/linux/blob/asahi/drivers/usb/typec/tipd/core.c). On the Macs, some parts of the USB specification are implemented by (undocumented) CD321x chips, similar to [TPS65982](https://www.ti.com/lit/ds/symlink/tps65982.pdf). Apple added some [debugging features](../hw/soc/usb-pd.md) to their Type-C ports, and if we want to make use of those when running Linux on an M1/M2 host for development (connected to another M1/M2 machine being the target of experimentation), we need to extend the `tipd` driver. | suggested by sven | +| Rewrite tuxvdmtool to userspace i2c | **Unclaimed** | [tuxvdmtool](https://github.com/AsahiLinux/tuxvdmtool) uses a [sysfs API](https://github.com/AsahiLinux/linux/commit/786523ac62f0aeec37bf9c6b991e8bf2fadc590d) which isn't particularly nice and probably not upstreamable. After publishing tuxvdmtool we came to the conclusion that using linux userspace I2C client driver API is a better choice and should work. See https://github.com/AsahiLinux/tuxvdmtool/issues/1 | janne | +| Fix serial port resets | **Unclaimed** | When using the apple silicon debug uart with two connected Apple silicon devices the serial port on the host device (`/dev/ttySAC0`) resets within seconds after `tuxvdmtool reboot serial`. Find the cause for this and fix the issue. This tasks is a little annoying since m1n1's hypervisor clobbers the hardware uart0 for its own use. | janne | | Bluetooth suspend | **Unclaimed** | Currently, when suspending and then resuming Bluetooth breaks. This is either an issue with the way hci_bcm4377 uses the bluetooth suspend API or we are missing some special vendor-specific commands before suspend or after resume. It's probably possible to figure this out without making the hypervisor survive a full suspend/resume cycle by using Apple's PacketLogger which is part of the "Additional Tools for XCode" to look for additional commands. It's probably also a good idea to compare how hci_bcm4377 suspend works to other Bluetooth drivers since it's also possible that it's just misusing some API that gets the device stuck in a wrong state. | sven | | Keyboard layout cleanup (XKB/hid_apple) | Unclaimed | Apple keyboard support across the Linux desktop stack has been hit-and-miss, across layouts and hardware keyboards. Since our keyboard drivers are not upstream yet, we have the chance to do some major cleanup. In particular, the keyboards on these machines have a soft *Fn* key that is handled entirely in software. The `hid_apple` driver currently does this in the kernel, but this is the wrong approach. This key should be handled in userspace in XKB/Wayland (Xorg cannot do it, but it's deprecated), so that we can have more comprehensive Fn key mappings including letting users customize the key bindings like they would any other modifier key, or offer special symbols like macOS does. This should probably be done by introducing new XKB keyboard models, which do this mapping in userspace. To test this, use the `fnmode=0` module parameter for `hid_apple` to disable all Fn key processing. We will later want to introduce a new fnmode that *only* does Fn key combination emulation for the edit keys (insert/delete/home/end/pgup/pgdown), which is the minimum required for a usable TTY and Xorg, and leave the rest to XKB, defaulting to this mode on Apple Silicon machines. Besides the Fn story, there are also many regional Mac layouts that need to be fixed in XKB configuration, and everyone with a non-English keyboard is welcome to help out with that effort. [Relevant xkeyboard-config issue](https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/379)| marcan | From 060ec3e67ccdb1aadf5b12182869a9f5f33e3dfb Mon Sep 17 00:00:00 2001 From: Janne Grunau Date: Sun, 21 Sep 2025 17:35:54 +0200 Subject: [PATCH 2/3] project: help-wanted: Remove bluetooth suspend task This seems to be fixed since quite a while. No current reports and a targeted reproduction failed recently as well. Signed-off-by: Janne Grunau --- docs/project/help-wanted.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/project/help-wanted.md b/docs/project/help-wanted.md index dd94294c..78ca0b98 100644 --- a/docs/project/help-wanted.md +++ b/docs/project/help-wanted.md @@ -14,5 +14,4 @@ any questions or are in need of assistance. | libgnome-volume-control fixes | Unclaimed | GNOME's volume mixer is implemented in the `libgnome-volume-control` plugin. Unfortunately, this interacts poorly with WirePlumber/Pipewire and does not seem to respect node graph permissions. This leads to the default sink being the "raw" hardware device on GNOME, bypassing our DSP, which is completely unsupported. `libgnome-volume-control` needs to be fixed so that it hides the raw hardware sink and selects the correct default sink. | chadmed | | Rewrite tuxvdmtool to userspace i2c | **Unclaimed** | [tuxvdmtool](https://github.com/AsahiLinux/tuxvdmtool) uses a [sysfs API](https://github.com/AsahiLinux/linux/commit/786523ac62f0aeec37bf9c6b991e8bf2fadc590d) which isn't particularly nice and probably not upstreamable. After publishing tuxvdmtool we came to the conclusion that using linux userspace I2C client driver API is a better choice and should work. See https://github.com/AsahiLinux/tuxvdmtool/issues/1 | janne | | Fix serial port resets | **Unclaimed** | When using the apple silicon debug uart with two connected Apple silicon devices the serial port on the host device (`/dev/ttySAC0`) resets within seconds after `tuxvdmtool reboot serial`. Find the cause for this and fix the issue. This tasks is a little annoying since m1n1's hypervisor clobbers the hardware uart0 for its own use. | janne | -| Bluetooth suspend | **Unclaimed** | Currently, when suspending and then resuming Bluetooth breaks. This is either an issue with the way hci_bcm4377 uses the bluetooth suspend API or we are missing some special vendor-specific commands before suspend or after resume. It's probably possible to figure this out without making the hypervisor survive a full suspend/resume cycle by using Apple's PacketLogger which is part of the "Additional Tools for XCode" to look for additional commands. It's probably also a good idea to compare how hci_bcm4377 suspend works to other Bluetooth drivers since it's also possible that it's just misusing some API that gets the device stuck in a wrong state. | sven | | Keyboard layout cleanup (XKB/hid_apple) | Unclaimed | Apple keyboard support across the Linux desktop stack has been hit-and-miss, across layouts and hardware keyboards. Since our keyboard drivers are not upstream yet, we have the chance to do some major cleanup. In particular, the keyboards on these machines have a soft *Fn* key that is handled entirely in software. The `hid_apple` driver currently does this in the kernel, but this is the wrong approach. This key should be handled in userspace in XKB/Wayland (Xorg cannot do it, but it's deprecated), so that we can have more comprehensive Fn key mappings including letting users customize the key bindings like they would any other modifier key, or offer special symbols like macOS does. This should probably be done by introducing new XKB keyboard models, which do this mapping in userspace. To test this, use the `fnmode=0` module parameter for `hid_apple` to disable all Fn key processing. We will later want to introduce a new fnmode that *only* does Fn key combination emulation for the edit keys (insert/delete/home/end/pgup/pgdown), which is the minimum required for a usable TTY and Xorg, and leave the rest to XKB, defaulting to this mode on Apple Silicon machines. Besides the Fn story, there are also many regional Mac layouts that need to be fixed in XKB configuration, and everyone with a non-English keyboard is welcome to help out with that effort. [Relevant xkeyboard-config issue](https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/379)| marcan | From e98abdd29279b15003fac61188a7dda1862a44a4 Mon Sep 17 00:00:00 2001 From: Janne Grunau Date: Sun, 21 Sep 2025 17:37:57 +0200 Subject: [PATCH 3/3] project: help-wanted: Update contact for keyboard layout task While marcan was still interested in this I'm available on irc/matrix. Signed-off-by: Janne Grunau --- docs/project/help-wanted.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/help-wanted.md b/docs/project/help-wanted.md index 78ca0b98..40c762db 100644 --- a/docs/project/help-wanted.md +++ b/docs/project/help-wanted.md @@ -14,4 +14,4 @@ any questions or are in need of assistance. | libgnome-volume-control fixes | Unclaimed | GNOME's volume mixer is implemented in the `libgnome-volume-control` plugin. Unfortunately, this interacts poorly with WirePlumber/Pipewire and does not seem to respect node graph permissions. This leads to the default sink being the "raw" hardware device on GNOME, bypassing our DSP, which is completely unsupported. `libgnome-volume-control` needs to be fixed so that it hides the raw hardware sink and selects the correct default sink. | chadmed | | Rewrite tuxvdmtool to userspace i2c | **Unclaimed** | [tuxvdmtool](https://github.com/AsahiLinux/tuxvdmtool) uses a [sysfs API](https://github.com/AsahiLinux/linux/commit/786523ac62f0aeec37bf9c6b991e8bf2fadc590d) which isn't particularly nice and probably not upstreamable. After publishing tuxvdmtool we came to the conclusion that using linux userspace I2C client driver API is a better choice and should work. See https://github.com/AsahiLinux/tuxvdmtool/issues/1 | janne | | Fix serial port resets | **Unclaimed** | When using the apple silicon debug uart with two connected Apple silicon devices the serial port on the host device (`/dev/ttySAC0`) resets within seconds after `tuxvdmtool reboot serial`. Find the cause for this and fix the issue. This tasks is a little annoying since m1n1's hypervisor clobbers the hardware uart0 for its own use. | janne | -| Keyboard layout cleanup (XKB/hid_apple) | Unclaimed | Apple keyboard support across the Linux desktop stack has been hit-and-miss, across layouts and hardware keyboards. Since our keyboard drivers are not upstream yet, we have the chance to do some major cleanup. In particular, the keyboards on these machines have a soft *Fn* key that is handled entirely in software. The `hid_apple` driver currently does this in the kernel, but this is the wrong approach. This key should be handled in userspace in XKB/Wayland (Xorg cannot do it, but it's deprecated), so that we can have more comprehensive Fn key mappings including letting users customize the key bindings like they would any other modifier key, or offer special symbols like macOS does. This should probably be done by introducing new XKB keyboard models, which do this mapping in userspace. To test this, use the `fnmode=0` module parameter for `hid_apple` to disable all Fn key processing. We will later want to introduce a new fnmode that *only* does Fn key combination emulation for the edit keys (insert/delete/home/end/pgup/pgdown), which is the minimum required for a usable TTY and Xorg, and leave the rest to XKB, defaulting to this mode on Apple Silicon machines. Besides the Fn story, there are also many regional Mac layouts that need to be fixed in XKB configuration, and everyone with a non-English keyboard is welcome to help out with that effort. [Relevant xkeyboard-config issue](https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/379)| marcan | +| Keyboard layout cleanup (XKB/hid_apple) | Unclaimed | Apple keyboard support across the Linux desktop stack has been hit-and-miss, across layouts and hardware keyboards. Since our keyboard drivers are not upstream yet, we have the chance to do some major cleanup. In particular, the keyboards on these machines have a soft *Fn* key that is handled entirely in software. The `hid_apple` driver currently does this in the kernel, but this is the wrong approach. This key should be handled in userspace in XKB/Wayland (Xorg cannot do it, but it's deprecated), so that we can have more comprehensive Fn key mappings including letting users customize the key bindings like they would any other modifier key, or offer special symbols like macOS does. This should probably be done by introducing new XKB keyboard models, which do this mapping in userspace. To test this, use the `fnmode=0` module parameter for `hid_apple` to disable all Fn key processing. We will later want to introduce a new fnmode that *only* does Fn key combination emulation for the edit keys (insert/delete/home/end/pgup/pgdown), which is the minimum required for a usable TTY and Xorg, and leave the rest to XKB, defaulting to this mode on Apple Silicon machines. Besides the Fn story, there are also many regional Mac layouts that need to be fixed in XKB configuration, and everyone with a non-English keyboard is welcome to help out with that effort. [Relevant xkeyboard-config issue](https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/379)| janne |