[Dri-devel] Re: [PATCH] Savage streams re-work

2004-03-21 Thread Felix Kühling
On the Savage IX it freezes now, when the 3D window gets too close to
the bottom of the screen. There is an extra allocation of 128kb at the
end of the frame buffer that is not included in RamNeedeFor3D. It
doesn't seem to be used though.

Also the computation of the HW cursor location is off by one.

The attached patch fixes these problems on the SavageIX. It also removes
a few obviously useless lines of code.

Finally I wonder why the case for disableCOB looks pretty much the same
as the case with COB enabled. I guess the cobIndex will be ignored
later, so setting it doesn't do any harm at least. But do we really have
to allocate those 128KB?

Regards,
  Felix

On Sat, 20 Mar 2004 09:07:55 -0800 (PST)
Alex Deucher [EMAIL PROTECTED] wrote:

[snip]

--- ./savage_driver.c.~1.16.~   2004-03-20 23:06:21.0 +0100
+++ ./savage_driver.c   2004-03-21 03:01:09.0 +0100
@@ -775,7 +775,6 @@
 char *s = NULL;
 unsigned char config1, m, n, n1, n2, sr8, cr66 = 0, tmp;
 int mclk;
-int endfb;
 vgaHWPtr hwp;
 int vgaCRIndex, vgaCRReg;
 pointer ddc;
@@ -1313,9 +1312,6 @@
 #endif
 
 #if 1 /* S3's code */
-/* reserved 128K for HWICON and DSTN buffer */
-endfb = psav-videoRambytes - 0x2 - 1;
-
 /*
  * If we're running with acceleration, compute the command overflow
  * buffer location.  The command overflow buffer must END at a
@@ -1325,7 +1321,6 @@
 if (psav-NoAccel) {
 psav-cobIndex = 0;
 psav-cobSize = 0;
-psav-cobOffset = endfb;
 }
 else if( ((S3_SAVAGE4_SERIES(psav-Chipset)) ||
  (S3_SUPERSAVAGE == psav-Chipset))  psav-disableCOB ) {
@@ -1335,7 +1330,6 @@
  */
 psav-cobIndex = 2;
 psav-cobSize = 0x8000  psav-cobIndex;
-psav-cobOffset = endfb - psav-cobSize;
 }
 else {
 /* We use 128kB for the COB on all other chips. */
@@ -1350,17 +1344,14 @@
} else {
psav-cobIndex = 7;
}
-psav-cobOffset = endfb - psav-cobSize;
 }
  
 /* align cob to 128k */
-psav-cobOffset = ((endfb - psav-cobSize + 1) + 0x2)  ~0x2;
-endfb = psav-cobOffset - 1;
+psav-cobOffset = (psav-videoRambytes - psav-cobSize)  ~0x1;
 
 /* The cursor must be aligned on a 4k boundary. */
-psav-CursorKByte = (endfb  10) - 4;
-endfb = (psav-CursorKByte  10) - 1;
-psav-endfb = endfb;
+psav-CursorKByte = (psav-cobOffset  10) - 4;
+psav-endfb = (psav-CursorKByte  10) - 1;
 
 #endif
 



[Dri-devel] mach64 and USE_NEW_INTERFACE

2004-03-21 Thread Dave Airlie

I've checked in the changes for the mach64 to use the new interface, I
haven't turned it on as I had to change some stuff I'm unsure off...

I've had to set
 modes-drawableType = GLX_WINDOW_BIT | GLX_PIXMAP_BIT;

the r200 just had the GLX_WINDOW_BIT ..

Apart from that, 24-bit needs looking at.. not sure I've enough RAM for it
:-)

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



---
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=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] Lockup after suspend w/ S3 savage

2004-03-21 Thread Mental Patient
Hello. I'm trying to determine a workaround/fix for a problem I'm having 
with my laptop ( an ibm thinkpad t22 ).

Whenever the laptop comes out of suspend, any DRI app (game, 
screensaver, etc) causes the screen to hang. If I happen to be on the 
network, I can ssh in and look around. But killing/restarting X doesn't 
fix the screen. The only thing that gets the screen back to a usable 
state is a reboot.

I'm using the current trunk of both the xc and mesa projects out of cvs. 
The hardware in question is :

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge 
(rev 03)
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13)

I had some problems with acpi, so I'm using apm/apmd for suspend/power 
management.

When suspending, I see the following in my logs:

== /var/log/XFree86.0.log ==
 hdsp: 1024 hbeg: 1040 hend: 1136 httl: 1312
 vdsp: 768 vbeg: 769 vend: 772 vttl: 800 flags: 5
