Page 1 of 6 123 ... LastLast
Results 1 to 10 of 55

Thread: Intel GPU Driver Tries To Rip Out FBDEV Support

  1. #1
    Join Date
    Jan 2007
    Posts
    14,303

    Default Intel GPU Driver Tries To Rip Out FBDEV Support

    Phoronix: Intel GPU Driver Tries To Rip Out FBDEV Support

    Intel's Daniel Vetter is attempting for the Intel DRM graphics driver to remove support for its FBDEV frame-buffer layer with a new patch-set entitled "fbdev no more!", but will this finally usher in the killing of the Linux kernel's FBDEV subsystem?..

    http://www.phoronix.com/vr.php?view=MTM5MDc

  2. #2
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    What does it mean though? Does it mean no hi res console? No console decorations?

  3. #3
    Join Date
    May 2010
    Posts
    159

    Default

    no fbdev? how would Weston work in VirtualBox?

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

    Default

    Quote Originally Posted by nerdopolis View Post
    no fbdev? how would Weston work in VirtualBox?
    VirtualBox gets off its ass and makes a proper KMS driver like VMWare is working on/did

    EDIT: Oh hey, guess they are. http://www.phoronix.com/scan.php?pag...tem&px=MTAxOTk Shouldn't be an issue then.
    Last edited by Ericg; 06-17-2013 at 06:28 PM.

  5. #5
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,859

    Default

    Quote Originally Posted by duby229 View Post
    What does it mean though? Does it mean no hi res console? No console decorations?
    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)

  6. #6
    Join Date
    Mar 2013
    Posts
    144

    Default

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

  7. #7
    Join Date
    Sep 2009
    Posts
    116

    Default

    I've had to use virtual terminals as a fallback in situations where I've bricked my video drivers. It would sure be nice to retain high-res VTs if DRM is not working. Does anyone know if that ability will be removed as part of the process?

  8. #8
    Join Date
    Nov 2011
    Posts
    267

    Default

    Quote Originally Posted by MaxToTheMax View Post
    I've had to use virtual terminals as a fallback in situations where I've bricked my video drivers. It would sure be nice to retain high-res VTs if DRM is not working. Does anyone know if that ability will be removed as part of the process?
    I presume you mean kernel DRM, not the userspace side of DRM?
    If so, you never had high resolution VTs without kernel DRM, unless you use a straight framebuffer (unaccelerated) driver, whether native or VESA/VGA.

    If you mean the userspace DRM interface, the short answer is yes:
    Quote Originally Posted by Daniel Vetter
    Of course a general purpose distro propably wants David's kmscon for any
    fallbacks needs and a system compositor to ditch the VT subsystem - atm my
    machine here runs with the dummy console so that VT switching between different
    X sessions still works ;-)
    The longer answer is that the in-kernel accelerated graphics drivers all use DRM, the kernel VT emulation currently uses fbcon in graphics mode, and fbcon currently needs a framebuffer; no one wants to maintain the VT emulation, so "drmcon.ko" will probably not happen.

    Now, I'll try to avoid a system without fbdev, even if it means not updating to a new kernel; for me, it would break Links2 and fbi, and it would spell the end for fbvnc, etc. Say what you will about "x is broken, you shouldn't use it": it works for me, and I can use a graphical browser without needing to fire up X.
    ...

    Oh, the patches aren't quite what they're advertised as. They make fbdev support optional, by stubbing out all the hooks when you don't select DRM_I915_FBDEV. Which means that all of the analysis above is only true for CONFIG_DRM_I915_FBDEV=n.

  9. #9
    Join Date
    Jun 2013
    Posts
    1

    Default

    Hmmm..that's sucks. Browsing with links2, watching videos with mplayer and even playing SLD games (fb is the only true way to use ScummVM) on the console weekends was always pretty fun
    And FBDEV is a pretty nice fallback option in case of X failure too

  10. #10
    Join Date
    Jan 2011
    Posts
    98

    Default What?

    Did I understand correctly? They are completely ditching the VT subsystem without providing any equivalent replacement? Certainly this can't be.

Posting Permissions

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