On Mon, Sep 13, 2010 at 06:06:03PM +0200, Guennadi Liakhovetski wrote:
> On Mon, 13 Sep 2010, Greg KH wrote:
>
> > On Mon, Sep 13, 2010 at 09:17:04AM +0200, Guennadi Liakhovetski wrote:
> > > Hi
> > >
> > > I do not know, whether this can be a problem for any existing driver, but
> > > such an inconsistency seems like a bad idea to me anyway. The struct
> > > fb_ops::fb_release() method can be called in following ways:
> > >
> > > fbmem.c::fb_release() under the info->lock mutex (file.close("/dev/fbX")
> > > operation)
> > > fbcon.c::con2fb_release_oldinfo() under console semaphore
> > > fbcon.c::fbcon_exit() from
> > > fbcon_deinit() from
> > > vt.c::vc_deallocate() under console semaphore (has
> > > WARN_CONSOLE_UNLOCKED())
> > > bind_con_driver() under console semaphore
> > > fb_console_exit() under console semaphore
> > >
> > > I.e., it can be either called within an acquire_console_sem() /
> > > release_console_sem() block, or within a mutex_lock(&info->lock) /
> > > mutex_unlock(&info->lock) block, which looks inconsistent to me.
> > >
> > > The problem, this is causing me is, that I'd like to call the framebuffer
> > > notifier chain from my driver's fb_release() method.
> >
> > Why would you need/want to do this? If you don't do that, all should be
> > fine, right?
>
> I am implementing HDMI hot-plug support. When a new monitor is plugged in,
> I configure its physical resolution, but keep the framebuffer parameters,
> as long as there are user-space applications, using it. I have to do this,
> because currently there is no way to inform users about a changed
> geometry. Then, when the last non-console user releases the framebuffer, I
> reconfigure the framebuffer and issue a notification to inform the
> console, which then redraws the screen.
Hm, sounds valid. I really don't know the fb layer at all, sorry,
someone else is going to have to help you.
good luck,
greg k-h
--
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
