Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mac mini 12+ DCP initialization fails with some monitors #159

Open
VinDuv opened this issue Jan 29, 2022 · 45 comments
Open

Mac mini 12+ DCP initialization fails with some monitors #159

VinDuv opened this issue Jan 29, 2022 · 45 comments

Comments

@VinDuv
Copy link
Contributor

VinDuv commented Jan 29, 2022

I have two monitors: An iiyama ProLite E2473HDS (1080p) and a Philips 279P1 (4K). They do not work with m1n1 from a 12.1 Mac mini (connected over HDMI).
When m1n1 starts, the 1080p monitor wakes up from sleep (power LED turns blue), and a few seconds later displays “No signal” and goes back to sleep. m1n1 logs (including the DCP syslog messages) indicate nothing out of the ordinary; the display is correctly recognized at the correct resolution/refresh rate. In fact, the log is identical to the one produced when the mini is connected to a 1080p capture card.
The 4K monitor does not seem to even wake up.

I’ve messed with m1n1’s display init code (mostly with the 1080p monitor since it’s not my primary display) and found out the following:

  • The monitor wakes up from sleep when dcp_ib_swap_begin is called.
  • Calling dcp_ib_set_mode after dcp_ib_swap_begin does not change anything at that point.
  • Calling dcp_ib_get_hpd in a loop after dcp_ib_swap_begin shows that connected goes back to 0 after 1-2 seconds, then goes back to 1 after ~400ms.
  • Calling dcp_ib_set_mode after connected is back to 1, then completing the swap (dcp_ib_swap_set_layer/dcp_ib_swap_end) makes the monitor work correctly; it will actually show m1n1 logo/console. It still takes a couple of seconds after completing the swap for the image to actually appear.
  • When rebooting, the situation is messier; after the call to dcp_ib_swap_begin, the monitor will still disconnect/reconnect, but after 5-6 seconds, not 1-2 seconds. It is, however, not necessary to wait for the disconnection: calling dcp_ib_set_mode a couple of seconds after dcp_ib_swap_begin seems to prevent the disconnection, and the monitor works afterwards.

I managed to make both my monitors work by making these changes: wait up to 5 seconds for the display to disconnect; if it does, wait for it to reconnect and call dcp_ib_set_mode; if it doesn’t, call dcp_ib_set_mode anyway.

This has the obvious issue of slowing down startup by at least 5 seconds on all monitors; it also seems very fragile and timing-dependent. I’m guessing there must be a better solution, since the monitors work (most of the time) in m1n1 with 11.6 iBoot, and it doesn’t seem to wait 5 seconds for the monitor to disconnect/reconnect… (I’ve tried to measure the time iBoot takes before starting m1n1, and it seems 11.6 is only slower than 12.1 by 900ms)
@tpwrules
Copy link
Contributor

I have an ACER G247HL which never worked with iBoot or m1n1's display initialization. This patch gets it working properly. For the record, it says it waited 400ms to connect, 1400 ms to disconnect, then 300ms to connect again. When I chainload, it says it waited 0ms for connection, but didn't disconnect again.

I also have an HP LA2205wg which worked sometimes, but had timing issues so I would have to reset the monitor often. This patch gets it to work all the time. On that one it says it waited 700ms to connect, but did not disconnect again.

This does introduce a 5 second delay on chainloading which is somewhat annoying. But it does mean I can actually reliably see things now! Thank you for your investigation.

@marcan marcan mentioned this issue Mar 27, 2022
Closed
@marcan
Copy link
Member

marcan commented Mar 27, 2022

Now that we have m1n1 chainloading from the ESP, I think the right solution here is to both make stage 2 always re-probe the display (that gives it a second chance to work for everyone) and then offer a m1n1 option to both configure the display mode and optionally introduce a longer timeout. That will allow people with problematic monitors to make it work, without unconditionally increasing boot times for everyone.

@pat42smith
Copy link

