[HN Gopher] Fedora 36: A brave new (DRM/KMS only) world
___________________________________________________________________
Fedora 36: A brave new (DRM/KMS only) world
Author : fcambus
Score : 176 points
Date : 2022-04-24 16:25 UTC (6 hours ago)
(HTM) web link (blog.dowhile0.org)
(TXT) w3m dump (blog.dowhile0.org)
| noobermin wrote:
| 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.
| zh3 wrote:
| 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
| djur wrote:
| 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.
| deadbunny wrote:
| Why were you using a distro with a 9 month lifespan for 10+
| year deployments?
| hypothesis wrote:
| 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/
| deadbunny wrote:
| I stand corrected, but the question doesn't change.
| olliej wrote:
| 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
| stjohnswarts wrote:
| I actually had some hope that this would be a fix for the low
| resolutions for DRM in firefox, et al.
| skozharinov wrote:
| Fedora is a bleeding edge distro, I thibk it's okay to disable
| legacy stuff there.
| butz wrote:
| "Leading-edge" would be more exact description of Fedora. They
| are somewhere in between bleeding-edge distributions and stable
| distributions (like Debian).
| Buttons840 wrote:
| 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.
| bproven wrote:
| i agree - I have been using it for years and found it much
| better than Ubuntu in general
| stjohnswarts wrote:
| 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.
| rplnt wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| A lot of people live a release behind latest going by:
|
| https://retrace.fedoraproject.org/faf/summary/
| hypothesis wrote:
| 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.
| Buttons840 wrote:
| 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.
| johnny22 wrote:
| 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.
| okasaki wrote:
| 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.
| ufo wrote:
| 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.
| ripley12 wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| Fedora 36 is still in beta. Wayland fractional scaling is
| an experimental feature. Have you tried the "large text"
| option in Settings -> Accessibility?
| viraptor wrote:
| Some of us just run KDE instead. Fractional scaling has
| been here for quite a while.
| Buttons840 wrote:
| 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.
| lazyier wrote:
| Fractional scaling is a thing. It is also per-monitor.
| Just have to enable it via gsettings.
| gsettings set org.gnome.mutter experimental-features
| "['scale-monitor-framebuffer']"
|
| The problem with it is that X11 doesn't handle the
| scaling well. Tend to get blurry fonts with X apps.
|
| Now that most applications are supporting Wayland this is
| less of an issue than it used to be.
| lazyier wrote:
| > 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.
| akoster wrote:
| 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)
| [deleted]
| throwaway81523 wrote:
| 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.
| robonerd wrote:
| Use umatrix in whitelist mode. By default, I only load first
| party html, images, and CSS.
| TheChaplain wrote:
| Isn't umatrix deprecated?
| robonerd wrote:
| Still works.
| stjohnswarts wrote:
| 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
| amenod wrote:
| 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).
| Arnavion wrote:
| It is equally granular.
| https://news.ycombinator.com/item?id=26284124
| cabirum wrote:
| DRM = Direct Rendering Manager
| stjohnswarts wrote:
| I was definitely trying to connect this in my brain with some
| weird logic after just skimming the article.
| allenbina wrote:
| You would think they would be more aware of very commonly used
| acronyms, especially those with a negative connotation.
| kzrdude wrote:
| DRM has been used by Direct Rendering Manager for 15 years or
| so, so it's itself a commonly used acronym.
| arka2147483647 wrote:
| No. If you are not in-the-know of linux trivia, this will
| be highly arcane to you.
| gm3dmo wrote:
| Digital Rights Management (DRM) is what sprang to my mind.
| notreallyserio wrote:
| Me too, and KMS is key management system or software. But
| I'm more in the devops side of the industry.
| chipotle_coyote wrote:
| 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!
| btdmaster wrote:
| There used to be some documentation that explicitly
| mentioned it by name, but it has since been removed: http
| s://archive.ph/20140226185421/https://git.kernel.org/cgi.
| ..
| robonerd wrote:
| 'KMS' (kernel mode setting) probably disambiguates 'DRM' for
| most of those who are familiar with desktop Linux.
| thenewwazoo wrote:
| I read it as "key management system" i.e. TPM, and was
| confused too.
| robonerd wrote:
| Heh, well I guess with only 26^3 TLAs to choose from,
| collisions are unavoidable.
| iso1210 wrote:
| That's why the world invented ETLAs and VELTAs
| amaranth wrote:
| 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.
| tremon wrote:
| To keep with the theme of the thread: CSS = Content
| Scramble System, nothing to do with cascading style sheets.
| pfortuny wrote:
| 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)...
|
| :~/
| em-bee wrote:
| especially with the dystopian "brave new world" reference
| ucm_edge wrote:
| 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.
| userbinator wrote:
| Those familiar with Windows will certainly think of
| "DRM/KMS" in that way since that's what those acronyms
| mean there.
| DoctorOW wrote:
| To be fair Digital Rights Management displays are a real
| thing:
|
| https://en.wikipedia.org/wiki/High-
| bandwidth_Digital_Content...
| pfortuny wrote:
| Of course, that is why I was confused. Also the title of
| the post is either confusing or a kind of play on words.
| ILMostro7 wrote:
| 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.
| shmerl wrote:
| What prevents Linux kernel featured terminal (tty) from
| supporting true color and other fancy terminal features?
| throwaway82652 wrote:
| Nothing, things like this have existed for a while:
|
| https://www.freedesktop.org/wiki/Software/kmscon/
|
| https://wiki.archlinux.org/title/KMSCON
| AreYouSirius wrote:
| fmakunbound wrote:
| Does this mean less display flickering during Linux boot while
| the system tries to figure out what mode to use?
| wmf wrote:
| That was solved a few years ago:
| https://www.phoronix.com/scan.php?page=news_item&px=Fedora-3...
| jancsika wrote:
| Is KMS the KMS from "dtoverlay=vc4-kms-v3d" in the rpi400's
| boot/config.txt?
|
| 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: (_(
| /_/'_____/) " | | |""""""|
| zaarn wrote:
| 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.
| jancsika wrote:
| > 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?
| snvzz wrote:
| >an underpowered thing
|
| I would not call Raspberry Pi 400 underpowered.
|
| The Cortex-A72 cores are fairly fast.
| bri3d wrote:
| 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.
| zeusk wrote:
| > 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...
| brkho wrote:
| 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.
| heavyset_go wrote:
| 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.
| PragmaticPulp wrote:
| 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.
| [deleted]
| Syonyk wrote:
| > _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.
| derefr wrote:
| 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"
| cagey wrote:
| > 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?
| Syonyk wrote:
| 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.
| jancsika wrote:
| 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.
| AreYouSirius wrote:
| usrn wrote:
| I'm a little surprised people expect Chromium to run decently
| on the Raspberry Pi.
| jancsika wrote:
| 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?
| robonerd wrote:
| 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.
| usrn wrote:
| Like someone else mentioned it's probably because the video
| is in some kind of pure framebuffer mode.
| jancsika wrote:
| 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.
| jeroenhd wrote:
| 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.
| jancsika wrote:
| > 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.
| stefan_ wrote:
| 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.
| phendrenad2 wrote:
| 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.
| jancsika wrote:
| 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.
| wubbert wrote:
| How will this change affect the users of Fedora?
| wmf wrote:
| It won't.
| robonerd wrote:
| Most have been using DRM/KMS for years now, so there won't be
| any noticeable change for them.
| rwmj wrote:
| 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.
| dfox wrote:
| 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.
| mise_en_place wrote:
| 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
| amluto wrote:
| I would hope the simpledrm can do this too. It certainly ought
| to work, especially on UEFI systems.
___________________________________________________________________
(page generated 2022-04-24 23:00 UTC)