Announcement

Collapse
No announcement yet.

The - Hopefully - Final Stab At Intel Fastboot Support

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

  • The - Hopefully - Final Stab At Intel Fastboot Support

    Phoronix: The - Hopefully - Final Stab At Intel Fastboot Support

    Intel's Maarten Lankhorst has sent out what could be the final patches for enabling "fastboot" support by default within their DRM graphics driver...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Ridiculously funny until recently i didn't know this is an intel issue... i was disliking this "linux issue" for a while... haha good to know this will disappear!!!!

    Comment


    • #3
      Originally posted by debianxfce View Post
      Too bad that they develop acpi and other important stuff in the Linux kernel.
      The ACPI x86 was specifically designed by Intel on Microsoft's behalf to make it possible for OEMs to use closed-sourced bios (and later, UEFI) modules. This, in turn, allowed chip developers to keep their APIs closed source and only write drivers for Windows.

      Consequently, they're not developing ACPI in the Linux kernel. At best, they're undoing their past own attempts at sabotaging it. At worst, they're continuing to sabotage it while making it seem like they're slowly fixing it to discourage anyone from actually attaching an hardware debugger and starting to reverse Microsoft's ACPI interpreter like they're doing with Hackintoshes.

      Considering the state of BayTrail on Linux, I'd say it's the latter.
      Last edited by c117152; 18 November 2017, 07:55 AM.

      Comment


      • #4
        Originally posted by c117152 View Post

        The ACPI x86 was specifically designed by Intel on Microsoft's behalf to make it possible for OEMs to use closed-sourced bios (and later, UEFI) modules. This, in turn, allowed chip developers to keep their APIs closed source and only write drivers for Windows.

        Consequently, they're not developing ACPI in the Linux kernel. At best, they're undoing their past own attempts at sabotaging it. At worst, they're continuing to sabotage it while making it seem like they're slowly fixing it to discourage anyone from actually attaching an hardware debugger and starting to reverse Microsoft's ACPI interpreter like they're doing with Hackintoshes.

        Considering the state of BayTrail on Linux, I'd say it's the latter.
        Are there warriors doing that reverse right now?

        Comment


        • #5
          Originally posted by timofonic View Post

          Are there warriors doing that reverse right now?
          Not to my knowledge. I think the SeaBIOS folks came the closest when they managed to boot Windows. But since ACPI is a standard, the linux devs would rather stick to the specs then try imitate Windows' brand-of-broken even if it so happens to be the de-facto standard. Especially considering the typical in-bios tables are so horribly broken that it's very likely that even if you interpreted it just like Microsoft, you'd still need to know what Microsoft's drivers are ignoring or using from them. For instance, about half the laptops on the market have broken ACPI instructions for the lid. So Microsoft white/blacklists certain table entries per-model and lets drivers also choose what to use and what to ignore...

          Overall:

          Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.
          -- Linus Travolds, Linux Journal, November 2003

          Comment


          • #6
            Originally posted by c117152 View Post

            Not to my knowledge. I think the SeaBIOS folks came the closest when they managed to boot Windows. But since ACPI is a standard, the linux devs would rather stick to the specs then try imitate Windows' brand-of-broken even if it so happens to be the de-facto standard. Especially considering the typical in-bios tables are so horribly broken that it's very likely that even if you interpreted it just like Microsoft, you'd still need to know what Microsoft's drivers are ignoring or using from them. For instance, about half the laptops on the market have broken ACPI instructions for the lid. So Microsoft white/blacklists certain table entries per-model and lets drivers also choose what to use and what to ignore...

            Overall:


            -- Linus Travolds, Linux Journal, November 2003
            Stick to the standards? There are no real standards, all of them are designed to have "caveats" that monopolies/oligopolies take advantage of them. Look at websites, OpenGL, USB...

            Devices not working correctly in Linux or having bugs, hardware vendors not giving a shit (like MSI, unfortunately the brand of my laptop). I agree about voting with our money, but we are still insignificant for them. Linux Desktop "Radicals" are like a minority of crazy people for them, even the Linux kernel development is still mostly tailored for non-desktop hardware (what about full and clean merging of realtime patches? What about better audio without requiring layers like PulseAudio or Jack? What about undervalued efforts like Con Kolivas patches and many other "forks" that struggle to get updated with upstream? What about a proper and official software that makes fwts+.hw-probe+others join and become a really serious effort with resources and able to provide both useful feeback but bughunting, etc?

            Comment


            • #7
              Originally posted by timofonic View Post
              ...hardware vendors not giving a shit (like MSI, unfortunately the brand of my laptop).
              It's not that they don't give a shit so much as they just don't know what's wrong. When OEM hardware engineers write ASL per-board, they just make small tweaks to the reference designs to get stuff like chip substitutions (another wan, another audio chip...) or sensors (an open/closed lid, battery and fan control...) working in windows through trial and error while referencing the chip docs and examples and targeting windows. Most of them know their voltages and fuses enough to barely modify a reference PCB to cheaper components. A few can even pick up a bunch of chips and design their own boards. But when it comes to the software, they're all mostly script-kiddies that learned their Intel provided SDK and copy-pasted stuff off the docs without even reading the standards.

              I think it's been getting better over the last few years as more embedded, Linux-oriented engineers that had experience with Android and ChromeOS ended up in the laptop board designs teams. Sadly, MSI doesn't have those guys on-board by the looks of it.

              Comment


              • #8
                When I enabled fastboot by i915.fastboot=1 on 4.15-rc1 the brightness keys of the laptop responded different (unwanted behavior) than before.

                Does anybody else notice this behavior?

                Comment

                Working...
                X