public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Eger <eger@theboonies.us>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver
Date: Tue, 17 Feb 2004 09:57:47 +1100	[thread overview]
Message-ID: <1076972267.3649.81.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402161420390.30742@home.osdl.org>


> I don't see that anybody else can possibly care. In fact, I doubt even 
> vgacon actually cares. It's just a regular unblank, but with the 
> information that we came from graphics mode. I think it would be cleaner 
> to add a new parameter to the "con_blank()" function, which would also 
> cause compiler warnings for non-converted consoles, which is good.
> 
That's what I was talking about: what drivers should I convert :) On
PPC, I don't build things like vgacon etc... Anyway, patch coming soon.

Note that a mode_switch separate from blank would have made sense
too some way...

> Right now we encode multiple things into the one existing "blank"
> parameter, which is just confusing. We have
> 
>    -1: /* enter graphics mode (just save whatever state we need to save, 
>           possibly clear state to be polite) */

And make sure accel engine is idle...

>     0: /* regular unblank (restore screen contents, enable backlight) */
>     1: /* regular blank */
>     2..x: VESA blank type x-1.
> 
> and I'd suggest that the new case would be the "regular unblank", but with 
> the new parameter saying that we're coming from graphics mode. For 
> example, I don't think the vgacon_blank() function would change at _all_ 
> (except for the new parameter that it would just ignore).
>
> As far as I can tell, fbcon is the _only_ thing that wouldn't ignore the 
> new information, exactly because fbcon might want to reset things like the 
> graphics engine.

Yup.

Ben.



  reply	other threads:[~2004-02-16 22:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.50L0.0402160411260.2959-100000@rosencrantz.theboonies.us>
2004-02-16  4:01 ` 2.6.3-rc3 radeonfb: Problems with new (and old) driver Benjamin Herrenschmidt
2004-02-16 17:56   ` Linus Torvalds
2004-02-16 21:50     ` Benjamin Herrenschmidt
2004-02-16 22:13       ` Linus Torvalds
2004-02-16 22:18         ` Benjamin Herrenschmidt
2004-02-16 22:30           ` Linus Torvalds
2004-02-16 22:57             ` Benjamin Herrenschmidt [this message]
2004-02-16 23:09               ` Linus Torvalds
2004-02-16 23:31                 ` Benjamin Herrenschmidt
2004-02-16 23:49                   ` Linus Torvalds
2004-02-17  0:04                     ` Benjamin Herrenschmidt
2004-02-15  6:16 [PATCH] Remove debug cruft from via-pmu.c driver Benjamin Herrenschmidt
2004-02-15 18:02 ` 2.6.3-rc3 radeonfb: Problems with new (and old) driver Mike Houston
2004-02-15 21:01   ` Petr Vandrovec

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=1076972267.3649.81.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=eger@theboonies.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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