search

trigg / Discover

Yet another discord overlay for linux
GNU General Public License v3.0
649 stars 28 forks source link

Overlay sometimes appears on the wrong monitor in multi monitor setups #334

Open HikariKnight opened 6 months ago

HikariKnight commented 6 months ago

Steps to Reproduce

Steps to reproduce the behavior:

  1. Set overlay to show on monitor 0
  2. Reboot
  3. Overlay might end up on the wrong monitor (as monitor 0 and the other monitor has swapped indexes on this boot)
  4. Update config to use new monitor index (repeat step 2-4)

Expected behavior

Overlay appears on the correct monitor, this is a triple monitor setup for reference.

Problematic behavior

It seems like the monitor indexes can randomly get shuffled at boot, making the overlay display on the wrong monitor. This might be an underlying problem with some libraries and not directly a discover overlay issue.

Desktop (please complete the following information):

Installation Method

Discord client information

Additional context

So far from what i have noticed, only index 0 and 1 seem to swap places, will update this if i notice i have to swap to index 2 at any point. The indexes seem to be shuffled each time to be assigned a new index.

HikariKnight commented 5 months ago

Updating this with the info that the numbers are entirely random as i had to set it to index 2 the other day, but 0 and 1 seems to be the most common ones that i have to "correct" it to.

peterweissbier commented 5 months ago

installed from aur, version 0.7.4 this is happening for me too. atm i am trying to switch the layout from a monitor to the other but it isnt even doing anything even though i try it out with different settings. oh and it only happens in the anchor to edge setting. there is also no "place window" button in this setting.

trigg commented 5 months ago

That last comment sounds like an unrelated issue so I've opened a new issue for it. Thanks for the heads up I'll look into this shortly

trigg commented 4 months ago

Probably a stupid question, but want to rule out something before commiting major changes:

Do the xrandr/wl-randr names remain consistent at least? So monitors always show as the same name (HDMI-1, DP-1, eDP-1 etc)

I strongly doubt driver changes would be the cause, but if we're sure the device name is consistent I could use that in place of index storage.

trigg commented 4 months ago

Nope, went ahead with it without waiting for an answer. Sorry.

@HikariKnight Heads up, the config-switcher you're using will probably break with this upstream change.

Now the monitor = lines expect a Plug Name (eDP, eDP-1, HDMI-1) and these are decided by the desktop environment. On testing the ones set when using openbox don't match the ones in wayfire.

This is probably the nearest we'll get to a sensible answer. For most people Any will suffice fine.

HikariKnight commented 4 months ago

Nope, went ahead with it without waiting for an answer. Sorry.

@HikariKnight Heads up, the config-switcher you're using will probably break with this upstream change.

Now the monitor = lines expect a Plug Name (eDP, eDP-1, HDMI-1) and these are decided by the desktop environment. On testing the ones set when using openbox don't match the ones in wayfire.

This is probably the nearest we'll get to a sensible answer. For most people Any will suffice fine.

Salutations! this is great news at least!

HikariKnight commented 4 months ago

Probably a stupid question, but want to rule out something before commiting major changes:

Do the xrandr/wl-randr names remain consistent at least? So monitors always show as the same name (HDMI-1, DP-1, eDP-1 etc)

I strongly doubt driver changes would be the cause, but if we're sure the device name is consistent I could use that in place of index storage.

bit late as i was on vacation with no access to github. but yes kde uses kscreen-doctor and gnome i believe has no way to get the value but i made a script that gets a list of the output plugs from dconf. bazzite-gnome has gnome-randr