Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?

2002-06-26 Thread Nicolas Aspert

Slava Polyakov wrote:

 
 2.4.19-pre10:
 
 version: 0.99
 bridge id: 0x11308086
 agp_mode: 0x1f000207
 aper_base: 0xd800
 aper_size: 64
 pg_total: 82176
 pg_system: 82176
 pg_used: 0
 entry.key : 0
 entry.key : 1
 Allocated 8 megs of GART memory
 MemoryBenchmark: 521 mb/s
 MemoryBenchmark: 606 mb/s
 MemoryBenchmark: 606 mb/s
 Average speed: 577 mb/s
 Testing data integrity (1st pass): passed on first pass.
 Testing data integrity (2nd pass): passed on second pass.

That's OK.


 2.4.19-rc1
 open: no such device
 
 apprently i815 agp support got broken in 2.4.19-rc1.  
 

Yep, looks like something went wrong. I don't see any blatant error at 
the moment...
Do you see something strange in your logs when doing a 'modprobe 
agpgart' ? And maybe also send the output of 'lspci -nv', just to be sure

a+


-- 
Nicolas Aspert  Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)
Office:  ELE 237
Phone:   +41 - 21 - 693 36 32 (LTS Office)
Fax: +41 - 21 - 693 76 00  Web: http://ltswww.epfl.ch/~aspert



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Save Big with steep declines in interest rates 0635WwjX2-556j-13

2002-06-26 Thread wixtc1117b32

Warning
Unable to process data: 
multipart/mixed;boundary==_NextPart_000_00B7_44E11C5B.D0815A74




Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?

2002-06-26 Thread Slava Polyakov

On June 26, 2002 02:29 am, Nicolas Aspert wrote:
 Slava Polyakov wrote:
  2.4.19-pre10:
 
  version: 0.99
  bridge id: 0x11308086
  agp_mode: 0x1f000207
  aper_base: 0xd800
  aper_size: 64
  pg_total: 82176
  pg_system: 82176
  pg_used: 0
  entry.key : 0
  entry.key : 1
  Allocated 8 megs of GART memory
  MemoryBenchmark: 521 mb/s
  MemoryBenchmark: 606 mb/s
  MemoryBenchmark: 606 mb/s
  Average speed: 577 mb/s
  Testing data integrity (1st pass): passed on first pass.
  Testing data integrity (2nd pass): passed on second pass.

 That's OK.

  2.4.19-rc1
  open: no such device
 
  apprently i815 agp support got broken in 2.4.19-rc1.

 Yep, looks like something went wrong. I don't see any blatant error at
 the moment...
 Do you see something strange in your logs when doing a 'modprobe
 agpgart' ? And maybe also send the output of 'lspci -nv', just to be sure

 a+

Nope... dmesg shows all the same with both kernels:

[drm] AGP 0.99 on Intel i815 @ 0xd800 64MB
[drm] Initialized radeon 1.3.0 20020521 on minor 0

and here is the lspci:

00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory 
Controller Hub (rev 04)
Subsystem: ABIT Computer Corp.: Unknown device 0407
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR-
Latency: 0
Region 0: Memory at d800 (32-bit, prefetchable) [size=64M]
Capabilities: available only to root

00:01.0 PCI bridge: Intel Corp.: Unknown device 1131 (rev 04) (prog-if 00 
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: dc00-ddff
Prefetchable memory behind bridge: d000-d7ff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B-

00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 11) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: a000-bfff
Memory behind bridge: de00-dfff
Prefetchable memory behind bridge: e000-e00f
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) 
(rev 11)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 0

00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 (rev 
11) (prog-if 80 [Master])
Subsystem: ABIT Computer Corp.: Unknown device 0407
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 0
Region 4: I/O ports at f000 [size=16]

