[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Linux-fbdev-devel] [PATCH 0/7] Detaching fbcon
    Michal Suchanek wrote:
    > On 6/12/06, Antonino A. Daplas <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-12 16:18    [W:0.029 / U:12.416 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site