--- Steve Holland <[EMAIL PROTECTED]> wrote: > My apologies for being horribly slow to respond. > The mode switching problem occurs with bpp=24 (bpp=32 didn't work at > all > for me). Hardware is SuperSavage/IXC SDR (ThinkPad T23). > I do get the message: > (==) SAVAGE(0): Using video BIOS to set modes > But I get this regardless of whether I have the UseBIOS option set or > not in XF86Config. > > At this point the display always seems to be corrupted (bad mode) if > I > select 24 bpp (before it worked fine until I started tuxracer). > > The corrupted display shows the right colors, but the pixel > arrangement > is off. What should be the vertical left/right border of the screen > is > actually at a 30 degree angle to the horizontal, wrapping around from > left to right (goes down and to the right). Moving the mouse down > makes > the pixels representing the pointer go down and to the right. Moving > the > mouse to the right makes them go up and to the right. > > I have also noticed a problem with loading the kernel driver. > Even after I added: > /sbin/modprobe agpgart > /sbin/modprobe savage > to /etc/rc.d/rc.local, the X server did not start with DRI enabled. > The reason seems to be that some time is needed between the > 'modprobe agpgart' and the 'modprobe savage'. > Changing rc.local to: > /sbin/modprobe agpgart > sleep 1 > /sbin/modprobe savage > sleep 1 > > Solved the problem and now I get the message > kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: > SuperSavage > IX/C SDR > on bootup. > > HOWEVER, I noticed general system instability (random lockups) > when operating in the original case, that is when both agpgart.o > and savage.o were loaded, but savage not properly initialized.
Steve, If you haven't already please try again with the DRI/mesa trunks rather than savage-2-0-0-branch. There have been quite a few updates since the branch was merged. Also how much videoram does your card have? You will need almost 17 MB for 1400x1050x24bpp (24bpp is really 32 bpp as far as the driver is concerned). The new driver disables the DRI if there is not enough ram. Before my changes to check available videoram, the front/back/depth buffers would be arbitrarily allocated and if you only have 16MB of video ram, the back buffer would overflow into the front buffer. Alex > > Thanks, > Steve > > > On Fri, 2004-02-27 at 15:21, Alex Deucher wrote: > > -- Felix Khling <[EMAIL PROTECTED]> wrote: > > > Forwarding to dri-devel. Some of this (mode switching problem) > looks > > > like a 2D issue. Alex? > > > > I'll have to double check, but I don't recall having any problems > with > > mode switching in tuxracer last time I played with it. Steve, what > > chip are you running on? bios or non-bios mode setting? it also > might > > be an issue with the backbuffer overwriting the front buffer. see > > below. > > > > > > > > I don't know why drawpix to the backbuffer works for me but not > for > > > you. > > > I'll look into this some time. But it's no priority right now. > > > > > > Hmm, I was just wondering if you have enough memory for 3D in > 32bpp > > > mode > > > with 1400x1050. Front, back and depth buffers need a bit more > than 16 > > > MB > > > in this mode. If your chip uses shared memory you'd have to > reserve > > > 32MB > > > of shared memory for it to work. > > > > One of these days, maybe this weekend, I'll put a quick check in > the > > buffer allocation code in savage_accel.c to make sure there is > enough > > memory for 3D in the current mode/depth. <OT> I haven't really > been > > testing the trunk to much lately, as I've been messing around with > > duoview support. I've just about got it working. I can set up the > > second controller and dot clock, I just can't get it to produce a > > signal. it's driving me nuts...</OT> > > > > Alex > > > > > > > > Regards, > > > Felix > > > > > > Begin forwarded message: > > > > > > Date: Fri, 27 Feb 2004 11:59:22 -0600 > > > From: Steve Holland <[EMAIL PROTECTED]> > > > To: Felix Khling <[EMAIL PROTECTED]> > > > Subject: Re: [Dri-devel] savage-2-0-0 test notes > > > > > > > > > I tested it with a fresh copy from the trunk (effective tuesday), > and > > > have the same problems. > > > > > > Here are some PNG's of the results from drawpix: > > > 16 bit display, drawing to back buffer: > > > http://69.5.151.193/~sdh4/drawpix16bit.png > > > drawing to front buffer: > > > http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png > > > 24 bit display drawing to back buffer: > > > http://69.5.151.193/~sdh4/drawpix24bit.png > > > (24 bit display drawing to front buffer was similar to 16->front > > > buffer) > > > > > > I also noticed problems when switching video modes on a 24 bit > > > display. > > > For example, running tuxracer would get the display parameters > wrong, > > > > > > leading to an incomprehensible display (even after quitting). > > > > > > Thanks, > > > Steve > > > > > > > > > > > > On Tue, 2004-02-24 at 07:13, Felix Khling wrote: > > > > On Mon, 23 Feb 2004 14:18:53 -0600 > > > > Steve Holland <[EMAIL PROTECTED]> wrote: > > > [snip] > > > > > > __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
