conflicts between fbcon and user-mode fbdev clients

conflicts between fbcon and user-mode fbdev clients

[Bernie Thompson]

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/

Re: conflicts between fbcon and user-mode fbdev clients

[James Simmons]

> 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.

That shouldn't happen. In the xorg.conf do you have in the 

Option UseFBDev "True"

Re: conflicts between fbcon and user-mode fbdev clients

[Bernie Thompson]

On Thu, Dec 10, 2009 at 11:02 AM, James Simmons <jsimmons@infradead.org> wrote:
> That shouldn't happen. In the xorg.conf do you have in the
>
> Option UseFBDev "True"

That option appears to have no effect (have tried both ways).  Do you
know who parses it?  Couldn't find it in core xserver.

The DisplayLink support is still very rough, but it's currently using
its own X server driver
(http://libdlo.freedesktop.org/wiki/xf86-driver-displaylink), which
has some IOCTLs to its framebuffer driver, including a mode setting
IOCTL.

If the arbitration between fbdev clients is intended to happen at the
point of mode setting, rather than at open(), that would explain the
problem.  Are there any old posts or docs which describe how
arbitration is handled for the fbdev driver and multiple clients?

Jaya Kumar has written an alternative DisplayLink fbdev driver that
uses defio and works with the standard fbdev X servers.  That support
will be merged in soon, so then it'll be easy to test what happens
where there's no special mode set paths between X and the framebuffer
driver.

Thanks,
Bernie

Re: conflicts between fbcon and user-mode fbdev clients

[Geert Uytterhoeven]

On Thu, Dec 10, 2009 at 20:43, Bernie Thompson <bernie@plugable.com> wrote:
> On Thu, Dec 10, 2009 at 11:02 AM, James Simmons <jsimmons@infradead.org> wrote:
>> That shouldn't happen. In the xorg.conf do you have in the
>>
>> Option UseFBDev "True"
>
> That option appears to have no effect (have tried both ways).  Do you
> know who parses it?  Couldn't find it in core xserver.
>
> The DisplayLink support is still very rough, but it's currently using
> its own X server driver
> (http://libdlo.freedesktop.org/wiki/xf86-driver-displaylink), which
> has some IOCTLs to its framebuffer driver, including a mode setting
> IOCTL.
>
> If the arbitration between fbdev clients is intended to happen at the
> point of mode setting, rather than at open(), that would explain the
> problem.  Are there any old posts or docs which describe how
> arbitration is handled for the fbdev driver and multiple clients?

Usually the X server locks the VT (virtual terminal) using an ioctl,
and uses another ioctl to switch the VT to graphics mode, so fbcon
will stop drawing to it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds