Announcement

Collapse
No announcement yet.

Enabling Intel Fastboot Support By Default Brought Up, Again

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

  • Enabling Intel Fastboot Support By Default Brought Up, Again

    Phoronix: Enabling Intel Fastboot Support By Default Brought Up, Again

    The Intel DRM "Fastboot" option is what allows skipping a mode-set upon the device initalization during the Linux boot process to allow for a slick and smooth Linux desktop boot experience free of any excess flickers. While Intel Fastboot has been an option for years, it isn't yet the default behavior for this 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
    Typo:

    Originally posted by phoronix View Post
    upon the device initalization during the Linux boot process
    The only problem with fastboot is that it screws up the bit depth on this Mac, until a modeset is done...

    Comment


    • #3
      What about AMD fastboot? Any chance to get it, even behind a dev flag?
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by tildearrow View Post
        The only problem with fastboot is that it screws up the bit depth on this Mac, until a modeset is done...
        They can't please everyone.

        Comment


        • #5
          Originally posted by debianxfce View Post

          It is systemd that causes flashing with its randomness entropy filling shit. No wonder fedora is so interested to hide it.
          Code:
          graphical.target @798ms
          └─lightdm.service @698ms +100ms
          └─systemd-user-sessions.service @694ms +2ms
          └─network.target @693ms
          └─wicd.service @572ms +120ms
          └─basic.target @568ms
          └─sockets.target @568ms
          └─dbus.socket @568ms
          └─sysinit.target @568ms
          └─systemd-timesyncd.service @266ms +301ms
          └─systemd-tmpfiles-setup.service @251ms +13ms
          └─local-fs.target @250ms
          └─media-ssd.mount @242ms +6ms
          └─dev-disk-by\x2duuid-9e9d5167\x2d3dc9\x2d4e9d\x2db39e\x
          Code:
          xfce@ryzenpc:~$ systemd-analyze time
          Startup finished in 1.993s (kernel) + 803ms (userspace) = 2.797s
          graphical.target reached after 798ms in userspace
          I fail to see the correlation here. My experience with lightdm is that it's a source of flashing. At least on some of my systems.

          Comment


          • #6
            Originally posted by debianxfce View Post

            It is systemd that causes flashing with its randomness entropy filling shit. No wonder fedora is so interested to hide it.
            Code:
            graphical.target @798ms
            └─lightdm.service @698ms +100ms
            └─systemd-user-sessions.service @694ms +2ms
            └─network.target @693ms
            └─wicd.service @572ms +120ms
            └─basic.target @568ms
            └─sockets.target @568ms
            └─dbus.socket @568ms
            └─sysinit.target @568ms
            └─systemd-timesyncd.service @266ms +301ms
            └─systemd-tmpfiles-setup.service @251ms +13ms
            └─local-fs.target @250ms
            └─media-ssd.mount @242ms +6ms
            └─dev-disk-by\x2duuid-9e9d5167\x2d3dc9\x2d4e9d\x2db39e\x
            Code:
            xfce@ryzenpc:~$ systemd-analyze time
            Startup finished in 1.993s (kernel) + 803ms (userspace) = 2.797s
            graphical.target reached after 798ms in userspace
            Are you using lightdm? If so, it's not systemd's fault but lightdm's, because it requires entropy.

            Comment


            • #7
              Originally posted by debianxfce View Post

              Lightdm is started at end of the process, so it is systemd required haveged.service that cause flashing at early boot.
              I uninstalled haveged, FWIW.

              You should also be able to suppress console output by adding this:

              Code:
              StandardOutput=null
              StandardError=journal+console
              in the [Service] section of the haveged service file.
              Last edited by Sloth; 17 December 2018, 02:47 PM. Reason: Formatting

              Comment


              • #8
                Originally posted by debianxfce View Post

                You need some entropy filler (see arch wiki), otherwise you must move the mouse or type with the keyboard to get boot going forward faster. The stupid kernel random number generator with systemd waiting causes this. I have zero messages in console, just one display mode change distortion line and one brightness change before the Xfce desktop is visible. Booting from the bios message to the desktop takes 10 seconds and it is the same time that I had several years earlier with much slower hardware. Systemd has bloated internally, the systemd-analyze dot command shows millions of services.
                Not seeing that here. Same boot time with and without haveged, not touching the mouse or keyboard.

                Comment


                • #9
                  I'm still baffled so much effort is being invested in beautifying boot screen output. Which is output rarely seen on stable systems, and seriously, why should I bother if some boot status output looks nicely? It's not like its more than a few seconds to be seen, anyway.

                  Comment


                  • #10
                    Am I the only one who don't care about the screen chainging modes during boot?

                    Comment

                    Working...
                    X