TheCaconym [any]

What’s the browser you’re using ? and also please do:

glxinfo|egrep -i "^direct"

You’re looking for a line that says “direct rendering”; specifically whether or not it says “yes”. This will help pinpoint if you’re actually using your GPU or some onboard chipset instead.

With that being said, even assuming you use the latter, stuttering video playback in the browser is weird; if using firefox, out of curiosity: try to disable or enable hardware rendering (options > advanced > general), and try again. Switch it back to what it was when your test is done.

BIOS booting stays winning

DVI should not control the monitor’s actual physical controls - it does include a small non-display channel but IIRC that’s used to get the display modes info from the monitor, and potentially to transmit contrast information and the like; some monitors will prevent you from adjusting contrast if DVI sends that info for example, but it certainly shouldn’t disable the power button.

My guess would be a hardware issue - in the monitor itself - which is somehow triggered by the sequence in which you do enable the displays, and your system update being unrelated. It’s a huge guess though. One thing to try is repeating both sequences (the one that locks your buttons and the one that doesn’t) using a live CD - not a “nobara 38” one if such a thing exists, another distro. Trying both monitors on another computer would be an interesting test as well, although not necessarily that helpful (because if it doesn’t occur there, it might just mean the issue is triggered by peculiarities in your graphic card).

While SHA1 might be considered problematic security-wise in terms of collision (using it for certs today would be very bad, for example), it is not problematic in terms of preimage attacks (even MD5 isn’t broken that way IIRC), which is what truly matters in the context of 2FA / TOTPs

As for “why not SHA256”, compatibility