I haven't looked into what's causing this behaviour yet because I was cooking but I did manage to make it reproducable. Also it's very unlikely to show up in normal daily use.
I was playing a series of flac files through mplayer (single process, many files) in a root shell on the text console (DISPLAY will not have been set, nor XAUTHORITY) and using X normally. When mplayer started a new track the X display acted as though a key was stuck down. Which key was stuck changes (it may have been related to keys I was pressing). The keyboard's state can be restored by switching to any console and back again (Ctrl-Alt-Fn). The apparently-stuck key happened in the xenodm login screen as well as the fvwm session. I'm not sure if all flac files also contain an image or only these ones. Notably mplayer did NOT open an X window. I will do a deeper dive later to figure out what's happening. In particular to try and remove mplayer from the loop and re-do my testing when I'm not distracted, but I wanted to get this out there in case anyone familiar with X has a clue what might be happening. The machine, for what it's worth, is a very uninteresting Dell Latitude laptop running a stock 7.2 with no customisation. Dmesg, logs and other data will come with a more thorough bug report (or not and a patch, if the stars align). One oddity I can think of is that xenodm isn't started normally on that laptop but by logging in as root and running xenodm (I could rcctl -f start xenodm but that's more typing). Mplayer was almost certainly running in the same console login session. I can't think how that matters. Cheers, Matthew ps. I'm well aware this deviates far from good practice. This is not my daily-use computer nor does it ever go anywhere near anything that might be called production.
