Announcement

Collapse
No announcement yet.

Linux 5.4 Features Are Huge From exFAT To New GPUs To Enabling Lots Of New Hardware

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

  • #31
    Originally posted by skeevy420 View Post
    Fucking hilarious that we used the same phone model in our examples.
    Sony Xperia Sola != Sony Xperia Z3.
    "Xperia" is Sony's equivalent of Samsung's "Galaxy". All Sony phones and tablets are "Xperia"

    The model name is "Sola" or "Z3" The Sola is from 2012, the Z3 is from 2014

    Comment


    • #32
      Originally posted by starshipeleven View Post
      "root easily" is not really a good thing. Malware can root your phone just as easily.
      Agreed, but until Google implements a few options in the Android UI, like setting your OWN font through a TTF file for example (which is not a weird thing as most desktop OS's allow it), root is the only option for me.

      Comment


      • #33
        Originally posted by starshipeleven View Post
        It's more complex than just "checking for root". Modern Android has a more complex system, with APIs and stuff to ensure that the system was not tampered with.
        It's called SafetyNet https://www.howtogeek.com/241012/saf...ooted-devices/

        Quality root applications like say Magisk https://magisk.me/ (which is opensource, among other things) can fake an unrooted and "safe" system so that I can run Google Pay on my LineageOS phone for example. (If it had NFC hardware anyway)
        Thanks for the link. I will take a look at it.

        Once I forgot to exit USB Debugging Mode and a financial app rejected my open request saying the app wasn't permitted to work while the device was in a debugging mode and it closed.

        So I was aware there was some API being checked but not the details.

        As for whitelisted UEFI/BIOS, yes, my Lenovo W510 allowed just about anything, anywhere except in the dang mini-Pcie slot where the WiFi adapter was.

        It wasn't until I located a home patched BIOS that permitted an Intel AC adapter to sit there, I was somewhat miffed. It was my first Lenovo product that was enforcing a whitelist since they took over ThinkPad from IBM.

        The bottom of the barrell Dell servers like the T5xx have a slot whitelist so that you can't upgrade the storage adapters to something more capable and higher performing. Its also to keep people from converting them to workstations because they sell them so cheap. I used to take these off peoples hands so I could turn them into NAS boxes, but stopped due to the whitelist.

        Its like when Honda tied the engine type to a chip in the key. People were taking the more powerful Acura version of the engine and doing a drop in replacement of the weak Civic motor. Honda didn't like it so they tied the engine, ECU and the key chip to the Acura so they couldnt be easily be swapped.

        Comment


        • #34
          Originally posted by skeevy420 View Post

          To keep people from wanting to unlock their devices and switching to custom roms. If you have to stay stock because the phone becomes crap when unlocked, they figure we'll just spend more money. Personally, most crap from mid-2016 to now is just fine for me (as long as it has a removable battery and a headphone jack).
          But why? Seriously, what is so bad about using a custom firmware?

          Comment


          • #35
            Originally posted by tildearrow View Post

            But why? Seriously, what is so bad about using a custom firmware?
            In which term? In the Android world, custom firmware is usually synonymous with custom rom. The bad in that regard is to the phone manufacturers because it can break a user from their pay for upgrades business model. Apple, OTOH, sells enough models for enough profit that they have a much better record with phone and os updates.

            If you're talking about custom firmware in regards to the SOC and hardware components, that can be anything from blobs only supplied by Qualcomm and other SOC makers to blobs from Sony for their Bravia engine and advanced camera functionality.

            With SOC makers, sometimes the phone manufacturer, like LG or Google, is simply unable to get new and updated blobs because Qualcomm/the SOC maker has moved on and now only supports this shiny new SOC and the old SOC is basically stuck to a specific Android version to collect dust unless the community manages to hack around those limitations. There's usually not a lot that can be done in those situations and there's only so long they'll get community support.

            The bad there is blobs essentially tie people to specific Android versions forcing them to upgrade a perfectly fine and working device. If you care about the environment, that should matter because it just makes us trash what should be perfectly working equipment. Some country pushing a mandatory support time-frame law would assist with that.

            With the phone manufacturers and the features they add, a lot of different scenarios really. Just lots of changes to how Android did things over the years and the many and varied things different manufacturers have done. At one point in time it was as simple as copy some stock APKs and libraries over to CM or AOKP.

            These days the DRM partition seems to be the method of choice and wiping that is normally tied in to fastboot oem unlock forcing users to choose between almost all features or all features with limited functionality. Design the stock APKs to just work with reduced functionality to cover people who unlock and everyone's "fine" because everything still works, just not to spec. In those cases the only choices are to find an exploit that allows for rooting and backup that partition (the tools usually block access to those partitions making root and dd the only way) or to hope that the community comes up with a method to spoof a DRM partition using things like Magisk or Xposed like has been done with some Sony devices.

            The bad there is we shouldn't have to rely on a security exploit to even do proper backups and restores of our phones. Some phones are so DRM integrated that the firmware can't be spoofed and it's unable to be copied from one device to another (unless some magical dev DRM gets leaked). While infrequent, bad updates have borked hypersensitive DRM schemes and simply being able to have the ability to revert a device to a known working state shouldn't require 27 hackers. They don't want us to be able to do that because it gives those 27 hackers more incentive to hack away at their stock APKs and get them working on custom roms. We'd need a device freedom law for this to not be as bad as it is. We shouldn't be punished because we want to run a kernel on the stock rom with nothing different than reduced frequencies and a CPU scheduler change because we don't plan on playing assloads of phone games and would like some extra battery life because a tiny amount of UI lag doesn't bother us. DRM wiping us so we can do things of that nature is bad.

            Comment


            • #36
              Originally posted by skeevy420 View Post
              What's the point of being GPL compliant if the end user can't make use of it?

              Exactly. These let them have their cake and eat it too by using the Linux kernel to turn an OS into an unchangeable binary firmware blob by restricting users' freedoms in how they use their hardware that they purchased. They also further entrench "buy to upgrade" by making it even harder to fully unlock and root our devices for long term use so we literally have to Pay to (use Google) Play. I'm kind of proud of that pun.

              The GPLv2 needs an updated clause about hardware freedom along the line of "if your hardware requires GPL software to function, the end-user should be allowed to freely modify, install, replace, remove, whatever the GPL software used".

              What sucks is these can be great in the hands of end-users wanting to harden our systems; they're just ripe for abuse by "evil corporations" to use free software to make proprietary, locked-down hardware which literally pisses on the spirit of the Free Software Movement and the Open Source Movement.
              You bring up good points. But it was to be expected.. Enterprises contribute majority of commits nowadays and of course they go the way THEY prefere.
              I am not sure it's even possible to change GPL v2 terms retroactively?

              Besides, once Google gets it's Fuchsia going, Android might be moot point anyway.

              Comment


              • #37
                hi, i need information about this new amd option,I don't know what it is for or for which family of amd cards it is addressed
                i am using amd rx470 and not sure if better to activate or just keep N

                thanks a lot
                *
                * Graphics support
                *
                VGA Arbitration (VGA_ARB) [Y/n/?] y
                Maximum number of GPUs (VGA_ARB_MAX_GPUS) [16] 16
                Laptop Hybrid Graphics - GPU switching support (VGA_SWITCHEROO) [N/y/?] n
                Enable DisplayPort CEC-Tunneling-over-AUX HDMI support (DRM_DP_CEC) [N/y/?] n
                ATI Radeon (DRM_RADEON) [N/m/?] n
                AMD GPU (DRM_AMDGPU) [M/n/?] m
                Enable amdgpu support for SI parts (DRM_AMDGPU_SI) [N/y/?] n
                Enable amdgpu support for CIK parts (DRM_AMDGPU_CIK) [N/y/?] n
                Always enable userptr write support (DRM_AMDGPU_USERPTR) [N/y/?] (NEW) ?

                CONFIG_DRM_AMDGPU_USERPTR:

                This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
                isn't already selected to enabled full userptr support.

                Symbol: DRM_AMDGPU_USERPTR [=n]
                Type : bool
                Prompt: Always enable userptr write support
                Location:
                -> Device Drivers
                -> Graphics support
                -> AMD GPU (DRM_AMDGPU [=m])
                Defined at drivers/gpu/drm/amd/amdgpu/Kconfig:27
                Depends on: HAS_IOMEM [=y] && DRM_AMDGPU [=m] && MMU [=y]
                Selects: HMM_MIRROR [=n] && MMU_NOTIFIER [=y]



                Always enable userptr write support (DRM_AMDGPU_USERPTR) [N/y/?] (NEW)
                Last edited by papu; 26 November 2019, 06:12 PM.

                Comment

                Working...
                X