docs(mkdocs): add ahk exe troubleshooting section

This commit is contained in:
LGUG2Z
2024-05-10 14:50:41 -07:00
parent 1accbf65ca
commit c47cf4718b
+124 -106
View File
@@ -1,106 +1,124 @@
# Troubleshooting # Troubleshooting
## Komorebi is unresponsive when the display wakes from sleep ## AutoHotKey executable not found
This can happen in rare cases when your monitor state is not preserved after it If you try to start komorebi with AHK using `komorebic start --ahk`, and you have
wakes from sleep. not installed AHK using `scoop`, you'll probably receive an error:
### Problem ```text
Error: could not find autohotkey, please make sure it is installed before using the --ahk flag
Your hotkeys in _whkd_ work, but it feels as if _komorebi_ knows nothing about ```
the previous state (you can't control previous windows, although newly launched ones
can be manipulated as normal). Depending on how AHK is installed the executable on your system may have a
different name. In order to account for this, you may set the `KOMOREBI_AHK_EXE`
### Solution environment variable in your
[PowerShell profile](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles?view=powershell-7.4)
Some monitors, such as the Samsung G8/G9 (LED, Neo, OLED) have an _adaptive to match the name of the executable as it is found on your system.
sync_ or _variable refresh rate_ setting within the actual monitor OSD that can
disrupt how the device is persisted in the _komorebi_ state following suspension. After setting `KOMOREBI_AHK_EXE` make sure to either reload your PowerShell
profile or open a new terminal tab.
To fix this, please try to disable _Adaptive Sync_ or any other _VRR_ branded
alias by referring to the manufacturer's documentation. ## Komorebi is unresponsive when the display wakes from sleep
!!! warning This can happen in rare cases when your monitor state is not preserved after it
wakes from sleep.
Disabling VRR within Windows (e.g. _Nvidia Control Panel_) may work and can indeed
change the configuration you see within your monitor's OSD, but some monitors ### Problem
will re-enable the setting regardless following suspension.
Your hotkeys in _whkd_ work, but it feels as if _komorebi_ knows nothing about
### Reproducing the previous state (you can't control previous windows, although newly launched ones
can be manipulated as normal).
Ensure _komorebi_ is in an operational state by executing `komorebic start` as
normal. ### Solution
If _komorebi_ is already unresponsive, then please restart _komorebi_ first by Some monitors, such as the Samsung G8/G9 (LED, Neo, OLED) have an _adaptive
running `komorebic stop` and `komorebic start`. sync_ or _variable refresh rate_ setting within the actual monitor OSD that can
disrupt how the device is persisted in the _komorebi_ state following suspension.
1. **`komorebic state`**
To fix this, please try to disable _Adaptive Sync_ or any other _VRR_ branded
```json alias by referring to the manufacturer's documentation.
{
"monitors": { !!! warning
"elements": [
{ Disabling VRR within Windows (e.g. _Nvidia Control Panel_) may work and can indeed
"id": 65537, change the configuration you see within your monitor's OSD, but some monitors
"name": "DISPLAY1", will re-enable the setting regardless following suspension.
"device": "SAM71AA",
"device_id": "SAM71AA-5&a1a3e88&0&UID24834", ### Reproducing
"size": {
"left": 0, Ensure _komorebi_ is in an operational state by executing `komorebic start` as
"top": 0, normal.
"right": 5120,
"bottom": 1440 If _komorebi_ is already unresponsive, then please restart _komorebi_ first by
} running `komorebic stop` and `komorebic start`.
}
] 1. **`komorebic state`**
}
} ```json
``` {
"monitors": {
This appears to be fine -- _komorebi_ is aware of the device and associated "elements": [
window handles. {
"id": 65537,
2. **Let your display go to sleep.** "name": "DISPLAY1",
"device": "SAM71AA",
Simply turning the monitor off is not enough to reproduce the problem; you must "device_id": "SAM71AA-5&a1a3e88&0&UID24834",
let Windows turn off the display itself. "size": {
"left": 0,
To avoid waiting an eternity: "top": 0,
"right": 5120,
- _Control Panel_ -> _Hardware and Sound_ -> _Power Options_ -> _Edit Plan "bottom": 1440
Settings_ }
}
_Turn off the display: 1 minute_ ]
}
Allow a minute for the display to reset, then once it actually shuts off }
allow for any additional time as prompted by your monitor for the cycle to ```
complete.
This appears to be fine -- _komorebi_ is aware of the device and associated
3. **Wake your display again** by pressing any key. window handles.
_komorebi_ should now be unresponsive. 2. **Let your display go to sleep.**
4. **`komorebic state`** Simply turning the monitor off is not enough to reproduce the problem; you must
let Windows turn off the display itself.
Don't stop _komorebi_ just yet.
To avoid waiting an eternity:
Since it's unresponsive, you can open another shell instead to execute the above command.
- _Control Panel_ -> _Hardware and Sound_ -> _Power Options_ -> _Edit Plan
```json Settings_
{
"monitors": { _Turn off the display: 1 minute_
"elements": [
{ Allow a minute for the display to reset, then once it actually shuts off
"id": 65537, allow for any additional time as prompted by your monitor for the cycle to
"name": "DISPLAY1", complete.
"device": null,
"device_id": null, 3. **Wake your display again** by pressing any key.
}
] _komorebi_ should now be unresponsive.
}
} 4. **`komorebic state`**
```
Don't stop _komorebi_ just yet.
We can see the _komorebi_ state is no longer associated with the previous
device: `null`, suggesting an issue when the display resumes from a suspended Since it's unresponsive, you can open another shell instead to execute the above command.
state.
```json
{
"monitors": {
"elements": [
{
"id": 65537,
"name": "DISPLAY1",
"device": null,
"device_id": null
}
]
}
}
```
We can see the _komorebi_ state is no longer associated with the previous
device: `null`, suggesting an issue when the display resumes from a suspended
state.