regedit

Interesting tidbit about Disney's Mulan (animated):

In all Disney animated movie, singalong songs are the norm. Except, that is, for the animated Mulan movie. The last song they sing is this one, which ends abruptly as they arrive to join forces with the main dude's father's army. They were all wiped out by the enemy before they got there. After that, the rest of the movie is somber and includes no more sing along songs.

Also, it was the first movie to include CGI with hand-drawn animations.

Aww thanks!

At the time it was using X11. But changing to Weyland was one of the things I tried. Seemed whatever the fault, it persisted through reboots and those changes. Is there something that both X11 and Weyland check when processing the handshakes?

Healthcare is too expensive!

I was sold on genAI until I realized how capitalism was trying to pervert and monetize the wrong parts of it. Now it just seems like a means to an end. An end I don't want to participate in.

I do this all the time because of my ADHD hyper-focus. It's how I stay so slim (unhealthy as fuck on the inside, I'm sure)!

I say this to my wife any time we watch a movie with animals in it!

Anything with that many eyes is definitely self-aware!

No wonder the Pentagon hasn't passed an audit in a decade or something!

I posted this in another comment in this same thread, but figure I'd just paste it here for you!

I don’t know how wine works fully, but I know a bit about how Windows works. Based on my use of emulation and VMs, wine strikes me more as an emulator. Windows expects a certain structure and wine sets up a sort of emulated instance of that environment. If I’m correct in my assumptions, wine has to get control information about the monitor from Linux to display the application correctly when it’s being emulated. When I closed Studio 2.0, I believe wine failed to pass this monitor information/control back to Linux. Linux didn’t think it should have the monitor control cause wine never passed it back, so every time the OS detected the monitors, it would essentially say, “no thanks, you should be hanging out with wine right now!” and disable the monitors within Linux. This caused the monitors to basically disconnect. Since wine had closed, there was nothing to take that control back, so the monitor just reappeared on the list of OS hardware to take control of, and would again say, “no thanks,” over and over.

Again, I may be completely off-base and merely speculating, but when I managed to quickly toggle the monitor back to enable and save the configuration, it changed the handling of the monitor to forcefully tell Linux to take it back and use it, which broke the loop. Again, not sure, but it was quite a journey. Glad to have all my monitors back to 100Hz and super glad my graphics card doesn’t need to be replaced!

Thank you for your question!

I appreciate you taking the time to reply!

That is simultaneously ridiculous and amazing. Blindly clicking the buttons to enable the screen definitely proves you’re getting familiar with the OS.

Thank you for the kind words and I completely agree! I feel like I'm more in control and simultaneously more willing to tinker, with my computer when it has these issues, rather than just dumping files and/or reinstalling or something drastic like I would have done in the past. One of my friends from childhood swears that he can't get into Linux and always ends up going back to Windows. I think he suffers from the same issues I had before I just accepted that I am back to being a complete nub and can only take my cursory knowledge of PC troubleshooting to investigate and fix Linux issues. I accepted my ignorance of the OS and expect to face issues I have to learn how to fix. I think that's the mindset that a lot of tech-savvy people may need to adopt when moving from Windows to Linux full-time. However, that's just my personal opinion and what's worked for me!

Why do you think wine/Bricklink messed it up in the first place?

I don't know how wine works fully, but I know a bit about how Windows works. Based on my use of emulation and VMs, wine strikes me more as an emulator. Windows expects a certain structure and wine sets up a sort of emulated instance of that environment. If I'm correct in my assumptions, wine has to get control information about the monitor from Linux to display the application correctly when it's being emulated. When I closed Studio 2.0, I believe wine failed to pass this monitor information/control back to Linux. Linux didn't think it should have the monitor control cause wine never passed it back, so every time the OS detected the monitors, it would essentially say, "no thanks, you should be hanging out with wine right now!" and disable the monitors within Linux. This caused the monitors to basically disconnect. Since wine had closed, there was nothing to take that control back, so the monitor just reappeared on the list of OS hardware to take control of, and would again say, "no thanks," over and over.

Again, I may be completely off-base and merely speculating, but when I managed to quickly toggle the monitor back to enable and save the configuration, it changed the handling of the monitor to forcefully tell Linux to take it back and use it, which broke the loop. Again, not sure, but it was quite a journey. Glad to have all my monitors back to 100Hz and super glad my graphics card doesn't need to be replaced!

Thank you for your question!

So something disabled your monitors and you were able to get them back by quickly enabling them during the brief period of time that they were visible.

That is correct. I don't remember what online resource I found, but one of them mentioned where to find the kscreen or kwin shared files. There were multiple files: one with just a GUID for the display and one for the type of connection. I noticed that there were combinations where one GUID would be DP-1, HDMI, DP-2, etc. That got me thinking about the whole settings/config files stuff and what led me to watch the actions of the Monitor Configuration screen more closely to understand what was happening.

The monitors should still be listed in the display configuration even if disabled.

But only if they're plugged in at the time. And plugging them in would blank the other side monitor if connected, and lead to my main monitor flashing and glitching as it kept finding and rejecting the other monitors over and over. They'd constantly disappear and reappear from the configuration screen every time it happened, causing any changes I made to the configuration, which were not applied before they lost the connection, to be lost.

May be worth filing a bug with kde. Seems like a massive oversight if that isn’t the intended behavior.

I may do that. However, outside of my experience with closing a wine app leading to this, I'm not sure if there's an easy way to reproduce it. Regardless of where I go from here, I am happy it is back to working, and thank you for your comment and questions!