I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
video chip (ID 0x4c49 or LI). With the patch below, atyfb compiles
and seems to mostly work. However, I didn't see any penguin on boot.
Instead the top inch or so of the screen was just black.
X seems to be running just fine. I have 'Option "UseFBDev"' in my
/etc/X11/XF86Config-4. What doesn't work is changing VTs from X to a
text console. If I press ctrl-alt-F1, for instance, the colormap
changes but I don't see anything get redrawn. The screen looks just
like what I had in X but with the altered colormap. If I then press
alt-F7, it switches back to X and X redraws the screen properly and
restores its colormap.
The other worrying thing is that on two occasions now the machine has
oopsed in free_block(), called from reap_timer_fnc(), because it has
dereferenced a bogus pointer value. When I look at the memory that it
read the pointer from, it looks like a console screen buffer, that is,
the bytes are alternately 0x07 and ascii characters that look like a
login prompt. This happened when waking the machine up from sleep and
when exiting X. It sounds to me like you are freeing a console screen
buffer and then continuing to use it.
The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
work and I don't believe anyone has ever used it.
I have also tried aty128fb with some local patches to get it to
compile for my G4 powerbook. It also doesn't draw the penguin, and it
oopses when X starts, for some reason.
Regards,
Paul.
diff -urN linux-2.5/drivers/video/aty/atyfb_base.c pmac-2.5/drivers/video/aty/atyfb_base.c
--- linux-2.5/drivers/video/aty/atyfb_base.c 2002-12-10 15:29:52.000000000 +1100
+++ pmac-2.5/drivers/video/aty/atyfb_base.c 2002-12-11 09:16:11.000000000 +1100
@@ -70,7 +70,7 @@
#ifdef __powerpc__
#include <asm/prom.h>
-#include <video/macmodes.h>
+#include "../macmodes.h" /* XXX relative include, yuck */
#endif
#ifdef __sparc__
#include <asm/pbm.h>
@@ -84,9 +84,6 @@
#ifdef CONFIG_BOOTX_TEXT
#include <asm/btext.h>
#endif
-#ifdef CONFIG_NVRAM
-#include <linux/nvram.h>
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
@@ -226,14 +223,9 @@
#endif
#ifdef CONFIG_PPC
-#ifdef CONFIG_NVRAM_NOT_DEFINED
-static int default_vmode __initdata = VMODE_NVRAM;
-static int default_cmode __initdata = CMODE_NVRAM;
-#else
static int default_vmode __initdata = VMODE_CHOOSE;
static int default_cmode __initdata = CMODE_CHOOSE;
#endif
-#endif
#ifdef CONFIG_ATARI
static unsigned int mach64_count __initdata = 0;
@@ -1412,16 +1404,16 @@
static int aty_sleep_notify(struct pmu_sleep_notifier *self, int when)
{
struct fb_info *info;
- struct atyfb_par *par = (struct atyfb_par *) info->fb.par;
+ struct atyfb_par *par;
int result;
result = PBOOK_SLEEP_OK;
for (info = first_display; info != NULL; info = par->next) {
- struct fb_fix_screeninfo fix;
int nb;
- nb = fb_display[fg_console].var.yres * info->fix.line_length;
+ par = (struct atyfb_par *) info->par;
+ nb = info->var.yres * info->fix.line_length;
switch (when) {
case PBOOK_SLEEP_REQUEST:
@@ -1439,7 +1431,7 @@
if (par->blitter_may_be_busy)
wait_for_idle(par);
/* Stop accel engine (stop bus mastering) */
- if (par->accel_flags & FB_ACCELF_TEXT)
+ if (info->var.accel_flags & FB_ACCELF_TEXT)
aty_reset_engine(par);
/* Backup fb content */
@@ -1844,14 +1836,6 @@
(&var, info, mode_option, 8))
var = default_var;
} else {
-#ifdef CONFIG_NVRAM
- if (default_vmode == VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
- if (default_vmode <= 0
- || default_vmode > VMODE_MAX)
- default_vmode = VMODE_CHOOSE;
- }
-#endif
if (default_vmode == VMODE_CHOOSE) {
if (M64_HAS(G3_PB_1024x768))
/* G3 PowerBook with 1024x768 LCD */
@@ -1873,10 +1857,6 @@
if (default_vmode <= 0
|| default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
- if (default_cmode == CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
-#endif
if (default_cmode < CMODE_8
|| default_cmode > CMODE_32)
default_cmode = CMODE_8;
On Tue, 2002-12-10 at 23:31, Paul Mackerras wrote:
> I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
> video chip (ID 0x4c49 or LI). With the patch below, atyfb compiles
> and seems to mostly work. However, I didn't see any penguin on boot.
> Instead the top inch or so of the screen was just black.
>
> X seems to be running just fine. I have 'Option "UseFBDev"' in my
> /etc/X11/XF86Config-4.
AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
Marc Aurele La France (maintainer of this driver) is basically allergic
to kernel fbdev support.
> What doesn't work is changing VTs from X to a
> text console. If I press ctrl-alt-F1, for instance, the colormap
> changes but I don't see anything get redrawn. The screen looks just
> like what I had in X but with the altered colormap. If I then press
> alt-F7, it switches back to X and X redraws the screen properly and
> restores its colormap.
I don't know if happened with earlier fbdev versions for you, but one
possibility is that X reconfigures the display base, and possibly more
bits of the card's internal memory map. Either fbdev should restore
that, or adapt to what X set. On R128's and radeon's, this is things
like DISPLAY_BASE_ADDR.
> The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
> work and I don't believe anyone has ever used it.
Yup, it's some wacky old pmac stuff that should be killed.
> I have also tried aty128fb with some local patches to get it to
> compile for my G4 powerbook. It also doesn't draw the penguin, and it
> oopses when X starts, for some reason.
Hrm... I'll have to test radeonfb... It worked yesteday in console (I
don't remember about the penguin) but I didn't try X.
> AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> Marc Aurele La France (maintainer of this driver) is basically allergic
> to kernel fbdev support.
:-(
> I don't know if happened with earlier fbdev versions for you, but one
> possibility is that X reconfigures the display base, and possibly more
> bits of the card's internal memory map. Either fbdev should restore
> that, or adapt to what X set. On R128's and radeon's, this is things
> like DISPLAY_BASE_ADDR.
I will have to go threw the X code to fix that :-(
> > I have also tried aty128fb with some local patches to get it to
> > compile for my G4 powerbook. It also doesn't draw the penguin, and it
> > oopses when X starts, for some reason.
>
> Hrm... I'll have to test radeonfb... It worked yesteday in console (I
> don't remember about the penguin) but I didn't try X.
No penguin. That is weird. I get the penguin on my ix86 box.
On Tue, 2002-12-10 at 22:18, James Simmons wrote:
> > AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> > Marc Aurele La France (maintainer of this driver) is basically allergic
> > to kernel fbdev support.
>
> :-(
I've always stated that the whole fbdev model was flawed, it makes
basic assumptions about how a video card's memory and registers are
accessed (ie. the programming model) and many popular cards absolutely
do not fit into that model.
> I will have to go threw the X code to fix that :-(
There is nothing to fix. You simply must restore the video state when
the last mmap() client goes away. The __sparc__ code does exactly that.
I think relying on an application that mmap's a card to perfectly
restore the state would work in a perfect world, one we do not live
in. Furthermore, fixing up the state like I am suggesting makes life
much simpler for people actually working on things like X servers and
other programs directly programming the ATI chip.
On Wed, 2002-12-11 at 04:11, Benjamin Herrenschmidt wrote:
>
> I don't know if happened with earlier fbdev versions for you, but one
> possibility is that X reconfigures the display base, and possibly more
> bits of the card's internal memory map. Either fbdev should restore
> that, or adapt to what X set. On R128's and radeon's, this is things
> like DISPLAY_BASE_ADDR.
>
Although this is in the faqs for a long time, (behavior is undefined if
fbdev is used with software that touches the video card) this is an
issue that needs to be taken into consideration. Without the set_var()
hook, fbcon will depend on the contents of info->var if there is a need
to touch the hardware or not. And switching from X to the console will
not change the var, but since X actually did touch the hardware, you
just messed up your screen or worse, crashed the hardware.
Before, most drivers just unconditionally refresh the hardware at every
switch during set_var(). I've been pointing this out for a long time
now, do we unconditionally do a check_var()/set_par() after every
console switch, or do we rely on fbdev and X cooperating with each
other? Or better, maybe fbcon has a way of knowing if the switch came
from Xfree86.
Tony
> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.
I agree that the design of the /dev/fbX interface is not the best.
Unfortunely we are stuck with it. Changing it would break userland apps.
> > I will have to go threw the X code to fix that :-(
>
> There is nothing to fix. You simply must restore the video state when
> the last mmap() client goes away. The __sparc__ code does exactly that.
I should of worded that better. Meaning I have to see what X is doing so
the fbdev driver sets the state itself better. Hm. I'm thinking about the
mmap approach versus the fb_open approach being used now.
> I think relying on an application that mmap's a card to perfectly
> restore the state would work in a perfect world, one we do not live
> in. Furthermore, fixing up the state like I am suggesting makes life
> much simpler for people actually working on things like X servers and
> other programs directly programming the ATI chip.
:-( True. We should always assume X or any userland app could be broken.
> Before, most drivers just unconditionally refresh the hardware at every
> switch during set_var(). I've been pointing this out for a long time
> now, do we unconditionally do a check_var()/set_par() after every
> console switch, or do we rely on fbdev and X cooperating with each
> other? Or better, maybe fbcon has a way of knowing if the switch came
> from Xfree86.
My next project is to fix this issue. I will be working on that today.
From: James Simmons <[email protected]>
Date: Wed, 11 Dec 2002 07:16:04 -0800 (PST)
I agree that the design of the /dev/fbX interface is not the best.
Unfortunely we are stuck with it. Changing it would break userland apps.
I totally understand. I do not suggest to break fbdev in it's current
form, too much stuff uses it.
My main point was, don't be surprised the X servers, like the ATI
driver, don't use fbdev and instead just mmap the device and simply
program it directly.
fbdev is nice, in the specific cases where the device fits the fbdev
model, because once you have the kernel bits you have X support :)
Franks a lot,
David S. Miller
[email protected]
On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> fbdev is nice, in the specific cases where the device fits the fbdev
> model, because once you have the kernel bits you have X support :)
fbdev also can't be used in some situations on x86. Deeply fascinating
things happen on some x86 processors if you execute a loop of code with
an instruction that crosses two different memory types.
James Simmons writes:
> :-( True. We should always assume X or any userland app could be broken.
I don't think we can blame X in this particular situation. When I
press ctrl-alt-F1 in X, it resets the screen to the colormap and depth
that the text console was using, but the kernel doesn't redraw the
text console screen image. (I presume it also resets the resolution,
but since I have only tried on an LCD screen I can't say for sure.)
Paul.
On 11 Dec 2002, David S. Miller wrote:
> On Tue, 2002-12-10 at 22:18, James Simmons wrote:
> > > AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> > > Marc Aurele La France (maintainer of this driver) is basically allergic
> > > to kernel fbdev support.
> >
> > :-(
>
> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.
Could you please elaborate so we have a chance to improve the model? Thanks!
In case you just mean graphics hardware (e.g. Creator) where you don't want to
provide direct access to the frame buffer, but do everything through the
acceleration engine, just set smem_start and smem_len both to 0.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On 11 Dec 2002, Alan Cox wrote:
> On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> > fbdev is nice, in the specific cases where the device fits the fbdev
> > model, because once you have the kernel bits you have X support :)
>
> fbdev also can't be used in some situations on x86. Deeply fascinating
> things happen on some x86 processors if you execute a loop of code with
> an instruction that crosses two different memory types.
Do you mean one load/store access to memory where the first and the last part
(e.g. first 2 and last 2 bytes for a 32-bit word) are to different memory types
(e.g. main RAM and video RAM on PCI)? If yes, where does that happen? If no,
can you please clarify?
(At first I thought you meant an instruction where the opcode crosses those
two memory types, but we don't put code in video RAM...)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> (At first I thought you meant an instruction where the opcode crosses those
> two memory types, but we don't put code in video RAM...)
I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
bit. So any user able to open /dev/fb can bring down such a box. Similar
things apply with early athlon and prefetching /dev/fb
Hi!
> On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> > fbdev is nice, in the specific cases where the device fits the fbdev
> > model, because once you have the kernel bits you have X support :)
>
> fbdev also can't be used in some situations on x86. Deeply fascinating
> things happen on some x86 processors if you execute a loop of code with
> an instruction that crosses two different memory types.
Sounds like cpu bug to me? What cpus are affected?
Could be worked around by pointing debug register at memory boundary?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
On 13 Dec 2002, Alan Cox wrote:
> On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> > (At first I thought you meant an instruction where the opcode crosses those
> > two memory types, but we don't put code in video RAM...)
>
> I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
> bit. So any user able to open /dev/fb can bring down such a box. Similar
> things apply with early athlon and prefetching /dev/fb
Weird... So it really crashes the box, not just throwing an exception?
On PPC you cannot use prefetching on non-cached memory, but if you try it won't
take down the whole box.
Then make sure /dev/fb is accessible by `trusted' users on such machines.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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