Announcement

Collapse
No announcement yet.

Linux Patch Sparks Differing Views Over External Monitor Handling With iGPU vs. dGPU

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by user1 View Post

    There are some reports that it breaks not just Nvidia.
    Btw, at the end, these kind of devs are usually proven wrong after they go into their initial denial mode, so I wouldn't be surprised if that's the case here as well.
    That's an internal API of the kernel, it does not have any stability guarantee, so the kernel devs can change these APIs as they want.
    Third party modules that are not mainlined need to fix their own code themselves, the kernel devs are only responsible for what is already mainlined.

    Comment


    • #12
      Originally posted by user1 View Post

      That "we are volunteers, therefore we have the right to break your stuff" argument really makes my blood boil. I recently heard the same argument about future GTK versions and GTK 4 text rendering from Gnome devs. As a user of your software, I don't give an f. I want everything to work properly and I don't care what it takes to fix something.
      What?

      It is an internal API of linux, it does not have any stability guarantee.
      This is how software development works - Linux guarantees that syscall API/ABI is always stable because it is the public interface and the internal APIs can change at will.

      This has nothing to do with the "volunteers" mindset, it's simply that fixing an out-of-tree driver is beyond the scope of the Linux project.

      Comment


      • #13
        Originally posted by NobodyXu View Post

        That's an internal API of the kernel, it does not have any stability guarantee, so the kernel devs can change these APIs as they want.
        Third party modules that are not mainlined need to fix their own code themselves, the kernel devs are only responsible for what is already mainlined.
        But there is a chance it affects AMD as well, which is not a third party module.
        I think devs in general should at the very least notify that they're about to introduce a change that may potentially break stuff, like in the case of glibc update breaking EAC and other software, including free software.
        Last edited by user1; 17 August 2022, 07:44 AM.

        Comment


        • #14
          Originally posted by reba View Post
          On the Lenovo here the external connectors are also routed through the Nvidia dGPU - so if you want to connect a monitor to expand your workspaces you'll have to switch the dGPU on, which is a kind of shame as it burns power just by being on and for nearly no usage, even when the DE runs on the Zen's iGPU.
          In my case (Asus Zephyrus G14 2021), using the USB-C port for display output is tied to the dGPU while the HDMI port is tied to the iGPU. When I connect a USB-C dock while the dGPU is off, the Asus software just displays this message:
          image.png

          Even the weak Vega iGPU is fine for all non-gaming scenarios. Unless one decides on a performance mode for gaming or so, iGPU is fine.
          Typical Canonical incompetence.

          Comment


          • #15
            Originally posted by user1 View Post

            But there is a chance it affects AMD as well, which is not a third party module.
            I think devs in general should at the very least notify that they're about to introduce a change that may potentially break stuff, like in the case of glibc update breaking EAC and other software.
            If that commit breaks any mainlined driver, then the devs who wrote that patches need to fix it before it can be merged into upstream or other devs will fix it if it is found to be faulty after the commit/patch is merged into mainline.

            And no, in glibc case, they have switched to DT_HASH + DT_GNU_HASH decades ago, and only made that switch to disable DT_HASH decades later.
            The DT_HASH part is an implementation detail, not an API/ABI, and that changes have been introduced decades ago so that softwares who use this implementation details can migrate to DT_GNU_HASH.
            A decade has passed and now they removed DT_HASH, I don't think they are at fault there.

            Just tell the EAC devs to fix their anti-cheat softwares, these anti-cheat softwares are fragile anyway because they use that exotic tricks to detect cheating that are fragile because they don't follow the usual software dev practice and try to depend on some subtle parts of the system, like DT_HASH, an implementation of ELF itself that are only relevant to the dynamic linker (which is also implemented by glibc).
            Last edited by NobodyXu; 17 August 2022, 07:49 AM.

            Comment


            • #16
              Originally posted by NobodyXu View Post
              This has nothing to do with the "volunteers" mindset.
              Well, that's what that dev said, not me.

              Also, when I constantly see things breaking on the Linux desktop, both in user and kernel space, and then look at Windows and realize this stuff just doesn't happen on WIndows, I see it as a weak point of Linux. Idk, maybe I'm too much of a perfectionist and I see flaws that other people don't see, but at the very least, like I said, can devs at least notify they're about introduce a change that may potentially break stuff so this kind of stuff doesn't happen in the first place? I'm not asking for a stable kernel ABI.

              Comment


              • #17
                Originally posted by user1 View Post
                Well, that's what that dev said, not me.
                I didn't find that, but there are just too many msgs and I honestly don't want to spend time reading through every one of them.

                Originally posted by user1 View Post
                Also, when I constantly see things breaking on the Linux desktop, both in user and kernel space, and then look at Windows and realize this stuff just doesn't happen on WIndows, I see it as a weak point of Linux. Idk, maybe I'm too much of a perfectionist and I see flaws that other people don't see, but at the very least, like I said,
                For nvidia driver, the best way is to upstream it and making it part of the mainline.
                With nvidia opening up nvidia Linux kernel driver, it is possible for that to happen, though I read that the driver they put on github needs some serious refactor before it can be upstreamed and some nouveau devs is working on using the information revealed to improve this opensource nvidia driver.

                For others stuff you're talking about, I can't say much because it is just too general.

                The desktop experience of Linux is indeed not as good as Win or Mac because:
                - They are developed by volunteers and most tech companies isn't interest in the Linux desktop.
                - They lack the ecosystem, both Win and Mac successfully locked down their platform and makes some softwares exclusive to them.

                As for the breaking in userspace on desktop, I'm sure it also happens on Windows.
                The windows update has bricked my computer by fucking up its own Windows bootloader.

                My friends also experienced this from time to time due to windows update.

                Originally posted by user1 View Post
                can devs at least notify they're about introduce a change that may potentially break stuff so this kind of stuff doesn't happen in the first place? I'm not asking for a stable kernel ABI.
                For the Linux kernel, that is hard to do because nobody knows what the out-of-tree modules/drivers are doing and which APIs they use, especially when they are proprietary.

                For the userspace, well, I'm not so sure because that also includes a lot of different kinds of softwares and I just cannot think of a general answer.

                Comment


                • #18
                  Originally posted by birdie View Post
                  There's another drama going on but seems like the community hasn't noticed/doesn't care:

                  NVIDIA Open GPU Kernel Modules Version nvidia-dkms 515.57.10 Does this happen with the proprietary driver (of the same version) as well? Yes Operating System and Version Arch Linux Kernel Release L...

                  216303 – Commit ee7a69aa38d87a3bbced7b8245c732c05ed0c6ec broke legacy frame buffer with NVIDIA
                  216331 – Kernel 5.18.13 freezes VT display
                  I think it's a bit hard for people to care when someone is running around like a whiny, entitled Karen.

                  This is a perfect summary of the issue, and I would quite frankly close the issue with that and let NVIDIA approach the kernel devs. if there truely is an issue with the kernel
                  NVIDIA owners should be reporting problems related to NVIDIA drivers to NVIDIA.
                  Originally posted by user1 View Post

                  That "we are volunteers, therefore we have the right to break your stuff" argument really makes my blood boil. I recently heard the same argument about future GTK versions and GTK 4 text rendering from Gnome devs. As a user of your software, I don't give an f. I want everything to work properly and I don't care what it takes to fix something.
                  It might make your blood boil, but it's a response to rude, non-constructive behaviour. I absolutely don't blame them at all for responding like this. If you can't approach a problem constructively, don't expect constructive replies back.

                  Comment


                  • #19
                    Originally posted by AHSauge View Post
                    I think it's a bit hard for people to care when someone is running around like a whiny, entitled Karen.

                    This is a perfect summary of the issue, and I would quite frankly close the issue with that and let NVIDIA approach the kernel devs. if there truely is an issue with the kernel

                    It might make your blood boil, but it's a response to rude, non-constructive behaviour. I absolutely don't blame them at all for responding like this. If you can't approach a problem constructively, don't expect constructive replies back.
                    This is not an NVIDIA driver issue but it surely looks like you've skipped the most important parts and found your confirmation bias.

                    Comment


                    • #20
                      Originally posted by user1 View Post

                      Well, that's what that dev said, not me.

                      Also, when I constantly see things breaking on the Linux desktop, both in user and kernel space, and then look at Windows and realize this stuff just doesn't happen on WIndows, I see it as a weak point of Linux. Idk, maybe I'm too much of a perfectionist and I see flaws that other people don't see, but at the very least, like I said, can devs at least notify they're about introduce a change that may potentially break stuff so this kind of stuff doesn't happen in the first place? I'm not asking for a stable kernel ABI.
                      If you feel like Windows is stable and bug free, I'm very interested in knowing which version and build number you're using, because that would make my work life so much better.

                      My experience is that Windows is only stable-ish if you wait as long as possible with applying updates. Due to cutbacks in QA resources in Microsoft, the quality on what they deliver is quite visibly worse than before. Here is an ex-employee talking about it.

                      Comment

                      Working...
                      X