virtual desktops sometimes completly broken

[luiswirth]

I don't know what exactly causes it, but sometimes the virtual desktops become completly broken... The only way to remedy this I found is to restart Hyprland and to hope to not trigger it again.

Based on the workspace indicators on my waybar, I can tell, that this happens whenever both workspaces representing a single desk (e.g. workspaces 1,2 for desk 1) are somehow one the same monitor (according to waybar). Then I get very glitchy behavior. I get unrendered some unrendered windows. Also just the act of moving the mouse from one monitor to the other makes the workspaces somehow swap between monitors and I can't get to the other workspace anymore... It's very weird.

Running hyprctl reload or hyprctl dispatch vdeskreset cannot fix this.

One thing that might play a role is, the fact, that when starting hyprland I first deactivate the internal monitor (monitor 3 if you want so).

[levnikmyskin]

Hi, sometimes this also happens to me, and it's most likely due to monitors layout changing (in your case, internal monitor going off).
I think this happens because the plugin by default tries to remember layouts and workspaces, but it's not easy to track when the workspace change is triggered by the user or by hyprland.

I'll take a look into this. In the meantime, if vdeskreset doesn't work, you could try specify rememberlayout = none in the configuration options

PS. How are you switching off your monitor? Do you use something like kanshi?

[luiswirth]

Yes I agree, changing layouts does seem to cause this. Also when first having no monitor connected and my internal monitor turned on and then just connecting a 2nd monitor causes a bug, where there is a weird workspace setup.

Setting rememberlayout = none still makes the problem happen. To only apparently sure way to have a working setup, is to start hyprland with all monitors I want plugged in (for now just one addiontal one) and then not messing with the monitor layout.

[levnikmyskin]

Can you check if this happens on hyprland 0.39.1 as well?

[luiswirth]

I'm having a hard time downgrading on NixOS... Using an old flake.lock gives a build error...
I will however try to investigate the error further and provide new information.

[levnikmyskin]

I see. I use arch, so unfortunately cannot really help there. Also, you forgot to say which tool you're using to shutdown/ power up the monitors

[luiswirth]

Usually I do use kanshi, but unfortunatly it doesn't work for hyprland v40, see hyprwm/Hyprland#5978.
So instead I currently modify my monitor setup manually using hyprctl keyword monitor ...

[levnikmyskin]

Yeah, this happens every now and then unfortunately. Just yesterday night I opened this PR on another small tool which is using hyprctl directly.
Until hyprland stabilises, it might be a better solution IMO.

Anyway, please also attach hyprland logs of when this behaviour happens

[levnikmyskin]

Hi! The kanshi problem was fixed upstream. Does this happen with kanshi too? If you can reproduce it, could you attach the hyprland log?

[adam-neeley]

Maybe it was fixed. I don't think I've ever experienced anything like this issue, except possibly when I first installed the plugin, but such things aren't uncommon when tinkering with window settings on my particular NixOS setup. Either restarting a service, logging out, or rebooting solved the issue, I don't recall.

[levnikmyskin]

That's good to know! Unfortunately, I think this problem (vdesks going crazy etc) is still present, despite rather unpredictable. One day I'll look into it. Most likely, it will require changes in Hyprland itself to send an event before/after workspaces have been "adjusted", following a monitor connection/disconnection

[adam-neeley]

Hmm, come to think of it I generally keep my monitors on at all times. I will test when I have access to them.

It's remarkable that your first plugin is so good considering the complex nature of the situation. I'm repeating myself but virtual desktops kept me on Plasma until now so I'm very grateful for this project.

[levnikmyskin]

Thanks for the kind words. And yes, I also just can't work without this metaphor anymore :)

[levnikmyskin]

hey, just curious. Is this still happening? I feel like on aquamarine this stuff kind of fixed itsef (?)

[luiswirth]

I don't use this plugin anymore, since it wasn't working for me at the time.

[WhySoBad]

hey, just curious. Is this still happening? I feel like on aquamarine this stuff kind of fixed itsef (?)

Hi, I've had this issue for some time now on hyprland-git (currently 0.44.0.r63.08cc063e-1).

I can't really reproduce it but it happens to me almost every time I want to move a window from say vdesk 1 to vdesk 2 after on vdesk 1 all three monitors were populated with a window.

On vdesk 2 the window in some kind of background layer and I can open other windows on top of it. Sometimes new windows created on vdesk 2 then are buggy and take space but get invisible.

In most of the cases I'm able to "fix" this issue by going to vdesk 3 and populating every monitor with a window and then switching back to vdesk 2. If this does not work I repeat the same process with vdesk 4 etc.

I've suspected hyprland to cause this bug for quite some time now but I'm getting the feeling it's this plugin which causes this behavior. I've not yet had the time to dig through the source to find possible reasons for this behavior but I'll have a look in the next weeks and let you know if I find something

[levnikmyskin]

Thank you for the details. For this weird behaviours, I've always suspected the code that handles the monitor connection/disconnection. When this happens, hyprland re-adapts the windows on the workspaces, possibly messing up with the virtual desktop layouts.
I've never found a proper way to deal with this, othert than what I did in the code so far. I think only way would be for hyprland to expose an event for "after" monitor connection/disconnection actions (i.e., after hyprland is done doing its stuff upon monitor connection/disconnection)

[WhySoBad]

But when the code which handles the monitor connection/disconnection is the culprit I should not have any issues on my desktop where all monitors are "hardwired" and connected at boot or am I wrong?

[levnikmyskin]

mh not really, because the monitor connection event would anyway be sent twice (assuming you have two monitors) by Hyprland

[WhySoBad]

Fair enough, I just wondered because on my laptop I've never had any problems. I only use the laptop with it's inbuilt monitor but still have the plugin enabled.