[PATCH] compositor-fbdev: Wait and retry before failing on reconnect to the framebuffer

[Pekka Paalanen]

On Wed, 13 May 2015 21:43:39 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
> udev might be configured to set the permissions on framebuffer devices with the UACCESS attribute.
> Weston currently attempts to reconnect to the framebuffer device before udev can set the permissions back.
> 
> It waits 3 times in case if the system is heavily paging, or slowed down, and prevents udev from working.
> In my testing the delay is long enough where it works on the first try
> ---
>  src/compositor-fbdev.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 7c505ce..42d2881 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -663,13 +663,23 @@ fbdev_output_reenable(struct fbdev_compositor *compositor,
>  	struct fbdev_output *output = to_fbdev_output(base);
>  	struct fbdev_screeninfo new_screen_info;
>  	int fb_fd;
> +	int retries;
>  	const char *device;
>  
>  	weston_log("Re-enabling fbdev output.\n");
>  
>  	/* Create the frame buffer. */
> -	fb_fd = fbdev_frame_buffer_open(output, output->device,
> +	fb_fd = -1;
> +	retries = 0;
> +	while (fb_fd < 0 && retries < 3) {
> +		usleep(10000);
> +		fb_fd = fbdev_frame_buffer_open(output, output->device,
>  	                                &new_screen_info);
> +		if (fb_fd < 0) {
> +		  weston_log("Creating frame buffer failed. Retrying...\n");
> +		}
> +		retries++;
> +	}
>  	if (fb_fd < 0) {
>  		weston_log("Creating frame buffer failed.\n");
>  		goto err;

Hi,

I hate sleeps. I'd really want an explanation in the commit message on
why this cannot be fixed properly at all, and you need a delay to have
it work.

It is possible there is no better way, but I would like to understand
why first.

For instance, should reenable() be waiting for some sort of udev
advertisement of the fb device? Is there any event from udev to signal
this?

Do you have systemd involved in your use case? Could this be solved with
systemd or logind? Or should we let weston-launch open the fb device
instead?

I'm CC'ing David, maybe he might have an idea?


Thanks,
pq