My review: Mintcaps, Womier and Ducky budget keycaps ►
◄ The Phantom of the Opera (1986 musical) original London cast
This entry is part of my Project Zebra series covering migration to Linux for personal computing use.
Two things that are wholly unrelated. No title reference this time, either.
Updating yt-dlp on Debian. The current version reported by yt-dlp --version is 2023.07.06 so I know it's way behind. and the version installed via apt is 2023.03.04 – I don't recall installing either, so they probably came along with media players.
Forum admin post: "What I do is download the (currently) 2.71 MB yt-dlp file [...] It's just a simple Python script. Extract it and put it in ~/bin which will be used in preference to the version installed with apt. You can uninstall the apt version (although you will lose the man page, doesn't hurt to keep it)."
That's a useful clue, but on my system the 2023.07.06 copy was in /home/[user]/.local/bin/ and updating the copy already there was the answer. Either folder will be treated as a user's private /bin/ if it exists.
Okay, the screen glitch troubleshooting saga. The glitches in question were occasional split second thin flicker-y lines in solid R/G/B colours whilst playing video or (apparently) using applications or web pages with transparency. Since it started being noticeable only recently I assumed it was a software problem, new kernel, etc. rather than hardware failing. To cut a long story short it was mainly the switch (taking it out of the circuit and sticking two cables together with a joiner is much better) and also one or more of the cables, but it was difficult to troubleshoot since certain colour combinations or transparency effects at certain screen locations set off HDMI drop outs or flickering green/red lines. HDMI is notoriously fragile anyway.
I think this comment about mechanical HDMI switches deserves a mention (although there are one or two mechanical HDMI switches on eBay apparently): "Always keep in mind HDMI is not there to make life simpler or improve video or audio – it is there to protect high value content and as such requires power to drive the circuitry employed to encrypt and decrypt your content, plus a myriad of other ‘communication’ protocols. [...] Mechanical switching doesn’t meet the requirements as laid out by HDMI.org – hence your difficulty in finding any legitimate device to meet your requirement."
And it wasn't an issue equally with different devices plugged into the same Techole switch, so I think DisplayPort to HDMI may have exacerbated the effect. But it showed up slightly in grub (since Debian uses a background graphic, not just a black background) and at the BIOS as well as in an X11 or Wayland session in various distros, and when I caught a subtle glitch in the laptop output too that narrowed things down a bit.
This was also a useful clue for me: "Basically, there are conditions (in this case, color combinations and placement) when the voltage supplied for propagation across the screen causes incorrect/unexpected pixel responses." Which very much describes the unreliability being affected by what's on screen, when the switch was being used. It might also reflect that the monitor is particularly dependent on getting a strong HDMI signal.
VGA was never an issue. Prior to this setup IIRC I was actually using the VGA out, but now have the VGA output going to an old eMachines/Acer E192HQV. Also weirdly with software rendering it was less frequent. I can't recommend this by the way since it canes an older processor, but the how to is:
"users may add LIBGL_ALWAYS_SOFTWARE=true and GALLIUM_DRIVER=llvmpipe to $HOME/.config/plasma-workspace/env/path.sh. This is however, both unfriendly and not well documented, whereas a checkbox in the settings app would be obvious and user-friendly."
https://userbase.kde.org/Session_Environment_Variables
~/.config/plasma-workspace/env/exports.sh
#!/bin/bash
export LIBGL_ALWAYS_SOFTWARE=true
export GALLIUM_DRIVER=llvmpipe
Restart and test with: printenv LIBGL_ALWAYS_SOFTWARE GALLIUM_DRIVER
So I've reset the disable GPU flags on Chromium browsers and set acceleration back to auto in VLC and removed the env variables. Had to disable in VLC again otherwise weird cropping issues. Oh, and launching VLC indirectly from a browser is resulting in no video output again, whereas launching from Nemo does. This is probably completely unconnected but I remember it happening previously so it's a regression in something.
I did have a nagging suspicion it was likely to be the monitor or the ThinkCentre itself. I got the ThinkCentre in 2014. The monitor is labelled May 2017 and is a 24M47VQ-P and it's possible either it or its power adapter is wearing out. Monitors usually tend to fail, if they're going to fail gradually rather than all at once, by getting slower and slower to restore power due to bad capacitors. Meanwhile the M92p has done me well, sporting a i5-3470T CPU @ 2.90GHz and 16GB RAM, and it's DisplayPort output to HDMI in the first place.
Searching eBay just in case for (M70q,M75q,M80q,M90q) which is what's on Lenovo's site as current, and 16GB or 32GB models, there are examples for as low as £250. Older serviceable models can be had for as low as about fifty. Like myriad other models, there are versions with different CPUs, but since my point of comparison is much older, the more modern lower end specs aren't too much of a concern. However, it does appear that Lenovo is reusing model numbers and what they're selling as new is gen 2/3/4/5 versions, so it's difficult to make direct comparisons. And you may need to quiz sellers to make sure the BIOS isn't locked with anti-theft options turned on, etc.
In this chat lots of people point out that used SFF PCs are much more versatile than novelty machines like the Raspberry Pi, and are apparently still buying older models. This one interestingly mentions using a more powerful PSU for better graphics performance.
Since removing the switch occasionally the laptop plugged into the monitor had brief drop outs. So I got more robust short cables and connectors, plus a spare monitor as a fallback since my other one's elsewhere. Maybe a sledgehammer to crack a nut, but touch wood all's been okay since and having the extra spare won't hurt.
Update: since I only really need to switch between two inputs most of the time, I've picked up a simpler switch from AliExpress (under £3) which probably isn't fully mechanical but with good quality cables touch wood I haven't experienced any problems. The switch definitely is analogue and only has two states, whereas the fancier switch I was using before just had a click to switch between three inputs and automatically ignored inputs that weren't live. With this kind of thing, simpler is definitely better.
Bonus link: a good old rant about Microsoft not taking security seriously. https://www.theregister.com/2024/06/28/windows_insecure_by_design/?td=rt-3a
💬 Comments are off, but you can use the mail form to contact or see the about page for social media links.