"option to ... configure the display mode": I like that idea. With my 4k display, currently the only available resolution is 1920x2160, which is distorted enough that I wouldn't want to use it for any length of time.

@marcan
Copy link
Member

marcan commented Mar 27, 2022

I didn't realize it did 2:1 scaled modes like that... I can fix that in the m1n1 mode selection. Pushed as 8af401a for the future (won't help you until we make stage2 also do this and I cut a release and you enable it though).

@marcan
Copy link
Member

marcan commented Mar 27, 2022

Oh god while looking into this I just realized why sometimes displays don't init sometimes. We're treating the HPD flag as 32 bits but it's actually just a bool, 8 bits. The rest is uninitialized, though I didn't notice it can be nonzero until now. If the top bit of the 32 happens to be set, it gets cast to signed later and interpreted as an error, and then m1n1 thinks no monitor is connected.

@marcan
Copy link
Member

marcan commented Mar 27, 2022 •
edited

Okay, for the folks with issues: please make a backup of /boot/efi/m1n1/boot.bin (in the same folder) and replace it with this one: https://mrcn.st/t/boot_display-test.bin (make sure to rename it to boot.bin).

Let me know if that improves things by default, for folks with no display output at all. Then, if you want to set the mode:

echo display=1920x1080 >> /boot/efi/m1n1/boot.bin

You can also use 1920x1080@60 to set the rate, or even 1920x1080@59.94 for fractional rates (but the parser is really dumb, always use two decimals).

You can also do:

echo display=auto >> /boot/efi/m1n1/boot.bin

And that will re-invoke the mode autoconfig logic (@pat42smith this should help with your 4K issue).

Obviously only do the echo once. For each time m1n1 finds the display= line it'll set the mode, so if you append it multiple times you'll wind up with the mode changing repeatedly.

By the way, the framebuffer size is limited and currently unchecked, so 4K modes may not work / may make everything crash. You've been warned. You can restore the boot.bin from macOS if this breaks things, as long as you backed up boot.bin inside /boot/efi, since macOS can access that FAT32 partition.

@rockinrobstar
Copy link

Just tested on my Lenovo L27m-28 (both default and with display setting) and no luck. Can confirm the file works fine otherwise on my Dell U4320Q @ 1920x1080.

One thing I did notice is that the Lenovo does have a very aggressive sleep mode (~ 2 sec) - so not sure if that is a factor.

@patlux
Copy link

patlux commented Mar 27, 2022 •
edited

I have the same problem with my Xiaomi Curved Monitor 34".

I tried all variations but it doesn't help:

cd /boot/efi/m1n1
sudo su
cp boot.bin boot.bin.bkp
rm boot.bin
wget https://mrcn.st/t/boot_display-test.bin

# first try
cp boot_display-test.bin boot.bin
reboot

# 2.
cp boot_display-test.bin boot.bin
echo display=1920x1080 >> /boot/efi/m1n1/boot.bin
reboot

# 3.
cp boot_display-test.bin boot.bin
echo display=1920x1080@60 >> /boot/efi/m1n1/boot.bin
reboot

# 4.
cp boot_display-test.bin boot.bin
echo display=1920x1080@59.94 >> /boot/efi/m1n1/boot.bin
reboot

# 5.
cp boot_display-test.bin boot.bin
echo display=auto >> /boot/efi/m1n1/boot.bin
reboot

@VinDuv
Copy link
Contributor Author

VinDuv commented Mar 27, 2022

The modified boot.bin also fails to initialize the monitor in my case. I replaced it with a freshly compiled m1n1.bin to be able to recover m1n1 logs.

  • Without display= option, stage2 m1n1 detects that the display is already initialized (by stage1 m1n1) and does nothing.
  • With display=auto, stage2 m1n1 seems to correctly re-perform the DCP init:
