App will be stuck when reconnecting to Philips display

[LitchiCherry]

Display model: Philips 245E1
Issue: Disconnecting extra display is OK. But app will be stuck when reconnecting to Philips display.

[didriksg]

Thanks for the report! I don't have a Philips to reproduce on, so a few questions to narrow it down:

1. Which Crisp and macOS version, and is this an Apple Silicon Mac?
2. By "reconnecting", do you mean Crisp's own Disconnect display toggle, or physically unplugging and replugging the cable?
3. What does "stuck" look like: the whole app beachballs, the menu just won't open, or the display stays black? Does it recover on its own or only after force-quitting?
4. This is the most useful one: while it's stuck, open Activity Monitor, select Crisp, and choose "Sample Process" from the (...) menu, then attach the saved file here. That shows exactly which call it's hanging in.

[didriksg]

1.5.0 is out, and it carries a rework of how Crisp disconnects and reconnects displays.

https://github.com/didriksg/Crisp/releases/tag/v1.5.0

I can't promise it fixes your Philips, since I still haven't managed to reproduce it here, but the reconnect path is quite different now and it's worth trying before we dig further. Note this is the first version with built-in updates, so you install it by hand this time, then it's one click after.

If it still gets stuck, the questions from my earlier comment all still stand. The Sample Process file is by far the most useful of them, since it shows exactly which call it's hanging in.

[LitchiCherry]

Thanks for the report! I don't have a Philips to reproduce on, so a few questions to narrow it down:

1. Which Crisp and macOS version, and is this an Apple Silicon Mac?
   - Macbook M3 with macos 15.6.
2. By "reconnecting", do you mean Crisp's own Disconnect display toggle, or physically unplugging and replugging the cable?
   - With a hub, not directly connected to display
3. What does "stuck" look like: the whole app beachballs, the menu just won't open, or the display stays black? Does it recover on its own or only after force-quitting?
   - The whole macos was frozen and can not be operated. Extra display is black without output.
4. This is the most useful one: while it's stuck, open Activity Monitor, select Crisp, and choose "Sample Process" from the (...) menu, then attach the saved file here. That shows exactly which call it's hanging in.
   - Just can not operate system when stuck.

After updated to latest version, issue still exit. Disconnection-> reconnection -> stuck. But after a long time (30 sec), extra display will be reconnected successfully finnally and macos will also be operatable.

[didriksg]

Thanks for the details, and sorry 1.5.0 didn't do it.

The part where the whole Mac freezes for 30 seconds and then everything comes back on its own tells me this isn't a hang inside Crisp: a stuck app can't freeze the whole system. It looks like WindowServer waiting while the display renegotiates through the hub. Crisp can still be the trigger, since its Disconnect toggle asks macOS to drop the display, so two things would settle it:

1. Is the freeze from Crisp's Disconnect toggle in Tools, or from physically unplugging and replugging at the hub? And does the same replug freeze the Mac when Crisp isn't running at all? If it freezes without Crisp, it's the hub or the monitor. If only with Crisp, it's mine.

2. You can't sample a frozen system, but the log survives. Right after it recovers, run this in Terminal and attach the file:

   log show --last 3m --predicate 'process == "WindowServer" OR process == "Crisp"' > ~/Desktop/crisp-reconnect.log
   

Which hub is it, and how is the Philips attached to it (HDMI, DisplayPort, USB-C)?

[LitchiCherry]

Thanks for the details, and sorry 1.5.0 didn't do it.

The part where the whole Mac freezes for 30 seconds and then everything comes back on its own tells me this isn't a hang inside Crisp: a stuck app can't freeze the whole system. It looks like WindowServer waiting while the display renegotiates through the hub. Crisp can still be the trigger, since its Disconnect toggle asks macOS to drop the display, so two things would settle it:

1. Is the freeze from Crisp's Disconnect toggle in Tools, or from physically unplugging and replugging at the hub? And does the same replug freeze the Mac when Crisp isn't running at all? If it freezes without Crisp, it's the hub or the monitor. If only with Crisp, it's mine.
2. You can't sample a frozen system, but the log survives. Right after it recovers, run this in Terminal and attach the file:

   log show --last 3m --predicate 'process == "WindowServer" OR process == "Crisp"' > ~/Desktop/crisp-reconnect.log
   

Which hub is it, and how is the Philips attached to it (HDMI, DisplayPort, USB-C)?

Really thanks for your reply.
For Q1
Freeze caused by Crisp and only happens when I try to reconnect the disconnected display.
Without Crisp, unplugging and replugging will not cause freeze issue.

For Q2
Log as below. I find that freeze time is not stable. Sometimes longer and sometimes shoter.

BTW it is a Lenovo hub with a type c input hole. There is no typec c hole on the display. So I have to use it to connect my display.
----------------log----------------------

crisp-reconnect.log

[didriksg]

Thank you for the log, and for pinning it to reconnect only; that narrows it more than anything so far.

What the capture shows: WindowServer goes completely silent from 22:32:18 to 22:32:47, 29.5 seconds with no output at all, and the first thing it does on waking is process the Philips leaving (hot plug 0, set_enabled=0, uuid cleared). After that the display cycles out and in five more times over the next two minutes. Nothing display-related precedes the hole, which fits your description exactly: the freeze is the whole window server blocking, not Crisp hanging, and Crisp's reconnect is what asks for it.

What it does not show is our side, because 1.5.0 has no logging on that path. That is fixed on main now (#100): Crisp logs which action opened the transaction and, separately, how long the window server took to commit it. On my hardware a reconnect commits in under a second; on yours I expect that line to say about thirty. 1.6.0 is close and carries it; if you are on the in-app updater you will get it without doing anything. Once you have it, the capture to send is

log show --predicate 'subsystem == "com.crisp.app"' --last 10m --style compact

taken right after one reconnect.

One question in the meantime: is disconnecting through Crisp always clean for you, and only the reconnect freezes? Your message reads that way, and if so it matters, because enabling a display needs the link to retrain through the hub and disabling does not.

[didriksg]

1.6.0 is out with the fix I described: Crisp keeps DDC off the bus while a display is enabled or disabled. WindowServer's enable was waiting behind an I2C read in flight, and the whole machine stalled with it, which matches the 29.5 second silence in your capture. Crisp also logs the display path now.

If you update and try the reconnect that used to hang, does it still freeze? If it does, this is the capture that would tell me where it stops:

log show --predicate 'subsystem == "com.crisp.app"' --last 10m --style compact