Re: [Linux-fbdev-devel] [PATCH 0/7] Detaching fbcon

[Knut Petersen <Knut_Petersen@t-online.de>]

Hi Tony,

> We'll use fb_restore_state and fb_save_state if available, yes, but I don't
> think we need to implement unbind and bind.  For one, as Jon and Andrew
> has pointed out, drivers should have no concept of binding. (That's why the
> patch has escalated to VT binding).
>
>  
Well, it does not matter if it´s the fbcon or vt layer that does the
binding. I agree with Jon and Andrew that vt binding is the better
way.

> And why force drivers to have an fb_restore_state/fb_save_state just to
> unbind/bind?  This is going to penalize 10's of drivers that don't need
> it.  Just make this feature an experimental kconfig option, or make this
> available as a boot option.
>  
An experimental feature could be "Allow all framebuffer drivers to unbind".
Non-experimental behaviour really should be to allow unbinding
only if the framebuffer driver allows it. The fbcon and vt layer simply
does not know if it is safe, and thus they have to interrogate the
hardware layer that knows the answer.

Your current proposal is to allow unbinding and removal of the framebuffer
driver and the fbcon layer, no matter what the result will be. I don´t think
that this is ok.  There is  John User that tries to switch to text mode, and
he will complain if it does leave his hardware in an unusable state.

I suggest to add the fb_unbinding / fb_binding fbops and to only allow
unbinding if we know that it will not leave the video hardware in a state
that is unusable for proper operation.

If there is nothing to be done inside those two fbops, they simply return
0.

Other framebuffer drivers set the hardware to a state that is completely
unusable by a textmode console and that is incompatible with X. These
might need to know if X is active to decide if unbinding makes any sense at
that specific moment. They can know that by adding the save/restore_state
fbops. No, I don´t think that the save/restore_state fbops should be 
required
for unbinding operations, I think you misunderstood me in that place.

cu,
knut
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/