00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) 
(rev 11) (prog-if 00 [UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 0407
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 0
Interrupt: pin D routed to IRQ 10
Region 4: I/O ports at d000 [size=32]

00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset SMBus (rev 11)
Subsystem: ABIT Computer Corp.: Unknown device 0407
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Interrupt: pin B routed to IRQ 3
Region 4: I/O ports at 5000 [size=16]

00:1f.4 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub B) 
(rev 11) (prog-if 00 [UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 0407
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 0
Interrupt: pin C routed to IRQ 11
Region 4: I/O ports at d400 [size=32]

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon QD (prog-if 00 
[VGA])

Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?

2002-06-26 Thread Nicolas Aspert

Slava Polyakov wrote:

 
 Nope... dmesg shows all the same with both kernels:
 
 [drm] AGP 0.99 on Intel i815 @ 0xd800 64MB
 [drm] Initialized radeon 1.3.0 20020521 on minor 0
 

Can you extract the agpgart bits from /var/log/messages (the drm is a 
different part) ?
It should look like :

Jun 10 17:09:09 ltslinux34 kernel: agpgart: Maximum main memory to use 
for agp memory: 203M
Jun 10 17:09:09 ltslinux34 kernel: agpgart: agpgart: Detected an Intel 
i815, but could not find the secondary device. Assuming a non-integrated 
video card.
Jun 10 17:09:09 ltslinux34 kernel: agpgart: Detected Intel i815 chipset
Jun 10 17:09:09 ltslinux34 kernel: agpgart: AGP aperture is 64M @ 0xf800

a+
-- 
Nicolas Aspert  Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread José Fonseca

Last night the script tried to build the s3virge binary snapshot for the
first time, but it failed when building a file related with the i830
driver:

gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wnested-externs -pipe -g   -fno-merge-constants 
-I../../../../../../../programs/Xserver/hw/xfree86/common 
-I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. 
-I../../../../../../../programs/Xserver/include
-I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions 
-I../.. -Ikernel  -I../../../../../../.. -I../../../../../../../exports/include 
-I/usr/X11R6/include  -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE 
-D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE  -DSHAPE -DXINPUT -DXKB 
-DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension   -DPANORAMIX  
-DRENDER  -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA 
-DXvExtension -DXFree86LOADER  -DXFree86Server -DXF86VIDMODE -DXvMCExtension  
-DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG  -DFUNCPROTO=15 
-DNARROWPROTO  -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI 
-DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA   -c xf86drmI830.c
xf86drmI830.c: In function `drmI830CleanupDma':
xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function)
xf86drmI830.c:55: (Each undeclared identifier is reported only once
xf86drmI830.c:55: for each function it appears in.)
xf86drmI830.c:55: parse error before `init'
xf86drmI830.c:57: `init' undeclared (first use in this function)
xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this function)
xf86drmI830.c: In function `drmI830InitDma':
xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function)
xf86drmI830.c:69: parse error before `init'
xf86drmI830.c:71: `init' undeclared (first use in this function)
xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this function)
make[8]: *** [xf86drmI830.o] Error 1
rm -f xf86drmS3V.o

And the packaging script fails since it can't find libdrm.a.

Max, is there any file related to i830 missing or outdated in the
s3virge branch? Or perhaps the i830 driver should be disabled on this
branch.

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Alan Hourihane

I can do the trunk merge for you, if you want to fixup the code
later.

Alan.

On Wed, Jun 26, 2002 at 11:45:51AM +0100, José Fonseca wrote:
 Last night the script tried to build the s3virge binary snapshot for the
 first time, but it failed when building a file related with the i830
 driver:
 
 gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes 
 -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g   
 -fno-merge-constants 
 -I../../../../../../../programs/Xserver/hw/xfree86/common 
 -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. 
 -I../../../../../../../programs/Xserver/include
 -I../../../../../../../exports/include/X11 
 -I../../../../../../../include/extensions -I../.. -Ikernel  
 -I../../../../../../.. -I../../../../../../../exports/include 
 -I/usr/X11R6/include  -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L 
 -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE 
 -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP  
 -DXF86BIGFONT -DDPMSExtension   -DPANORAMIX  -DRENDER  -DGCCUSESGAS 
 -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension 
 -DXFree86LOADER  -DXFree86Server -DXF86VIDMODE -DXvMCExtension  
 -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG  
 -DFUNCPROTO=15 -DNARROWPROTO  -DIN_MODULE -DXFree86Module 
 -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING 
 -DGLX_USE_DLOPEN -DGLX_USE_MESA   -c xf86drmI830.c
 xf86drmI830.c: In function `drmI830CleanupDma':
 xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function)
 xf86drmI830.c:55: (Each undeclared identifier is reported only once
 xf86drmI830.c:55: for each function it appears in.)
 xf86drmI830.c:55: parse error before `init'
 xf86drmI830.c:57: `init' undeclared (first use in this function)
 xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this 
 function)
 xf86drmI830.c: In function `drmI830InitDma':
 xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function)
 xf86drmI830.c:69: parse error before `init'
 xf86drmI830.c:71: `init' undeclared (first use in this function)
 xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this 
 function)
 make[8]: *** [xf86drmI830.o] Error 1
 rm -f xf86drmS3V.o
 
 And the packaging script fails since it can't find libdrm.a.
 
 Max, is there any file related to i830 missing or outdated in the
 s3virge branch? Or perhaps the i830 driver should be disabled on this
 branch.
 
 José Fonseca
 
 
 ---
 This sf.net email is sponsored by: Jabber Inc.
 Don't miss the IM event of the season | Special offer for OSDN members!
 JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
 ___
 Dri-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/dri-devel


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Alan Hourihane

Looks like the s3virge branch is lagging quite a bit behind the trunk.

Max - you should bring in the current trunk code into your s3virge
branch and fixup for the new drmCommand interface.

Alan.

On Wed, Jun 26, 2002 at 11:45:51AM +0100, José Fonseca wrote:
 Last night the script tried to build the s3virge binary snapshot for the
 first time, but it failed when building a file related with the i830
 driver:
 
 gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes 
 -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g   
 -fno-merge-constants 
 -I../../../../../../../programs/Xserver/hw/xfree86/common 
 -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. 
 -I../../../../../../../programs/Xserver/include
 -I../../../../../../../exports/include/X11 
 -I../../../../../../../include/extensions -I../.. -Ikernel  
 -I../../../../../../.. -I../../../../../../../exports/include 
 -I/usr/X11R6/include  -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L 
 -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE 
 -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP  
 -DXF86BIGFONT -DDPMSExtension   -DPANORAMIX  -DRENDER  -DGCCUSESGAS 
 -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension 
 -DXFree86LOADER  -DXFree86Server -DXF86VIDMODE -DXvMCExtension  
 -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG  
 -DFUNCPROTO=15 -DNARROWPROTO  -DIN_MODULE -DXFree86Module 
 -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING 
 -DGLX_USE_DLOPEN -DGLX_USE_MESA   -c xf86drmI830.c
 xf86drmI830.c: In function `drmI830CleanupDma':
 xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function)
 xf86drmI830.c:55: (Each undeclared identifier is reported only once
 xf86drmI830.c:55: for each function it appears in.)
 xf86drmI830.c:55: parse error before `init'
 xf86drmI830.c:57: `init' undeclared (first use in this function)
 xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this 
 function)
 xf86drmI830.c: In function `drmI830InitDma':
 xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function)
 xf86drmI830.c:69: parse error before `init'
 xf86drmI830.c:71: `init' undeclared (first use in this function)
 xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this 
 function)
 make[8]: *** [xf86drmI830.o] Error 1
 rm -f xf86drmS3V.o
 
 And the packaging script fails since it can't find libdrm.a.
 
 Max, is there any file related to i830 missing or outdated in the
 s3virge branch? Or perhaps the i830 driver should be disabled on this
 branch.
 
 José Fonseca
 
 
 ---
 This sf.net email is sponsored by: Jabber Inc.
 Don't miss the IM event of the season | Special offer for OSDN members!
 JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
 ___
 Dri-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/dri-devel


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