Found a variable at 0x802318000: display=auto
dart: dart /arm-io/dart-dcp at 0x23130c000 is a t8020 (locked)
dart: dart /arm-io/dart-disp0 at 0x231304000 is a t8020
rtkit(dcp): booting with version 12
rtkit(dcp): unknown system endpoint 0x0a
rtkit(dcp): pre-allocated buffer (ep 0x1, dva 0xf00237000, phys 0x9e6213000)
EPIC: started interface 0 (disp0-service)
display: waited 0 ms for display status
display: connected:1 timing_cnt:45 color_cnt:12
display: timing mode: valid=1 1920x1080 60.00 Hz
display: color mode: valid=1 colorimetry=1 eotf=1 encoding=1 bpp=32
display: swapped! (swap_id=3)
Found a variable at 0x80231800d: chosen.asahi,efi-system-partition=b85d68d6-f947-4a31-8d76-cc46bca458a6
No more payloads at 0x802318054

It looks like the chainload is so fast, the monitor hasn’t started its reset cycle yet (waited 0 ms for display status), so it doesn’t prevent the monitor disconnection.

@tpwrules @rockinrobstar @patlux Something you can try (It seems to work in my case): Turn off the Mac, hold the power button until the boot menu shows up, and select Asahi Linux. The Mac reboots when you do this, but in my case the monitor doesn’t have the time to fully go to sleep, so the DCP initialization by m1n1 works.

@patlux
Copy link

patlux commented Mar 27, 2022 •
edited

@VinDuv tried the steps you described but it didn't helped. Neither with nor without display=auto.

VinDuv added a commit to VinDuv/m1n1 that referenced this issue Mar 27, 2022
@VinDuv
display: Add wait option to handle monitor disconnection
734b1e9 
Some monitors disconnect when getting out of sleep mode; they rely on the OS
hotplug support to work properly. To make them work properly in m1n1, it is
necessary to:

1. Wait for DCP to detect the monitor.
2. Set the mode and start a swap. This causes the monitor to start getting out
   of sleep mode.
3. Wait for the monitor to disconnect. Unfortunately this step takes close to
10 seconds.
4. Wait for the monitor to reconnect.
5. Set the mode again; from this point the monitor will stay up.
6. Finish the swap.

Since this process delays boot for 10 seconds on monitors that don’t
disconnect, it is not enabled by default.

To enable it, use the following boot parameter:
display=wait
To specify the resolution:
display=wait,1980x1080
(The parameters cannot be swapped)

Should fix AsahiLinux#159.

Signed-off-by: Vincent Duvert <vincent@duvert.net>
@VinDuv
Copy link
Contributor Author

VinDuv commented Mar 27, 2022

I started working on adapting my previous “wait for display reset” patch to enable it conditionally in m1n1: #183
You can download a build here. The display=wait parameter is already appended so it should work directly once copied in the EFI partition.

@patlux
Copy link

patlux commented Mar 27, 2022 •
edited

@VinDuv really nice work. Now it works but now it freezes at the „Running proxy“ line.

70A51A64-4A96-43FF-B0A7-E9C46FFE0C47

/edit: maybe it has something to do with the installation of docker previously. I will reinstall Asahi linux to be sure..

@VinDuv
Copy link
Contributor Author

VinDuv commented Mar 27, 2022

@patlux Don’t reinstall! This is normal behavior. The boot.bin file I provided doesn’t include the U-Boot payload, so once m1n1 is started it waits for a payload to be sent over serial (from another computer). I’ll try to build a full version later; in the meantime, you can restore your original boot.bin from macOS.

@Skirmisher
Copy link

Skirmisher commented Mar 27, 2022 •
edited

@marcan:

Okay, for the folks with issues: please make a backup of /boot/efi/m1n1/boot.bin (in the same folder) and replace it with this one: https://mrcn.st/t/boot_display-test.bin (make sure to rename it to boot.bin).

