display: Add wait option to handle monitor disconnection #183
Conversation
|
I modified the patch so it only waits for disconnection before setting the mode and performing the swap, relying on the fact that the monitor is already waking up from stage1 m1n1. This works and allow the monitor to display something during the wait when a chainload is performed. I tried to add u-boot payloads but for some reason that caused the monitor initialization to fail. Will investigate this evening. |
|
Gzip your U-Boot image. This is explained in the m1n1 user guide doc. It's an issue with the raw kernel format not having an accurate length field.
…On 2022年3月28日 15:18:37 JST, VinDuv ***@***.***> wrote:
I modified the patch so it only waits for disconnection before setting the mode and performing the swap, relying on the fact that the monitor is already waking up from stage1 m1n1. This works and allow the monitor to display something during the wait when a chainload is performed.
I tried to add u-boot payloads but for some reason that caused the monitor initialization to fail. Will investigate this evening.
--
Hector Martin "marcan" ***@***.***)
Public key: https://mrcn.st/pub
|
|
Thanks for the heads-up! That was indeed the problem. It seems to work fine with payloads now. |
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>
|
Hello, good morning from EDT! Wanted to chime in with my personal experience with this patch. I noticed a similar display bug you are describing, with a Samsung C27JG5X monitor. asahi-installer would successfully complete, but no display upon reboot. This is the monitor I will be describing in this comment! EDIT: wanted to mention this is all connected over HDMI, presumably, to a 2020 M1 mini To install this patch, I have cloned the asahi-installer and edited the source to add the m1n1 var I will comment that, the base asahi-installer does not make this a rather easy process. I do not have much background with this project, admittedly--the recent Alpha release is what finally caught my eye, however I notice the installer does not allow the end-user (or expert-user for that matter) to modify m1n1 boot arguments. At minimum this patch would be more easily accessible with an accompanying asahi-installer patch, allowing the end (or expert!) user to add boot variables. After rebooting my Mac mini with this patch applied, I can now see Arch Linux ARM with linux-asahi at full resolution, with the entire Asahi Linux Desktop package installed and functioning as well as it would otherwise. Wonderful experience overall, & i am hoping this will be upstreamed until GPU support makes it in! |
|
Okay, it looks like it works. The parser still requires “wait[:x],” to come before the specified resolution (if any), but I don’t think it’s worth making it more complicated to handle this. |
VinDuv
changed the title
|
|
||
| if (!config || !strcmp(config, "auto")) | ||
| if (!config) |
There was a problem hiding this comment.
I would keep the mode parsing code as is. I think it makes sense to keep it as first parameters for the display= variable. Have a look how I added support for comma separated parameters in #212 for retina
|
|
||
| if (!config || !strcmp(config, "auto")) | ||
| if (!config) |
There was a problem hiding this comment.
I would keep the mode parsing code as is. I think it makes sense to keep it as first parameters for the display= variable. Have a look how I added support for comma separated parameters in #212
| int max_retries = wait_delay * 1000 / DISPLAY_STATUS_DELAY; | ||
|
|
||
| for (int retries = 0; retries < max_retries; retries += 1) { | ||
| hpd = dcp_ib_get_hpd(iboot, &timing_cnt, &color_cnt); |
There was a problem hiding this comment.
dcp_ib_get_hpd can be called with NULL for timing_cnt and color_cnt, would be simpler here since we are just waiting for hpd == 0
| int max_retries = wait_delay * 1000 / DISPLAY_STATUS_DELAY; | ||
|
|
||
| for (int retries = 0; retries < max_retries; retries += 1) { | ||
| hpd = dcp_ib_get_hpd(iboot, &timing_cnt, &color_cnt); |
There was a problem hiding this comment.
dcp_ib_get_hpd can be called with NULL for timing_cnt and color_cnt
|
I think this is obsolete with the DCP shutdown hack. |
Add an explicit wait for monitor reset in
display.c, triggered by thedisplay=wait(ordisplay=wait,<mode…>) boot parameter.TODO:
Check that it works on monitors other than mineCheck that it works with payloadsCurrently the wait for the monitor to disconnect/reconnect is done betweenThe wait is now done before the swap, relying on stage1 m1n1 to wake up the monitor. However, this will fail to initialize the monitor if too much time passes between stage1 m1n1 and stage2 m1n1, allowing the monitor to fully go back to sleep between the two. That is probably not a huge concern.dcp_ib_swap_beginanddcp_ib_swap_set_layer.