2002-06-26 Thread Keith Whitwell

Michel Dänzer wrote:
 On Wed, 2002-06-26 at 10:32, Keith Whitwell wrote:
 
CVSROOT:  /cvsroot/dri
Module name:  xc
Repository:   xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by:   keithw@usw-pr-cvs1. 02/06/26 01:32:32

Log message:
  Fog correction

 
 Out of curiosity, what was the problem?

A typo -- a malformed statement like

rmesa-hw.ctx.cmd[VTX_FOO]

which should have been

rmesa-hw.vtx.cmd[VTX_FOO]

Picked this up in the r200 driver because it was causing a malformed packet there.

Keith



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Alan Hourihane

On Wed, Jun 26, 2002 at 03:43:42PM +0200, Massimiliano Lingua wrote:
 On Wed, 2002-06-26 at 12:54, Alan Hourihane wrote:
  I can do the trunk merge for you, if you want to fixup the code
  later.
 
 Ok. It would be very nice from you. What I am supposed to do after:
 cvs update? So that code on my HD will get in sync with CVS?

Yes. Just cvs update and that will bring in the changes.

I'll do the merge now for you.

Obviously this branch won't build at all until fixed up for the
new drmCommand stuff.

Alan.


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Massimiliano Lingua

On Wed, 2002-06-26 at 12:45, José Fonseca wrote:

 
 Max, is there any file related to i830 missing or outdated in the
 s3virge branch? Or perhaps the i830 driver should be disabled on this
 branch.

There was a stale #if 0 in drm/kernel/drm.h. Fixed now. Could you please
let me know if this is enough to build things fine?

It was needed to build thing against 4.1.0. Since sometimes people ask
me for tarballs, and they do not have the latest code.


I checked config/cf/host.def too, to see it was ok. It should just build
support for s3virge. i830 was disabled both in XF86CardDrivers than
DriDrivers. Why is it being built?

Thanks,

- max lingua



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Massimiliano Lingua

On Wed, 2002-06-26 at 15:52, Alan Hourihane wrote:

 I'll do the merge now for you.
 
 Obviously this branch won't build at all until fixed up for the
 new drmCommand stuff.

I have been away a couple of months from active development. Where could
I gather more infos about drmCommand? Is it easy to understand just
peeking at the code of other drivers? What are its benefits?
 
 Alan.




---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: S3 VIRGE DRI in CVS now

2002-06-26 Thread Massimiliano Lingua

 Do you mean S3 Savage MX or is it a S3 virge MX???
 Thanks,
 JrSky.

S3 *** Virge *** MX. For Savage MX try utah. Or wait for us to code a
driver ; )

Vale,
- max





---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



RE: [Dri-devel] Capturing debugging info without networking

2002-06-26 Thread Alexander Stohr

i would prefer this
  DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%Y-%m-%d-%T`
so that on sorted dir listings the most recent is
always on top since this date is encoded MSB first.
(textual month locales wont sort that good at all.)

another two things you might want to add:
  /sbin/lspci -vvv $DRI_DEBUG_DIR/lspci.txt
  /sbin/lsmod $DRI_DEBUG_DIR/lsmod.txt

do you expect this commands beeing executed as root
or as a user? you might want to add some suid root
detection or a su - query to the script lines.

hmm, is there a way to dectect what built in or 
external modules a specific linux kernel does provide?

why are you using  for some of the redirections?

what about a final bz2 tarball creation?

 -Original Message-
 From: Al Tobey [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, June 25, 2002 23:39
 To: DRI
 Subject: [Dri-devel] Capturing debugging info without networking
 
 
 Here is a sort of simple shell script that I just thought of 
 that might
 make people's lives a little easier.  Cut  paste this into a file
 (maybe /usr/local/bin/dri_debug.sh) and then add this line to your
 equivalent of /etc/rc.local:
 /bin/sh /usr/local/bin/dri_debug.sh
 to have it run at boot time to save info from the last crash. 
 Otherwise, just run it any old time to get a snapshot of log data.
 
 If there's interest, I'll put together a nice rc script that 
 should work
 on most distros for distribution with the testing binaries.  This is
 just a mock up (I haven't even run it - I hate dog food ;) of what
 should be a bit more complicated and grab a few more things, 
 but you get
 the idea.
 
 DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T`
 mkdir $DRI_DEBUG_DIR
 cp /var/log/XFree86.0.log $DRI_DEBUG_DIR
 # this should work, but a grep might be better ...
 tail -5000 /var/log/messages $DRI_DEBUG_DIR/syslog.log
 cp /etc/X11/XF86Config* $DRI_DEBUG_DIR
 ls -l /usr/lib/libGL* $DRI_DEBUG_DIR/usr_GLFiles.txt
 ls -l /usr/X11R6/lib  $DRI_DEBUG_DIR/X11R6_libFiles.txt
 ldd /usr/X11R6/bin/glxgears $DRI_DEBUG_DIR/ldd_glxgears.txt
 
 # any other files ...
 
 tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR
 #rm -rf $DRI_DEBUG_DIR
 
 It might be nice to patch xinitrc to do this:
 glxinfo /var/tmp/glxinfo.txt
 every time so it can be bundled up, too.
 
 Then when people start having problems, the list can expect (somewhat)
 consistent reports.  Lemme know what you think.
 
 I take no responsibility for the meltdown of your system ;)
 -Al Tobey
 
 
 
 
 
 This email and any files transmitted with it are confidential
 and intended solely for the use of the individual or entity
 to whom they are addressed.  If you have received this 
 email in error please notify the Priority Health Information
 Services Department at (616) 942-0954.
 
 
 
 
 ---
 This sf.net email is sponsored by: Jabber Inc.
 Don't miss the IM event of the season | Special offer for 
 OSDN members! 
 JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
 ___
 Dri-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/dri-devel
 



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)