(--) SAVAGE(0): Chose mode 117 at 75Hz.
SwitchToMode - Succeeded
(II) PM Event received: Power Status Change
(II) PM Event received: System Suspend Request
(II) PM Event received: Power Status Change
(II) PM Event received: Normal Resume System
(--) SAVAGE(0): Chose mode 117 at 75Hz.
(II) Mouse0: ps2EnableDataReporting: succeeded
== /var/log/messages ==
Mar 21 14:18:34 warpath hda: completing PM request, resume
Mar 21 14:18:34 warpath hdc: Wakeup request inited, waiting for !BSY...
Mar 21 14:18:34 warpath hdc: start_power_step(step: 1000)
Mar 21 14:18:34 warpath hdc: completing PM request, resume
Mar 21 14:18:34 warpath eth1: got resume request
Mar 21 14:18:34 warpath eth1: resetting device...
Mar 21 14:18:34 warpath eth1: uploading firmware...
Mar 21 14:18:34 warpath eth1: firmware uploaded done, now triggering 
reset...

An attempt to run one of the opengl xscreensavers yeilded the following:
== /var/log/XFree86.0.log ==
SwitchToMode - scrn: 0 clock: 36000
   hdsp: 640 hbeg: 696 hend: 752 httl: 832
   vdsp: 480 vbeg: 481 vend: 484 vttl: 509 flags: 10
Checking against clock: 78800 (78800)
 hdsp: 1024 hbeg: 1040 hend: 1136 httl: 1312
 vdsp: 768 vbeg: 769 vend: 772 vttl: 800 flags: 5
Checking against clock: 75000 (75000)
 hdsp: 1024 hbeg: 1048 hend: 1184 httl: 1328
 vdsp: 768 vbeg: 771 vend: 777 vttl: 806 flags: 10
Checking against clock: 65000 (65000)
 hdsp: 1024 hbeg: 1048 hend: 1184 httl: 1344
 vdsp: 768 vbeg: 771 vend: 777 vttl: 806 flags: 10
Checking against clock: 44900 (44900)
 hdsp: 1024 hbeg: 1032 hend: 1208 httl: 1264
 vdsp: 768 vbeg: 768 vend: 776 vttl: 817 flags: 21
Checking against clock: 57284 (57284)
 hdsp: 832 hbeg: 864 hend: 928 httl: 1152
 vdsp: 624 vbeg: 625 vend: 628 vttl: 667 flags: 10
Checking against clock: 56300 (56300)
 hdsp: 800 hbeg: 832 hend: 896 httl: 1048
 vdsp: 600 vbeg: 601 vend: 604 vttl: 631 flags: 5
Checking against clock: 49500 (49500)
 hdsp: 800 hbeg: 816 hend: 896 httl: 1056
 vdsp: 600 vbeg: 601 vend: 604 vttl: 625 flags: 5
Checking against clock: 5 (5)
 hdsp: 800 hbeg: 856 hend: 976 httl: 1040
 vdsp: 600 vbeg: 637 vend: 643 vttl: 666 flags: 5
Checking against clock: 4 (4)
 hdsp: 800 hbeg: 840 hend: 968 httl: 1056
 vdsp: 600 vbeg: 601 vend: 605 vttl: 628 flags: 5
Checking against clock: 36000 (36000)
 hdsp: 800 hbeg: 824 hend: 896 httl: 1024
 vdsp: 600 vbeg: 601 vend: 603 vttl: 625 flags: 5
Checking against clock: 61000 (61000)
 hdsp: 700 hbeg: 744 hend: 820 httl: 940
 vdsp: 525 vbeg: 526 vend: 532 vttl: 541 flags: 37
Checking against clock: 54000 (54000)
 hdsp: 640 hbeg: 664 hend: 720 httl: 844
 vdsp: 512 vbeg: 512 vend: 514 vttl: 533 flags: 37
Checking against clock: 36000 (36000)
 hdsp: 640 hbeg: 696 hend: 752 httl: 832
 vdsp: 480 vbeg: 481 vend: 484 vttl: 509 flags: 10
(--) SAVAGE(0): Chose mode 111 at 85Hz.
SwitchToMode - Succeeded
It hangs forever here. Nothing brings back the display.

Is there a way to suspend/re-init the agp driver when entering/exiting 
suspend mode? This problem seems to occur even if I suspend outside of X.

If there's any more info I can provide, or a workaround I can try, I'd 
be grateful. For now, I simply do not set any opengl screensavers, and 
reboot after unsuspending before using DRI.



--
Mental ([EMAIL PROTECTED])
Know what I pray for? The strength to change what I can, the inability
to accept what I can't and the incapacity to tell the difference.
-- Calvin
GPG public key: http://www.neverlight.com/pas/Mental.asc



Re: [Dri-devel] Lockup after suspend w/ S3 savage

2004-03-21 Thread Alex Deucher

--- Mental Patient [EMAIL PROTECTED] wrote:
 Hello. I'm trying to determine a workaround/fix for a problem I'm
 having 
 with my laptop ( an ibm thinkpad t22 ).
 
 Whenever the laptop comes out of suspend, any DRI app (game, 
 screensaver, etc) causes the screen to hang. If I happen to be on the
 
 network, I can ssh in and look around. But killing/restarting X
 doesn't 
 fix the screen. The only thing that gets the screen back to a usable 
 state is a reboot.
 
 
 I'm using the current trunk of both the xc and mesa projects out of
 cvs. 
 The hardware in question is :
 
 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
 bridge 
 (rev 03)
 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP
 bridge 
 (rev 03)
 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV
 (rev 13)
 
 
 I had some problems with acpi, so I'm using apm/apmd for
 suspend/power 
 management.
 
 When suspending, I see the following in my logs:
 
 == /var/log/XFree86.0.log ==
   hdsp: 1024 hbeg: 1040 hend: 1136 httl: 1312
   vdsp: 768 vbeg: 769 vend: 772 vttl: 800 flags: 5
 (--) SAVAGE(0): Chose mode 117 at 75Hz.
 SwitchToMode - Succeeded
 (II) PM Event received: Power Status Change
 (II) PM Event received: System Suspend Request
 (II) PM Event received: Power Status Change
 (II) PM Event received: Normal Resume System
 (--) SAVAGE(0): Chose mode 117 at 75Hz.
 (II) Mouse0: ps2EnableDataReporting: succeeded
 
 == /var/log/messages ==
 Mar 21 14:18:34 warpath hda: completing PM request, resume
 Mar 21 14:18:34 warpath hdc: Wakeup request inited, waiting for
 !BSY...
 Mar 21 14:18:34 warpath hdc: start_power_step(step: 1000)
 Mar 21 14:18:34 warpath hdc: completing PM request, resume
 Mar 21 14:18:34 warpath eth1: got resume request
 Mar 21 14:18:34 warpath eth1: resetting device...
 Mar 21 14:18:34 warpath eth1: uploading firmware...
 Mar 21 14:18:34 warpath eth1: firmware uploaded done, now triggering 
 reset...
 
 An attempt to run one of the opengl xscreensavers yeilded the
 following:
 == /var/log/XFree86.0.log ==
 SwitchToMode - scrn: 0 clock: 36000
 hdsp: 640 hbeg: 696 hend: 752 httl: 832
 vdsp: 480 vbeg: 481 vend: 484 vttl: 509 flags: 10
 Checking against clock: 78800 (78800)
   hdsp: 1024 hbeg: 1040 hend: 1136 httl: 1312
   vdsp: 768 vbeg: 769 vend: 772 vttl: 800 flags: 5
 Checking against clock: 75000 (75000)
   hdsp: 1024 hbeg: 1048 hend: 1184 httl: 1328
   vdsp: 768 vbeg: 771 vend: 777 vttl: 806 flags: 10
 Checking against clock: 65000 (65000)
   hdsp: 1024 hbeg: 1048 hend: 1184 httl: 1344
   vdsp: 768 vbeg: 771 vend: 777 vttl: 806 flags: 10
 Checking against clock: 44900 (44900)
   hdsp: 1024 hbeg: 1032 hend: 1208 httl: 1264
   vdsp: 768 vbeg: 768 vend: 776 vttl: 817 flags: 21
 Checking against clock: 57284 (57284)
   hdsp: 832 hbeg: 864 hend: 928 httl: 1152
   vdsp: 624 vbeg: 625 vend: 628 vttl: 667 flags: 10
 Checking against clock: 56300 (56300)
   hdsp: 800 hbeg: 832 hend: 896 httl: 1048
   vdsp: 600 vbeg: 601 vend: 604 vttl: 631 flags: 5
 Checking against clock: 49500 (49500)
   hdsp: 800 hbeg: 816 hend: 896 httl: 1056
   vdsp: 600 vbeg: 601 vend: 604 vttl: 625 flags: 5
 Checking against clock: 5 (5)
   hdsp: 800 hbeg: 856 hend: 976 httl: 1040
   vdsp: 600 vbeg: 637 vend: 643 vttl: 666 flags: 5
 Checking against clock: 4 (4)
   hdsp: 800 hbeg: 840 hend: 968 httl: 1056
   vdsp: 600 vbeg: 601 vend: 605 vttl: 628 flags: 5
 Checking against clock: 36000 (36000)
   hdsp: 800 hbeg: 824 hend: 896 httl: 1024
   vdsp: 600 vbeg: 601 vend: 603 vttl: 625 flags: 5
 Checking against clock: 61000 (61000)
   hdsp: 700 hbeg: 744 hend: 820 httl: 940
   vdsp: 525 vbeg: 526 vend: 532 vttl: 541 flags: 37
 Checking against clock: 54000 (54000)
   hdsp: 640 hbeg: 664 hend: 720 httl: 844
   vdsp: 512 vbeg: 512 vend: 514 vttl: 533 flags: 37
 Checking against clock: 36000 (36000)
   hdsp: 640 hbeg: 696 hend: 752 httl: 832
   vdsp: 480 vbeg: 481 vend: 484 vttl: 509 flags: 10
 (--) SAVAGE(0): Chose mode 111 at 85Hz.
 SwitchToMode - Succeeded
 
 It hangs forever here. Nothing brings back the display.
 
 Is there a way to suspend/re-init the agp driver when
 entering/exiting 
 suspend mode? This problem seems to occur even if I suspend outside
 of X.
 
 If there's any more info I can provide, or a workaround I can try,
 I'd 
 be grateful. For now, I simply do not set any opengl screensavers,
 and 
 reboot after unsuspending before using DRI.

