Originally created by @whaaaley on GitHub (Oct 14, 2024).
Summary
I'm unable to focus or move windows after I reconfigured my monitor setup over the weekend. Previously everything was perfect, but I had a weird configuration for my extra monitors, using a mix of onboard and dedicated ports. Over the weekend I moved everything to dedicated by plugging my two bottom monitors into a hub.
Now I can't move or focus windows in monitor 4. Moving windows or focusing down only goes to 3. Is there something I need to do? I'm wondering if they're getting reported as a single monitor to Komorebi due to the hub, rather than individual.
Version Information
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
PS C:\Users\dustin> komorebic check
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\dustin
Looking for configuration files in C:\Users\dustin
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\dustin\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
Originally created by @whaaaley on GitHub (Oct 14, 2024).
### Summary
I'm unable to focus or move windows after I reconfigured my monitor setup over the weekend. Previously everything was perfect, but I had a weird configuration for my extra monitors, using a mix of onboard and dedicated ports. Over the weekend I moved everything to dedicated by plugging my two bottom monitors into a hub.
Now I can't move or focus windows in monitor 4. Moving windows or focusing down only goes to 3. Is there something I need to do? I'm wondering if they're getting reported as a single monitor to Komorebi due to the hub, rather than individual.

### Version Information
```
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
```
```
komorebic 0.1.29
tag:v0.1.29
commit_hash:818ac340
build_time:2024-09-28 01:48:31 +00:00
build_env:rustc 1.81.0 (eeb90cda1 2024-09-04),stable-x86_64-pc-windows-msvc
```
### Komorebi Configuration
```json
{
"$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.29/schema.json",
"app_specific_configuration_path": "$Env:USERPROFILE/applications.yaml",
"window_hiding_behaviour": "Cloak",
"cross_monitor_move_behaviour": "Insert",
"mouse_follows_focus": false,
"default_workspace_padding": 36,
"default_container_padding": 12,
"border": true,
"border_width": 2,
"border_offset": 0,
"border_style": "Square",
"border_colours": {
"single": {
"r": 255,
"g": 168,
"b": 60,
"a": 0
},
"stack": {
"r": 255,
"g": 168,
"b": 60,
"a": 0
},
"monocle": {
"r": 255,
"g": 168,
"b": 60,
"a": 0
},
"unfocused": {
"r": 0,
"g": 0,
"b": 0,
"a": 255
}
},
"stackbar": {
"height": 40,
"mode": "OnStack",
"tabs": {
"width": 300
}
},
"display_index_preferences": {
"0": "SAM0E14-5&1796117&0&UID4355",
"1": "SAM0E14-5&1796117&0&UID4357",
"2": "HHS1400-5&1796117&0&UID4650",
"3": "HHS1400-5&1796117&0&UID4651"
},
"monitors": [
{
"workspaces": [
{
"name": "I",
"layout": "VerticalStack"
}
]
}
]
}
```
### Hotkey Configuration
Default
### Output of `komorebic check`
```
PS C:\Users\dustin> komorebic check
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\dustin
Looking for configuration files in C:\Users\dustin
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\dustin\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
```
### Output of `komorebic monitor-information`
```
{
"HHS1400-5&1796117&0&UID4650": {
"left": 640,
"top": 1440,
"right": 1920,
"bottom": 1200
},
"HHS1400-5&1796117&0&UID4651": {
"left": 2560,
"top": 1440,
"right": 1920,
"bottom": 1200
},
"SAM0E14-5&1796117&0&UID4355": {
"left": 0,
"top": 0,
"right": 2560,
"bottom": 1440
},
"SAM0E14-5&1796117&0&UID4357": {
"left": 2560,
"top": 0,
"right": 2560,
"bottom": 1440
}
}
```
adam
added the bug label 2026-01-05 14:51:04 +01:00
I actually think this is the same issue as https://github.com/LGUG2Z/komorebi/issues/447, but in my configuration it prevents me touching monitor 4. I must have had an inconsistent layout in my previous configuration that allowed it to work due to imperfect coordinates.
@whaaaley commented on GitHub (Oct 14, 2024):
I actually think this is the same issue as https://github.com/LGUG2Z/komorebi/issues/447, but in my configuration it prevents me touching monitor 4. I must have had an inconsistent layout in my previous configuration that allowed it to work due to imperfect coordinates.
Shifting the bottom two monitors slightly to the right allows me to get access to monitor 4, although there's oddities.
[works] Left <---> right, between 1 and 2
[works] Left <---> right, between 3 and 4
[works] Top <---> bottom, between 1 and 3
[not working] Top ---> bottom, from 2 to 4, goes to 3 instead of 4
[not working] Bottom ---> Top, from 4 to 2, goes to 1 instead of 2
The behavior of going down from monitor 2 to 3, instead of 4, is still present even in the most drastic of scenarios:
@whaaaley commented on GitHub (Oct 16, 2024):
Shifting the bottom two monitors slightly to the right allows me to get access to monitor 4, although there's oddities.
[works] Left <---> right, between 1 and 2
[works] Left <---> right, between 3 and 4
[works] Top <---> bottom, between 1 and 3
[not working] Top ---> bottom, from 2 to 4, goes to 3 instead of 4
[not working] Bottom ---> Top, from 4 to 2, goes to 1 instead of 2

