Intel Laptop Users Should Avoid Linux 5.19.12 to Avoid Damaging the Display
lore.kernel.org
lore.kernel.org
https://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-spea... https://groups.google.com/g/comp.os.linux.advocacy/c/QslNrtx...
(note it doesn't actually require installing another distro - alsamixer was available in the base chromeos install)
Tbh I'm still pretty salty about it.
[1]: https://www.dell.com/community/Laptops-Wiki/How-Using-the-VL...
I only read the one thread on this, so I'm guessing a lot here, but it sounds like you could patch the <100hz frequency problem in hardware for like $0.50 with a high pass filter soldered in at the speaker?
That thread is a little hard to read, so I don't know if there really is a dc problem. That's a little harder to fix in the speaker cavity.
A high-pass filter in the DSP/driver software is free, sell a million Chromebooks and that's $500k of pure profit from cutting costs. Unless you account for warranty recalls due to buggy drivers, in which case a 0.1% failure rate is enough to make this a bad idea.
Not nice.
Judging by https://community.frame.work/t/psa-dont-upgrade-to-linux-ker..., it has been solved in 5.9.13 already.
Date: Tue, 4 Oct 2022:
> 5.19.13 is now released with 8 reverts for this driver, hopefully that sould [sic] resolve this issue. thanks, greg k-h
Does that mean you experienced the "potentially bogus panel power sequencing delays, which may harm the LCD panel" ? If so, was your LCD panel harmed?
As another commenter mentioned, fancy pants filesystems that support snapshots simplify this situation.
This is what I used. zfsbootmenu is an EFI executable with support for doing zfs rollbacks (and any other arbitrary zfs command) so as long as my EFI partition is left untouched, I don't need a livecd or another partition or anything.
Maybe just didn’t want to boot on faulty kernel at all, now that the risk of permanently damaging the display was known.
> Linux fedora 5.19.13-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Oct 4 15:42:43 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
How come these things are not secured against at the LCD controller side? Why would a general purpose controller be designed to accept e.g. too high voltage levels?
But is that really the case for these laptops? Seems kind of negligent from the manufacturer if so.
edit: https://www.diodes.com/assets/Datasheets/AP3019A.pdf example of simple one. The value of the single resistor decides the max current.
there's absolutely no safety mindset for anything behind the cover.
if it's industrial, just put a big sticker on it, write something about it in the mandatory occupational hazards training kit, maaaaaaaybe consider adding a fence, but it's fine anyway.
if it's consumer stuff? well, as long as kids won't choke on it, it's A-OK. especially if it comes to electronics. just write in the user's guide that always disconnect it from the mains when not in use, if used improperly that's on you, and don't ever think about opening it. that only for professionals who are trained in the dark arts of handling this exact piece of immanetized hell-forged eschaton housed in a convenient beige plastic.
adding a voltage limiter between the LCD panel and the input would cost money. designing it would cost money. adding an analog limiter on the regulator would cost money (plus setting it mechanically is very expensive compared to flashing on some firmware), compartmentalizing the software - by having a segment that's set at assembly that contains the physical properties of connected parts, which communicates the operational limits, and the other segment which can be set via software - would also cost a lot of money.
As a counter-point: One persons "safety" is another persons "limitation". Sometimes it's good that things are generally protected but you can break through the protections somewhat.
You could hack the firmware and make the device behave out of spec, but you could also hack the hardware. If you bypassed your voltage limiter on the board then you could blow it up too.
For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
I meant hacking as-in messing around, poor choice of word.
> But more like if software can cause hardware damage, that means software bugs can cause hardware damage and potentially pose a safety risk, which should be seen as a critical hardware bug
Hardware bugs can cause hardware damage.
> For example the safety critical systems you mention should absolutely fail-safe at the bare minimum, all kinds of things can adversely affect running software like equipment generating EM noise nearby or someone tripping over the wrong cable
They're just not. The ABS, stability, and collision avoidance systems in your car can't fail safe if the software fails because the software is required to control the dynamic situation. It can't just say stop everything. Same as control software in airliners. Or industrial control and monitoring systems (although they can have mechanical interlocks in more cases, not all).
And very little that can be _absolutely_ fail-safe, not even purely mechanical devices. How do you make a fail safe bridge?
That's true, although I think the original point was that if software can damage the hardware it's running on then that should be seen as a fault/bug, but with cost reduction/market pressures/etc. it is often ignored
And fail-safe doesn't necessarily mean everything turns off because that can be just as dangerous, I take it more as a systems mindset where thought, care and attention are paid to failure conditions and making sure those outcomes pose the least risk. Again something which can often be ignored for cost or expediency reasons
Perfection is probably an unattainable goal but I've been around software long enough that I wouldn't want someones safety to depend solely on one piece of software
It is.
And I'm still waiting to hear how that absolutely fail-safe bridge is going to work...
The fact is, Engineering has become the Art of specifying the worst (read: cheapest) implementation one can get away with.
It can involve software though.
Same the other way round, just because the hardware shouldn't allow setting a value to X, doesn't mean the software should request the setting.
Obligatory xkcd post
For comparison, my risk of getting into a car accident is north of 1% and the risk of dying in a car accident is around 0.02%.
So in other words compared to all the other risks out there home electronics are very safe.
Woman on Plane : Are there a lot of these kinds of accidents?
Narrator : You wouldn't believe.
Woman on Plane : Which car company do you work for?
Narrator : A major one.
Reputational damage is so high from consumer deaths now days, the balance sheet comes out in favor of fixing issues.
Even to the point where an actual horrific accident doesn't necessarily mean that vehicle is any more dangerous than other vehicles on the road, they just don't have that exact failure mode but do kill people nonetheless.
And no amount of money is going to buy perfect safety either. As always, engineering is all about tradeoffs, no way around it. Car companies have dropped the ball on safety in several cases, but just because somebody died, doesn't mean they did.
There's not as large of an incentive for product durability and repairability today as there was or should be.
1% of what?
Or “one in a hundred”.
It means that in out of a hundred trips, it’s pretty certain one will involve an accident.
https://ehlinelaw.com/blog/odds-of-being-injured-car-acciden...
Two rules for anyone reading: [1]: never, ever, be in the way of anyone - don't ever be an obstacle to traffic flow; [2]: if you abide to [1], consider you're the only sain person on the road who really knows how to drive, all others don't - everyone around is a danger to you, so be hyper vigilant, always.
In general, be polite and out of the way (both on the road and in life), and you’ll avoid most scratches and crashes.
And presuming everyone (else) is probably nuts doesn’t hurt either :)
Per a quick glance at NHTSA’s summary figures [1] I wonder if the previous poster is referring to the “1000 injured per 100,000 drivers” figure. Which divides out to 1% I guess, a little more in past years. But that’s a little awkward to express in plain language, in that one wreck can injure lots of people, and people can get injured who are not drivers (drivers comprise around half of the injuries, it looks like, from higher up in the table).
Although the total number of crashes (including the large majority that don’t involve injuries) still looks pretty wild as a proportion of licensed drivers. If I were trying to raise concern about cars, I’d point to that ratio of 1 collision (of any sort) for every 43 licensed drivers every year.
[1] https://cdan.nhtsa.gov/tsftables/National%20Statistics.pdf
That's partially because MonkeyClub didn't do the math correctly. If the accident rate is really 1% of trips (which seems doubtful), there is a 99% chance of an accident free trip, a (99%)^N chance of N accident free trips, and a 1 - (99%)^N chance of one or more accidents occurring in N trips. For N = 100, this is 63%, and for N = 365*2 this is 99.9%.
As you mention, the data from the NHTSA seem to indicate a much lower accident/injury rate. Based on this data from the NHTSA [0], and going back to 2018 to avoid any pandemic-related effects on the statistics, it looks like there was on average only 1 (police-reported) crash per 481 thousand vehicle-miles, or one crash involving an injury or fatality per 1.7 million vehicle-miles.
[0] https://cdan.nhtsa.gov/tsftables/National%20Statistics.pdf, other formats and more data available here: https://cdan.nhtsa.gov/tsftables/tsfar.htm
Or at all, since it’s just how possibilities work. I wasn’t calculating the annual possibility.
When I wrote: > For N = 100, this is 63%, ... I was responding to your comment: > It means that in out of a hundred trips, it’s pretty certain one will involve an accident.
Whether or not 63% == 'pretty certain' is another matter I suppose.
Yep, totally.
Remember the counter resets with every ride: it’s the first of the hundred, with 1% possibility of (any) car accident.
That seems about right. It’s one (probably minor) car accident per driver every 20 years.
If there is a 1% chance of something happening during an independent event, then to calculate the probability of it happening at least once across N events, you must use the formula 100% - 99%^N, where the 99% was derived from 100% minus the "1% chance" in the original scenario.
So a 1% chance across 100 trials is 63.4% likely to happen.
Look up the Birthday Paradox for more.
You mean you'll only die or get injured in one out of a thousand home fires? That seems really low. But I'm picking nits.
My main argument is that the consumer electronics as small systems are so so sooo optimized for cost. (Which is good, people can afford them.) But somewhere along the way the components inside them stopped being useful by themselves. (Of course a direct consequence of optimization of integrated parts.)
This basically resulted in custom parts for custom systems. And now as software is eating everything custom software is also part of the system. (Though at least it brought back some general parts!)
Safety as a system level property is still there, but completely lost in the parts. And similarly many other desirable properties have been optimized out. (Like reliability, serviceability, etc.)
The quality of consumer goods is decaying everyday. It is all about the last millionth of a cent to be spared.
Just nobody cares.
You need to look at both sides of that equation. Would you be willing to pay, say, $4000 for a laptop where all the quality engineering was top notch? (It's a reasonably informed guess as to what that would cost.) Maybe some people would. Probably not many. Most people want the $700 laptop which is "just as good", even if the display sometimes fails.
(edit: changed "printing" -> "creating" since the former is a tribalism trigger)
That is... a weirdly revisionist interpretation. People have been complaining about consumer electronics quality consistently and pervasively for decades and decades. Absolutely nothing about that point is "modern" or "new". Yet... you really think it's due to events of the last few months? And not even just any events, politically charged events interpreted and explained using partisan language[1]. Really?
[1] Seriously, one of the easiest ways to tell whether or not to pay attention to an economics argument is whether it includes the phrase "printing money".
Politically, I call the current price inflation "Trumpflation", since that is when the monetary inflation that's driving much of it occurred. We'll see how the Biden administration did in a few years. And while being an Austrian-leaning libertarian, I think the Democrats are at least honest in that they want to use some of the newly created money to compensate for the financial damage that monetary inflation causes, whereas the Republicans want to give it all to the banks while preaching austerity for everyone else.
Let's say a given widget costs $10 to produce, and look at what happens over 4 years. Say offshoring, cost optimization, and technological progress would allow it to be produced for $7. The Fed creates enough new money that the new price is $11. The Fed calls this "2.5% inflation", whereas the actual inflation has been 12%. The sticker price reflects the 2.5%, and the remaining 9.5% is reflected in the item being made cheaper, not supporting the local economy, and the gains of technological progress accruing to the central bank rather than being distributed throughout society.
At the larger level, this does not happen uniformly to every component of CPI. Instead, prices for things that can be bought with new money increase more. So manufactured goods still have relatively low price inflation, where things that the consumer can finance (housing, education, healthcare, vehicles) shoot through the roof.
Bringing this back to the original topic - since the median consumer's expenditure is expected to be ~fixed (slightly rising) for a basket of goods that are decreasing in quality, they're unable to afford the previous baseline quality that is now considered luxury. Rather than seeing a choice between buying what they know and saving money with a lower-quality item, they're given a choice between paying slightly more for the lower quality one or paying much more for the quality that they were used to.
It's true, that if you correct for all the inventions and economies that have made its production possible, the relative "cost" of, say, a nice new five-burner induction range is indeed extremely high in comparison to, say, the bow drill your ancestors would have used. Probably in the billions or so, if not higher.
But that's not telling you anything! In point of fact the "cost" measured in hours of labor[1] of collecting fuel and starting fires over the course of a decade or so[2] is VASTLY higher for the paleolithic toolkit. And it's not even remotely close, which is why no one chooses to cook with an open fire and a bow drill except as an amusement.
Basically: you're bending yourself around and measuring the wrong thing to try to make a point about inflation in an area that has nothing to do with it.
[1] Which is, at the end of the day, all we really care about optimizing. We live one life and we want to live it well doing as little work as possible. Frankly this is sort of "postulate zero" of the whole field of economics.
[2] Just assume the range will last for a decade. I don't know what the real average is but it's in that range.
Furthermore, accounting for optimization via tradeoffs as if it's bona fide growth is doubly wrong. Cost reduction via quality reduction is actually the opposite of growth, but gets counted as increased efficiency for labor rather than reduced quality of life for humans.
Focusing on hours of labor and gradually reducing hours worked would have been a different way to keep the benefits of growth distributed throughout society. Instead full time employment has been fixed at 40 hours through a long period of high growth, with the new money feedback loop soaking up the individual's surplus.
Yes. This is also why I do exactly that. Thankfully there’s still one company making good laptops left, Apple.
Unfortunately, all the brands I used to buy from decided it was better to cut the cost by half by cutting the quality by 9/10s.
The ones from 2011 are.
YES, please, I beg of the industry give me this.
In a loud, resounding voice.
Buying a new laptop takes days of investment to get it all set up just right. Maintaining the software and OS to keep it snappy is also a timesink. The initial cost of the hardware is a trivial portion of the TCO for me.
It's also an item I only carry around one of (lugging around a backup device would be too inconvenient even if it only cost a dollar), so reliability is paramount.
My current laptop (Dell Precision from ~2011) cost a little over your price point, and has been upgraded many times over the years. Finding something I'm happy to replace it with has been a conundrum, there's a ton of absolute garbage out there. (Framework almost does what I need and is a leading contender).
I kind of do this. I bought two used laptops a few years ago, one 13" XPS and a big bulky ~17" ThinkPad. The XPS is great for meetings, the other one is great for software development, and I have a backup ready and set up, ready to go. And if I travel for more than a day I sometimes take both. (So far the strategy seems to be flawless, as both work in well their own sub-par broken but reliable way, as Windows machines tend to, maybe each one is kept blinking by pride, or just to spite the other one. :D)
The other problem is that niche high quality stuff also would not benefit from economies of scale as much, and at some point buying 4 of the cheap might get you thru longer than one of the "reliable" one
The top-end electronics are maybe a bad example as (at least till now, it seems to slow down at last) the performance is also a big factor, so buying $700 laptop you will want to replace anyway in few years is sensible over "will never break" $4000 one that will just go out of date.
But on like, just about everything else ? Reliability and repairability please, I will pay extra.
Isn't that what Emperor Linux is (nominally) about? Not that I have ever tried them out because that is way beyond my pay grade, but several of their machines are in that price range.
Absolutely. Yes please. That would mean I can use it for 10 years without major problems, I'm able to repair it, no Jail breaking needed... make it 5k. More than happy.
But I understand, I'm not the majority of the market.
On the software side I reckon the driving circuit is the deciding factor, which a vendor (of displays) can't control.
Why would they be secured there? The device doesn't allow setting any of the dangerous settings, so noone will break their displays this way.
Look at cars for example... pretty much cars have systems in place not to overheat (thermostatic valves, fans, etc.). Most even have code to go into limp mode and turn off if they overheat. Now imagine someone taking the ECU out of the car, installing gentoo on it, putting it back in, and forget to write a script to check the temperature and turn on the fans when needed... the car would probably work ok when driving high airflow) but when stopped, it would heat, overheat and eventually something would break down. Do we need some kind of a hardware system in our cars to turn on the fans, or something that turns off the main relay, because someone decided to hack the software and forgot to implement sotware limits and checks?
So does a switch.
Someone installing gentoo on a cars ECU, and not implementing the feature to turn the fans on will easily overheat and destroy the car... the same is happening here with the lcd controller (and yes, the switch is designed so that the user can never go above some brightness level... unless the user hacks the switch and installs some random linux on it).
The car will alert the driver than something is wrong and should stop as soon as it is safe.
Because stopping engine abruptly in middle of highway could be very dangerous.
A lot of cars also have so-called "limp mode" where some failures cause car to limit engine power and other stuff, basically to get to the next point the car can be stopped and towed to shop
We're talking about someone taking a device, hacking it, installing some random software (whatever hacked version of linux runs on switch), and that software does not have the feature of limiting the max brightness at an accaptable (non-damaging level). So the same as if you took an ecu of a car, put linux on it, didn't implement the limp mode feature and then blame the hardware for overheating.
Pragmatic design decisions. My bet is they decided that adding voltage regulation was unnecessary since they can limit it via software which they have control. Adding voltage regulation would increase the component count which takes up board space and lengthens the BOM (bill of materials.)
I thought I fried the thing, but it went away it on its own and the display continued to work. I couldn’t figure out a mechanism for causing it to happen, but this explains it.
Because we make generic LCD controllers that can service a wide range of panels.
Using generic parts with adjustable outputs is standard practice. It keeps prices down, keeps supply chains flowing, and makes it easier to design new systems around common parts. It also reduces the amount of waste because common parts can be re-used in new designs and resold if unused.
Many things around you are controlled by software settings without separate hardware limits to keep them in check. If you have an enthusiast motherboard, you can reboot right now into the BIOS and set the CPU and RAM voltages to numbers that will fry your chips in short order if you want, and it won't stop you at the hardware level.
Generic parts with a wide output range are great, but it requires care and attention to make sure the software is providing the right settings.
The simplest hardware design is just running it at say 10% max in flashlight mode but allowing for short bursts of overdrive for flashing. The LED is big enough to handle short bursts, but not thermally cooled well enough to work at full power all the time. So you rely on firmware/software to do its job instead of having specialised hardware controller that's only job would be to make sure LED isn't on on 100% for more than say half a sec.
You control software so you don't GAF, but people putting custom one have to take same amount of care
Second example: You're an engineer and need to drive a backlight. You can
* slap a constant-current controller (buck or two of parts) so 100% is a maximum safe level all while regulating it at >90% efficiency * slap a high value resistor costing $0.01 so 100% is maximum level is safe but you lose a lot of power in the resistor * slap a low value resistor then just drive it at 20% duty cycle and waste less heat in resistor all while still costing $0.01
They just most likely picked 3rd. Or picked 1st and misengineered the limits I guess...
Yes, those who said that are long gone. Me, and the few that said it was doable (and did, moving those 5"1/4 floopies drive beyond the heads' limits), are here, watching the news...
Just a matter of getting used to, I guess.
So while they often get overly-full of markup like these ones, the markup follows a pattern that's rarely broken, and it becomes very easy to follow after you've gotten through a few threads.
For both, it seems like I read messages in random order and then have to guess at the general gist. There's seems like no easy way to get an accurate timeline of things.
I think the problem is made worse when people forward (or retweet) as part of a conversation. There's often forwards of other email chains included as a reply with or without unique new messages being added.
Sometimes people are left off part of the CC chain for some messages, so there are gaps in the flow.
The problem is compounded when there are multiple email threads about the same thing, often because someone replied to an old version that turned into a new conversation. Or they read just the first sentence in the original email and replied about that in the newest follow-up in a 100 email chain.
---
As an off topic side note, text chat programs are the ultimate form of communication. It has the fewest flaws of all mediums. It's linear in a single timeline that everybody has (and has the history to). It's pretty hard to mess up the history of what happened or who said what.
I enjoy it when people get frustrated about text chat. It's almost always because they can't dominate the conversation by talking over people or "win by talking loudest" which makes them frustrated and uncomfortable.
I don't use Twitter so I don't know what it does, but if you look at the email, the oldest posts are quoted first, so you just read the message top to bottom like anything else.
And if that's too confusing, there are links to every message in the thread at the bottom.
If you're talking about the quoting, the ">" marks denote one level of quoting, so the more ">" marks in a line, the older the message. As long no unwashed heathen has top-posted their reply, then you can just read the message top to bottom in chronological order.
From top to bottom, like we did for centuries.
Replies at the top are the devil’s work. Or maybe Microsoft.
> No idea if that was real though
Chose one :) You can't state it was a myth and then later say you don't know!
I've heard the same thing about older CRT monitors and remember reading about people damaging their CRT monitors by careless programming in regards to refresh rates. But I haven't actually seen in real life, and I must have read about this in the early 90s or something like that I think, so long time ago.
However, I have seen people having Mew back when I played some Gameboy myself, that one is _not_ a myth :)
The RNG method to encounter Mew in the wild was only discovered years and years later and most definitely wasn't known 20 years ago.
The word myth generally has two meanings. One is that it's a false belief. The other is that it's a legendary story of which the truth is not known. GP obviously intended the latter definition.
The Amiga could output stock NTSC/Pal and some close variants, and many monitors existed which could handle that lower scan frequency (15khz), as well as higher res output with Picasso cards.
https://bigbookofamigahardware.com/bboah/product.aspx?id=466
Anyhow, we always tested new monitors before selling them. Monitors which could handle 15khz and higher frequencies too, were expensive and rare.
Often customers would plug in a cheaper, standard PC monitor, and so we wanted to offer those too.
We plugged in one such, and when the switch came to 15khz? It exploded. Like, the magic grey smoke escaped, along with flames and melting plastic.
Every other monitor brand we tested just went blank screen, or reported "out of sync" on the display.
In as customers might accidentally leave passthrough on/setup, we figured selling this monitor to them to be a mistake.
So if it can happen with too low of a frequncy, surely crappy monitors also exist which blow when too high a frequency is passed.
But that's just terrible, crappy hardware.
A typical modeline calculator warning:
It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk.
<https://arachnoid.com/modelines/>
My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
> My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
It's done in the monitor.
One little oopsie, and that monitor had a line through it for the rest of its life.
- A modeline used to output 480i SDTV-compatible signals (525 scanlines) from a PC, differs from the same resolution's modeline under Coordinated Video Timings (arachnoid.com generates a 516-line modeline for 480i, and Linux's cvt tool doesn't document its interlacing flag because interlacing is not part of VGA or something).
- DVI and HDMI signals are effectively continuous signals with CRT-like timings, translated into digital signals (discrete-time at your GPU's configured dot clock, and quantized) and encoded using TMDS with special pixel values on the blue channel (outside of the 0-255 range) for hblank and vblank. Whereas DP signals are packetized in some manner I haven't researched.
- One common way to output 480i is through HDMI-to-component converters. But 480i has a too low pixel clock below the HDMI spec's minimum timing, and many GPUs cannot put out such a slow signal or converters cannot understand it. (I wonder how DP-to-component would fare, given it's packet-based and might not suffer from a minimum dot clock readable by the receiver chip.) A common workaround recommended by the developers "CRT Emudriver" (AMD GPU drivers modded by in-place binary patching) is to set a 2560x240p or 480i "super resolution", then configure emulators and games to output stretched signals. Unfortunately, neither non-RetroArch games nor Windows's CRT Emudriver cannot rescale their image to non-square pixels and their 1440x480 images were squashed to a 4:3 aspect ratio, so I had to switch to Linux and xrandr for square images.
- I had to pick 1440x480i because otherwise the vblank pulses generated by my AliExpress HDMI-to-component converter were insufficiently staggered between interlaced and non-interlaced scanlines. Since I don't have an oscilloscope, I diagnosed this by piping the sync-on-green composite signal into my motherboard's 192khz line-in capture, then recording in Audacity and comparing to correct NTSC timings (the vertical serrations should be evenly spaced and they weren't).
- The Linux amdgpu driver is well capable of outputting a 1440x240p resolution (there are many NTSC modelines, with varying undesirable horizontal offsets and stretching, and vertical offsets), and xrandr is an excellent way to scale a 1280x960 framebuffer to 1440x240 or such (which is scaled back to square aspect ratio on-screen). Unfortunately Linux amdgpu's dc driver for its display controller (compatible with atomic modesetting) has missing support for interlacing, the easiest workaround being to pass `amdgpu.dc=0` to the Linux kernel command line (this disables atomic modesetting, switches to the legacy display controller driver, breaks HDMI audio, and makes the mouse cursor unaffected by Redshift so Plasma's text cursor becomes practically invisible on white text fields).
- - I debugged this extensively at https://gitlab.freedesktop.org/drm/amd/-/issues/1636, but failed to solve the problem. If I hack the driver to force interlacing on (not realizing I needed interleaving as well), the resulting analog signal repeats the first scanline hundreds of times followed by a birth-defect serration pulse, which I would be unsurprised if it would physically destroy some CRTs. I recorded a video (epilepsy warning) at https://www.youtube.com/watch?v=GoQ9q1lwKHI.
- - Antonio Giner claims to have a fix for interlacing in amdgpu.dc=1 mode, for his GroovyArcade arcade CRT distribution, but it's not upstreamed, it doesn't currently work on my GPU, and I never did get around to porting it to my older RX 570, finding the correct modeline, and testing that it works. Turns out modern games like Stray aren't optimized for interlaced displays (vsync caused horrendous input lag) or 480-line-tall screens (HUD elements and jump prompts are too small to see), who would've known! I do think Celeste would work fairly well in 240p mode, but I haven't gotten around to testing that either (in either amdgpu.dc=0 or porting my patch).
- Compensating for CRT television overscan (since modern games like Stray draw HUD elements like jump prompts right on the edge of the screen) is a nightmare. On amdgpu, xrandr's underscan option can only take off <=128 pixels evenly split between the left and right, or the top and bottom. Worse yet, the display controller outputs eg. 1340x460 of non-black image, by downscaling (in hardware?) a second time from the 1440x480 framebuffer downscaled in software from 1280x960, creating unnecessary vertical blur.
- - Since I don't know how to perform both downscaling steps in hardware with unmodified amdgpu drivers (like a non-square-pixel VSR), I opted to perform both downscaling steps in software, by writing a shell script to kill plasmashell and open a full-screen mpv showing a black .png file on a 1440x1030 framebuffer, then use KWin rules to overlay a 1280x960 borderless window of Stray at a precise position over mpv (with black mpv borders on all 4 sides), use xrandr to downscale 1440x1030 to 1440x480i, then kill mpv once Stray exits. It's a terrible setup and I wish there was a better way. But CRTs and overscan is dead, interlacing is dead, 640x480 is dead, and only a fool or experimenter (or someone with complex-trauma depression seeking comfort in nostalgia and cats) would try hooking up modern computers and games to triply-dead CRT SDTVs and expecting them to work.
Also not mentioned there but on the MSX 1 you could 'burn out" the tape drive relay by switching it on and off very fast.
If at all truth, it was in very specific HW (I was in touch with really, really, really big amounts of people in the industry and HW, and have never first hand heard of that happening).
I updated my Framework‘s Arch install (to kernel 5.19.12) the other day and the display began flickering on and off on boot up. Had to get out a live USB to revert.
Me: "Crap, I got 5.19 running"
Also me: "Calm down, it's only 5.19.13"
Rollercoaster of emotions :)
> >> I definitely had no plans to backport any of that stuff, > >> but I guess the automagics did it anyway. > >> Looks like stable is at least missing this pile of stuff:
Did a half-finished feature end up in the release due to an automatic merge?
Here's an article about the machine learning bits: https://lwn.net/Articles/764647/
I dunno what's up but the 5.19 kernel has had some pretty shoddy releases or major bugs getting through. I kind of think the video, audio, etc. drivers for these highly integrated SoCs are just getting way too complex and unwieldy for anyone to reason about or review.
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
So sounds like it can cause some out of spec stuff at the analog level, which could plausibly result in damage, but also probably dependant on exactly what bogus values are sent in a particular case and how resilient a particular LCD is.
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
> After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
My framework laptop was affected by this. When I booted 5.19.12 my display was flickering like crazy. Rebooting with 5.19.11 corrected it. 6.0 is also fine.
It talks about power and general speaking I would have thought that outside extreme cases most electronics just draw the amount of power they need but not more. Can a kernel determine this somehow?
The project I'm working now, and the last I was, we had in a 4x4 inch board more than 10 voltages (1.0v 1.1v 1.3v 1.6v 3.3v 4v 5v 6v and I do not know what more) , all generated by micro controller configured power supply circuits. Those 10 voltages had to follow a very specific sequence, failing to follow it, could in worst case, damage the whole board. Basic explanation: if circuit part B is powered before part A, power flows "backwards" to A, melting it.
In addition, an error in the configuration of the supply ASICs would also lead to too high voltages. That is, the output voltage was configured in one register.
I think something along the lines is going on here.
Electronic circuits will only let a certain amount of electrons flow. If the power supply has way more electrons "available" than necessary, that's no problem, you only encounter problems if the power supply can't keep up.
However, electronic circuits are built to run at a particular voltage. If the electrons "want" to move too much, they may jump across gaps in unintended ways and generally cause havoc.
So in short: A power supply can't damage electronics by providing too high current, but it can damage electronics by providing too high voltage.
I don't know if that's what's happening here, I haven't read about the actual bug, but that's a basic primer on how it's possible to damage electronics even though they only draw the amount of current they need. And software is often involved in setting the voltages which are being supplied to certain components.
At least that's a prevalent and very useful picture of how electricity works, and what's being taught in university courses. It's probably a good enough explanation to answer "why can too much power destroy electronics if electronics control how much current they draw".
From Wikipedia, sourced from The art of electronics.
Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant? If it turns out I (and Wikipedia, and all material I've seen on the topic) is wrong, I'd certainly love to know. I'm just interested in this stuff; I have only taken introductory courses at university and learned on a hobby basis, I haven't taken advanced courses.
And power is what destroys things, mostly, by over heating them and transforming them into a different shape that no longer functions as expected.
> Do you have a link to an explanation of what current is which makes the movement of charged particles almost irrelevant?
Not really, but consider when was this slow drift (~3 mm/s) of electrons ever of interest/topic in your education, instead of much faster changes in charge distribution on the surfaces of conductors caused by (or creating) electrical fields?
3 mm/s is extremely slow, you'd very much notice if any phenomenon you routinely worked with in EE courses was this slow.
In practice not respecting these timings is kinda like toggling your ceiling lights on/off repeatedly. I bet your parents used to tell you the house could be set on fire if you did that, but you did it anyway and nothing ever happened. I think it's unlikely somebody will actually be able to damage their panels with that bug. But hey I'm pulling this guess out of my ass so don't quote me on that. But that can result in the panel failing to turn on and giving you a black or flickering screen.
In fact, at least a few years ago when I looked at this, the Intel driver was very conservative regarding those numbers because a long time ago in a galaxy far away the VBT values for some laptop models were bogus, so as a result nearly everybody had timeouts longer than what they needed to. There's a chance that even with a bogus VBT you're waiting more than you should for your panel. But that doesn't really affect real people very much, it's only really a significant problem if you're testing Display code and doing thousands of modesets per minute. Unless you're getting black screens, of course.
Reading through the i915 driver and Sandy/Ivy Bridge GPU datasheets, I found that the backlight was controlled by two GPU registers at 0x48250 and 0x48254 (CPU-written?), with mirrors-ish at 0xC8250 and 0xC8254 (PCH-written?). There's actually a script to decrease the backlight period register at https://github.com/edio/intelpwm-udev, but the problem is that Linux still scales the pulse width register based on the original period (10ms) at time of bootup and doesn't see the userspace tool writing a shorter period (higher frequency). If you halve the backlight period to 5ms, 50% brightness suddenly configures the GPU to turn the screen on for 5 of 5 ms, setting the screen to full brightness instead (all lower brightness values are doubled, and all higher ones are technically illegal chip configurations). As an added gotcha, if you write to the wrong register mirror (0xCxxxx vs 0x4xxxx), you get seizure-inducing screen backlight flicker comparable to the issue report at https://gitlab.freedesktop.org/drm/intel/-/issues/7013.
I tried recompiling the i915 driver to increase the PWM frequency at boot time, but was unable to compile and replace that driver alone due to symbol version mismatches (and I didn't want to rebuild the whole kernel on an obsolete dual-core Ivy Bridge). So I tried changing the backlight frequency in the BIOS itself, which was OS-agnostic and didn't require editing Linux drivers. I began decompiling the UEFI firmware in Ghidra and tracing control flow across multiple undocumented labyrinthine EFI executables, finding that I had to modify a VBT file's backlight PWM frequency field to change the refresh rate. Sadly this only affected pure UEFI boot and not CSM mode, but disabling CSM causes Windows 7 (the OS I used when the laptop was new, and which I keep this laptop just to run) to show a black screen. And I got burnt out from reversing EFI, and broke a flash chip leg and two motherboard pads reflashing my BIOS (and barely managed to patch the BIOS chip circuit back together with bodge wire soldered to the chip's stub)... so I'm still stuck with 100Hz flickering...
100Hz flicker is terrible. It's amazing vendors still are so clueless.
I forgot to mention, I actually managed to write a program that would dynamically rewrite the period and pulse width registers to play music off the screen backlight, based off a conversion of the Monkey Island tunes from https://www.thanassis.space/monkeyisland.html. It almost worked... except that whenever I decreased the period (raised the pitch), there was a random chance the new period would be greater than the current phase, and so the display would hang at full or zero brightness nonstop (producing a gap in the sound) until the 16-bit counter running at 0.98 MHz (= 125/128) rolled over, rather than instantly setting the counter to zero and turning the display back on. I've recorded my "best effort" attempt at music, at https://www.youtube.com/watch?v=7qt0ssFk410 (every recording has different gaps when pitch increases).
Wonderful writeup BTW!
This is a lesson we've learned many times over by now: Software limits alone are insufficient.
Also spend some time reading product forums. Windows and MacOS have plenty of bugs...
Anyhow, a quick google search yields stuff like this: https://www.makeuseof.com/tag/fix-windows-10-screen-flashing...