Announcement

Collapse
No announcement yet.

Developer Steps Up Wanting To Maintain Linux's FBDEV Subsystem

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

  • Developer Steps Up Wanting To Maintain Linux's FBDEV Subsystem

    Phoronix: Developer Steps Up Wanting To Maintain Linux's FBDEV Subsystem

    The Linux kernel's frame-buffer device "FBDEV" subsystem has thankfully been on the decline over the past number of years thanks to the success of the more useful DRM/KMS drivers and having FBDEV compatibility emulation support. While not actively maintained, the FBDEV subsystem and some drivers remain within the Linux kernel and are used with some interest primarily in some legacy/embedded environments. The subsystem was orphaned while now a Linux kernel developer has stepped up to serve as its maintainer...

    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
    I suppose there's not much going on in PA-RISC these days. Probably not a whole lot more in FBDEV.

    Comment


    • #3
      Scrollback, scrollback, scrollback! Please?

      Comment


      • #4
        I'm guessing it's at least easier to maintain FBDEV than DRI. I wonder if anyone has statistics on the amount of devices still in used that require FBDEV.

        Comment


        • #5
          Originally posted by Jabberwocky View Post
          I wonder if anyone has statistics on the amount of devices still in used that require FBDEV.
          Thats not even what you should care about. Many, if not most of them dont run anything near an up-2-date kernel. That what someone should care about is the devices who actually need or will probably see these changes.

          Comment


          • #6
            Originally posted by lumks View Post

            Thats not even what you should care about. Many, if not most of them dont run anything near an up-2-date kernel. That what someone should care about is the devices who actually need or will probably see these changes.
            You're right, if the device requires other drivers that are not mainlined it would be useless to recieve updates.

            I suppose in the best case FBDEV support might help community/other maintainers to debug/update a device that is not maintained by the manufacturer. Which I'm guessing is the case for PA-RISC. I'm just glad I don't have to be the person responsible for it such a thing (touch wood).

            Comment


            • #7
              Originally posted by birdie View Post
              Linux-5.9-Drops-Soft-Scrollback Scrollback, scrollback, scrollback! Please?
              Really no. That been dropped for quite awhile now. Yes 11 October 2020 its not coming back. Tmux and gnu screen and others can generate the scroll back functionality as userspace code so when it goes wrong it does not kernel panic the system.

              More likely is complete removal for interactive console code from Linux kernel than Scrollback ever coming back to kernel. Yes the interactive console code in kernel space of the Linux kernel has been a on going cause of bugs.

              Yes the systemd-console/kmscon development stalled out at this stage due to the lead developer getting employed and giving other projects to work on and that why we still have config-vt enabled every where.

              Yes something like systemd-console/kmscon could also give you back scrollback without kernel space code todo it. Birdie so soft scrollback in kernel you need to justify why in heck it should be in kernel space code. Reality here with the number of options that exist that perform scrollback without kernel code suggest kernel soft scrollback not required at all but instead investment in user-space solutions is required. The reality is the arguement anyone trying to return soft scrollback into the Linux kernel is going to run into.

              Originally posted by Jabberwocky View Post
              I'm guessing it's at least easier to maintain FBDEV than DRI. I wonder if anyone has statistics on the amount of devices still in used that require FBDEV.




              There are a lot of drivers still in fbdev that no one wants to update some have been superceeded like uvesa fbdev that is really superceeded by simpledrm driver but the old driver is still in the kernel.

              When you see the drm tiny drivers the fbdev drivers are not easier to maintain. FBDEV drivers just avoid having to recode the driver and recoding the driver means having the hours todo it and the physical hardware to test it with some of these drivers the physical hardware to test with is a real problem to get anyone to recode the driver. Yes drivers ported from FBDEV to tinydrm normally results in more shared code so lower maintenance cost.

              Comment


              • #8
                The problem with user mode scrolling is: often you don't have a user mode in which you have screen or tmux. For example, being right in the initramfs. If you have to to do the init=/bin/bash trick (I do need this more often than I would like to do...) you can't even just fire up screen.

                Comment


                • #9
                  Originally posted by mifritscher View Post
                  The problem with user mode scrolling is: often you don't have a user mode in which you have screen or tmux. For example, being right in the initramfs. If you have to to do the init=/bin/bash trick (I do need this more often than I would like to do...) you can't even just fire up screen.
                  Add debugging tools to an existing initramfs, even if it is for a foreign architecture - mephi42/initramfs-wrap

                  That reasoning does not hold up. It is possible to have tmux or screen in you initramfs.or have a debugging initramfs with either. So do we need to alter the kernel or alter the standard of tools included in the initramfs. Altering the tools included in the initramfs is not that hard.

                  Sorry mifritscher problem has being brought up many times on the lkml as a reason to keep the internal kernel scrollback before its removal reality that reason does not hold up.

                  Something else to consider here if you have to access the device by serial then fbcon and vgacon scrollback was also useless but a tmux or screen in initramfs works. The more flexible solution to the scrollback problem is the userspace one.

                  There is s serous question if scrollback should really be function of shell and for years it was just placed in completely the wrong place.

                  Comment


                  • #10
                    Originally posted by oiaohm View Post





                    There are a lot of drivers still in fbdev that no one wants to update some have been superceeded like uvesa fbdev that is really superceeded by simpledrm driver but the old driver is still in the kernel.

                    When you see the drm tiny drivers the fbdev drivers are not easier to maintain. FBDEV drivers just avoid having to recode the driver and recoding the driver means having the hours todo it and the physical hardware to test it with some of these drivers the physical hardware to test with is a real problem to get anyone to recode the driver. Yes drivers ported from FBDEV to tinydrm normally results in more shared code so lower maintenance cost.
                    This gives me a very good idea of what I wanted to know and even more. Thank you.

                    Comment

                    Working...
                    X