This works for me, but only if I append display=1280x1024 (Apple Studio Display, 17" LCD, ADC). This tracks with the symptoms I was seeing (monitor LED was turning on, but no signal appeared). The display works correctly under macOS.

@marcan
Copy link
Member

marcan commented Mar 27, 2022

None of these displays "work" under macOS because Apple disabled iBoot display output entirely since 12.0 ;-)

There is no display output until the OS driver loads, which means no verbose boot, no iBoot messages, no Apple logo and no progress bar until the kernel is half booted, etc. In fact, you get those features back if you chainload macOS under m1n1 and the display was initialized properly.

Once Linux has a real display driver it will work like macOS. The problem we're trying to solve in this bug is bootloader display output, which is handicapped by the iBoot-mode interface that Apple provides for it. That's why we're having so much trouble with modes and timeouts and such.

@alyssarosenzweig
Copy link
Member

alyssarosenzweig commented Mar 27, 2022 via email

@pat42smith
Copy link

@marcan: Setting the display mode to 1920x1080 with your modified boot.bin works, thanks!

Setting 3840x2160 partially works - the top 2/3 of the screen seem fine, but the bottom 1/3 is just black.

On startup blankness - what I'm seeing is that often after a reboot (including 'shutdown -r now' in Linux), the screen will stay blank. Not always, but often. The only pattern I'm seeing is that the only times it didn't stay blank were when I had the display mode set with the new boot.bin. But even then, sometimes it stayed blank. So I don't know.

On the other hand, every time I completely shutdown the system and then restart it, the display works. Including one reinstall where I got to the "press enter to reboot" prompt inside Mac Recovery, I instead shut down the system from the apple menu. So for me at least, this is not a showstopper.

@Skirmisher Skirmisher mentioned this issue Mar 27, 2022
Closed
@tpwrules
Copy link
Contributor

tpwrules commented Mar 28, 2022 •
edited

marcan's patch lets me set my HP LA2205wg to its native resolution and get rid of the obnoxious nag, and for that I am grateful. But it doesn't fix the Acer. I did find on the HP that configuring it in its setup menu to always use the DVI input and disable auto-searching made it work 100% of the time, so if your monitor lets you do that it may help.

@VinDuv it would probably be good for your patch to add a configurable delay AND resolution

Maybe once DCP lands in Linux, this can be a configurable option somewhere. GRUB/U-boot being invisible in some circumstances on first boot would be unfortunate, but probably not a showstopper, even for USB boot. The user could then fix things for their particular setup once booted.

@marcan
Copy link
Member

marcan commented Mar 28, 2022

4K is not currently supported since the framebuffer is not big enough to support that mode on the Mini.

VinDuv added a commit to VinDuv/m1n1 that referenced this issue Mar 28, 2022
@VinDuv
display: Add wait option to handle monitor disconnection
b575d53 
Some monitors disconnect when getting out of sleep mode; they rely on the OS
hotplug support to work properly.

Since stage1 m1n1 initializes the display, the monitor is already getting out
of sleep mode when stage2 m1n1 starts execution. For the display to work,
stage2 m1n1 has to wait for the monitor to disconnect (which unfortunately
can take close to 10 seconds), wait for reconnection, and then proceed
as normal.

Since this process delays boot for 10 seconds on monitors that don’t
disconnect, it is not enabled by default.

To enable it, use the following boot parameter:
display=wait
To specify the resolution:
display=wait,1980x1080
(The parameters cannot be swapped)

Should fix AsahiLinux#159.

Signed-off-by: Vincent Duvert <vincent@duvert.net>
VinDuv added a commit to VinDuv/m1n1 that referenced this issue Mar 28, 2022
@VinDuv
display: Add wait option to handle monitor disconnection
42e5b6e 
Some monitors disconnect when getting out of sleep mode; they rely on the OS
hotplug support to work properly.

Since stage1 m1n1 initializes the display, the monitor is already getting out
of sleep mode when stage2 m1n1 starts execution. For the display to work,
stage2 m1n1 has to wait for the monitor to disconnect (which unfortunately
can take close to 10 seconds), wait for reconnection, and then proceed
as normal.

Since this process delays boot for 10 seconds on monitors that don’t
disconnect, it is not enabled by default.

To enable it, use the following boot parameter:
display=wait
To specify the wait delay (in seconds):
display=wait:5
To specify the resolution (can also include an explicit wait delay):
display=wait,1980x1080
(The parameters cannot be swapped)

Should fix AsahiLinux#159.

Signed-off-by: Vincent Duvert <vincent@duvert.net>
@VinDuv
Copy link
Contributor Author

VinDuv commented Mar 29, 2022

@patlux can you try boot_display_wait.bin? It should wait for the monitor to come up and then boot Linux.
@tpwrules I followed your suggestion of adding a way to control the wait delay; you can test it by downloading either m1n1.bin or boot.bin from https://vincent.duvert.net/dropbox/ and append a display=... line to them. The format is:

Parameter
<none> Display is initialized by stage2 m1n1 and if only if it wasn’t initialized in stage1
display=auto Display is (re-)initialized by stage2 m1n1 regardless of its current state
display=1280x1024 Display is (re-)initialized by stage2 m1n1, preferring 1280x1024 resolution
display=wait
display=wait,auto		 Display is (re-)initialized by stage2 m1n1 after waiting 10 seconds for monitor reset
display=wait:6
display=wait:6,auto		 Display is (re-)initialized by stage2 m1n1 after waiting 6 seconds for monitor reset
display=wait,1280x1024 Display is (re-)initialized by stage2 m1n1 after waiting 10 seconds for monitor reset, preferring 1280x1024 resolution
display=wait:6,1280x1024 Display is (re-)initialized by stage2 m1n1 after waiting 6 seconds for monitor reset, preferring 1280x1024 resolution

@Skirmisher if you’re interested, you can download m1n1_1280_modes.bin that will dump all the timing modes that the DCP thinks are supported by the monitor (after setting it to 1280x1024). On my monitor it detects some resolutions that are probably not supported (3840x2160 on a 1080p monitor…), and I guess it’s the same in your case…

@Skirmisher
Copy link

@VinDuv:

@Skirmisher if you’re interested, you can download m1n1_1280_modes.bin that will dump all the timing modes that the DCP thinks are supported by the monitor (after setting it to 1280x1024). On my monitor it detects some resolutions that are probably not supported (3840x2160 on a 1080p monitor…), and I guess it’s the same in your case…

Yeah, you could say that...

display: waited 0 ms for display connected
display: connected:1 timing_cnt:18 color_cnt:3
display: timing mode: valid=1 1280x1024 60.02 Hz
display: color mode: valid=1 colorimetry=1 eotf=1 encoding=1 bpp=32
display: swapped! (swap_id=4)
fb init: 1280x1024 (30) [s=1280] @0xbe3a18000
fb console: max rows 60, max cols 64
fb: display logo
mode list:
 - valid=1 720x480 59.94 Hz
 - valid=1 720x480 60.00 Hz
 - valid=1 1280x720 59.94 Hz
 - valid=1 1280x720 60.00 Hz
 - valid=1 720x576 50.00 Hz
 - valid=1 1280x720 50.00 Hz
 - valid=1 1920x1080 59.94 Hz
 - valid=1 1920x1080 60.00 Hz
 - valid=1 1920x1080 50.00 Hz
 - valid=1 3840x2160 23.98 Hz
 - valid=1 3840x2160 24.00 Hz
 - valid=1 3840x2160 25.00 Hz
 - valid=1 3840x2160 29.97 Hz
 - valid=1 3840x2160 30.00 Hz
 - valid=1 3840x2160 50.00 Hz
 - valid=1 3840x2160 59.94 Hz
 - valid=1 3840x2160 60.00 Hz
 - valid=1 1280x1024 60.02 Hz

