linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 12 Jun 2006 09:49:50 +0200	[thread overview]
Message-ID: <448D1C9E.7050606@t-online.de> (raw)
In-Reply-To: <448C83AD.9060200@gmail.com>

Hi Tony,

>We'll use fb_restore_state and fb_save_state if available, yes, but I don't
>think we need to implement unbind and bind.  For one, as Jon and Andrew
>has pointed out, drivers should have no concept of binding. (That's why the
>patch has escalated to VT binding).
>
>  
>
Well, it does not matter if it´s the fbcon or vt layer that does the
binding. I agree with Jon and Andrew that vt binding is the better
way.

>And why force drivers to have an fb_restore_state/fb_save_state just to
>unbind/bind?  This is going to penalize 10's of drivers that don't need
>it.  Just make this feature an experimental kconfig option, or make this
>available as a boot option.
>  
>
An experimental feature could be "Allow all framebuffer drivers to unbind".
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.

I suggest to add the fb_unbinding / fb_binding fbops and to only allow
unbinding if we know that it will not leave the video hardware in a state
that is unusable for proper operation.

If there is nothing to be done inside those two fbops, they simply return
0.

Other framebuffer drivers set the hardware to a state that is completely
unusable by a textmode console and that is incompatible with X. These
might need to know if X is active to decide if unbinding makes any sense at
that specific moment. They can know that by adding the save/restore_state
fbops. No, I don´t think that the save/restore_state fbops should be 
required
for unbinding operations, I think you misunderstood me in that place.

cu,
 knut

  reply	other threads:[~2006-06-12  7:48 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
2006-06-11 20:57   ` Antonino A. Daplas
2006-06-12  7:49     ` Knut Petersen [this message]
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=448D1C9E.7050606@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).