```
{
"HHS1400-5&1796117&0&UID4650": {
"left": 716,
"top": 1440,
"right": 1920,
"bottom": 1200
},
"SAM0E14-5&1796117&0&UID4357": {
"left": 2560,
"top": 0,
"right": 2560,
"bottom": 1440
},
"HHS1400-5&1796117&0&UID4651": {
"left": 2636,
"top": 1440,
"right": 1920,
"bottom": 1200
},
"SAM0E14-5&1796117&0&UID4355": {
"left": 0,
"top": 0,
"right": 2560,
"bottom": 1440
}
}
```
---
The behavior of going down from monitor 2 to 3, instead of 4, is still present even in the most drastic of scenarios:

@LGUG2Z commented on GitHub (Oct 16, 2024):
https://github.com/LGUG2Z/komorebi/blob/c0c3c81d69d43c4db3e3d26e674bffbfde8504e8/komorebi/src/window_manager.rs#L465-L496
This is the logic that needs to be updated ^
@LGUG2Z commented on GitHub (Oct 16, 2024):
I don't have enough monitors to try this out but you can test this commit: https://github.com/LGUG2Z/komorebi/commit/e8e18a48ada1a76c68295ba5b25d63cc899d6a3c
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @whaaaley on GitHub (Oct 14, 2024).
Summary
I'm unable to focus or move windows after I reconfigured my monitor setup over the weekend. Previously everything was perfect, but I had a weird configuration for my extra monitors, using a mix of onboard and dedicated ports. Over the weekend I moved everything to dedicated by plugging my two bottom monitors into a hub.
Now I can't move or focus windows in monitor 4. Moving windows or focusing down only goes to 3. Is there something I need to do? I'm wondering if they're getting reported as a single monitor to Komorebi due to the hub, rather than individual.
Version Information
Komorebi Configuration
Hotkey Configuration
Default
Output of
komorebic checkOutput of
komorebic monitor-information@whaaaley commented on GitHub (Oct 14, 2024):
I actually think this is the same issue as https://github.com/LGUG2Z/komorebi/issues/447, but in my configuration it prevents me touching monitor 4. I must have had an inconsistent layout in my previous configuration that allowed it to work due to imperfect coordinates.
@whaaaley commented on GitHub (Oct 16, 2024):
Shifting the bottom two monitors slightly to the right allows me to get access to monitor 4, although there's oddities.
[works] Left <---> right, between 1 and 2
[works] Left <---> right, between 3 and 4
[works] Top <---> bottom, between 1 and 3
[not working] Top ---> bottom, from 2 to 4, goes to 3 instead of 4
[not working] Bottom ---> Top, from 4 to 2, goes to 1 instead of 2
The behavior of going down from monitor 2 to 3, instead of 4, is still present even in the most drastic of scenarios:
@LGUG2Z commented on GitHub (Oct 16, 2024):
https://github.com/LGUG2Z/komorebi/blob/c0c3c81d69d43c4db3e3d26e674bffbfde8504e8/komorebi/src/window_manager.rs#L465-L496
This is the logic that needs to be updated ^
@LGUG2Z commented on GitHub (Oct 16, 2024):
I don't have enough monitors to try this out but you can test this commit: https://github.com/LGUG2Z/komorebi/commit/e8e18a48ada1a76c68295ba5b25d63cc899d6a3c
@alex-ds13 commented on GitHub (Dec 26, 2024):
@whaaaley Can you check if this is still an issue on the latest releases?