Re: [PATCH 0/7] Detaching fbcon

["Michal Suchanek" <hramrach@centrum.cz>]

On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> 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?

I do not say it must be different. vgacon (or whatever is the text
console called) fails to do proper suspend/resume for me. I just use X
and think the console is flawed. However, it would be nice if I was
warned in advance that the console will die on suspend.

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

yes, that's it. And if it does not it is X problem. Not fb problem.


Thanks

Michal

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel