On 6/12/06, Antonino A. Daplas [off-list ref] wrote:

Michal Suchanek wrote:

quoted

On 6/12/06, Antonino A. Daplas [off-list ref] wrote:

quoted

quoted

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.

quoted

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