2002-06-26 Thread Alan Hourihane

On Wed, Jun 26, 2002 at 04:00:18PM +0100, José Fonseca wrote:
 On Wed, Jun 26, 2002 at 07:07:00AM -0700, Alan Hourihane wrote:
  merge trunk into s3virge branch (probably won't build at all now).
  
  Needs fixing for drmCommand interface.
 
 
 Er.. I was just about to suggest to do the merge in a new branch
 (e.g., s3virge-0-0-2-branch) to avoid leave the s3virge broken while Max
 is too busy to do the required changes...
 
It shouldn't take too long to fixup. Jens did the other drivers very
quickly.

 BTW, Alan, is the trident branch in shape for binary snapshots too, or
 are they already available elsewhere?

No. The trident driver works, but there's no fallbacks yet and
lots of stuff doesn't work.

Alan.


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Fixed binaries on SF

2002-06-26 Thread Konstantin Lepikhov

Hi Jos?!

Tuesday 25, at 09:48:20 AM you wrote:

 On Tue, Jun 25, 2002 at 12:06:36PM +0400, Konstantin Lepikhov wrote:
 Hi Jos?!
 
 Monday 24, at 10:16:51 PM you wrote:
 
 As some of you already noticed, fixed binaries  - i.e, including libdri.a 
 -, are now available on SF.
 
 When [and if] the binary compatability of libdri.a is restored, let me
 know and I'll restore the things as they were.
 
 Jos? Fonseca
 Problem is gone away for voodoo3 (again :) DRI is working again after
 trivial compilation  installation binaries. So whats happen?
 
 
 What's happened was that changes in libdri.a in the Radeon tcl-0-0-branch 
 which were after included in the trunk broke compatability with previous 
 versions of the library so drivers after this changes require an updated 
 libdri.a.
 
 Jos? Fonseca
 
Bad news :( My collegue who have ATI Radeon 7500 QW (AGP) reported this:

he using 20020625 snapshot

from XFree86.0.log
...
(II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
...

DRI still not work!

PS It's not a gcc problem (because ALTLinux have the same gcc-2.96-110).

-- 
with best regards,   ICQ: 109916175
   JID: [EMAIL PROTECTED]
Konstantin Lepikhovmailto:[EMAIL PROTECTED]

Motto: Linux is like a wigwam - no windows, no gates, apache inside!




---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch:s3virge-0-0-1-branch)

2002-06-26 Thread Leif Delgass

On Wed, 26 Jun 2002, José Fonseca wrote:

 On Wed, Jun 26, 2002 at 07:07:00AM -0700, Alan Hourihane wrote:
   merge trunk into s3virge branch (probably won't build at all now).
   
   Needs fixing for drmCommand interface.
 
 
 Er.. I was just about to suggest to do the merge in a new branch
 (e.g., s3virge-0-0-2-branch) to avoid leave the s3virge broken while Max
 is too busy to do the required changes...

Jose, I think now would be a good time for us to merge the trunk into a 
new Mach64 branch.  Brian released Mesa 4.0.3 and the trunk looks like 
it's been updated, and we need to convert to drmCommand as well.  Plus 
there are ppc fixes that should help with our current texture problems.

-- 
Leif Delgass 
http://www.retinalburn.net



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



RE: [Dri-devel] Re: Fixed binaries on SF

2002-06-26 Thread Alexander Stohr

 he using 20020625 snapshot
 
 from XFree86.0.log
 ...
 (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), 
 Permission denied
 (EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
 ...

Huh? Hi might try as root. If it works then something
with per user file permissions or sticky bits is odd.

other idea: for the odd case of legacy problems i would 
suspect that there is an API mismatch due to file inconsistency
or the drm devices just do have the device file id.
(there was a change in that area some time ago.)



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Fixed binaries on SF

2002-06-26 Thread Konstantin Lepikhov

Hi Alexander!

Wednesday 26, at 06:22:24 PM you wrote:

  he using 20020625 snapshot
  
  from XFree86.0.log
  ...
  (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), 
  Permission denied
  (EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
  ...
 
 Huh? Hi might try as root. If it works then something
 with per user file permissions or sticky bits is odd.
 
 other idea: for the odd case of legacy problems i would 
 suspect that there is an API mismatch due to file inconsistency
 or the drm devices just do have the device file id.
 (there was a change in that area some time ago.)
We also checking this. Please wait while we tracking all variants. I
don't want bother everybody about every trifle :)  

-- 
with best regards,   ICQ: 109916175
   JID: [EMAIL PROTECTED]
Konstantin Lepikhovmailto:[EMAIL PROTECTED]

Motto: Linux is like a wigwam - no windows, no gates, apache inside!




---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote:
[...]
Jose, I think now would be a good time for us to merge the trunk into a 
new Mach64 branch.  Brian released Mesa 4.0.3 and the trunk looks like 
it's been updated, and we need to convert to drmCommand as well.  Plus 
there are ppc fixes that should help with our current texture problems.

Okidoki. Feel free to start the merge whenever you want - before I join 
you I just want to make the changes in the DRM I promised to the PPC guys 
to debug the problems they've been experienced. I think that's a good
idea to bump the branch number too.

José Fonseca



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Alan Hourihane

On Wed, Jun 26, 2002 at 04:31:09PM +0100, Alan Hourihane wrote:
 On Wed, Jun 26, 2002 at 03:59:06PM +0200, Massimiliano Lingua wrote:
  On Wed, 2002-06-26 at 15:52, Alan Hourihane wrote:
  
   I'll do the merge now for you.
   
   Obviously this branch won't build at all until fixed up for the
   new drmCommand stuff.
  
  I have been away a couple of months from active development. Where could
  I gather more infos about drmCommand? Is it easy to understand just
  peeking at the code of other drivers? What are its benefits?
 
 I'll try and give you a hand on this now.

Max,

It builds now, so could you 'cvs update' build, install, and check
everything is working.

Alan.


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Merging trunk changes into mach64 branch

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 01:52:00PM -0400, Leif Delgass wrote:
On Wed, 26 Jun 2002, José Fonseca wrote:

 On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote:
 [...]
 Jose, I think now would be a good time for us to merge the trunk into a 
 new Mach64 branch.  Brian released Mesa 4.0.3 and the trunk looks like 
 it's been updated, and we need to convert to drmCommand as well.  Plus 
 there are ppc fixes that should help with our current texture problems.
 
 Okidoki. Feel free to start the merge whenever you want - before I join 
 you I just want to make the changes in the DRM I promised to the PPC guys 
 to debug the problems they've been experienced. I think that's a good
 idea to bump the branch number too.

It's been a while since I did a merge.  I'm thinking I'll make the branch
from the trunk (I'm checking out a fresh tree from the trunk now) and then
merge in changes from mach64-0-0-4-branch once you've checked in anything
you'd like to get in before the merge.  Does that sound like the right 
way to do it?  I was thinking this might be easier than merging the 
changes on the trunk into the branch since there's been a lot of activity 
on the trunk since our last branchpoint from it.


Yep. That's it. Basically one needs to checkout the trunk, tag it with
the new mach64-0-0-5-branch, and then merge from the old branch (by
doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA,
is adding the mach64 stuff to all Makefiles because the mach64 driver
was never merged back into the trunk...

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Merging trunk changes into mach64 branch

2002-06-26 Thread Leif Delgass

On Wed, 26 Jun 2002, José Fonseca wrote:

 On Wed, Jun 26, 2002 at 01:52:00PM -0400, Leif Delgass wrote:
 On Wed, 26 Jun 2002, José Fonseca wrote:
 
  On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote:
  [...]
  Jose, I think now would be a good time for us to merge the trunk into a 
  new Mach64 branch.  Brian released Mesa 4.0.3 and the trunk looks like 
  it's been updated, and we need to convert to drmCommand as well.  Plus 
  there are ppc fixes that should help with our current texture problems.
  
  Okidoki. Feel free to start the merge whenever you want - before I join 
  you I just want to make the changes in the DRM I promised to the PPC guys 
  to debug the problems they've been experienced. I think that's a good
  idea to bump the branch number too.
 
 It's been a while since I did a merge.  I'm thinking I'll make the branch
 from the trunk (I'm checking out a fresh tree from the trunk now) and then
 merge in changes from mach64-0-0-4-branch once you've checked in anything
 you'd like to get in before the merge.  Does that sound like the right 
 way to do it?  I was thinking this might be easier than merging the 
 changes on the trunk into the branch since there's been a lot of activity 
 on the trunk since our last branchpoint from it.
 
 
 Yep. That's it. Basically one needs to checkout the trunk, tag it with
 the new mach64-0-0-5-branch, and then merge from the old branch (by
 doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA,
 is adding the mach64 stuff to all Makefiles because the mach64 driver
 was never merged back into the trunk...

Wouldn't it be easier to do 'cvs update -j mach64-0-0-4-branch'?  That
should merge everthing from the branch (changes relative to the
branchpoint on the trunk), and I'll just have to merge any
conflicts/rejects by hand.

-- 
Leif Delgass 
http://www.retinalburn.net



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: Merging trunk changes into mach64 branch

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 02:17:26PM -0400, Leif Delgass wrote:
On Wed, 26 Jun 2002, José Fonseca wrote:

[...]
 
 Yep. That's it. Basically one needs to checkout the trunk, tag it with
 the new mach64-0-0-5-branch, and then merge from the old branch (by
 doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA,
 is adding the mach64 stuff to all Makefiles because the mach64 driver
 was never merged back into the trunk...

Wouldn't it be easier to do 'cvs update -j mach64-0-0-4-branch'?  That
should merge everthing from the branch (changes relative to the
branchpoint on the trunk), and I'll just have to merge any
conflicts/rejects by hand.

Perhaps. What I suggested was what I've done the last time. I make no
claim that is the best method since as you can see my CVS knowledge is that deep! ;-)

On the other hand I could not see on the CVS manpage how the -j option
would have the effect you described. Is just a matter of trying anyway.

Perhaps you should try instead what is suggested on HOW TO MERGE THE
TRUNK INTO YOUR BRANCH in http://dri.sf.net/doc/cvspolicy.txt .

Alan, hint? (Or How have you just done now with the s3virge branch?)

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] RE: Dri-devel S3 VIRGE DRI in CVS now

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 08:51:18PM +0200, Massimiliano Lingua wrote:
On Wed, 2002-06-26 at 16:48, José Fonseca wrote:


 Are the ProSavage docs you have enough to get a good start on Savage4?

their 3D engine is nearly identical. Er, I forgot, I got Savage4 docs
too from S3/VIA. I am definetly the luckiest coder on Earth ; )


Well, at least someone of us has. That's good enough for me!

So on a Savage4 running my hack you will see just the same as me:
monochrome (black), smeared triangles ; (
 
I am quite busy now (I have to pass this fucking law exam...), but if
you are interested in the 2nd half of July I could send you a copy of my
code + some comment (it should be very intuitive even without docs), so
maybe you can guess what I am doing wrong.

I would appreciate it. But have no hurry because of me, since only on the 
26th of July I'll have access to my Savage4 card (when I return to Portugal 
in vacations), so only then I'll be able to test it myself. 

Nevertheless it would be nice to have whatever you have in CVS - as is -  so that 
others can start playing with it. If you want just send me the parts and I'll 
do the integration with the CVS myself. But only if this isn't too much
trouble for you now, of course. (I don't how big is what you have nor how
fast is your internet connection).

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



RE: [Dri-devel] Capturing debugging info without networking

2002-06-26 Thread Sergey V. Udaltsov

Good boys! Can anyone invent the way to do the same thing with gdb? So
on X crash one could get backtrace without remote debugging...

Cheers,

Sergey



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote:
  o.k. it's builds now, max needs to check it runs o.k.


I've tested and I still get errors when building it:

gcc -c -O2  -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wnested-externs -pipe -g  -I../.
./../../../../exports/include/X11 -I../../../../../../include/extensions 
-I../../../../../../extras/Mesa/src-I../../../../../
../lib/GL/mesa/src/drv/common   -I../../../../../../lib/GL/mesa/src/drv/s3v 
-I../../../../../../lib/GL/dri  -I../../.
./../../../lib/GL/glx   -I../../../../../../exports/include 
-I../../../../../../exports/include/GL  -I../../.
./../../../programs/Xserver/GL/dri  
-I../../../../../../programs/Xserver/hw/xfree86/os-support  
-I../../../../../
../programs/Xserver/hw/xfree86/drivers/s3virge  
-I../../../../../../programs/Xserver/hw/xfree86/common  -I../../../../../
../lib/GL/dri/drm   -I../../../../../../lib/GL/include  
-I../../../../../../include  -I../../../../../.. -I../../
../../../../exports/include -I/usr/X11R6/include  -Dlinux -D__i386__ 
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOU
RCE -D_SVID_SOURCE  -D_GNU_SOURCE   -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS  
-D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -D
GLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA  
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE
_3DNOW_ASM -DUSE_SSE_ASM   s3v_context.c
In file included from s3v_context.c:5:
s3v_context.h:215: parse error before `drm_s3v_sarea_t'
s3v_context.h:215: warning: no semicolon at end of struct or union
s3v_context.h:378: `Window' redeclared as different kind of symbol
../../../../../../exports/include/X11/X.h:101: previous declaration of `Window'
s3v_context.h:403: parse error before `}'
s3v_context.c: In function `s3vCreateContext':
s3v_context.c:57: `drm_s3v_sarea_t' undeclared (first use in this function)
s3v_context.c:57: (Each undeclared identifier is reported only once
s3v_context.c:57: for each function it appears in.)
s3v_context.c:57: `saPriv' undeclared (first use in this function)
s3v_context.c:57: parse error before `)'
s3v_context.c:62: dereferencing pointer to incomplete type
...

And alot of similar errors after.

Perhaps something was forgoten when commiting?

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: Merging trunk changes into mach64 branch

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 04:22:07PM -0400, Leif Delgass wrote:
On Wed, 26 Jun 2002, Alan Hourihane wrote:

 On Wed, Jun 26, 2002 at 07:44:14PM +0100, José Fonseca wrote:
  Alan, hint? (Or How have you just done now with the s3virge branch?)
 
 cvs update -j HEAD
 
 and resolve the conflicts by hand.

OK, I can do that.  I guess it'll be about the same difficulty as merging
the branch changes into the trunk code.  Jose, do you have anything else
you want to commit before I tag the new branch?  I'm going to update my

No. I just have the new vertex template stuff but I'm still working on
it and it shouldn't be more difficult to commit directly to the new
branch.

mach64-0-0-4-branch tree and tag it to create the new mach64-0-0-5-branch.  
Then I'll merge in the trunk and start working on conflicts and the
drmCommand changes.

Ok.

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch))

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 08:56:04PM +0100, Alan Hourihane wrote:
On Wed, Jun 26, 2002 at 08:38:03PM +0100, José Fonseca wrote:
 On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote:
  o.k. it's builds now, max needs to check it runs o.k.
 
 
 ...
 
 Perhaps something was forgoten when commiting?

Indeed. Committed.

It worked like a charm!

The first s3virge binary snapshot is now available on
http://dri.sourceforge.net/snapshots/bleeding-edge/ .

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] How to trace switching to software rendering

2002-06-26 Thread Michael Schlueter

Hi Brian,

sorry for disturb you again.

Am Sam, 2002-06-22 um 00.00 schrieb Brian Paul:
 Most of the DRI drivers have a per-context field called 'Fallback'.
 It's a bitmask which records various reasons why we need to fallback
 to software rendering.  In the case of the mga (G400) driver you'll
 see these flags in mgacontext.h:
 
 #define MGA_FALLBACK_TEXTURE0x1
 #define MGA_FALLBACK_DRAW_BUFFER0x2
 #define MGA_FALLBACK_READ_BUFFER0x4
 #define MGA_FALLBACK_LOGICOP0x8
 #define MGA_FALLBACK_RENDERMODE 0x10
 #define MGA_FALLBACK_STENCIL0x20
 #define MGA_FALLBACK_DEPTH  0x40
 
 If you search the code, you'll find where we set these flags by
 calling mgaFallback() (via the FALLBACK() macro).  You could put
 a printf in there to print the bit value and get an idea of what's
 slowing you down.

Ok, I did a printf there and switch MGA_DEBUG on. Now I need a bit help
with the analyse of the output...

mgaFallback: bit:1 mode:0

Looks like this is a call from mgaUpdateTextureState. Since mode is 0
the fallback flag is unset? 

FLUSH_BATCH in mgaReadDepthPixels_16
FLUSH_BATCH in mgaWriteDepthPixels_16
FLUSH_BATCH in mgaWriteRGBAPixels_565
FLUSH_BATCH in mgaDDBindTexture
FLUSH_BATCH in mgaDDUpdateHwState
FLUSH_BATCH in mgaFallback
FALLBACK: GL_DECAL RGBA texture, unit=0
FLUSH_BATCH in mgaReadDepthPixels_16
FLUSH_BATCH in mgaWriteDepthPixels_16
FLUSH_BATCH in mgaWriteRGBAPixels_565

This looks more interesting to me. Is there a problem with RGBA
textures?

Bye, Michael



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Parhelia vs. Radeon 8500

2002-06-26 Thread German Gomez Garcia

Hello, I have some money to spend (finally!!!) so I'm thinking
of replacing my old G400MAX for a new card, as I prefer open source, I
have to choose between ATI and Matrox, and the optios (for me) are
the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card
works better under Linux, as far as I know somebody is working in 3D for
the 8500 even TCL!!, and the Gatos project has good quality video in/out
for the AIW DV. The parhelia is quite misterious, but I could wait two
or three months if the drivers would be good enough. 

I would like to know if anybody from Matrox contacted developers
here, well, in fact, I would like to know if I should wait for the
parhelia linux drivers or go for the AIW. What do you think??

Regards,

- german

-- 
Send email with SEND GPG KEY as subject to receive my GnuPG public key.


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Parhelia vs. Radeon 8500

2002-06-26 Thread José Fonseca

On Wed, Jun 26, 2002 at 11:22:16PM +0200, German Gomez Garcia wrote:
   Hello, I have some money to spend (finally!!!) so I'm thinking
of replacing my old G400MAX for a new card, as I prefer open source, I
have to choose between ATI and Matrox, and the optios (for me) are
the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card
works better under Linux, as far as I know somebody is working in 3D for
the 8500 even TCL!!, and the Gatos project has good quality video in/out
for the AIW DV. The parhelia is quite misterious, but I could wait two
or three months if the drivers would be good enough. 

   I would like to know if anybody from Matrox contacted developers
here, well, in fact, I would like to know if I should wait for the
parhelia linux drivers or go for the AIW. What do you think??


For some reviews, comparisons and discussion regarding Matrox Parhelia follow 
this link http://slashdot.org/article.pl?sid=02/06/25/1317222 .

Regarding the availability of linux drivers check the Matrox plan at
http://www.extremetech.com/article2/0,3973,182491,00.asp .

Regarding the ATI Radeon 8500 I'm sure you're already aware of the
Wheather Channel sponsoring the development of DRI drivers:
http://slashdot.org/article.pl?sid=02/06/09/0236221 .

The choice [as always] depends entirely on which factors you value the most. I hope 
this helps.

José Fonseca


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[dbronaugh@linuxboxen.org: Re: [Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch))]

2002-06-26 Thread José Fonseca

- Forwarded message from David Bronaugh [EMAIL PROTECTED] -

Date: Wed, 26 Jun 2002 14:54:29 -0700
From: David Bronaugh [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc 
(branch: s3virge-0-0-1-branch))
To: Jos Fonseca [EMAIL PROTECTED]

 
 It worked like a charm!
 
 The first s3virge binary snapshot is now available on
 http://dri.sourceforge.net/snapshots/bleeding-edge/ .
 
 José Fonseca
 

Trying out your binary snapshot on a Debian Potato machine without any luck.

Errors are as follows when trying to build DRM:

Stretch:/home/bronaugh/X11R6-DRI/dripkg/drm# make -f Makefile.linux
=== KERNEL HEADERS IN /lib/modules/2.4.16/build/include
=== SMP=0 MODULES=1 MODVERSIONS=1 AGP=0
=== Compiling for machine i586
=== WARNING
=== WARNING Use 2.4.x kernels ONLY !
=== WARNING
cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes 
-Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer 
-DCONFIG_DRM_SIS -DMODVERSIONS -include 
/lib/modules/2.4.16/build/include/linux/modversions.h -DEXPORT_SYMTAB 
-I/lib/modules/2.4.16/build/include -c s3v_drv.c -o s3v_drv.o
In file included from s3v_drv.c:8:
s3v_drv.h:23: parse error before `drm_s3v_sarea_t'
s3v_drv.h:23: warning: no semicolon at end of struct or union
s3v_drv.h:55: parse error before `}'
s3v_drv.h:55: warning: type defaults to `int' in declaration of `drm_s3v_private_t'
s3v_drv.h:55: warning: data definition has no type or storage class
In file included from s3v_drv.c:40:
drm_bufs.h: In function `s3v_mapbufs':
drm_bufs.h:1055: parse error before `)'
In file included from s3v_drv.c:44:
drm_drv.h: At top level:
drm_drv.h:209: `DRM_IOCTL_S3V_INIT' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
drm_drv.h:209: `DRM_IOCTL_S3V_RESET' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_LOCK' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_FLUSH_LOCK' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_UNLOCK' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
drm_drv.h:209: `DRM_IOCTL_S3V_STATUS' undeclared here (not in a function)
drm_drv.h:209: nonconstant array index in initializer
drm_drv.h:209: (near initialization for `s3v_ioctls')
make: *** [s3v_drv.o] Error 1

Not sure all of what this means.

GCC 2.95.2, glibc 2.2, kernel 2.4.16

David Bronaugh

- End forwarded message -


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch

2002-06-26 Thread Alan Hourihane

On Thu, Jun 27, 2002 at 12:48:30AM +0200, Massimiliano Lingua wrote:
 On Wed, 2002-06-26 at 19:16, Alan Hourihane wrote:
 
  
  It builds now, so could you 'cvs update' build, install, and check
  everything is working.
 
 I had some problem building it in mesa/src/drv/s3v
 
 In s3v_context.h (215) I have something like drm_s3v_sarea_t. Where
 other drivers seems to have now something like NAMESAREADRIPtr.
 I wonder:
 1) is the former no longer valid?
 2) am I supposed to add this new structure in some driver file?

I fixed that a few hours ago. Ensure you do another 'cvs update'

Alan.


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



RE: [Dri-devel] Capturing debugging info without networking

2002-06-26 Thread Alexander Stohr

some of the current desktop managers has those dial home 
feature with the fault handler built in. each crash could
get sent to the development team if the user likes it.

Maybe improved crash logging should get an integral feature 
of X11 on general platforms (of course embedded folks wont like it).

 -Original Message-
 From: Sergey V. Udaltsov [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, June 26, 2002 21:23
 To: Alexander Stohr
 Cc: Al Tobey; DRI
 Subject: RE: [Dri-devel] Capturing debugging info without networking
 
 
 Good boys! Can anyone invent the way to do the same thing with gdb? So
 on X crash one could get backtrace without remote debugging...
 
 Cheers,
 
 Sergey
 
 



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] How to trace switching to software rendering

