All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.