Menu
▾
▴
linux-fbdev-devel
|
From: Paul M. <pa...@sa...> - 2002-12-10 22:31:29
|
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;
|
|
From: Benjamin H. <be...@ke...> - 2002-12-10 23:08:10
|
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. |
|
From: James S. <jsi...@in...> - 2002-12-11 05:26:42
|
> 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. |
|
From: David S. M. <da...@re...> - 2002-12-11 08:16:52
|
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. |
|
From: James S. <jsi...@in...> - 2002-12-11 14:24:13
|
> 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. |
|
From: David S. M. <da...@re...> - 2002-12-11 20:47:58
|
From: James Simmons <jsi...@in...> 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 da...@re... |
|
From: Alan C. <al...@lx...> - 2002-12-11 21:01:57
|
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. |
|
From: Geert U. <ge...@li...> - 2002-12-13 09:00:17
|
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 -- ge...@li...
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
|
|
From: Alan C. <al...@lx...> - 2002-12-13 09:53:35
|
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 |
|
From: Geert U. <ge...@li...> - 2002-12-22 13:43:09
|
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 -- ge...@li...
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
|
|
From: Pavel M. <pa...@uc...> - 2002-12-13 12:04:03
|
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? |
|
From: Paul M. <pa...@sa...> - 2002-12-11 21:06:52
|
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. |
|
From: Stefan R. <st...@su...> - 2002-12-15 11:45:33
|
* James Simmons <jsi...@in...> [021211 16:16]: > > > 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. One thing I was wondering: Is there a proper way to make sure that acceses to the framebuffer end up only on one specific virtual console? I have an application that runs on one virtual console, but when switching I do not want the screen to be trashed by writing just into the framebuffer memory. My solution was to check whether the current console is the console the application started on, but this looks a bit bloated to me and I had some weird effects when switching to X and back - like one frame still got painted into graphics memory while X was already shown. Any ideas? Stefan -- Laissez Faire Economics is the theory that if each acts like a vulture, all will end as doves. |
|
From: Geert U. <ge...@li...> - 2002-12-13 08:52:08
|
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 -- ge...@li...
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
|
|
From: Antonino D. <ad...@po...> - 2002-12-11 09:55:50
|
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 |
|
From: James S. <jsi...@in...> - 2002-12-11 14:54:50
|
> 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. |
Thanks for helping keep SourceForge clean.
X