Unfortunately the the only DRI driver with suspend support is radeon. 
You could 

Re: [Dri-devel] Re: [PATCH] Savage streams re-work

2004-03-21 Thread Alex Deucher
--- Felix Kühling [EMAIL PROTECTED] wrote:
 On the Savage IX it freezes now, when the 3D window gets too close to
 the bottom of the screen. There is an extra allocation of 128kb at
 the
 end of the frame buffer that is not included in RamNeedeFor3D. It
 doesn't seem to be used though.
 
 Also the computation of the HW cursor location is off by one.
 
 The attached patch fixes these problems on the SavageIX. It also
 removes
 a few obviously useless lines of code.
 
 Finally I wonder why the case for disableCOB looks pretty much the
 same
 as the case with COB enabled. I guess the cobIndex will be ignored
 later, so setting it doesn't do any harm at least. But do we really
 have
 to allocate those 128KB?

I guess that's what I get for using S3's code.  Thanks for catching
these.  The patch looks good.  I don't see why we would would have to
allocate the 128K for the disable case, especially since it never even
gets written to the cob regs.  How does the attached patch look
(untested - it's basically just yours with some further cleanups and
removes the 128K allocation)?

Alex

 
 Regards,
   Felix
 
 On Sat, 20 Mar 2004 09:07:55 -0800 (PST)
 Alex Deucher [EMAIL PROTECTED] wrote:
 
 [snip]


__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

cobfixes.diff
Description: cobfixes.diff


Re: [Dri-devel] Switching dri over to new drm tree

2004-03-21 Thread Dave Airlie
  anything after that did not have working direct rendering.  But since the
  snaps are generated from the head...  I've seen this error posted here
  before but I haven't seen a resolution, maybe I missed it.

 Ian, does this look at all like it could be related to your libGL, etc.
 changes?

yup if I just build HEAD and install it it works fine.. so it looks like a
snapshot + older libGL issue.. I'm not really setup for testing that sorta
thing here... I've always been a build HEAD and install :-)

Dave.
-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



---
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=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] [Bug 314] 3D support for Radeon IGP chips

2004-03-21 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=314   
   

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[EMAIL PROTECTED]  |
 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-03-21 18:48 ---
This bug has been obsolete for a while. Get the code from DRI CVS. Most if not
all of the patches attached to this bug are incomplete and not expected to work
with the current DRM.   
   
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
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=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Switching dri over to new drm tree

2004-03-21 Thread Ian Romanick
ajax wrote:

X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  144 (XFree86-DRI)
  Minor opcode of failed request:  5 ()
  Value in failed request:  0x1e2
  Serial number of failed request:  30
  Current serial number in output stream:  30

This was installed from a snapshot.  Snapshots up to March 2 worked, anything 
after that did not have working direct rendering.  But since the snaps are 
generated from the head...  I've seen this error posted here before but I 
haven't seen a resolution, maybe I missed it.
As far as I know, that was fixed on 3/13.  I tested my fix with two 
different drivers (one that uses the new interface and one that doesn't) 
from both the DRI tree and XFree86 (post 4.4.0) CVS.  I don't have time 
to deal with it now.  Sorry.

http://marc.theaimsgroup.com/?l=dri-develm=107914598527974w=2



---
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=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel