[lkml]   [2013]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

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.


 \ /
  Last update: 2013-02-17 23:41    [W:0.046 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site