One of the first chromebooks would melt and burn if you fired up alsamixer and tried toggling a few of the toggles.
I encountered this myself fiddling with the audio settings and ended up with magic smoke and melting plastic before I quickly powered it off.<p><a href="https://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-speakers-in-your-chromebook/" rel="nofollow">https://marcin.juszkiewicz.com.pl/2012/12/10/how-to-fry-spea...</a>
<a href="https://groups.google.com/g/comp.os.linux.advocacy/c/QslNrtxo__A/m/9o2VKW0dDAAJ" rel="nofollow">https://groups.google.com/g/comp.os.linux.advocacy/c/QslNrtx...</a><p>(note it doesn't actually require installing another distro - alsamixer was available in the base chromeos install)
<i>Intel GPU</i> Users<p>Judging by <a href="https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch1-1/23171/66" rel="nofollow">https://community.frame.work/t/psa-dont-upgrade-to-linux-ker...</a>, it has been solved in 5.9.13 already.<p>Date: Tue, 4 Oct 2022:<p>> 5.19.13 is now released with 8 reverts for this driver, hopefully that sould [sic] resolve this issue. thanks, greg k-h<p><a href="https://lore.kernel.org/all/YzxDIXMPIWqsELmj@kroah.com/" rel="nofollow">https://lore.kernel.org/all/YzxDIXMPIWqsELmj@kroah.com/</a>
I remember seeing somewhere that in the beginning of Linux on the Nintendo Switch that people destroyed their displays by raising the brightness bar too high.<p>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?
I remember back in 1998 when I was in a strong discussion on how software couldn't damage hardware: no matter what you did, you wouldn't be able to damage hardware with your bits.<p>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...
It looks like the issue was caused by a wrong merge, not by a particular commit.<p><a href="https://lore.kernel.org/all/YzsfrkJcwqKOO+E%2F@intel.com/" rel="nofollow">https://lore.kernel.org/all/YzsfrkJcwqKOO+E%2F@intel.com/</a>
Ha, reminds me of a myth from 20+ years ago, that there was a virus that could damage your CRT display by requesting the monitor to refresh at 1000Hz or something stupid, which would damage at least some monitors without the proper safeguards. No idea if that was real though.
I guess I got hit by this?<p>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.
FYI if you're running Arch Linux, Linux 5.19.13 has already been released into [core] so you should be OK, assuming that your mirror is up-to-date and you've run pacman -Syu recently. <a href="https://archlinux.org/packages/core/x86_64/linux/" rel="nofollow">https://archlinux.org/packages/core/x86_64/linux/</a>
Me: Furiously typing uname -a into terminal.<p>Me: "Crap, I got 5.19 running"<p>Also me: "Calm down, it's only 5.19.13"<p>Rollercoaster of emotions :)
What does he mean by:<p>> >> 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:<p>Did a half-finished feature end up in the release due to an automatic merge?
Ooph that sucks. The 5.19 kernel completely broke audio for my Ryzen APU laptop too, I have to wait for a 5.19.10+ kernel in my distro (pop os) to get a fix.<p>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.
Is there a layman's explanation for what is happening here?<p>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?
Interestingly I have a similar experience of flashing displays, though my issue reflected the backlight and not the panel poweron sequence. After chip-level-flashing an Ivy Bridge Dell laptop with a corrupted BIOS chip, I was disappointed to find that the backlight was dimmed using PWM at 100 Hz (10ms periods) (CORRECTION: 200 Hz), where 50% brightness in Linux sets the light to turn on for 5ms, then off, and repeat every 10ms. This causes noticeable flicker when I move my hand in front of the screen.<p>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 <a href="https://github.com/edio/intelpwm-udev" rel="nofollow">https://github.com/edio/intelpwm-udev</a>, 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 <a href="https://gitlab.freedesktop.org/drm/intel/-/issues/7013" rel="nofollow">https://gitlab.freedesktop.org/drm/intel/-/issues/7013</a>.<p>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, <i>and</i> 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...
There is some weird bug on Intel NUC11TNK that makes displays at 5k2k@60/TB4 show overlapping regions with changing "soft" boundaries (like when overclocking CRT monitors that can't handle the resolution) and that bug is present on all 5.5-5.19 kernels I've tested. Maybe it's related to this bug?
If I'm right the venerable ThinkPad X220 (T420 and so on) with Sandy Bridge (Intel HD3000) does use LVDS instead of eDP. And only some generations later Intel supported PSR with eDP. So it is safe?
I decided on Sunday to switch my Arch kernel to latest from LTS, I guess its just dumb luck it also brought Grub down and I had to roll back to using the LTS kernel.
Surprised no one has mentioned the Therac-25 debacle: <a href="https://en.wikipedia.org/wiki/Therac-25" rel="nofollow">https://en.wikipedia.org/wiki/Therac-25</a><p>This is a lesson we've learned many times over by now: Software limits alone are insufficient.