Fedora 36: A brave new (DRM/KMS only) world(blog.dowhile0.org)
blog.dowhile0.org
Fedora 36: A brave new (DRM/KMS only) world
https://blog.dowhile0.org/2022/04/22/fedora-36-a-brave-new-drm-kms-only-world/
139 comments
Nothing about the Raspberry Pi’s video system is normal.
Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
The F in fkms stands for “fake” because they created a quirky abstraction to fake KMS compatibility. The non-fake driver has been all sorts of problematic but it’s getting better.
But none of this Raspberry Pi specific weirdness should be extrapolated to the KMS/DRM subsystem in general.
Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
The F in fkms stands for “fake” because they created a quirky abstraction to fake KMS compatibility. The non-fake driver has been all sorts of problematic but it’s getting better.
But none of this Raspberry Pi specific weirdness should be extrapolated to the KMS/DRM subsystem in general.
> Nothing about the Raspberry Pi’s video system is normal.
Nothing about the Raspberry Pi at all is "normal," and it's a very useful filter for people who have read about the various deep weeds of firmware/OS development and those who have actually gotten their hands dirty on a Pi - because the first group will express admiration about the "open and well documented hardware," and the second group will laugh at the first group and start cursing the various non-and-poorly-documented nonsense that's in the Pis.
They're nice devices, and work well enough, but they are architecturally insane and unlike anything else except the previous Raspberry Pis that were hacked to to make the new ones.
The Pi1/2/3 are more or less an (undocumented) GPU with an ARM core bolted on the side. The GPU boots the system, allows the ARM core some access to the DRAM (not at the same addresses as the GPU sees things, so be sure which version of memory addresses you're looking at), and most of the hardware control is done by asking the GPU to please do this thing for you through the mailbox interfaces. In the same way that userland applications make syscalls into the kernel, the kernel running on a Pi makes syscall-like requests into the GPU to do just about anything.
The reason you see things like "All the interrupts are only ever on a single core" is because the interrupt controllers simply don't allow anything else. The Pi2 BCM2836 interrupt controller feels a little bit like an intern's project, using the BCM2835 bolted on the front as an input for the rest of the hardware. At least the Pi4 finally gets a GIC...
They're fine, sort of... as long as you're OK with the only documentation for some of the hardware being "This Linux driver works with it" and "Well, people have reverse engineered most of it." But they're absolutely insane, architecturally, they're poorly documented, and this doesn't seem widely known.
Nothing about the Raspberry Pi at all is "normal," and it's a very useful filter for people who have read about the various deep weeds of firmware/OS development and those who have actually gotten their hands dirty on a Pi - because the first group will express admiration about the "open and well documented hardware," and the second group will laugh at the first group and start cursing the various non-and-poorly-documented nonsense that's in the Pis.
They're nice devices, and work well enough, but they are architecturally insane and unlike anything else except the previous Raspberry Pis that were hacked to to make the new ones.
The Pi1/2/3 are more or less an (undocumented) GPU with an ARM core bolted on the side. The GPU boots the system, allows the ARM core some access to the DRAM (not at the same addresses as the GPU sees things, so be sure which version of memory addresses you're looking at), and most of the hardware control is done by asking the GPU to please do this thing for you through the mailbox interfaces. In the same way that userland applications make syscalls into the kernel, the kernel running on a Pi makes syscall-like requests into the GPU to do just about anything.
The reason you see things like "All the interrupts are only ever on a single core" is because the interrupt controllers simply don't allow anything else. The Pi2 BCM2836 interrupt controller feels a little bit like an intern's project, using the BCM2835 bolted on the front as an input for the rest of the hardware. At least the Pi4 finally gets a GIC...
They're fine, sort of... as long as you're OK with the only documentation for some of the hardware being "This Linux driver works with it" and "Well, people have reverse engineered most of it." But they're absolutely insane, architecturally, they're poorly documented, and this doesn't seem widely known.
Doesn’t sound too insane; sounds like an architecture designed for real-time professing, where you’ve got an “IO processor” that boots the system and handles all the interrupt-heavy work, and an “application processor” that can be solely dedicated to your workload and will only be interrupted by the IO processor if it explicitly asks to be by first making a request to it.
Very similar to previous-gen game consoles, e.g. the Wii U’s “Broadway”
Very similar to previous-gen game consoles, e.g. the Wii U’s “Broadway”
Does the pi allow to put own routines straight onto it's "IO processor"?
Hopefully the work done by the LibreRPi folks helps things get a little less weird:
https://github.com/librerpi/ https://gwolf.org/2022/04/how-is-the-free-firmware-for-the-r...
https://github.com/librerpi/ https://gwolf.org/2022/04/how-is-the-free-firmware-for-the-r...
I'm quite familiar with Clever's work. I understand how it's put together at a pretty deep level - and it's still weird. It's not the slightest bit like anything else that is used as a general purpose computer in the layout of "how pieces talk to each other or how they interact with hardware." You can draw some parallels to the ARM Trusted Firmware interfaces if you squint hard enough, but it's still a really weird hardware layout for what it's commonly used for.
"Non- and poorly-documented nonsense" is exceedingly common throughout the embedded hardware ecosystem. The Pi is doing well on a relative scale of freedom and openness, not an absolute one.
> The Pi1/2/3 are more or less an (undocumented) GPU with an ARM core bolted on the side.
Is the Pi4 any different/better?
Is the Pi4 any different/better?
I don't know the Pi4 architecture deeply enough to offer an opinion on it, sorry. Ask me in a year or two and I'll likely know it a lot better.
Well, they fucked up their implementation of USB-PD with a rookie-level mistake, it took ages for them to support booting off USB, the 5V rail is noisy...
Raspberry Pis were initially just a way for the Pi foundation to help Broadcom sell SoCs nobody wants anymore but they still had lots of stock/tooling for. Sort of like "hybrid" bicycles are how bike manufacturers milk more money out of hardtail (non-suspension) MTB frames.
Raspberry Pis were initially just a way for the Pi foundation to help Broadcom sell SoCs nobody wants anymore but they still had lots of stock/tooling for. Sort of like "hybrid" bicycles are how bike manufacturers milk more money out of hardtail (non-suspension) MTB frames.
It's almost the same overall architecture, just a lot of pieces have been upgraded to be wider and faster, and some peripherals added.
Are Broadcom's ARM chips that half-baked in general, or are these quirks specific to the ones used in the Raspberry Pi?
[deleted]
Ah, thanks for that.
> Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
It's funny, I just posted a comment about being afraid to dig into KMS code for fear a wizard would show up and tell me I'm looking in a wrong or irrelevant place. Luckily, your comment preempts that process.
And also luckily, I've only thrown flags at Chromium provided by other wizards so far. So my ignorance about KMS remains pure. :)
> The non-fake driver has been all sorts of problematic but it’s getting better.
So... are there like two different teams, one Pi-specific 'f', one general 'not f', racing to see whose module will become stable first?
Do both teams stream on Twitch? If not they should.
> Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
It's funny, I just posted a comment about being afraid to dig into KMS code for fear a wizard would show up and tell me I'm looking in a wrong or irrelevant place. Luckily, your comment preempts that process.
And also luckily, I've only thrown flags at Chromium provided by other wizards so far. So my ignorance about KMS remains pure. :)
> The non-fake driver has been all sorts of problematic but it’s getting better.
So... are there like two different teams, one Pi-specific 'f', one general 'not f', racing to see whose module will become stable first?
Do both teams stream on Twitch? If not they should.
[deleted]
The dtoverlay parameter (device tree overlay) allows manually inserting device nodes into the device tree loaded by the system.
vc4-fkms-v3d is a module, vc4-kms-v3d is an entirely different module. These correspond to files somewhere on your device that describe the device and how to operate it.
The -f- version seems to do more video processing in the firmware rather than in the kernel. I can't tell you exactly what they do differently, but I'd assume that the -f- variant uses some kind of Broadcom magic and the non-f-version runs mostly in-kernel and therefore has different side effects when it comes to video processing.
Switching between these changes the way the kernel deals with graphics, so that's probably why you see the mouse being smoother in one version and hardware acceleration being unreliable in the other.
I can't tell you why Chromium is being weird. It could be a Wayland/X11 issue, it could be a driver support issue, it could be firmware issue, or maybe it's got something to do with sandboxing (Ubuntu and its Snap sandboxing have caused hardware access issues for me in the past). I have no idea what DRDC is even supposed to do, I'm guessing it's an optimisation in the Chrome rendering engine but who knows at this point.
To get the answers you seek, you'll have to dig into source code, I'm afraid. Perhaps if you reserve engineer the requirements for Chrome to enable the setting you'll find a hint at what you need to do to your rendering software to get it to support Chrome's code.
vc4-fkms-v3d is a module, vc4-kms-v3d is an entirely different module. These correspond to files somewhere on your device that describe the device and how to operate it.
The -f- version seems to do more video processing in the firmware rather than in the kernel. I can't tell you exactly what they do differently, but I'd assume that the -f- variant uses some kind of Broadcom magic and the non-f-version runs mostly in-kernel and therefore has different side effects when it comes to video processing.
Switching between these changes the way the kernel deals with graphics, so that's probably why you see the mouse being smoother in one version and hardware acceleration being unreliable in the other.
I can't tell you why Chromium is being weird. It could be a Wayland/X11 issue, it could be a driver support issue, it could be firmware issue, or maybe it's got something to do with sandboxing (Ubuntu and its Snap sandboxing have caused hardware access issues for me in the past). I have no idea what DRDC is even supposed to do, I'm guessing it's an optimisation in the Chrome rendering engine but who knows at this point.
To get the answers you seek, you'll have to dig into source code, I'm afraid. Perhaps if you reserve engineer the requirements for Chrome to enable the setting you'll find a hint at what you need to do to your rendering software to get it to support Chrome's code.
> The -f- version seems to do more video processing in the firmware rather than in the kernel. I can't tell you exactly what they do differently, but I'd assume that the -f- variant uses some kind of Broadcom magic and the non-f-version runs mostly in-kernel and therefore has different side effects when it comes to video processing.
What does it mean to do video processing "in the kernel?" I assume that cannot mean software decoding-- if that were the case I wouldn't be able to play back smoothly.
What does it mean to do video processing "in the kernel?" I assume that cannot mean software decoding-- if that were the case I wouldn't be able to play back smoothly.
This is only about "kernel mode setting" - basically interfacing the hardware that drives your displays, sets up HDMI (if you use that) and so on. For the Raspberry Pi specifically, the "fkms" for fake KMS means that you use the proprietary RPi firmware to talk to the display and setup your screen, while the kernel just throws over a framebuffer. If you use the non-fake KMS, you have the kernel do all that lower level setup but you get more direct access to the hardware that allows you to use multiple planes and so on.
Why have both? The firmware, being derived from what was a set-top box, has a lot of proprietary magic to make things work with displays, also specifically with things like the official RPi display.
Why have both? The firmware, being derived from what was a set-top box, has a lot of proprietary magic to make things work with displays, also specifically with things like the official RPi display.
I can tell you why this is happening! I think!
OK, so first off, FKMS vs KMS.
KMS is Kernel Mode Setting. This is the kernel's framework for setting video modes, abstracting over HDMI/DSI initialization, timing parameters, etc. etc. across platforms.
FKMS is still KMS, but it's a special KMS driver for the Pi which sets up HDMI using the DispmanX API into the Broadcom proprietary OS that runs alongside Linux on the Raspberry Pi. This is nice because it's dead simple for Linux (Linux quite literally gets to say "yo, gimme a 1920x1080 layer!") but bad because it relies on a proprietary blob and the blob can't be extended.
Native KMS, on the other hand, sets up HDMI using native device access to the actual registers which affect the HDMI encoder, DSI link, and so on. This is more extensible and isn't closed source, but it's also mega complicated.
Now, here's the kicker on your Pi. Other commenters are correct that normally, KMS should just affect mode setting, not rendering. But, on the Pi, this isn't true. KMS and FKMS _also_ affect the way _layers_ are configured in the DRM (Direct Render Manager) subsystem.
Why? DispmanX isn't just a mode setter, it's also a scaling and compositing (layering) engine!
So, in the course of bypassing DispmanX, the DRM system in KMS mode now needs to act differently - it needs to configure 2D compositing planes through the KMS system instead of through DispmanX.
What's on a separate 2D compositing layer?
The legacy cursor.
Here's the switch where RealKMS is responsible for setting up the cursor compositing layers, a task which in FakeKMS was already handled by DispmanX:
https://github.com/raspberrypi/linux/blob/aeaa2460db088fb2c9...
https://github.com/raspberrypi/linux/blob/1fe617a917eac75800...
Now, _why_ this makes your cursor lag, I don't know, but that's the difference.
OK, so first off, FKMS vs KMS.
KMS is Kernel Mode Setting. This is the kernel's framework for setting video modes, abstracting over HDMI/DSI initialization, timing parameters, etc. etc. across platforms.
FKMS is still KMS, but it's a special KMS driver for the Pi which sets up HDMI using the DispmanX API into the Broadcom proprietary OS that runs alongside Linux on the Raspberry Pi. This is nice because it's dead simple for Linux (Linux quite literally gets to say "yo, gimme a 1920x1080 layer!") but bad because it relies on a proprietary blob and the blob can't be extended.
Native KMS, on the other hand, sets up HDMI using native device access to the actual registers which affect the HDMI encoder, DSI link, and so on. This is more extensible and isn't closed source, but it's also mega complicated.
Now, here's the kicker on your Pi. Other commenters are correct that normally, KMS should just affect mode setting, not rendering. But, on the Pi, this isn't true. KMS and FKMS _also_ affect the way _layers_ are configured in the DRM (Direct Render Manager) subsystem.
Why? DispmanX isn't just a mode setter, it's also a scaling and compositing (layering) engine!
So, in the course of bypassing DispmanX, the DRM system in KMS mode now needs to act differently - it needs to configure 2D compositing planes through the KMS system instead of through DispmanX.
What's on a separate 2D compositing layer?
The legacy cursor.
Here's the switch where RealKMS is responsible for setting up the cursor compositing layers, a task which in FakeKMS was already handled by DispmanX:
https://github.com/raspberrypi/linux/blob/aeaa2460db088fb2c9...
https://github.com/raspberrypi/linux/blob/1fe617a917eac75800...
Now, _why_ this makes your cursor lag, I don't know, but that's the difference.
> Other commenters are correct that normally, KMS should just affect mode setting, not rendering.
Clearly those commenters don't have much experience working close to the wire around GPUs then. Scanout used to be very closely tied to rendering, and in some ways it still is. You can't take an arbitrary texture in GPU memory and scan it out to the display.
Windows has this thing called VidPN to work around the dependencies between source and target modes which gets even more complicated with VRR and virtual resolutions (retina).
https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
Clearly those commenters don't have much experience working close to the wire around GPUs then. Scanout used to be very closely tied to rendering, and in some ways it still is. You can't take an arbitrary texture in GPU memory and scan it out to the display.
Windows has this thing called VidPN to work around the dependencies between source and target modes which gets even more complicated with VRR and virtual resolutions (retina).
https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
Hardware composer is the Android version of this: https://source.android.com/devices/graphics/implement-hwc
This has become a lot more important with smartphones than desktop systems. You now have often very different silicon for things like video decoding, graphics and scanout - and to achieve reasonable battery time you need common use cases like watching a video to not involve the GPU at all.
This has become a lot more important with smartphones than desktop systems. You now have often very different silicon for things like video decoding, graphics and scanout - and to achieve reasonable battery time you need common use cases like watching a video to not involve the GPU at all.
Dedicated video decoding silicon is not part of the GPU?
Video decoders are usually fixed function blocks, separate from the SMs (which I believe the parent is referring to by "GPU") but are still usually on the same physical silicon as the GPU (in case of SoCs, also shared with CPU).
They're exposed as an independent engine on the GPU/SoC and can operate with most of the chip power gated.
They're exposed as an independent engine on the GPU/SoC and can operate with most of the chip power gated.
You're toying with forces that even the most learned KMS scholars haven't fully investigated. Remember: the kernel, and by extension KMS, evolved to it's current state through the collective intellect of many humans. No one knows what's in there, and those who get close are driven mad, like a modern-day kabbalah. It's best not to think too much about it, but you should be safe trying random incantations you find in books of arcana and witchcraft.
I'm almost afraid to try to peruse code at this point. I fear I'll be on the verge of understanding some relationship between this castle full of abstractions to my video stuttering, then find some wizard in a corner who will tell me that's old and the real codebase is in another castle.
If you don't want to experience this type of nonsense, use hardware from vendors that make good-faith efforts to fully support their hardware in mainline kernels, like Intel or AMD's hardware. Just treat graphics and acceleration on the RPi as a neat trick.
You can pick up SBC-like computers with Intel integrated graphics and not have to deal with these problems from vendors' unsupported hardware, and there are some with AMD APUs. There are also SBCs that have PCIe slots that you can stick your own graphics cards into, but I'd stick with x86 machines because embedded ARM devices almost always require forked kernels that might not support everything you'd want them to, including your otherwise-supported graphics cards.
Some Mali graphics chips also work pretty well with Panfrost/Lima.
You can pick up SBC-like computers with Intel integrated graphics and not have to deal with these problems from vendors' unsupported hardware, and there are some with AMD APUs. There are also SBCs that have PCIe slots that you can stick your own graphics cards into, but I'd stick with x86 machines because embedded ARM devices almost always require forked kernels that might not support everything you'd want them to, including your otherwise-supported graphics cards.
Some Mali graphics chips also work pretty well with Panfrost/Lima.
Do you have any experience with Pine64's creations and whether they involve this fuckey?
I don't, unfortunately. It looks like their products use Mali 400 MP2 GPUs, which seems to have support via Lima. I had several boards with Mali-T628's, and while they work, I ran into headaches a lot a 6+ years ago, like issues with GPU accelerated video, browsing in Chromium and desktop compositing. I've heard from developers that work on those boards that the GPU support is much better than it was a half decade ago, though.
Personally, I won't be buying more ARM SoCs unless they start supporting SBSA and have mainline kernel support for all of their peripherals. As it stands, the only hardware that I'm aware of that has full mainline support for everything, including GPUs, are boards with Intel iGPUs or AMD APUs.
Personally, I won't be buying more ARM SoCs unless they start supporting SBSA and have mainline kernel support for all of their peripherals. As it stands, the only hardware that I'm aware of that has full mainline support for everything, including GPUs, are boards with Intel iGPUs or AMD APUs.
KMS only means Kernel Mode Setting, it's a way for the kernel to handle display resolutions so it can set the proper resolution for a display during bootup and enables instant TTY switching.
DRM is the direct rendering manager, it's mainly an interface for applications like X11 to talk to the GPU directly (ie 3D Acceleration and Video Decoding).
If KMS is causing things to be slow, it might be because the video driver is not working and the software framebuffer is being used. At higher resolutions that'll be slow.
If Chrome doesn't have the option to enable DRDC then the driver used likely doesn't support DRM or the window manager is not passing it properly.
DRM is the direct rendering manager, it's mainly an interface for applications like X11 to talk to the GPU directly (ie 3D Acceleration and Video Decoding).
If KMS is causing things to be slow, it might be because the video driver is not working and the software framebuffer is being used. At higher resolutions that'll be slow.
If Chrome doesn't have the option to enable DRDC then the driver used likely doesn't support DRM or the window manager is not passing it properly.
> If KMS is causing things to be slow, it might be because the video driver is not working and the software framebuffer is being used. At higher resolutions that'll be slow.
But then how could using a software framebuffer on an underpowered thing like the RPI400 cause the video to play smoothly?
But then how could using a software framebuffer on an underpowered thing like the RPI400 cause the video to play smoothly?
DrDc is unrelated to the issue here. As another commenter guessed, it's just an optimization to Chromium's graphics pipeline. Chrome has a number of processes that need to execute GPU work. For example, there's the renderer process which actually draws the page content into tiles (we refer to this as "rasterization"). There's at least one renderer process per page because of Site Isolation, but there can be more like in the case of iframes. There's also the Viz process that (among other things) handles the composition of all of the tiles generated by the renderers into the final framebuffer (this is known as the Display Compositor). Each of these processes funnels their GL calls into a separate thread called the GPU main thread which as part of Chromium's security model, is the only thread privileged to interact with the actual system graphics drivers.
The insight behind DrDc is that display compositing is higher priority than rasterization, so having both share work on the GPU main thread is bad for performance. DrDc is a large effort, but at the risk of oversimplifying, it's main purpose is to create a new GPU thread that the display compositor can use exclusively. DrDc is still rolling out on most platforms which may explain why it's disabled on your device, but regardless, it should not help with the video playback issues you're seeing.
The insight behind DrDc is that display compositing is higher priority than rasterization, so having both share work on the GPU main thread is bad for performance. DrDc is a large effort, but at the risk of oversimplifying, it's main purpose is to create a new GPU thread that the display compositor can use exclusively. DrDc is still rolling out on most platforms which may explain why it's disabled on your device, but regardless, it should not help with the video playback issues you're seeing.
I'm a little surprised people expect Chromium to run decently on the Raspberry Pi.
I was surprised, too. But it did work on Raspbian buster minus one.
Then I upgraded to Raspbian buster to get a more recent version of Chromium since HBO Max was blocking me based on whatever version shipped with (buster minus one).
At that point I started shooting various startup flags at Chromium from the web of wizards' incantations until video started to play again. That including removing the 'f' per the incantation I mentioned. This cured video playback health but it put my mouse under some kind of latency spell.
I think I could beat this level with a drowsy mouse if only I could find increased magic for the subtitles somewhere.
Does anyone know if there is a Chromium arg I can use to just farm some magic?
Then I upgraded to Raspbian buster to get a more recent version of Chromium since HBO Max was blocking me based on whatever version shipped with (buster minus one).
At that point I started shooting various startup flags at Chromium from the web of wizards' incantations until video started to play again. That including removing the 'f' per the incantation I mentioned. This cured video playback health but it put my mouse under some kind of latency spell.
I think I could beat this level with a drowsy mouse if only I could find increased magic for the subtitles somewhere.
Does anyone know if there is a Chromium arg I can use to just farm some magic?
Laggy mouse is the surprising part I think. It used to be that you could count on the mouse still moving smoothly even when the rest of the system was falling to pieces. I understand this was because the mouse was a hardware-rendered sprite controlled by hardware interrupts. I don't claim to understand the details, but my impression is things have changed a lot.
The mouse lags. Sometimes it even turns on an invisibility cloak which I didn't even know was possible.
I need to see if there are any RPI400 Chromium Video Acceleration Challenge players streaming on Twitch, maybe they'd have some clues. There are bound to be a bunch of useful weapons to beat this level but I don't know how to unlock them.
I need to see if there are any RPI400 Chromium Video Acceleration Challenge players streaming on Twitch, maybe they'd have some clues. There are bound to be a bunch of useful weapons to beat this level but I don't know how to unlock them.
Like someone else mentioned it's probably because the video is in some kind of pure framebuffer mode.
DRM = Direct Rendering Manager
This is important, thanks. I "understood" (mis) the post thinking that somehow, Fedora would now only use Digital Rights Managed displays (with a hack to make all non-DRM displays into one)...
:~/
:~/
To be fair Digital Rights Management displays are a real thing:
https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...
https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...
Of course, that is why I was confused. Also the title of the post is either confusing or a kind of play on words.
especially with the dystopian "brave new world" reference
Definitely. Brave New World immediately sent my mind to think "Digital Rights Management" and "Key Management Server" had come to Fedora in a new dystopian way.
Those familiar with Windows will certainly think of "DRM/KMS" in that way since that's what those acronyms mean there.
You would think they would be more aware of very commonly used acronyms, especially those with a negative connotation.
Direct Rendering Manager has been a part of the kernel since 1999, before the 2.4 release. At that time the term Digital Rights Management as a catch-all for CSS, dongles, etc wasn't widespread.
To keep with the theme of the thread: CSS = Content Scramble System, nothing to do with cascading style sheets.
'KMS' (kernel mode setting) probably disambiguates 'DRM' for most of those who are familiar with desktop Linux.
I read it as “key management system” i.e. TPM, and was confused too.
DRM has been used by Direct Rendering Manager for 15 years or so, so it's itself a commonly used acronym.
I don't doubt it, but it was still a little frustrating -- as far as I can tell, DRM is never defined in the documentation on kernel.org. (I just doublechecked that by searching for "direct rendering" and nothing like "DRM (Direct Rendering Manager)" comes up.) I could tell from context that this didn't mean "digital rights management," but as someone who is not a GPU developer, I didn't have the context to figure it out.
So, I really think they should take a few extra words and put this in either the introduction to the GPU Driver Developer's Guide or the first page in the section entitled "DRM Internals". They do that for KMS!
So, I really think they should take a few extra words and put this in either the introduction to the GPU Driver Developer's Guide or the first page in the section entitled "DRM Internals". They do that for KMS!
There used to be some documentation that explicitly mentioned it by name, but it has since been removed: https://archive.ph/20140226185421/https://git.kernel.org/cgi...
No. If you are not in-the-know of linux trivia, this will be highly arcane to you.
It's not linux trivia - it's information anyone trying to get graphics drivers to work or looking for updates on linux might have come across.
Digital Rights Management (DRM) is what sprang to my mind.
Me too, and KMS is key management system or software. But I'm more in the devops side of the industry.
I was definitely trying to connect this in my brain with some weird logic after just skimming the article.
Fedora is a bleeding edge distro, I thibk it's okay to disable legacy stuff there.
As a Fedora user, I find it more polished than Ubuntu, Debian, and Mint (the other distros I've used). Newcomers shouldn't be dissuaded by this "bleeding edge" description.
Wow, I always found Fedora to be awful - it used to be the selinux crashes on a vanilla install on first login and the disgusting font rendering, and now it's the unusable default gnome interface (so bad Red Hat made a shitty gnome 2 clone for enterprize customers).
I guess on some level we just prefer what we're used to.
But I seriously wonder about people who run Fedora desktops though. I installed Fedora 36 two days ago to try it again, and it's unusable. The scaling options are 100%, 200%, 300%, and 400%. I have a 43" 4k screen, so around 120dpi. 100% is too small, 200% is way too big. And gnome settings doesn't even have font size options. What the fuck.
I guess on some level we just prefer what we're used to.
But I seriously wonder about people who run Fedora desktops though. I installed Fedora 36 two days ago to try it again, and it's unusable. The scaling options are 100%, 200%, 300%, and 400%. I have a 43" 4k screen, so around 120dpi. 100% is too small, 200% is way too big. And gnome settings doesn't even have font size options. What the fuck.
That's fair. More scaling options would be nice. I've never had Fedora crash, but I buy hardware with Linux compatibility in mind. It even worked well with a weird Thunderbolt 3 external display setup I have, the same setup makes macOS crash consistently if I connect it under certain conditions.
Fractional scaling is a thing. It is also per-monitor. Just have to enable it via gsettings.
Now that most applications are supporting Wayland this is less of an issue than it used to be.
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
Now that most applications are supporting Wayland this is less of an issue than it used to be.
X11 handles font scaling just fine. It has since the 1990's.
It's not suprising if some level of indirection on top of it broke it in some environments though. Perhaps it has something to do with gnome 3? It works with gnome 2, kde, and all the minimalist window managers I've tried.
None of those try to "scale framebuffer" though, whatever that means. If it means what it sounds like, whoever implemented it is incompetent.
It's not suprising if some level of indirection on top of it broke it in some environments though. Perhaps it has something to do with gnome 3? It works with gnome 2, kde, and all the minimalist window managers I've tried.
None of those try to "scale framebuffer" though, whatever that means. If it means what it sounds like, whoever implemented it is incompetent.
[deleted]
per display scaling? Mixed DPI works pretty well with wayland.
Yeah, the default scaling options are unacceptable. I was able to work around it by installing GNOME Tweaks (absolutely bonkers that this isn't installed by default) and changing the font scaling factor, but until I did that my 4k monitor was really hard to use.
The font size setting is hidden under the "GNOME Tweak Tool". The good news is that over the last couple releases, the GNOME settings have improved bit by bit and now also include some things that also used to be hidden in the Tweak Tool.
Fedora 36 is still in beta. Wayland fractional scaling is an experimental feature. Have you tried the "large text" option in Settings -> Accessibility?
Some of us just run KDE instead. Fractional scaling has been here for quite a while.
The trick is to use KDE
> But I seriously wonder about people who run Fedora desktops though.
And I wonder about people who can't figure this part out.
> and now it's the unusable default gnome interface (so bad Red Hat made a shitty gnome 2 clone for enterprize customers).
Kinda odd how it's the most popular Linux desktop and you are the one that can't figure it out and also the one calling it shit and unusable.
Seems more like a personal problem than a Gnome problem.
And I wonder about people who can't figure this part out.
> and now it's the unusable default gnome interface (so bad Red Hat made a shitty gnome 2 clone for enterprize customers).
Kinda odd how it's the most popular Linux desktop and you are the one that can't figure it out and also the one calling it shit and unusable.
Seems more like a personal problem than a Gnome problem.
Fedora switched to Wayland a release of two ago, which produces frequent errors on surprisingly many hardware configs (none of my Intel or Nvidia (i)gpu machines are stable under it). Means I had to switch away. Opensuse has become my new refuge, which has packages generally as current as Fedora, but a Q&A process that prevents things like Wayland from becoming the default prematurely.
I just don't want to upgrade every 6 months is all. I stick to popos/ubuntu LTS for daily drivers and arch when I want to be cutting edge. Fedora is in some strange middle ground to me.
I used to burden myself by reinstalling the OS with every new update, because I wanted a clean OS I reasoned. Eventually I stopped worrying and it hasn't been a problem. I'm still open to doing a fresh install if something goes wrong. I still back up my data knowing that the OS or the hardware can die any time.
To update to the latest Fedora versions I run a shell command and 30 minutes later I have the new version and I can hardly tell the difference.
To update to the latest Fedora versions I run a shell command and 30 minutes later I have the new version and I can hardly tell the difference.
I've been waiting for mine to break after my last fresh install on Fedora 27 (when i got an SSD for the first time). I'm on Fedora 36 now and it's been fine. I've been waiting for a new computer to do the next fresh install.
I think Fedora release is officially supported for 13 months, which allows one to upgrade every other release, or be a release behind at all times, if desired.
They seem to do go a good job updating major components for latest-1 release: kernel, Firefox, etc.
However, I noticed that say Chromium updates are not as fast or at latest version. So using Fedora that way might not be best choice.
They seem to do go a good job updating major components for latest-1 release: kernel, Firefox, etc.
However, I noticed that say Chromium updates are not as fast or at latest version. So using Fedora that way might not be best choice.
What I found working (although I haven't been using fedora for quite a few years now) is to skip a release if possible. Only when it seemed the N+2 is still too broken I upgraded to N+1.
A lot of people live a release behind latest going by:
https://retrace.fedoraproject.org/faf/summary/
https://retrace.fedoraproject.org/faf/summary/
i agree - I have been using it for years and found it much better than Ubuntu in general
[deleted]
THIS !! I recently switched from Ubuntu to Fedora workstation 35. It's been a month now and don't think I'm going to back to Ubuntu.
TL;DR Most things are just "a little nicer" and a "little more sane" I found.
EDIT: I also run i3 so I'm not part of the gnome(n..m) "problems" etc. Can really recommend it !
TL;DR Most things are just "a little nicer" and a "little more sane" I found.
EDIT: I also run i3 so I'm not part of the gnome(n..m) "problems" etc. Can really recommend it !
"Leading-edge" would be more exact description of Fedora. They are somewhere in between bleeding-edge distributions and stable distributions (like Debian).
This actually highlights a great, albeit belated, piece of work. In the end, this cleans up some legacy code and it helps to unify the framebuffer display across vendors AND (some) architectures.
Cutting through the linux kernel jargon, this is just deprecating one API for writing to the framebuffer (/dev/fb0 etc), since there is another way: using the standardized KMS API.
We, that is Proxmox VE (Linux based clustering & hyper-visor distro) and our other projects, had to roll back that exact change due to issues on some test HW a few months back, but it has to be said that we're on the 5.15 LTS while Fedora will use 5.17, so it may just be that there are a few fixes/improvements missing.
For us, it wasn't worth the deeper investigation, so we went to just ensure simplefb (same spirit w.r.t. taking over the firmware frame buffer, but no DRM) is activated for now.
Albeit, on one machine we could also get simpledrm to work after a BIOS update, so I'm definitively interested in how that plays out with Fedora.
In any way, it's definitively a welcomed change, so if it plays out well for them, I'll try to switch again with our next Kernel jump.
For us, it wasn't worth the deeper investigation, so we went to just ensure simplefb (same spirit w.r.t. taking over the firmware frame buffer, but no DRM) is activated for now.
Albeit, on one machine we could also get simpledrm to work after a BIOS update, so I'm definitively interested in how that plays out with Fedora.
In any way, it's definitively a welcomed change, so if it plays out well for them, I'll try to switch again with our next Kernel jump.
How will this change affect the users of Fedora?
There are some relatively ancient graphics cards supported by fbdev with no KMS driver. They may need to use the simple framebuffer-only support (simpledrm). I believe almost no users will be affected by this.
simpledrm expects somewhat sane framebuffer memory layout which many of the ancient cards cannot provide so even that probably is not a solution. But the problem is non-existent because in PC context these cards are ISA cards made well before 1995.
Most have been using DRM/KMS for years now, so there won't be any noticeable change for them.
It won't.
This sounds fine on paper, but I’d be nervous completely removing fb. Many times I’ve had to fall back to that when my nvidia drivers weren’t updated by dkms. Not having fb loaded and no nvidia-drm kernel module for the new kernel typically either hangs the system or you get a black screen and have to SSH in to fix it
I would hope the simpledrm can do this too. It certainly ought to work, especially on UEFI systems.
I guess I realized, on my gentoo machine, it had been years since I had to care about which fb option i set in the kernel, drm/kms only always worked.
Does this mean less display flickering during Linux boot while the system tries to figure out what mode to use?
That was solved a few years ago: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-3...
Well yeah, that's KMS. The flickering was when Xorg and fbdev did separate modesetting, so every time you switched from terminal to Xorg and back, one had to reset the screens into the default mode and the other had to then set the desired mode.
I was super confused and worried by DRM here, which I guess goes to show how long it’s been since getting video working on linux required futzing with manual kernel builds :D
I actually had some hope that this would be a fix for the low resolutions for DRM in firefox, et al.
No idea what is causing any of these video issues, but the ASCII goat by the OP is a nice gesture. Hail the gods for they are benevolent and wise!
What prevents Linux kernel featured terminal (tty) from supporting true color and other fancy terminal features?
Nothing, things like this have existed for a while:
https://www.freedesktop.org/wiki/Software/kmscon/
https://wiki.archlinux.org/title/KMSCON
https://www.freedesktop.org/wiki/Software/kmscon/
https://wiki.archlinux.org/title/KMSCON
Hmm:
> Development of Kmscon stopped in March 2015. There was a successor project called systemd-consoled, but this project was also later dropped in July 2015.
That doesn't sound very promising. Why can't kernel itself ship a more advanced terminal?
> Development of Kmscon stopped in March 2015. There was a successor project called systemd-consoled, but this project was also later dropped in July 2015.
That doesn't sound very promising. Why can't kernel itself ship a more advanced terminal?
>Why can't kernel itself ship a more advanced terminal?
Probably because nobody wants to put opentype font rendering and input method support and various other things from a window system into the kernel? This stuff all has to be in userspace so you're better off just running a minimal X or Wayland server at that point.
Probably because nobody wants to put opentype font rendering and input method support and various other things from a window system into the kernel? This stuff all has to be in userspace so you're better off just running a minimal X or Wayland server at that point.
Wider color support hardly requires having complex font rendering features.
OpenSUSE liveCD from circa 2010 had a full size art background behind the console. Their art was green vertical stripes logo on bottom corner. So, only your distro willingness to configure it is the factor here.
A complete side tangent: How does one prevent pingbacks from content-less "blogs" (which seem to be optimizing for clicks)? (I see 3 pingbacks from lzomedia.com, makemoneyonlinecom.com and imoneyhub.com at the above link)
That would be up to the blog operator, I'd expect. I've never seen any value to even legitimate pingbacks, so if I used a blog that had them, I'd disable them altogether.
Use umatrix in whitelist mode. By default, I only load first party html, images, and CSS.
Isn't umatrix deprecated?
Unfortunately, yes. But it still works and rocks.
uBlock Origin has kind-of-similar (but not quite) functionality where you can block by domains, but it is not as granular (it is called "Advanced" something IIRC).
uBlock Origin has kind-of-similar (but not quite) functionality where you can block by domains, but it is not as granular (it is called "Advanced" something IIRC).
It is equally granular. https://news.ycombinator.com/item?id=26284124
Yeah, the only similar replacement I know of is noscript. For me ublock origin + cookie autodelete + firefox strict mode is the 90% fix for now. Mostly set and forget without the maintenance of umatric and noscript. Tho, I am kind of surprised no one has forked umatrix and continued developing it
Still works.
[deleted]
Fortunately we moved off Fedora some time ago, for exactly this sort of reason - when you're working with industrial stuff where minimum timescale is a decade and reliability is a must, low-tech FB interfaces are de rigeur.
Once upon a time, breaking userspace was a no-no [0].
[0] https://lkml.org/lkml/2012/12/23/75
Once upon a time, breaking userspace was a no-no [0].
[0] https://lkml.org/lkml/2012/12/23/75
This is a weird comment. Fedora is absolutely not intended for "industrial stuff where minimum timescale is a decade and reliability is a must" and if you were using it for that and had issues, it's kind of your own fault. This reads like a criticism of Fedora when it's not really deserved.
I don't think Linus would agree that "don't break userspace" applies to distributions choosing how to configure the Linux kernel. That's why the configuration options exist in the first place.
Why were you using a distro with a 9 month lifespan for 10+ year deployments?
I think Fedora is supported for ~13 month [0]. At least I have no issues updating every other release once a year.
[0] https://docs.fedoraproject.org/en-US/releases/
[0] https://docs.fedoraproject.org/en-US/releases/
I stand corrected, but the question doesn't change.
You're posting that email way, way out of context. I cringe whenever I see that linked. "Userspace" here refers to the kernel's policy about certain APIs. They won't change fbdev at this point but downstreams could always compile it out. It's also an extremely unprofessional email and Linus should have never sent it.
You can still use DRM/KMS to drive "low-tech FB interfaces" and it's actually better because you don't have to deal with the weirdness of the fbdev ioctls.
You can still use DRM/KMS to drive "low-tech FB interfaces" and it's actually better because you don't have to deal with the weirdness of the fbdev ioctls.
If so:
Dear video gods,
A fickle wizard told me I could fix studdering Chromium playback on HBO Max for my RPI400 by reciting the following incantation:
"remove the letter f from the line `dtoverlay=vc4-fkms-v3d`"
I did as instructed. But now the wizard's spell has caused my mouse pointer to become drowsy-- it lags when I drag it in the Chromium window.
Please help me!
Also, if you could explain to a mere mortal what the hell that setting is, I would be grateful.
Also if you could explain why the "Direct Rendering Display Compositor" for Chromium is inescapably Disabled no matter what flags I set, I'd be grateful. It seems like that affects the efficiency of subtitle display, but I'm just guessing here. (Using Raspbian Buster on the Rpi400.)
In your honor I offer this ASCII goat: