Title: domeus
system message
Hello [EMAIL PROTECTED],
thanks for your interest in the group Integrated
On Fri, 2003-06-13 at 22:01, Andreakis, Dean (MED) wrote:
>
> I went ahead and commented out the dri section and the Load "dri", Load
> "GLcore" and Load "glx" lines in the "Module" section of XF86Config-4 to
> try and prevent the DRI drivers from loading but I still see the same
> messages in the
It's not the DRI per se... it's the radeon memory manager. it attempts
to statically allocate offscreen memory for use by the DRI, pixmaps,
etc. It has no effect on modes, so you can safely ignore it.
Alex
--- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote:
> Alex,
>
> I went ahead and comm
Alex,
I went ahead and commented out the dri section and the Load "dri", Load
"GLcore" and Load "glx" lines in the "Module" section of XF86Config-4 to
try and prevent the DRI drivers from loading but I still see the same
messages in the XF86 log file. Maybe I need to do something else to stop
DRI
this is from the DRI (front, back, and depth buffers) not the 2D driver
I think.
Alex
--- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote:
>
> (WW) RADEON (0): Static buffer allocation failed -- need at least
> 9216
> kB video memory
> (II) RADEON (0): Memory manager initialzed to (0,0) (10124
Ben,
Thanks again. I see the section in radeonfb.c you mentioned below:
You are probably hitting this:
>
> if ((var->xoffset + var->xres > var->xres_virtual)
> || (var->yoffset + var->yres > var->yres_virtual))
>return -EINVAL;
>
> In radeonfb fb_pan_display()
It's in the libvbe.a module. We'll probably need to see the
/var/log/XFree86.0.log to say more about why that's not resolved.
It's usually because the driver didn't request that it be loaded,
or if it crashes before then for some reason you often see messages
about unresolved symbols when the s
On Fri, 2003-06-13 at 17:08, Andreakis, Dean (MED) wrote:
> Given this result I tried comparing the sections of code in the kernel
> fbdev driver and the XF86 radeon driver that sets up the PLL and there
> was just a few minor diff's in the default min/max values. I went ahead
> and changed these
Ben,
Thanks for the information. I used fbset -x and updated XF86Config-4
accordingly.
All of the test results from my original post were without using the
kernel fbdev driver. I just now went ahead and added Option "UseFBDev"
to the lcd-related device section in XF86Config-4 and set BusID to
0:1
Can you check if the vbe module is loaded (and not unloaded) at this point?
Better yet, post your log file.
Egbert.
Alex Deucher writes:
> I had this problem as well at one point when I was messing with the
> savage driver. What was weird was I hadn't messed with any of the vbe
> stuff. I t
On Fri, 2003-06-13 at 00:10, Alex Deucher wrote:
> there are alot of issues with dualhead and LCDs on PPC. I believe the
> fix is to use fbdev, but I'm not sure anyone has gotten dualhead to
> work yet. check the archives from last month.
I had it working on the M6 a while ago, I haven't yet tri
> hing is ok.
>
> 2. On the iBook if I set both BusID's in both device sections to 0:10:0
> then X won't startup even though this is the ID reported by lspci for
> the ATI chip. If I just set the BusID in the device section associated
> with the external CRT to 0:10:0 then X will start and the co
I had this problem as well at one point when I was messing with the
savage driver. What was weird was I hadn't messed with any of the vbe
stuff. I think it ended up being a bad pointer reference or something
like that. also, if you are attempting to mess with programming
dualhead, you need to tu
13 matches
Mail list logo
