From: Knut Petersen <Knut_Petersen@t-online.de>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] Detaching fbcon
Date: Sun, 11 Jun 2006 15:25:43 +0200 [thread overview]
Message-ID: <448C19D7.5010706@t-online.de> (raw)
In-Reply-To: <44856223.9010606@gmail.com>
Antonino A. Daplas wrote:
>Overall, this feature is a great help for developers working in the
>framebuffer or console layer.
>
Well, it has long been possible to load / unload framebuffer hardware
drivers using the vfb module as an intermediate step. It even has been
possible to load both vesafb and another framebuffer driver for the same
hardware, to assign vesafb to tty{a,b,c..}, the other framebuffer driver
to tty{m,n,o...} and to switch between those drivers using the usual
keyboard hotkeys.
So the main addition of your patchset is the possibility to replace
fbcon and helper modules, a nice feature I missed in the past.
But should a framebuffer driver terminate and leave the hardware in
graphics mode or in text mode? Up to now that was not a real question,
as we all knew that another framebuffer driver would take over control.
With your patches it is possible that a user really wants to switch to text
mode and to remove the complete fbcon layer. So should we switch the
hardware to text mode upon unloading a framebuffer driver?
Maybe unbinding of the framebuffer console is not followed by an
unloading of the framebuffer module. You tell us that an
"echo 1 > /sys/class/graphics/fbcon/detach" has the simple effect of a
corrupt display unless vbetools is used. No, that´s not ok.
Think about an echo 1 > /sys/class/graphics/fbcon/detach inside of an
xterm session.
I think we need new fbops, eg.
int fb_fbcon_unbind(...)
int fb_fbcon_bind(...)
If these are not implemented, unbinding is not allowed. Any requests to do
so will be ignored.
If these are implemented the fbcon_unbind() function of the framebuffer
driver is called first. If it does not return an error, unbinding can
continue,
otherwise it fails.
With implemented fb_restore_state() and fb_save_state() fbops the
framebuffer
driver knows best about the current hardware state and can act in a way that
there is no need for vbetools & friends as well as no possibility of fatal
interactions with X.
Unbinding requests should only be honored if the framebuffer driver decides
that it is safe. Don´t enable it by default.
cu,
knut
next prev parent reply other threads:[~2006-06-11 13:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-06 11:08 [PATCH 0/7] Detaching fbcon Antonino A. Daplas
2006-06-06 16:10 ` Jon Smirl
2006-06-06 16:19 ` Jon Smirl
2006-06-06 19:45 ` Antonino A. Daplas
2006-06-06 21:00 ` Jon Smirl
2006-06-06 21:39 ` Dave Airlie
2006-06-06 21:55 ` Jon Smirl
2006-06-06 23:15 ` Antonino A. Daplas
2006-06-06 23:17 ` Antonino A. Daplas
2006-06-06 19:45 ` Antonino A. Daplas
2006-06-11 13:25 ` Knut Petersen [this message]
2006-06-11 20:57 ` Antonino A. Daplas
2006-06-12 7:49 ` Knut Petersen
2006-06-12 12:17 ` Antonino A. Daplas
2006-06-12 12:25 ` Geert Uytterhoeven
2006-06-12 13:28 ` Michal Suchanek
2006-06-12 14:15 ` [Linux-fbdev-devel] " Antonino A. Daplas
2006-06-12 16:44 ` Michal Suchanek
2006-06-12 14:20 ` [Linux-fbdev-devel] " Michel Dänzer
2006-06-12 16:46 ` Michal Suchanek
2006-06-12 17:20 ` Michel Dänzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=448C19D7.5010706@t-online.de \
--to=knut_petersen@t-online.de \
--cc=akpm@osdl.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).