2002-06-26 Thread Ville Syrjälä

On Wed, Jun 26, 2002 at 04:43:35PM -0600, Brian Paul wrote:
 Without looking at the code, my guess is that the GL_DECAL env mode
 with an RGBA texture probably isn't implemented in hardware.  Hardware
 from that era often had limitations that prevented some combinations
 of texture env modes and texture formats from being done in hardware.

There was a patch by Karl Lessard (?) that had something to do with
GL_DECAL. What happened to it?

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/


---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)

2002-06-26 Thread Eric Anholt

 Log message:
   Include protection against ioctl() definition only in the __FreeBSD__ and
   XFree86Server case.  These two drm.h's probably should be shared.

With this commit radeon, r128, and mga are all working on FreeBSD and
Linux.  Haven't tested tdfx, but I have no reason to not expect it to
work.

At this point, who should review this for a merge?

-- 
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/



---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)

2002-06-26 Thread Jens Owen

Eric Anholt wrote:


 Log message:
   The drmCommand interface was passing a size to DRM_IOR() and friends,
   when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of
   the kernel.  Make drmCommand use new DRM_IOC(), which expects a size.

Good catch!  I'm surprised this worked at all under Linux.

-- 
/\
  Jens Owen/  \/\ _
   [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)

2002-06-26 Thread Jens Owen

Eric Anholt wrote:

Log message:
  Include protection against ioctl() definition only in the __FreeBSD__ and
  XFree86Server case.  These two drm.h's probably should be shared.

 
 With this commit radeon, r128, and mga are all working on FreeBSD and
 Linux.  Haven't tested tdfx, but I have no reason to not expect it to
 work.
 
 At this point, who should review this for a merge?

Damn, this is looking sweet!  You have almost hit gold with this work, 
and here's what I would consider perfection:

The source repository and plain source trees that haven't been built, 
yet would contain an os-support/linux/drm/kernel that contained the drm* 
files for Linux:

drm_agpsupport.h  drm_drawable.h  drm_ioctl.h   drm_os_freebsd.h
drm_auth.hdrm_drv.h   drm_linux.h   drm_os_netbsd.h
drm_bufs.hdrm_fops.h  drm_lists.h   drmP.h
drm_context.h drm.h   drm_lock.hdrm_scatter.h
drm_dma.h drm_init.h  drm_memory.h  drm_sysctl.h
 drm_vm.h

Not these are all Linux specific, but Hardware independent, and of 
course an os-support/bsd/drm/kernel and other os specific directories, 
too.  None of which contained HW specific files.

The os-support/shared/drm/kernel directory would then contain the HW 
specifics:

gamma_dma.c  i810_drv.h  mga_drm.h   r128_drm.h   radeon_drv.h
gamma_drm.h  i810.h  mga_drv.c   r128_drv.c   radeon_state.c
gamma_drv.c  i830_dma.c  mga_drv.h   r128_drv.h   radeon.h
gamma_drv.h  i830_drm.h  mga_state.c r128_state.c tdfx_drv.c
gamma.h  i830_drv.c  mga_ucode.h r128.h   tdfx.h
i810_dma.c   i830_drv.h  mga_warp.c  radeon_cp.c
i810_drm.h   i830.h  mga.h   radeon_drm.h
i810_drv.c   mga_dma.c   r128_cce.c  radeon_drv.c

For the drivers you've ported to your OS independent templates (radeon, 
r128 and mga), it looks like the *_drv.c and Makefile support are all 
that's left in the OS directories.  If you can get these out of there, 
even by adding a few OS ifdefs in the shared directory, you will get big 
leverage when a new driver is written.  Generally, a driver writer 
copies another driver as a starting point, and they won't discard non 
development OS's simply because it's easier to ignore the directories.

In other words, let's make new drivers work on all supported OS's by 
default instead of having to enable each OS/driver combo by hand.  I can 
see the need for disabling a OS/driver combo by hand after we know it 
can't be easily supported.

I'm definitely interested in hearing your opinion on squeeking out the 
last bigs of OS specifics in these drivers.  I realize the last parts 
are usually the most difficult.

Regards,
Jens

-- 
/\
  Jens Owen/  \/\ _
   [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)

2002-06-26 Thread Eric Anholt

On Wed, 2002-06-26 at 23:12, Jens Owen wrote:
 Eric Anholt wrote:
 
 
  Log message:
The drmCommand interface was passing a size to DRM_IOR() and friends,
when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of
the kernel.  Make drmCommand use new DRM_IOC(), which expects a size.
 
 Good catch!  I'm surprised this worked at all under Linux.

Well, Linux (AFAIK) doesn't even care about the size passed in through
ioctl, since our drivers in Linux try to copy in the actual size of the
struct, not what the userland said the size was.  On BSD the copyin is
done by the ioctl syscall before passing the data to the per-ioctl
handler.  Really, the linux way is better for our code.  I once poked at
making the copyins work like linux, but it would have been ugly.

-- 
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/



---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel