Announcement

Collapse
No announcement yet.

Intel GPU Driver Tries To Rip Out FBDEV Support

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

  • #11
    Originally posted by c117152 View Post
    I love this. Now nVidia's property drivers will be forced to either target kmdcon's fbdev since the kernel's is being deprecated, or get rewriten to use the kernel's own Mode Setting (KMS) instead of the driver's
    Finally, I'll get to have decent resolutions on my linux console :P

    I suppose AMD will also need to clean up some of it's Catalyst code now...
    text mode =/= fbdev
    And nvidia supports the former, so you're out of luck.

    Comment


    • #12
      Originally posted by Ericg View Post
      Does anyone really use console decorations? And high res is still supported, you just do a straight up DRM console instead of FBDEV console (See KMSCon)
      Yes, and kmscon is userspace, which means less reliability in tough situations like OOM conditions.

      Comment


      • #13
        Originally posted by kokoko3k View Post
        text mode =/= fbdev
        And nvidia supports the former, so you're out of luck.
        Yes nvidia's proprietary driver requires a text mode console and does whine loudly if you do use fbdev for providing a hi res console

        Comment


        • #14
          Originally posted by curaga View Post
          Yes, and kmscon is userspace, which means less reliability in tough situations like OOM conditions.
          Complete...and utter FUD.

          Your VT may run in kernelspace but your shell, all of your commands, the login prompt, the text parser on the screen EVERYTHING that isn't the black background...is userspace. If you have an X-session started, it handles the switch to the VT anyway so you're screwed there. And once you GET to the VT, I've seen the login prompt take seconds to appear just for the simple fact that I was THAT constrained on memory. You don't get a "high priority" console just because you're on a VT...you're still in userspace. And you don't get a "Failsafe" console either just for being on a VT, its still just your standard shell. You want failsafe? Serial port. End of story. NOTHING else is failsafe and we could probably even break Serial if we tried.
          Last edited by Ericg; 06-18-2013, 11:14 AM. Reason: Typo, and added serial portion.

          Comment


          • #15
            Originally posted by curaga View Post
            Yes, and kmscon is userspace, which means less reliability in tough situations like OOM conditions.
            It's trivial to stop the OOM killer from killing a process, just do "echo -17 > /proc/$pid/oom_adj", where $pid is the PID of the relevant process.

            Comment


            • #16
              And if it's swapped to hell? I doubt it locks all its memory.

              @Ericg

              Screw your kneejerk reaction. It's not FUD if it's completely true.

              It is one more place to break, when compared to status quo. Currently, no matter how bad the situation, I can switch to the console X was started from, and CTRL-C X. No new processes are started, it's a VT switch to the existing terminal.

              If the VT switch were relegated to userspace like with kmscon, it could take minutes longer, if it succeeded at all.

              Comment


              • #17
                Originally posted by curaga View Post
                And if it's swapped to hell? I doubt it locks all its memory.

                @Ericg

                Screw your kneejerk reaction. It's not FUD if it's completely true.

                It is one more place to break, when compared to status quo. Currently, no matter how bad the situation, I can switch to the console X was started from, and CTRL-C X. No new processes are started, it's a VT switch to the existing terminal.

                If the VT switch were relegated to userspace like with kmscon, it could take minutes longer, if it succeeded at all.
                Not a kneejerk reaction, people shouting that the VT is in kernelspace annoys me as much as the people shouting that "Wayland can't do networking!!" Because its completely false.

                Nothing that matters in the VT is in kernelspace. Switching from X to a VT1 is handled by X, so if X is completely deadlocked then you cant even switch out, switching from VT1 to X is handled by Kernelspace.

                I'm not saying you can't have legitimate reasons against Kmscon, but the ones you are saying aren't them.. Everything ALREADY is in userspace.

                Comment


                • #18
                  With KMS, I don't think X has much to say about a VT switch. The kernel can still listen to the keyboard with X completely deadlocked, not once has magic sysrq failed in such a situation for me.

                  Comment


                  • #19
                    Originally posted by curaga View Post
                    With KMS, I don't think X has much to say about a VT switch. The kernel can still listen to the keyboard with X completely deadlocked, not once has magic sysrq failed in such a situation for me.
                    info I found (granted it was a forum thread on linuxquestions-- but it was from 2012, so it was post the switch to KMS) said that the kernel handles going from VT to X, but thag X controlled the X-to-VT handoff.

                    not saying you're wrong, the thread may have been wrong, but show me some documentation that says otherwise. otherwise we are just having a he-said-she-said debate.

                    Comment


                    • #20
                      Originally posted by curaga View Post
                      And if it's swapped to hell? I doubt it locks all its memory.

                      @Ericg

                      Screw your kneejerk reaction. It's not FUD if it's completely true.
                      If things are in a bad way, I think the only thing you can rely on is switch back to boot console triggerred by the panic notifier in kms, and even that is not necessarily as reliable as you think thanks to a lot of bad locking interactions thanks to the current design of fbdev, notifier_call_chain, console_lock, .. it is really a mess.

                      Anyways, don't panic yet, I don't think we are quite to the point of disabling fbdev by default. But Daniel has looked a lot into trying to solve some of these locking problems, and I tend to agree with him that we are eventually going to need to rip this all out to fix things properly. Punting it all out to userspace would certainly simplify things in the kernel a lot, which is generally a good thing. A small special process that gets all it's pages pinned could help in the 'swapped to hell' case, for example. There are other things to consider, but current VT switch really isn't the answer. It was designed back in the days of user mode setting, resulting in a bit of a dance between kernel space and userspace. Try attaching gdb to X11 and do a VT switch then :-P

                      Comment

                      Working...
                      X