Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 55

Thread: Intel GPU Driver Tries To Rip Out FBDEV Support

  1. #11
    Join Date
    Apr 2011
    Posts
    153

    Default

    Quote 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.

  2. #12
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    Quote 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.

  3. #13
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    953

    Default

    Quote 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

  4. #14
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote 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 at 11:14 AM. Reason: Typo, and added serial portion.

  5. #15

    Default

    Quote 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.

  6. #16
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    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.

  7. #17
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote 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.

  8. #18
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    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.

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote 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.

  10. #20
    Join Date
    Sep 2011
    Posts
    218

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •