Hi fbdevs, This is probably a FAQ, but I haven't found the answer. What (if anything) should a driver be doing to prevent fbcon and other clients (e.g. X, etc.) from simultaneously opening and rendering to the framebuffer? Running a USB graphics device using the udlfb framebuffer driver (in the staging tree of 2.6.32), a common problem is fbcon automatically opens the first available framebuffer device (/dev/fb0). Then when the user loads an X server, both the X server and fbcon continue to merrily render to the device, overwriting each other. So, typically, the udlfb driver will see this sequence at boot (with the xf-video-displaylink X server): fb_open(user = 0) fbcon opening the framebuffer fb_open(user = 1) X opening the framebuffer fb_open(user = 1) Another instance of X opening framebuffer * X and fbcon both render to the framebuffer, causing a mess * And then any calls to release() later. This will happen only for the 1st usb device on the system. For the 2nd or later (/dev/fb1 ...), fbcon doesn't try to grab the device. It's possible to disable fbcon as a module, or fail open() when user=0. But that's obviously not right. And fbset by the user could be a solution - but there's a desire to have this work out of the box. Looking at the various fbdev drivers, I don't see other drivers special casing this in general. So I assume there's a known recommended behavior here, but don't know what it is. What is the expected behavior, for a fbdev driver and its clients, to arbitrate among multiple clients? Thanks for any answers here! Bernie Thompson http://plugable.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
