Announcement

Collapse
No announcement yet.

Linux 5.16 To Support Sensor Readings On More ASUS Motherboards

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

  • #11
    Originally posted by Sonadow View Post
    That's precisely what is wrong with desktop Linux. There is no one "Linux", just a clusterf**k of distributions purposely designed to be incompatible with another.
    Care to elaborate on how are distros purposely designed to be incompatible with each other?

    Originally posted by Sonadow View Post
    Unfortunately, the lusers seem to think that board vendors have an obligation to make their hardware compatible with the clusterf**k of distributions.
    All the board vendors need to do is submit a patch to the mainline kernel. No need to deal with distros.

    Comment


    • #12
      Originally posted by MadCatX View Post
      Care to elaborate on how are distros purposely designed to be incompatible with each other?
      When a package for distribution X-1 is not even usable on distribution X without potentially breaking stuff.

      When a package for distribution X cannot be used on distribution Y without breaking stuff.


      Originally posted by MadCatX View Post
      All the board vendors need to do is submit a patch to the mainline kernel. No need to deal with distros.
      Why should they open up their secrets for an operating system that has < 2% desktop share?

      And even if they send something to the mainline kernel in development, practically every distribution use an older patched kernel and will never see that change implemented if that new development kernel happens to break ABI.

      Comment


      • #13
        Originally posted by birdie View Post
        And what's wrong with an individual willing to improve Linux?? Companies supporting Linux primarily do that to further their bottom line - they couldn't care less about Linux on the desktop which Phoronix is kinda dedicated to.
        There's nothing wrong with an individual improving Linux, but it's better if the vendor does it before the launch of the product and takes responsibility for their hardware to be fully supported on Linux. I'd much rather buy a motherboard from a company which sends just a few minor patches to improve their Linux support than to a company that does not care at all.

        Also, there are workplaces with thousands of employees which buy a lot of desktops running Linux. Even though it might not be as much money as to e.g. data centers, it's probably not an negligible amount at least.

        Comment


        • #14
          Originally posted by birdie View Post

          And what's wrong with an individual willing to improve Linux?? Companies supporting Linux primarily do that to further their bottom line - they couldn't care less about Linux on the desktop which Phoronix is kinda dedicated to. If Linux on the desktop improves after their contributions it's mainly a byproduct, not their primary interest. So, far the only company which has really been improving Linux on the desktop was Valve and only Valve. And if you think they do it because they "love" Linux? Nope, they do it to earn more by selling Steam Deck and games for it.
          I think it is great that an individual contributes and improves Linux. I just think it is sad that Asus doesn't contribute to improve Linux support for their own products.

          Comment


          • #15
            Originally posted by Sonadow View Post
            When a package for distribution X-1 is not even usable on distribution X without potentially breaking stuff.

            When a package for distribution X cannot be used on distribution Y without breaking stuff.
            Nothing of the above have any relevance for the driver support discussed in the article.

            Why should they open up their secrets for an operating system that has < 2% desktop share?
            Secrets? For hardware sensor readings? Are you serious?

            Comment


            • #16
              Originally posted by Sonadow View Post

              When a package for distribution X-1 is not even usable on distribution X without potentially breaking stuff.

              When a package for distribution X cannot be used on distribution Y without breaking stuff.
              This is not what purposely means. This is just an unfortunate side effect of different distros having different development philosophies and technical issues stemming from a highly complex software ecosystem. If there was a good fix for this, we would've adopted it already but there just isn't one. But it doesn't mean that distros aim to be incompatible on purpose. Most importantly, it is nothing that hardware manufacturers need to be concerned with.

              Originally posted by Sonadow View Post
              Why should they open up their secrets for an operating system that has &lt; 2% desktop share?
              .
              Because there are no secrets to be opened up. Reading out temperature and fan speed sensors data is not rocket science.

              Originally posted by Sonadow View Post
              And even if they send something to the mainline kernel in development, practically every distribution use an older patched kernel and will never see that change implemented if that new development kernel happens to break ABI.
              This is a downstream issue. All the HW manufacturers are asked to do is provide drivers for their hardware. Once the code hits mainline, they're off the hook. A good way how to deal with more conservative distros with older kernels is to provide software support ahead of time; Intel, for instance, has been doing this for years.

              Comment


              • #17
                Originally posted by MadCatX View Post
                This is not what purposely means. This is just an unfortunate side effect of different distros having different development philosophies and technical issues stemming from a highly complex software ecosystem. If there was a good fix for this, we would've adopted it already but there just isn't one. But it doesn't mean that distros aim to be incompatible on purpose. .
                There IS a fix. Declare a universal base distribution with minimum versions for the kernel and various packages that all distributions must adopt as a baseline. Android and ChromeOS were able to pull this off.

                The only reason it does not exist for desktop Linux is entirely down to NIH syndrome and egos.
                Last edited by Sonadow; 19 September 2021, 11:17 AM.

                Comment


                • #18
                  Originally posted by Sonadow View Post

                  There IS a fix. Declare a universal base distribution with minimum versions for the kernel and various packages that all distributions must adopt as a baseline. Android and ChromeOS were able to pull this off.
                  How is that a fix? That'd just create yet another distro.

                  Originally posted by Sonadow View Post
                  The only reason it does not exist for desktop Linux is entirely down to NIH syndrome and egos.
                  No. It's mostly a result of tradeoffs between various approaches to development.

                  Comment


                  • #19
                    Originally posted by Sonadow View Post
                    ... that all distributions must adopt as a baseline.
                    What do you mean by "must adopt"? Or else what? What will happen to those that do not obey?

                    Comment


                    • #20
                      I have been using this revert for my Asus TUF Z370-Plus gaming board since a regression was introduced quite a while ago. I don't remember what kernel it was, but it initially started as a patch in some subversion (eg. 5.6.10 or something) then when the new kernel (5.7) was introduced, it was back to non-working again.

                      Chip on the Asus TUF board i have is NCT-6793, but afaik it uses the 6775 kernel module too.

                      Code:
                      ---
                      drivers/acpi/acpica/dsopcode.c | 4 ----
                      1 file changed, 4 deletions(-)
                      
                      diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
                      index 639635291..8ebad18d6 100644
                      --- a/drivers/acpi/acpica/dsopcode.c
                      +++ b/drivers/acpi/acpica/dsopcode.c
                      @@ -431,10 +431,6 @@ acpi_ds_eval_region_operands(struct acpi_walk_state *walk_state,
                      ACPI_FORMAT_UINT64(obj_desc->region.address),
                      obj_desc->region.length));
                      
                      - status = acpi_ut_add_address_range(obj_desc->region.space_id,
                      - obj_desc->region.address,
                      - obj_desc->region.length, node);
                      -
                      /* Now the address and length are valid for this opregion */
                      
                      obj_desc->region.flags |= AOPOBJ_DATA_VALID;
                      --
                      If anyone is interested to ivestigate?

                      EDIT: It seems to be quite older than that, i just had to search a bit.
                      https://lkml.org/lkml/2018/11/12/1652
                      https://lkml.org/lkml/2018/11/13/44
                      Well.. did not take them that long to fix stuff :P
                      Last edited by Cybmax; 19 September 2021, 12:27 PM.

                      Comment

                      Working...
                      X