[TRACKER] linux-asahi-edge issues

[marcan]

This is a global tracker bug to group reports related to linux-asahi-edge. Since this is a bleeding-edge kernel, we know some things are broken and we make no promises that we'll get to reports in any amount of time. Please post any issues as comments on this bug, and we'll handle them or break them out into their own bugs as we deem appropriate. Please do not open new bugs for linux-asahi-edge issues that are not reproducible with the default linux-asahi kernel.

Only report issues here if they happen with linux-asahi-edge and NOT with linux-asahi. If you find a problem unrelated to the new features of linux-asahi-edge, you must test across at least 5 reboots on linux-asahi to make sure it never happens there and is truly a regression related to linux-asahi-edge.

Please make sure you have updated all your packages and have asahi-meta installed before reporting anything. Setups without asahi-meta installed are not supported and are expected to randomly break as we make changes to our packages. All Asahi installs since the first official alpha release come with asahi-meta preinstalled (and also asahi-desktop-meta for the desktop builds). If you choose to uninstall our infrastructure packages, you are on your own and we cannot provide support.

Known issues:

• USB: USB2/3 breaks after suspend/resume
• DCP: brightness is sometimes reported as 0 on boot, instead of the actual boot-time brightness
• DCP: brightness drops to min when the screen turns on (fixed by touching brightness keys)
• SPI+MTP: Keyboard/trackpad is not suspended properly (affects SPI/M1 and MTP/M2 differently)
• No backlight shutdown / screen-off on M2 (pending DCP support)
• General sleep excessive power consumption issues (this needs further debug)
• Xorg display scaling issues when changing display drivers. This is expected as Xorg is hopelessly broken when it comes to display scaling; we preconfigure new installs to work, but changes can and will break things. You should be able to get it fixed by manually changing the scale/DPI settings, but please don't report this, we can't do anything about it and upstream no longer supports Xorg.

When writing a comment, please run asahi-diagnose and attach the resulting logfile.

[aykevl]

Maybe this is already known but I'm reporting this here just in case...

Brightness control does not seem to work for me with the 6.1.0-rc6-asahi-4-1-edge-ARCH kernel, on a Macbook Pro (16 inch, M1 Pro, 2021):

• It doesn't work with the normal ways of changing brightness (brightness keys or slider in the KDE power taskbar widget). I think it was reported as the lowest brightness setting in KDE on startup. Even going all the way to the lowest setting doesn't affect brightness (the screen is still on).
• When I change /sys/class/backlight/apple-panel-bl/brightness manually, there is no change in display brightness (but the value is kept in the sysfs file).

(If there is any way I can help I'd certainly be willing to: brightness control is my number one issue with Asahi Linux right now).

[marcan]

Maybe this is already known but I'm reporting this here just in case...

Brightness control does not seem to work for me with the 6.1.0-rc6-asahi-4-1-edge-ARCH kernel, on a Macbook Pro (16 inch, M1 Pro, 2021):

* It doesn't work with the normal ways of changing brightness (brightness keys or slider in the KDE power taskbar widget). I think it was reported as the lowest brightness setting in KDE on startup. Even going all the way to the lowest setting doesn't affect brightness (the screen is still on).

* When I change `/sys/class/backlight/apple-panel-bl/brightness` manually, there is no change in display brightness (but the value is kept in the sysfs file).

(If there is any way I can help I'd certainly be willing to: brightness control is my number one issue with Asahi Linux right now).

Your mention of gpio-bl before the edit made me realize that shouldn't be there. Please update your kernel and try again. I don't know whether this will fix your issue, but that was definitely wrong.

[aykevl]

Whoa, I updated the kernel and the issue seems to be gone now? I can now adjust my screen brightness. I hope it stays that way, if not I'll report back.

Interestingly, before the update I booted into asahi-linux-edge, but the screen didn't turn on (or rather, it turned off just before the login screen). This happened twice. I had to reboot into the regular asahi-linux kernel to be able to install the kernel update.

(One nit I still have is that the brightness change steps are a bit too large to my taste. But that's a KDE issue. I suppose KDE wasn't made for screens with such a large range of brightness values).

(Somehow the kernel update also fixed a different issue I was about to report: before the update Alt + arrow keys would switch between TTYs which is rather inconvenient when you use them to go back/forward in web browsers).

(EDIT: sadly DCP support makes yakuake far too slow to be usable for me so I'm afraid I'll switch back to a non-DCP kernel even if that means no brightness control).

Hi, I can not mount my USB2 USB key with both asahi-linux-6.1rc6 and asahi-linux-edge through a USB dongle. Is it a common problem or I'm the first one reporting it?

EDIT: last time I've tried AsahiLinux there was 6.1 rc4 and it used to works as expected.

EDIT 2: connecting the USB key to the dongle and then the dongle to my MacBook did the trick.

EDIT 3: during boot both u-boot and grub see the USB key while the initramfs' shell doesn't. That's a problem for these like me who want to install another OS, like gentoo, over AsahiLinux.

[jannau]

• initial brightness at boot as reported by DCP in https://github.com/jannau/linux/tree/asahi-6.1-rc6-5_dcp-fixes
• M2 DCP support in https://github.com/jannau/linux/tree/asahi-6.1-rc6-4_dcp-m2 (avoiding dart changes), requires T8112 DCP support m1n1#265

Restoring brightness after DPMS requires updated brightness to DAC mappings. The current code based on the tables in the ADT results in an increasing brightness for each cycle.

[jannau]

• reject invalid modes in the CRTC's .atomic_check() - https://github.com/jannau/linux/tree/asahi-6.1-rc6-5_dcp-fixes
  On the M2 MacBook Pro 13" with DCP KDE's SystemSettings offers derived modes with lower resolution from the standard "2560x1600" resolution."2560x1600" is the only mode reported by DCP. Custom modes are currently not supported in DCP.

[Capta1nT0ad]

The 3.5mm jack is working in linux-asahi but not in linux-asahi-edge. I get no sound and KDE doesn't recognise my headphones. However, I do hear a crackle through the headphones when plugging them in our out.

EDIT: Forgot to mention I'm on M2 MBP
EDIT 2: Randomly fixed itself ¯_(ツ)_/¯

[acclaude]

Bose mini II SE speakers 'crackles' in linux-asahi-edge : bluetooth link (sounds + crackles)
I'm on MBP 14' M1

PS : 6.1.0-rc6-asahi-5-1-edge-ARCH

[marcan]

Please only report issues that are specific to the new features of linux-asahi-edge or regressions here. Unless you can reproduce a problem in edge and reliably never reproduce it in the regular kernel, it does not belong here.

[aykevl]

Update: for those reading this now, this is easily fixed by changing the resolution and logging out/in. You just need to change the resolution once (or twice) to trigger something that fixes the scaling issue. Somehow, the scaling is connected to DCP/no-DCP, and you need to redo this when you switch. (Or use Wayland instead of Xorg I guess).

---

Something is broken in desktop scaling under KDE, but only with linux-asahi-edge. Did not test other desktop environments.
Text is rendered at the correct size, but all the other elements are much smaller than they should be. Take a look at the below screenshot for example:

While buttons are mostly correct, other widgets (sliders, scrollbars, icons, etc) are way too small. The window also starts much smaller than with linux-asahi.
(This could very well be a KDE/X11 issue, but since this is a regression compared to linux-asahi I'm reporting it just in case - I suspect DPI isn't reported correctly somewhere in the stack).

EDIT: no environment variables related to scaling changed between the two kernels. These are the same whether I use asahi-linux or asahi-linux-edge: GDK_DPI_SCALE=0.5, GDK_SCALE=2, QT_AUTO_SCREEN_SCALE_FACTOR=0, QT_SCREEN_SCALE_FACTORS=None-1=2.5;

[marcan]

Something is broken in desktop scaling under KDE, but only with linux-asahi-edge. Did not test other desktop environments. Text is rendered at the correct size, but all the other elements are much smaller than they should be.

Is this with an external screen, or otherwise what device? Did you manually change any scaling settings? Scaling on Xorg is... "interesting" to put it mildly. There are several sources of information, and the DCP driver in edge should be capable of reporting the physical screen size where available, which probably affects this.

[jannau]

DCP doesn't report DisplayAttributes for the integrated displays. We need to add those to the devicetree. Can be calculated from the resolution and the dot-pitch property in disp0. I don't think this results in this issue though.

[aykevl]

Is this with an external screen, or otherwise what device?

Just the laptop screen itself. It's a 2021 Macbook Pro 16" M1 Pro.

Did you manually change any scaling settings?

The only thing I changed was that I changed "Global scale" in Display Configuration to 250% (from the default of, I think, 200%). I rebooted to linux-asahi-edge with Global scale set to 200% but that doesn't fix the issue (just makes it slightly less noticeable as the difference in scale is smaller).

Scaling on Xorg is... "interesting" to put it mildly.

True that. But it works surprisingly well in KDE, even better than with Wayland IMHO.

There are several sources of information, and the DCP driver in edge should be capable of reporting the physical screen size where available, which probably affects this.

I checked some sources of information. Here is xrandr -q:

 diff -u tmp/xrandr-fb.txt tmp/xrandr-dcp.txt
--- tmp/xrandr-fb.txt   2022-11-24 18:47:35.720265529 +0100
+++ tmp/xrandr-dcp.txt  2022-11-24 19:10:34.371000021 +0100
@@ -1,3 +1,3 @@
-Screen 0: minimum 320 x 200, current 3456 x 2160, maximum 4096 x 4096
-None-1 connected primary 3456x2160+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
-   3456x2160     60.00*+
+Screen 0: minimum 320 x 200, current 3456 x 2160, maximum 16384 x 16384
+eDP-1 connected primary 3456x2160+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
+   3456x2160     60.00*+  50.00    59.94    48.00    47.95  

It's different, but I don't see anything wrong here. I also checked xdpyinfo but while there were differences, I didn't see anything related to DPI or resolution.

Still, this should not be the issue. KDE/Qt clearly knows at what resolution to render because text looks correct. It's just all the other things that are wrong for some reason. But apparently DCP did affect rendering somehow.

EDIT: huh, now this same issue also affects linux-asahi. This is very weird, it has worked fine on linux-asahi all this time.

[aykevl]

Ok, I think I figured it out - sort of. Apparently the text scale setting is kept between the framebuffer and DCP, but the scale for other UI elements is not. So if I change the global scale on asahi-linux-edge, global scale only works properly on asahi-linux-edge (but not on asahi-linux), and vice versa.

...with this new information, I don't think there is a linux-asahi-edge bug. Good thing I played with the global scale setting, otherwise I wouldn't have found this.

Perhaps KDE/Plasma/X11/whatever stores the display ID with the global scale configuration and only applies it to the same display? (Where DCP is seen as a different display).

[marcan]

Yeah, that sounds about right. As I said, the whole mechanism is... "interesting" to say the least. We're likely to switch to Wayland by default when the GPU stuff lands, which will hopefully make this a bit less crazy.