(I'm assuming the last line is just the manually-set mode)

@patlux
Copy link

patlux commented Mar 30, 2022 •
edited

@VinDuv

@patlux can you try boot_display_wait.bin? It should wait for the monitor to come up and then boot Linux.

It works :) Thank you!

@pat42smith
Copy link

@VinDuv: your boot_display_wait.bin fixed the issue I was seeing with the screen sometimes staying blank after a reboot.

@Skirmisher Skirmisher mentioned this issue Apr 1, 2022
Closed
@jannau
Copy link
Member

jannau commented Apr 3, 2022

For higher resolutions like 4k the framebuffer has to be reallocated. I have work in progress branches for that in https://github.com/jannau/m1n1/tree/display_fb_alloc and https://github.com/jannau/m1n1/tree/display_fb_alloc2
The main outstanding problem is that macOS crashes with those changes.

@jannau jannau mentioned this issue Apr 3, 2022
Closed
@jannau jannau mentioned this issue Apr 12, 2022
Closed
@GitHuhl
Copy link

GitHuhl commented Apr 13, 2022 •
edited

Hello everyone. First of all thanks so much marcan and Alyssa and everyone else for getting this kickass distro off the ground so quickly!

My monitor is a Samsung, most easily found with this name: LU32J590UQNXZA. I opened an issue about the blank screen once Asahi is initialized, didn't see this one. While I haven't tried any of the suggested fixes yet, I can get Asahi to output graphics more or less as expected by setting the monitor into picture-in-picture mode, (annoyingly needing to use another machine to activate the monitor before turning on my Mini) -- but that's a small temporary price to pay. Great work, everyone.

When trying to run normally on a dedicated HDMI input, I can't get the monitor to wake up from its 'sleep' mode, either, similar to the person that opened this issue. Let me know if there is any additional helpful information I can provide.

@marcan
Copy link
Member

marcan commented Apr 13, 2022

@GitHuhl That sounds like the same issue then; your monitor likely goes through a hotplug cycle when it wakes up. Using PiP mode keeps it awake and stops it from doing that.

Looks like we'll have to add an option to the installer to pre-configure m1n1 with a higher display time-out, for folks with this issue. I wonder if we can make this automagic; maybe m1n1 can report whether such a hotplug happened / the safe display init time in the device tree somehow. Then the installer can initially configure it with a large time-out, and the firstboot script can drop it down to something faster if it detects a safe monitor...

@VinDuv
Copy link
Contributor Author

VinDuv commented Apr 17, 2022

I like the idea of auto-configuration, but I think it will be tricky to implement. My monitors temporarily disconnect upon waking up only if they have been asleep for a few seconds. (I guess they need to disconnect only to get out of “deep sleep”, and they don’t “deep sleep” immediately upon losing signal from the computer?)
So that means that when m1n1 starts for the first time after rebooting from macOS, the monitor will not disconnect, m1n1 won’t detect hotplug and the first boot script will disable the wait…

So I think the only way to have an auto-detection working would be to have a special “display check” mode in m1n1 that would:

  1. Turn off the display, since stage1 m1n1 will have turned it on (assuming the DCP iBoot interface allows doing this)
  2. Wait some amount of time for the display to go to sleep (at least 10 seconds for the E2473HDS)
  3. Turn the display back on. Wait to see if it disconnects.

That would probably work, but having the display go to sleep in m1n1 for 10 seconds (probably more) would be worrying for the user, I think.

Maybe a better alternative would be to do the detection in the installer, from macOS? This would also require temporarily turning off the display, but at least the installer could warn about it beforehand…

I’ve done some preliminary testing and it looks like it’s possible to turn the display off (with pmset displaysleepnow), back on (with caffeinate -u) and get display properties (with the AppleCLCD2 IOKit class). I’ll see if it’s possible to do this from Python…

@VinDuv
Copy link
Contributor Author

VinDuv commented May 7, 2022

Update: I wrote a Python script that detects, from macOS, if a monitor disconnects when getting out of sleep mode. It also detects the monitor native resolution.

I’d like to confirm that it works with other people’s hardware before attempting to integrate it into the installer, so if you can, please run it and give me the results :)

The script is here and requires Python 3 to be installed in macOS. If you haven’t Python installed, you can use the following Terminal command that will download Python (from the Asahi Installer) and run the script directly:

curl https://vincent.duvert.net/dropbox/display-info.sh | sh

The script doesn’t require any special privileges; you can run it from a guest account. You can also run it directly from the recovery environment.

Thanks!

@DarkShadow44
Copy link

I'm one of the guys who needs "boot_display_wait.bin". My results are:

Mac model: Macmini9,1
disp0,t8103: external (U3277WB), connected, HDMI transport, 3840x2160, did not disconnect
dispext0,t8103: external, disconnected

@pat42smith
Copy link

pat42smith commented May 8, 2022 via email

@VinDuv
Copy link
Contributor Author

VinDuv commented May 8, 2022

Okay, so it looks like the test didn’t detect the disconnection :-/ Weird.
Some things I though about:

  • Maybe the display actually disconnects after the test completes. The test duration was 10 seconds, I changed it to 20.
  • My displays only disconnect on wakeup if they were asleep for more than ~10 seconds. The test currently waits 20 seconds, but maybe some displays need more? (In @pat42smith ’s case, it looks like it’s the reverse: the display only disconnects if it has been sleeping for a small duration, which only happens during reboots). To check this, I made the sleep delay configurable:
    • If the script is started without arguments, it will prompt for the duration (with a default of 20 seconds).
    • The script can be started with one or more duration arguments, and will run the test for all the durations specified. For instance, display-info.py 5 10 30 will perform the test after sleeping the display for 5 seconds, then perform it again after sleeping for 10 seconds, etc. To do this from curl, add the -s option to sh:
      curl https://vincent.duvert.net/dropbox/display-info.sh | sh -s 5 10 30.

@DarkShadow44
Copy link 

Test results:
Mac model: Macmini9,1
Sleep duration: 5.0
disp0,t8103: external (U3277WB), connected, HDMI transport, 3840x2160, did not disconnect
dispext0,t8103: external, disconnected
Detection in progress, please wait…
Test results:
Mac model: Macmini9,1
Sleep duration: 10.0
disp0,t8103: external (U3277WB), connected, HDMI transport, 3840x2160, disconnected after 8479ms for 667ms
dispext0,t8103: external, disconnected
Detection in progress, please wait…
Test results:
Mac model: Macmini9,1
Sleep duration: 30.0
disp0,t8103: external (U3277WB), connected, HDMI transport, 3840x2160, disconnected after 1975ms for 2656ms
dispext0,t8103: external, disconnected

@pat42smith
Copy link

pat42smith commented May 8, 2022 via email

@vtsingaras
Copy link

Mac model: Macmini9,1
Sleep duration: 20
disp0,t8103: external (Mi Monitor), connected, HDMI transport, 3440x1440, disconnected after 9678ms for 1425ms
dispext0,t8103: external, disconnected

@VinDuv
Copy link
Contributor Author

VinDuv commented May 14, 2022

@DarkShadow44: okay, looks like the script successfully detected the disconnection at 10 seconds, which is a bit weird because it should have worked the first time you tried it… Maybe there are some timing issues. Could you run the test multiple times with a 11 second delay and check if it says “disconnected after XXXX” every time?

@pat42smith The “Displays should be sleeping now” message is printed just before display sleep, and erased just after display wake-up. If you can see it on your monitor it means the monitor isn’t sleeping when it should, and that means the
test results will be wrong. I just changed the message to be more clear about that. Unexpected displays wake-ups may happen if an application decides to force the displays on during the test (or if you move the mouse/press a key) and I haven’t yet found a good way to detect or prevent that so displaying a message is all the test can do for now.

Regarding your test results, they look a bit inconsistent but they seem to confirm that your display only disconnects after short sleeps. Maybe try to run the test multiple times with a small delay (3 seconds) and see if it consistently says “disconnected after XXXX”?

@vtsingaras Thanks for your test result! It looks like your monitor starts disconnecting very late, close to the 10 seconds mark, so I’ll probably extend the wait delay a bit in the m1n1 patch.

@DarkShadow44
Copy link

Seems to disconnect consistently now... Tried 10 times with 11s.

@pat42smith
Copy link

pat42smith commented May 14, 2022 via email

@DarkShadow44
Copy link

How can it disconnect after > 10s when your test time 4, 3, and 2?

@tpwrules
Copy link
Contributor

tpwrules commented May 15, 2022 •
edited

Here are the results for my two monitors:

% curl https://vincent.duvert.net/dropbox/display-info.sh | sh 
[...]
Monitor sleep duration: [20] 30
Detection in progress, please wait…
Test results:
Mac model: Macmini9,1
Sleep duration: 30.0
disp0,t8103: external (LA2205), connected, DVI transport, 1680x1050, disconnected after 1378ms for 614ms
dispext0,t8103: external, disconnected

% curl https://vincent.duvert.net/dropbox/display-info.sh | sh
[...]
Monitor sleep duration: [20] 
Detection in progress, please wait…
Test results:
Mac model: Macmini9,1
Sleep duration: 20
disp0,t8103: external (G247HL), connected, HDMI transport, 1920x1080, disconnected after 2479ms for 404ms
dispext0,t8103: external, disconnected

It's worth nothing that the first monitor (the LA2205) I can get to stop disconnecting by turning off auto source switching in its menu. It is also a 1680x1050 native panel, but m1n1 currently detects it as 1920x1080. It can render that resolution fine, but it displays an unremovable dialog box whining of a non-optimal resolution. Please be sure to have a way for the user to select the monitor's resolution in the installer.

@VinDuv
Copy link
Contributor Author

VinDuv commented Jun 4, 2022

A better solution to the disconnect problem was recently found: It basically disables the display controller once the display settings have been configured, so if the monitor disconnects and reconnects, it will still receive data.
This removes the need to wait for disconnection and speeds up booting. It also makes input switching work on all monitors.
This has been integrated into m1n1 (714420a) but has not yet been released; if you want to test it, you can download this boot.bin and put it in your EFI partition.
Note that the current solution may still have issues if the monitor disconnects at a very specific time; a fix for this is in the works.
If your monitor’s resolution is less than 1920x1080, you will still need to add a display=<res> line at the end of the boot.bin file. I’m currently working on a patch for the installer to do this automatically (and allow changing a previous setting).

@pat42smith
Copy link

pat42smith commented Jun 5, 2022 via email

@janrinze
Copy link

Thanks for all these pointers. Finally managed to get 4K output to my monitor!

@xfim
Copy link

xfim commented Aug 2, 2022

Dear all,

I tried the boot.bin linked by @VinDuv on June 4th, but the machine does not work anymore with the kernel that I was using. It freezes during boot. Noticeably, during boot it still says that is expecting 1980x1080, although my monitor is 4K. Do I need anything newer? With such boot.bin do I still have to append display=auto to it? I am on gentoo combining asahi-sources.

Thank you,

@janrinze
Copy link

janrinze commented Aug 3, 2022

@xfim: this thread is old, that boot.bin does not match newer setups and the related changes have already been merged in the latest m1n1.

Did you backup the original boot.bin? use that one instead and also keep an original copy.

Restore the boot.bin from your backup and append display=3840x2160 for a 4k monitor. (assuming that's the resolution of your display)

For anyone else here trying to use old boot.bin files linked here, please don't!
Just install Asahi Linux as described by the project.

@xfim
Copy link

xfim commented Aug 4, 2022

OK, understood @janrinze , thank you for the clarification.
Fortunately, I made a backup and I can go back. The problem is that appending the resolution did not work, and that's why I tried it. But I will make it work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests