Multi-monitor issues on hyprland

[stormckey]

This is quite an impressive project and I really love this😊. Now I am trying this out on my laptop with hyprland. There seems to be some problems. Here is the screenshot to show the problem. First, I am using an external monitor(4K) together with the one build-in (2.8K). When I call the menu out on my external monitor, it seems that it just takes up part of the area of the screen, not the full screen.

Second, it seems that the panel of the menu just look through anything behind it straightly to the wallpaper rather than floating over the windows behind it. (I am not sure whether the transparency is something do to with my hyprland config, anyway I just wonder how to change this)

By the way, I am wondering if there is a way to close the menu just through the mouse, like the right button or something? I have already bind the trigger to the side bar of it and I want everything to be done with my mouse.

[stormckey]

Sometimes the panel can fit my 4K monitor well. But it seems that Kando fails to track my mouse horizontally, which means that it appears somewhere with the same height with my mouse, but in a fixed horizontal position. Any ideas?

[Schneegans]

Hi there! Well, that's a couple of issues here :wink: Let's give you some hints and thoughts here.

• Have you put the stuff from #245 into your Hyprland config?
• If so, but you experience issues nonetheless, it would be awesome if you had some coding experience. We might need to debug this on your end :smile: Can you run Kando from source? The required steps are outlined here: https://github.com/kando-menu/kando/blob/main/docs/installing.md#b-manual-installation
• You can close the menu with your mouse by clicking the center of the root item.

[stormckey]

• Yes, I have added the required rules into my hyprland config.
• I have installed kando manually, so the next step should be?
• Thanks! That works. But I think closing it with a right click is way more convenient(since I dont need to move my cursor to the item). I remember fly-pie on gnome can be closed by right click? I like that.

[stormckey]

Something weird: The panel wont change if I comment the window rules in my hyprland config. It seems that these rules dont take effect now? I try to apply same noborder rules to my terminal, and it takes effect immediately.

[Schneegans]

Well, that's an interesting observation. Maybe the window name is not correct anymore? Could you run hyprctl clients while the menu is open and see if there is a kando?

Btw, I just pushed a commit to main which allows closing the menu with the right mouse button :wink:

[stormckey]

Great! I really appreciate the new feature! Thanks for your effort!

As for the problem, it turned out that the window is called Kando on my system, I am not sure if this is common, but after changing the name in the rule to Kando, the menu can function well now.

For the position mismatch I mentioned before, I have just found a way to repeat it easily. On my 4K external monitor, as long as my cursor is way too right, the menu will fail to track the cursor horizontally. Here is a viedo for your reference:

https://github.com/kando-menu/kando/assets/109893671/a54ce50c-73b7-43de-bbd0-bff54bc06f20

Another subtle problem showed in the video is the flicker of the screen when calling out the menu.

[Schneegans]

Yeah, I suspected the name change. Some time ago I changed the app name from "kando" to "Kando" and it seems that Electron uses this app name for the window title as well. I changed the comment in #245 accordingly. Does this change also affect the global shortcut? Does bind = CTRL, Space, global, kando:prototype_menu still work? Or does it need to be bind = CTRL, Space, global, Kando:prototype_menu?

The menu position issue is interesting. To get the pointer position on Hyprland, Kando uses hyprctl -j cursorpos. Maybe you could a debug print here to log the returned value. E.g. console.log(cursorpos.x + " " + cursorpos.y).

[stormckey]

• No, kando works well as a short cut, and it's Kando that cant function well here.
• I have just tried that out and here is the result: The output coincides with the output of hyprctl -j cursorpos. It's also reasonable as 4k is just 3840x2160, but the x of the menu is apparantly not as large. For the position, actually it feels that there is an extra offset to the x position, rather than a fixed x position.

[stormckey]

This is the position returned when the cursor is on my build-in screen.

I am not sure if you are aware of this? The left-top point of my external monitor locates in (0,0), the right-bottom point locates in (3840,2160) ,while the left-top point of my build-in screen locates in (3840,0). They are placed side by side.

If such configuration are needed for the app. They can be get through hyprctl monitors list

Hope my response is helpful for you 😊

[Schneegans]

Maybe Electron has some issues getting this information on Hyprland? You could add some more debug prints to figure this out. The window size and position is set here whenever the menu is opened. This ensures that it is shown fullscreen on the monitor where your mouse pointer currently is. If you print workarea.x, workarea.y, workarea.width, workarea.height in this method, you should get the same values as hyperctl returns. Does this work?

Further down in this method (here) the menu position is computed. This simply subtracts the monitor position from the pointer position. Mabe you could print pos.x and pos.y here. Is there something dubious about the returned values?

[stormckey]

I have just print the info as you instructed and here's the reuslts:

As I can see, something went wrong here. The screen locate in (0,0) should have the width 3840 and height 2160 not 2880 and 1800. So actually here you assume that the 4k external monitor should locate to the right of the build-in screen, which is opposite.

Is that assumption something fixed in your code ? Maybe you can change this and try to get the right composition.

Maybe the info in hyprctl monitors list is helpful.

[Schneegans]

So the mouse pointer coordinates are correct but the reported monitor positions are not? Well, this looks kind of like a bug in Electron. Or maybe even in Chromium. We should try to report this over there.

Do you have some experience with Electron? If so, you could create a small reproducible example using this tool. If no, I'll try to do this later. But it could take some time...

[stormckey]

So the workarea is something offered by Electron? If so, yes, there is something wrong there.

For the case above, it should either return (0,0,3840,2160) or(3840,0,2880,1800), not (0,0,2880,1800) ,(2880,0,3840,2160).

But I am sorry that I have no experience with Electron. I am always available for any further questions:)

[Schneegans]

I just create a minimal Electron example. Could you please install the Electron Fiddle and load the fiddle from this link: https://gist.github.com/Schneegans/95b5146eb253b0fe0ffe780742b33a05

If you hit the "Run" button, a hello-world window will pop up. If you move the window around, the console in Electron Fiddle will print the current position of the window's top left corner. It will also print the position and the extend of the screen which Electron thinks the window is on.

I am using GNOME on Wayland currently and have a similar setup to yours:

┌───────────────────┐
│                   │
│     Secondary     │┌─────────────┐
│     3840x2160     ││   Primary   │
│                   ││  1920x1200  │
└───────────────────┘└─────────────┘

If the window is moved on the secondary monitor, something like this is printed:

Window position:  [ 1600, 837 ]  Window's Screen:  { x: 0, y: 0, width: 3840, height: 2160 }

On the primary, something like this is printed:

Window position:  [ 4249, 1394 ]  Window's Screen:  { x: 3840, y: 960, width: 1920, height: 1200 }

Which totally makes sense. What does this print for you?

[stormckey]

I've tried it out and it's not normal for me... There is also negative number there and the workarea is just wrong the same way we used to see.

The actual position is :

┌───────────────────┐┌─────────────┐
│                   ││   Primary   │
│     Secondary     ││  2880x1800  │
│     3840x2160     │└─────────────┘
│                   │
└───────────────────┘

But in the view of electron, it is:

┌─────────────┐┌───────────────────┐
│   Primary   │|                   │
│  2880x1800  ││     Secondary     │
└─────────────┘│     3840x2160     │
               |                   │
               └───────────────────┘

By the way, the second view seems to be the default position hyprland give, but I configured it the first way.

[Schneegans]

How did you configure this? Did you assign a negative -3840 offset to the secondary screen or a positive offset of 3840 to the primary screen? Maybe only one way works properly?

[stormckey]

No, I just need to assign an origin point to the monitor. This is the specification from the hyprland wiki:

And this is my configuration:

I just let the external monitor to locate in 0x0, and the other monitor is placed automatically.

[Schneegans]

Maybe you could play with these values and see if it makes any difference? So either assign an explicit offset to the primary monitor or maybe a negative offset to the secondary?

[stormckey]

Assigning negative values is valid as said in the hyprland wiki, and I've tried that out.

It turned out that there is no change with the workarea returned by Electron. It seems that Electron just have no awareness of such a configuration.

And hyprland itself is aware of such a configuration. The info returned by hyprctl -j cursorpos and hyprctl monitors list will be negative as I config.

[Schneegans]

Well, I have basically no idea where this problem may come from. This could be an Electron bug, but I think that it is more likely an issue in the underlying Chromium code. I think that Chromium uses Ozone under the hood for such platform interaction, but I am not sure about this. So the issue could be in either of them, but it could also be in Hyprland. Maybe some Wayland protocol is not implemented correctly?

I think the best way would be if you opened an Electron issue here providing an explanation of how Electron seems to ignore Hyprland's monitor config. They ask for an Electron Fiddle link, there you could provide my example and explain the expected and the actual output.

[stormckey]

Sure, I will.