From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH 0/3] fbdev no more! Date: Mon, 17 Jun 2013 13:47:23 -0700 Message-ID: <51BF75DB.3090504@mit.edu> References: <1371394640-1130-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1371394640-1130-1-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Intel Graphics Development , DRI Development List-Id: intel-gfx@lists.freedesktop.org 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. 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. --Andy