Re: [PATCH 0/7] Detaching fbcon

["Jon Smirl" <jonsmirl@gmail.com>]

On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > Overall, this feature is a great help for developers working in the
> >> > framebuffer or console layer.  There is not need to continually
> >> reboot the
> >> > kernel for every small change. It is also useful for regular users
> >> who wants
> >> > to choose between a graphical console or a text console without
> >> having to
> >> > reboot.
> >>
> >> Instead of the sysfs attribute, what about creating a new escape
> >> sequence that you send to the console system to detach? Doing it that
> >> way would make more sense from a stacking order. It just seems
> >> backwards to me that you ask a lower layer to detach from the layer
> >> above it. The escape sequence would also work for any console
> >> implementation, not just fbcon.
> >>
> >> If console detached this way and there was nothing to fallback to
> >> (systems without VGAcon), it would know not to try and print anything
> >> until something reattaches to it.
> >
> > Another thought, controlling whether console is attached or not is an
> > attribute of console, not of fbcon.
>
> If the console attached fbcon, then I agree that console should decide
> when to detach fbcon.  But that's not what happens, it's fbcon that
> attaches itself.
>
> It's not that you're wrong, it's just how the current vt/console layer
> works.  If someone do decide to add this feature to the vt/console layer,
> then I'm more than willing to have fbcon support that as well.

This is just kind of twisted since console increments the fbcon ref
count. Is /dev/console a real device, it that where the sysfs
attribute should go?

How is the stack maintained of what was previously bound to console?
What if I unbind fbcon on a system that doesn't have VGAcon for a backup?

--
Jon Smirl
jonsmirl@gmail.com
-
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/