> > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
