[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPM=9txQtJ6FLFTEFr_Wi6RK=W9y3gKYxV_+zPCo6kLi4nM8eA@mail.gmail.com>
Date: Mon, 18 Feb 2013 08:02:16 +1000
From: Dave Airlie <airlied@...il.com>
To: David Herrmann <dh.herrmann@...il.com>
Cc: linux-kernel@...r.kernel.org,
Florian Tobias Schandinat <FlorianSchandinat@....de>,
linux-fbdev@...r.kernel.org, David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
>
> This series tries to fix the mess with global system framebuffer access in
> device drivers. Currently, architecture initialization sets the "screen_info"
> object according to the system framebuffer that was detected during boot. The
> device driver that can map VMEM first gets access to it. There is no way to give
> a specific driver access to the device and no _proper_ way to revoke access
> again. In fact, some drivers don't even check whether they mapped the VMEM
> successfully, letting multiple drivers to access the system framebuffer at the
> same time.
I'm unsure if I like this or not, and I don't see why its greatly more
useful than the interface we have now.
It doesn't solve the main problem with the current interface, which is
that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a
real driver, things will fail either miserably or crappy from a users
pov.
The internal reference counts stop vesafb from unloading due to the
mmaps, then i915 loads anyways and one bashes the other, or we fix so
i915 doesn't load and the user gets fail.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists