Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
