Closed ghost closed 2 years ago
As far as I know Display enumeration works like that because of the OS. The program is designed to show OSD on available display even if settings specify other display, so probably when the primary display is disabled, the secondary display you mention in your case is 0 and when you connect primary - connected display becomes 1. I dont think I can fix that easily.
Sorry, I have neglected to mention an important detail, my workaround: After enabling/disabling a display, simply exit and restart FancyOSD, or, open the Settings and Info dialog and change the display number to something random and then back to the same number (1).
So, you're right about how windows is handling it, but the problem here is not that the displays are enumerated incorrectly when they are enumerated, it is that FancyOSD assumes that the enumeration has not changed since it was initialised. If, after enabling or disabling a monitor, I force it to re-enumerate the displays, everything works as expected.
So I guess, there would need to be a function to detect when display enumeration changes (ie: monitors are disabled/enabled), or to enumerate them before every OSD display (sounds expensive, I don't know though) or something like that.... I don't know how practical this kind of thing would be in reality, so, no pressure! I'm quietly hoping there's a windows API you can hook into on enumeration changes and it'll be really simple :)
It's already keeping tracks of possible changes, but maybe display disconnection is not detected properly. Try this build and enable logger. Check what log file says when you disconnect/connect display. There will be something like
DEBUG DISPLAY ENUMERATION: Windows settings change detected - Desktop
VoicemeeterFancyOsd-x64-1.0.0.1 disp enum test.zip
Thanks for taking a look for me.
09-10-2022 23 44 07.737 Reading config: OK
09-10-2022 23 44 07.738 Writing config...
09-10-2022 23 44 07.743 Writing config: OK
09-10-2022 23 44 07.746 Initializing VmrApi Client
09-10-2022 23 44 07.933 VmrApi Login result: 0
09-10-2022 23 44 07.967 VmrApi WaitForNewParams returned: 1
09-10-2022 23 44 08.197 VmrApi Client initialized
09-10-2022 23 44 08.913 Program initialized
09-10-2022 23 44 38.879 DEBUG DISPLAY ENUMERATION: Windows settings change detected - Desktop
09-10-2022 23 44 39.071 DEBUG DISPLAY ENUMERATION: Windows settings change detected - Desktop
09-10-2022 23 44 39.169 DEBUG DISPLAY ENUMERATION: Windows settings change detected - Desktop
09-10-2022 23 45 21.151 DEBUG DISPLAY ENUMERATION: Windows settings change detected - Desktop
The first three all occurred when enabling the second (primary) monitor (23 44 39). The fourth was disabling it again (23 45 21)
Obviously I'm wrong and it's not assuming enumeration hasn't changed. Sorry, I'm just so accustomed to seeing that in other apps :) I wonder what strange thing on my system breaks it....
Perhaps of interest, this process: Have secondary display enabled only Start FancyOSD configured to use display 1 Enable primary display Open FancyOSD Settings dialog Do a thing to make OSD appear Note OSD on display 0 (primary) Change display setting to any other number and back to 1 Watch it immediately displayed there (the OSD moves while still displayed, nice)
So, it knows about my monitors, and which one I want....
Hope this helps
I see it detects. It will help to investigate further if I have some problem in my code or in the library that enumerate displays.
Try this version VoicemeeterFancyOsd-x64-1.0.0.1-preview.zip
Works like a charm! Thanks so much :)
There are no debug log messages in this one, I am guessing that's intentional, but I thought I should mention it.
Thanks for this very nice addition to the voicemeeter ecosystem :)
I've noticed one very small issue - I have dual displays here, and often use the secondary display only. This means that when I enable my primary display (read: turn on my other monitor), what was display '0' becomes display '1'.
I always want the popup to appear on that secondary display (as the primary is for gaming exclusively) so I have FancyOSD configured to use display 1. When only the secondary is enabled, this fails gracefully and uses display 0, being the secondary monitor, and all is well. When both displays are enabled, this works as configured and uses display 1, being the secondary monitor, and all is well. But If I start FancyOSD with only the one (secondary) monitor enabled, then enable the primary monitor, the monitor enumeration changes during FancyOSD's run time, and the OSD appears on my primary display, display 0, in spite of being configured to use display 1.
No big stress about this but if there's a performant way to deal with it, that'd be nice, so I thought I should report it.