Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski luto@amacapital.net wrote:
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and cried. Fixing up the console_lock mess around the fbdev notifier will be real work, semanatically the fbdev layer does lots of stupid things (like the radeon resume issue I've just debugged) and the panic notifier is pretty much a lost cause.
So I've decided to instead rip it all out. It seems to work \o/
I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever.
See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not.
Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver.
Already working on it.
Regards David