Announcement

Collapse
No announcement yet.

Sony Now "Officially" Maintaining The Linux PlayStation Input Driver, But Leads To Interesting Problem

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

  • #41
    Let me share a brief reply here. Since 2017 we have rewritten about half of hid-sony to support our controllers well (in particular ds4) and this is all upstream. The driver wasn't in good shape. Now we use it extensively and pretty much all mobile devices with a Linux kernel will use it this year.

    The challenge for us is mostly on the technical side as I mentioned on linux-input as well: https://lore.kernel.org/lkml/CAEc3ja...ail.gmail.com/. These devices kind of look and behave like ours, but they are different. They often use different HID descriptors and have other differences. We don't have their datasheets or know how they work. If the code is in our "official" driver, we can't vouch for the quality, it can cause regressions for our official controllers. We would also have to QA the driver for those devices etcetera. It causes issues for our partners etcetera. Ideally such code would live in a different driver supported by the community, but since these device use our vendor / product ids, that's not that easy.

    Comment


    • #42
      Originally posted by Lycanthropist View Post
      Linux is free software and I believe that while commercial companies are more than welcome to contribute to the Linux kernel, they should not be allowed to control it. Everyone should have the freedom to use whatever hardware they please. The interests of a commercial company is of no value in the realm of free software in my opinion.
      I am curious if you'd retain that opinion when it comes to somebody else using hardware some 'Your Service(TM)' is based on. Especially when your business model is built on primarily selling that service and you are selling client-side hardware (that would enable your subscribers to use your service) at a loss or breaking-even level. You'd have ZERO interest in allowing that hardware to be "open", whatever some marxist "I want it all"-wannabe revolutionaries think.

      Comment


      • #43
        Originally posted by Thunderbird View Post
        The challenge for us is mostly on the technical side as I mentioned on linux-input as well: https://lore.kernel.org/lkml/CAEc3ja...ail.gmail.com/. These devices kind of look and behave like ours, but they are different. They often use different HID descriptors and have other differences. We don't have their datasheets or know how they work.
        Isn't this the case with a lot of hardware for which Linux drivers are written? People figure out how their hardware works even in the absence of technical datasheets (e.g. by USB sniffing). So this isn't really an argument for or towards anything.

        Originally posted by Thunderbird View Post
        If the code is in our "official" driver, we can't vouch for the quality,
        Why would anyone expect you / Sony to vouch for the quality of hardware function? As long as the driver itself functions as best as possible and doesn't contain terrible software bugs (like memory leaks), the driver should be ok.

        If it makes it easier on the mind of Sony management, they could just decide "it's the official driver for OUR hardware" as opposed to being "an official Sony driver". It's not sensible for Sony people to think of it as *their* official driver, because it's not really theirs. If it's in the Kernel it comes under all the rules of kernel development (largely outside Sony's control) and it will have an Open Source license attached to the source code.

        Originally posted by Thunderbird View Post
        it can cause regressions for our official controllers.
        If the code is bugged yeah... but... is this an argument for not including hardware support in a driver? In general when you add new features to software, it can cause regressions.

        Originally posted by Thunderbird View Post
        We would also have to QA the driver for those devices etcetera.
        If Sony don't want to pay staff to handle this, surely another maintainer could step up to take over?

        Originally posted by Thunderbird View Post
        It causes issues for our partners etcetera.
        This isn't Sony's driver. It's a driver partially/largely developed by Sony which Sony employs staff to maintain.

        If this lived out of the kernel tree, what you said could reasonably be brought up when devs are discussing the driver. This is in-tree though. Linux is for everyone.
        Last edited by cybertraveler; 29 January 2020, 01:50 PM.

        Comment


        • #44
          Originally posted by Almindor View Post

          Well, no actually that'd be breaking the spirit of free software as well as possibly the GPL.

          The only good reason for refusing a valid patch from pretty much any source is a technical one.[...]
          Well, no. The GPL is about the fact that if you don't like where a project is heading to, you are allowed to fork it.

          There is nothing about accepting or not a patch on its technical merit or any other reasons

          Comment


          • #45
            Originally posted by cybertraveler View Post

            Isn't this the case with a lot of hardware for which Linux drivers are written? People figure out how their hardware works even in the absence of technical datasheets (e.g. by USB sniffing). So this isn't really an argument for or towards anything.
            Yes, but most device drivers only support one vendor's hardware.

            For example it is unlikely people would expect amdgpu developers to maintain support for gpus made by an unrelated company that copy AMD's pci ids. In this example, changes made to support the other company's gpus could cause regressions on the actual AMD cards, and likewise changes made to improve AMD gpus could cause regressions on the other company's gpus, and they would have no way of knowing until users scream at AMD developers for breaking the driver on non-AMD devices they cannot test and cannot get documentation for.

            Comment


            • #46
              Originally posted by Space Heater View Post

              Yes, but most device drivers only support one vendor's hardware.

              For example it is unlikely people would expect amdgpu developers to maintain support for gpus made by an unrelated company that copy AMD's pci ids. In this example, changes made to support the other company's gpus could cause regressions on the actual AMD cards, and likewise changes made to improve AMD gpus could cause regressions on the other company's gpus, and they would have no way of knowing until users scream at AMD developers for breaking the driver on non-AMD devices they cannot test and cannot get documentation for.
              Have a look at the latest Kernel 5.5 Benchmarks https://www.phoronix.com/scan.php?pa...ble-Benchmarks - it seems that AMDs performance is also affected at context switching - correct me if I'm wrong - but wasn't this mostly an Intel issue because of some mitigations? Isn't this the kind of situation given by your example. If we apply what you are impling it means we should reject all Intel patches covering their security leaks because it causes regression also on AMDs side? Or is it okay because Intel is one of the big players? and btw here we are back on topic.
              Last edited by CochainComplex; 29 January 2020, 06:51 PM.

              Comment


              • #47
                Originally posted by Space Heater View Post

                Yes, but most device drivers only support one vendor's hardware.

                For example it is unlikely people would expect amdgpu developers to maintain support for gpus made by an unrelated company that copy AMD's pci ids. In this example, changes made to support the other company's gpus could cause regressions on the actual AMD cards, and likewise changes made to improve AMD gpus could cause regressions on the other company's gpus, and they would have no way of knowing until users scream at AMD developers for breaking the driver on non-AMD devices they cannot test and cannot get documentation for.
                Take a look at network driver if you want a good example of how this is dealt with. It used to be very common for hardware to get cloned. The NE2000 was very popular. The driver ended up with a long list of variant detection code and the quirks to go with them. Novel didn't get to come in and say "this is a driver for our hardware, the rest of you get out". No, it was for NE2000 type cards of which the authentic Novel cards were just a few.

                Look into SoCs that use common IP. They are full of variants. It seems every SoC vendor (and several times within their own product lines) they implement things differently from the 'stock' IP. Does DesignWare come in and say that all the variants (even the unlicensed ones) need to get out? No, they don't.

                USB drivers, display engines, network adapters, SATA controllers all do it. This is extremely common in the kernel. The more popular a device, the more likely for this to happen.

                If a vendor thinks they can come in and take over a driver or even maintain strict control over a driver they provided (which is not the case here with Sony) they are sadly mistaken. If they deny patched based on politics and not of technical merits, they'll lose maintainership and their patches will receive extra scruitny. Look no further than FTDI if you don't believe me.

                Comment


                • #48
                  Originally posted by CochainComplex View Post
                  Have a look at the latest Kernel 5.5 Benchmarks https://www.phoronix.com/scan.php?pa...ble-Benchmarks - it seems that AMDs performance is also affected at context switching - correct me if I'm wrong - but wasn't this mostly an Intel issue because of some mitigations?
                  You are showing a benchmark, then making the unsubstantiated assertion that the regression is due to changes from Intel, and further you seem to be implying that this alleged Intel-sponsored change was made to some amd-maintained device driver. Please provide evidence of your claims, otherwise you are just going off into hypothetical land.

                  Originally posted by CochainComplex View Post
                  Isn't this the kind of situation given by your example.
                  No it's not, in the case of x86 platform code both AMD and Intel have shared responsibility. The problem would be if AMD were the sole maintainers and Intel just chucked code at them that caused regressions and then left it up to AMD.

                  Originally posted by CochainComplex View Post
                  If we apply what you are impling it means we should reject all Intel patches covering their security leaks because it causes regression also on AMDs side?
                  I'm not implying that the support cannot be put into the kernel driver. The issue is that people outside of sony need to explicitly say that they will support and test the hardware that they want to add. It's fine as long as someone is actually going to maintain and test code changes on real hardware, but it's not fair to dump that responsibility on developers who don't have access to them.

                  Originally posted by CochainComplex View Post
                  Or is it okay because Intel is one of the big players? and btw here we are back on topic.
                  You're just making things up and pretending I'm some intel shill, great way to have a discussion.

                  Originally posted by willmore View Post
                  Take a look at network driver if you want a good example of how this is dealt with. It used to be very common for hardware to get cloned. The NE2000 was very popular. The driver ended up with a long list of variant detection code and the quirks to go with them. Novel didn't get to come in and say "this is a driver for our hardware, the rest of you get out". No, it was for NE2000 type cards of which the authentic Novel cards were just a few.
                  I think they should accept support for all non-official controllers provided someone writes the patches, I just don't think anyone should expect Sony developers to *actively* maintain support for them, that should be up to the community or the company that made the controllers.

                  Comment


                  • #49
                    I think they have to do marketing against copycats. They can't do it in the driver code.

                    Comment


                    • #50
                      Originally posted by willmore View Post

                      Take a look at network driver if you want a good example of how this is dealt with. It used to be very common for hardware to get cloned. The NE2000 was very popular. The driver ended up with a long list of variant detection code and the quirks to go with them. Novel didn't get to come in and say "this is a driver for our hardware, the rest of you get out". No, it was for NE2000 type cards of which the authentic Novel cards were just a few.
                      That doesn't make the approach correct though. And as you noted, it complicated the driver due to having to deal with the quirks of each variant device.

                      Ideally, you wouldn't want to re-use the same driver between manufactures. A good example of this would be ASUS's Xonar line of sound cards, which are essentially just modified C-Media based chipsets. ASUS provides their own driver that handles each cards quirks, even if you can install the base C-Media driver to get most of the same functionality out of the box. What you're proposing here would be dragging ASUS's functionality into the C-Media driver, rather then ASUS just modifying C-Media's driver to fit their own needs. That's pretty much the argument here.

                      Comment

                      Working...
                      X