[Intel-gfx] [PATCH 0/3] fbdev no more!

David Herrmann dh.herrmann at gmail.com
Tue Jun 18 08:12:34 CEST 2013


Hi

On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski <luto at 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



More information about the Intel-gfx mailing list