Thread (67 messages) 67 messages, 8 authors, 2004-04-30

Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-)

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-04-28 08:41:11

Possibly related (same subject, not in this thread)

On Wed, 28 Apr 2004, Benjamin Herrenschmidt wrote:
quoted
No. Look the logic should go from the upper VT layer to the lower driver
to accomplish something. Not the reverse.

struct vc_data -> native console driver structure --> fbdev
But the upper VT layer has no clue about what a graphic mode can be and
we know well enough that we _need_ to be able to enforce graphics mode
or want to play with them by manipulating var structures, without losing
the console.

Your logic is only ever valid once every single fbdev is capable of
doing proper mode management & validation. And even then, there isn't
a 1:1 relationchip between a mode and an fbcon size.
quoted
Not.

fbdev --> native console driver --> struct vc_data.

This was the way it uses to be. If this is the case then I suggest we
write our own vt.c and vt_ioctl.c for the fbcon layer. We shouldn't even
use struct vc_data then. In fact each fbdev driver should be independent
console drivers. That is how 2.4.X was. Each driver was nearly its own
console driver. We need to go one way or the other.
I agree we need to go away and I'm not proposing adding anything to
fb_info nor whatever in this regard. It has to be all self-contained
in the console subsystem, that is fbcon. And we already have a data
structure holding per-console fbcon-specific data, it's called
struct display.
Agreed. We need a per-VT var.

The way I see it (and have always seen it), fbcon implements a text console _on
top of_ fbdev, just like vgacon implements a text console on top of the VGA
hardware. Not the other way around!

You give fbcon the number of columns and rows, and a font, and it will build a
text console using the current var (of the VT).

<sidenote>
In extremis, this means I wouldn't have a problem if you use stty to set a
80x25 console with a 8x16 font on a 1280x1024 screen, and get text in the
upper left 640x400 corner only. Or try a 160x100 console on a 640x480 screen,
of which only 80x32 characters are visible.

This would IMHO be much more logical than the way it is now.
</sidenote>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help