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

["Antonino A. Daplas" <adaplas@gmail.com>]

Michal Suchanek wrote:
> On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>>> 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.
>> This I disagree with you.  The view that an operation should be totally
>> done 100% within the kernel is very utopic.  We already have features that
>> require both the kernel and userspace for them to work. The nearest example
>> is suspend/resume. It's good if you can make suspend/resume work without
>> additional effort, but that's not the case. Majority of users still need
>> utilities such as vbetool.
> 
> Well, I guess that the fb driver should try to restore the original
> mode (ie text mode on x86) on unload. And it is either considered
> flawed if it doesnt or it should indicate somewhere that it does not
> know how to unload itself.

Well, failure to implement proper suspend and resume by a driver does not
stop the entire suspend/resume process, does it? Even if it results
in a blank screen. It doesn't because we have a userspace options and
tools that complements the kernel side. So why should it be any different
in this case? 

Some drivers, i810fb and rivafb, saves the hardware state on the
first open, and restores the hardware state on the last close. This
is usually sufficient for them to restore the hardware to VGA text
mode on unload. It would be nice if we can implement something like this
for all drivers, but failure to do so should not be a reason to stop the
entire process.

> I like the possibility to change X resolution using fbset (from inside
> X). I use it to correct problems caused by crashed X programs that
> change resolution. But I run X with the UseFbDev option. The X server
> would be probably quite unhappy if I removed the fb driver but since
> it uses the fb device the driver should not unload.

If X is using fbdev, then X is also holding a reference count on the
driver.  And the driver will not unload even if you try to.

Tony