Re: [PATCH 0/9] System Framebuffer Bus (sysfb)

[Dave Airlie]

>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/