docs/troubleshooting.md
Sometimes you may experience an application which leaves "ghost tiles" on a workspace, where there is space reserved for a window but no window visible.
You can ignore these windows by following these steps:
komorebic visible-windows to find details about the invisible windowIf you try to start komorebi with AHK using komorebic start --ahk, and you have
not installed AHK using scoop, you'll probably receive an error:
Error: could not find autohotkey, please make sure it is installed before using the --ahk flag
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
environment variable in your
PowerShell profile
to match the name of the executable as it is found on your system.
After setting KOMOREBI_AHK_EXE make sure to either reload your PowerShell
profile or open a new terminal tab.
This can happen in rare cases when your monitor state is not preserved after it wakes from sleep.
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).
Some monitors, such as the Samsung G8/G9 (LED, Neo, OLED) have an adaptive 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.
To fix this, please try to disable Adaptive Sync or any other VRR branded alias by referring to the manufacturer's documentation.
!!! warning
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
will re-enable the setting regardless following suspension.
Ensure komorebi is in an operational state by executing komorebic start as
normal.
If komorebi is already unresponsive, then please restart komorebi first by
running komorebic stop and komorebic start.
komorebic state
{
"monitors": {
"elements": [
{
"id": 65537,
"name": "DISPLAY1",
"device": "SAM71AA",
"device_id": "SAM71AA-5&a1a3e88&0&UID24834",
"size": {
"left": 0,
"top": 0,
"right": 5120,
"bottom": 1440
}
}
]
}
}
This appears to be fine -- komorebi is aware of the device and associated window handles.
Let your display go to sleep.
Simply turning the monitor off is not enough to reproduce the problem; you must let Windows turn off the display itself.
To avoid waiting an eternity:
Control Panel -> Hardware and Sound -> Power Options -> Edit Plan 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.
Wake your display again by pressing any key.
komorebi should now be unresponsive.
komorebic state
Don't stop komorebi just yet.
Since it's unresponsive, you can open another shell instead to execute the above command.
{
"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.
Users with Nvidia GPUs may have issues with transparency on the Komorebi Bar.
To solve this the user can do the following:
This should resolve the issue and your Komorebi Bar should render with the proper transparency.