Menu
▾
▴
mesa3d-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(11) |
Apr
(46) |
May
(65) |
Jun
(85) |
Jul
(94) |
Aug
(99) |
Sep
(62) |
Oct
(58) |
Nov
(85) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(90) |
Feb
(29) |
Mar
(90) |
Apr
(96) |
May
(78) |
Jun
(58) |
Jul
(44) |
Aug
(65) |
Sep
(40) |
Oct
(38) |
Nov
(79) |
Dec
(63) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(43) |
Apr
(53) |
May
(35) |
Jun
(59) |
Jul
(18) |
Aug
(12) |
Sep
(28) |
Oct
(61) |
Nov
(54) |
Dec
(23) |
| 2003 |
Jan
(16) |
Feb
(42) |
Mar
(38) |
Apr
(35) |
May
(20) |
Jun
(9) |
Jul
(10) |
Aug
(30) |
Sep
(22) |
Oct
(32) |
Nov
(25) |
Dec
(21) |
| 2004 |
Jan
(39) |
Feb
(36) |
Mar
(59) |
Apr
(32) |
May
(21) |
Jun
(4) |
Jul
(8) |
Aug
(21) |
Sep
(11) |
Oct
(21) |
Nov
(22) |
Dec
(19) |
| 2005 |
Jan
(62) |
Feb
(24) |
Mar
(17) |
Apr
(16) |
May
(16) |
Jun
(17) |
Jul
(26) |
Aug
(14) |
Sep
(13) |
Oct
(8) |
Nov
(23) |
Dec
(20) |
| 2006 |
Jan
(41) |
Feb
(18) |
Mar
(21) |
Apr
(47) |
May
(13) |
Jun
(33) |
Jul
(32) |
Aug
(21) |
Sep
(27) |
Oct
(34) |
Nov
(19) |
Dec
(46) |
| 2007 |
Jan
(21) |
Feb
(26) |
Mar
(13) |
Apr
(22) |
May
(5) |
Jun
(19) |
Jul
(56) |
Aug
(43) |
Sep
(37) |
Oct
(31) |
Nov
(53) |
Dec
(22) |
| 2008 |
Jan
(74) |
Feb
(31) |
Mar
(15) |
Apr
(35) |
May
(23) |
Jun
(26) |
Jul
(17) |
Aug
(27) |
Sep
(35) |
Oct
(30) |
Nov
(29) |
Dec
(17) |
| 2009 |
Jan
(35) |
Feb
(39) |
Mar
(44) |
Apr
(28) |
May
(20) |
Jun
(28) |
Jul
(49) |
Aug
(53) |
Sep
(23) |
Oct
(13) |
Nov
(12) |
Dec
(11) |
| 2010 |
Jan
(45) |
Feb
(28) |
Mar
(41) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: 明覺 <shi...@gm...> - 2009-05-09 15:55:15
|
The segmentation fault error occurs in the glXWaitX(void) function in glxcmds.c of the mesa package, here is the gdb info: ------------------------------------------------------------------------------------------------------------------------------ Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5d6da60 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff5d6da60 in ?? () from /lib/libc.so.6 #1 0x00007ffff6ec4671 in glXWaitX () at glxcmds.c:660 #2 0x00007ffff790c2a1 in QGLWidget::resizeEvent(QResizeEvent*) () from /usr/lib/libqt-mt.so.3 #3 0x00007ffff772f07b in QWidget::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #4 0x00007ffff76a8953 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #5 0x00007ffff76a962e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #6 0x00007ffff76aa03a in QApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libqt-mt.so.3 #7 0x00007ffff773018d in QWidget::show() () from /usr/lib/libqt-mt.so.3 #8 0x00007ffff772e5d1 in QWidget::showChildren(bool) () from /usr/lib/libqt-mt.so.3 #9 0x00007ffff7730260 in QWidget::show() () from /usr/lib/libqt-mt.so.3 #10 0x00007ffff772e5d1 in QWidget::showChildren(bool) () from /usr/lib/libqt-mt.so.3 #11 0x00007ffff7730260 in QWidget::show() () from /usr/lib/libqt-mt.so.3 #12 0x00007ffff78193c9 in QWidgetStack::show() () from /usr/lib/libqt-mt.so.3 #13 0x00007ffff772e5d1 in QWidget::showChildren(bool) () from /usr/lib/libqt-mt.so.3 #14 0x00007ffff7730260 in QWidget::show() () from /usr/lib/libqt-mt.so.3 ------------------------------------------------------------------------------------------------------------------------------ how could i solve this bug? my platform is debian-sid-amd64. thanks! -- 我的操作系統是Gnu/Linux Debian-sid-amd64/gNewSense Gnome Mozilla Gmail/Evolution Gtkmm/Clutter/Anjuta Scim Totem Pidgin. |
|
From: Brian P. <br...@vm...> - 2009-05-08 21:16:40
|
... can be downloaded from http://www.mesa3d.org/beta/ md5sums: 9c9b5542a067dcb691f72c1d4ee950d6 MesaLib-7.5-rc1.tar.gz a51c0692c8fd1ef8d508c8a276620695 MesaLib-7.5-rc1.zip b88828062a566ddae6b4da0d57f2e29b MesaDemos-7.5-rc1.tar.gz 9f44dd291c58adcb5aba720bd07b5090 MesaDemos-7.5-rc1.zip ebfc637c7400e55ef4712b51f906685e MesaGLUT-7.5-rc1.tar.gz c56ed2deb5c22c01da96ed24f4d60410 MesaGLUT-7.5-rc1.zip See the release notes file for details, but Mesa 7.5 will be the first release to include the new Gallium3D code. -Brian |
|
From: Richardson Clare-H. <Cla...@mo...> - 2009-05-08 20:19:47
|
Hello, I've built the Mesa DLLs on Windows using MinGW (aka without Visual Studio). But, I noticed the MinGW makefiles don't have a target for OSMesa, which I need. It looks like the only option is to use Visual Studio to get osmesa32.dll. Is that correct? Has anyone tried to build OSMesa on Windows without VStudio? Thanks! Clare Richardson |
|
From: Chris J. <cjn...@gm...> - 2009-05-03 00:51:32
|
On Thu, Apr 23, 2009 at 04:31:36AM EDT, José JORGE wrote: > A Thursday 23 April 2009 00:48:40, Chris Jones escreveu: > > Two examples of 3D with a Mach64 that make it worth enabling dri: > > . Heretic II - if dri is enabled + 16-bit color + 1024x768 at most > > the rendering is quite beautiful. If not, you are switched to the > > software renderer and the game is ugly as sin. > > . tuxracer - without dri, it takes maybe ten seconds before you > > switch from the menu to an actual game sequence - which turns out > > to be so slow that it is unplayable anyway. > > > Ok maybe Heretic (I didn't test). To be honest.. I don't think Heretic II could run - or even install on anything more recent that debian sarge.. needs patching.. that's not forthcoming.. > But tuxracer has been replaced by extremetuxracer or ppracer, which > both ask for a better graphics card. Sigh.. :-( > Of course, if you want a distribution that just works with Mach64 dri, > I'd recommend you a Mandriva 2007 Spring, it was the last one I used > with a Mach64 and DRI (and at his time I filled bug reports to > Mandriva each time DRI was forgotten for Mach64). If you just want > those old games, I think they will run better with such an old > distribution. That's why I haven't deleted my old sarge system. > > Another reason I was looking into this was indeed because I was > > wondering whether it would make any difference playing movies or > > streaming TV with mplayer+xv - not to mention watching Adobe Flash > > content in mozilla with the flashplayer plugin. > > Here DRI will not change anything : xv and flash DON'T use DRI. Thanks... that I am more concerned about that than gaming. CJ |
|
From: Andre B. <and...@gm...> - 2009-04-26 16:19:48
|
I'd like to know if there's support to framebuffer objects on intel driver for intel 945GM chipset, I've seen some promisses about future development some time ago and some users saying that have this support on newer chipsets like G33. I'm using the lattest stabe driver and can't see this support, so my question is: The lack is 'cause my system( I'm using Ubuntu 8.04 -kernel 2.6.24 - X.Org X Server 1.4.0.90), the chipset, or the driver(Mesa DRI Intel(R) 945G 20090418 2009Q1)/mesa GL( 1.4 Mesa 7.4.1)? |
|
From: José J. <lis...@fr...> - 2009-04-23 08:31:59
|
A Thursday 23 April 2009 00:48:40, Chris Jones escreveu: > Two examples of 3D with a Mach64 that make it worth enabling dri: > > . Heretic II - if dri is enabled + 16-bit color + 1024x768 at most the > rendering is quite beautiful. If not, you are switched to the software > renderer and the game is ugly as sin. > > . tuxracer - without dri, it takes maybe ten seconds before you switch > from the menu to an actual game sequence - which turns out to be so > slow that it is unplayable anyway. > Ok maybe Heretic (I didn't test). But tuxracer has been replaced by extremetuxracer or ppracer, which both ask for a better graphics card. Of course, if you want a distribution that just works with Mach64 dri, I'd recommend you a Mandriva 2007 Spring, it was the last one I used with a Mach64 and DRI (and at his time I filled bug reports to Mandriva each time DRI was forgotten for Mach64). If you just want those old games, I think they will run better with such an old distribution. > Another reason I was looking into this was indeed because I was > wondering whether it would make any difference playing movies or > streaming TV with mplayer+xv - not to mention watching Adobe Flash > content in mozilla with the flashplayer plugin. Here DRI will not change anything : xv and flash DON'T use DRI. |
|
From: Chris J. <cjn...@gm...> - 2009-04-22 22:48:51
|
On Wed, Apr 22, 2009 at 05:23:01PM EDT, José JORGE wrote:
> A Wednesday 22 April 2009 02:43:45, Chris Jones escreveu:
> > If not linux, what should we use it on..?
> The 2D part is OK, you can also play movies with the great Xv
> extension... what I mean is only the 3D with this card is somewhat
> useless. The only linux game that I played with it was Quake III
> arena, and it was slow and ugly.
Thanks for getting back to me.
Two examples of 3D with a Mach64 that make it worth enabling dri:
. Heretic II - if dri is enabled + 16-bit color + 1024x768 at most the
rendering is quite beautiful. If not, you are switched to the software
renderer and the game is ugly as sin.
. tuxracer - without dri, it takes maybe ten seconds before you switch
from the menu to an actual game sequence - which turns out to be so
slow that it is unplayable anyway.
Another reason I was looking into this was indeed because I was
wondering whether it would make any difference playing movies or
streaming TV with mplayer+xv - not to mention watching Adobe Flash
content in mozilla with the flashplayer plugin.
So maybe "of limited usefulness" is what it boils down to.
> > > Simple example : most of the 3D open-source games use much more than
> > > 8MB of video RAM.
> >
> > Hmm.. Whoever wrote the code wasted their/our time.. all we need is
> > credit cards and new hardware?
> Well, open source games are made by gamers, so yes they are done
> according to their recent hardware....
Problem being that with a family to feed, and .. the depressing "state
of the economy", I cannot afford to spend $5000.00 on a high-end gaming
laptop any time soon.
:-(
I'm currently in the process of switching from debian etch to lenny and
I will try again to get this to work .. hopefully before my ten-year old
machine expires.
CJ
|
|
From: José J. <lis...@fr...> - 2009-04-22 21:23:23
|
A Wednesday 22 April 2009 02:43:45, Chris Jones escreveu: > If not linux, what should we use it on..? The 2D part is OK, you can also play movies with the great Xv extension... what I mean is only the 3D with this card is somewhat useless. The only linux game that I played with it was Quake III arena, and it was slow and ugly. > > Simple example : most of the 3D open-source games use much more than > > 8MB of video RAM. > > Hmm.. Whoever wrote the code wasted their/our time.. all we need is > credit cards and new hardware? > Well, open source games are made by gamers, so yes they are done according to their recent hardware.... |
|
From: Chris J. <cjn...@gm...> - 2009-04-22 00:44:09
|
On Tue, Apr 07, 2009 at 04:14:13AM EDT, José JORGE wrote: [..] > Anyway, the 3D of such a card is so bad, I'd suggest you forgetting > using it on Linux. If not linux, what should we use it on..? > Simple example : most of the 3D open-source games use much more than > 8MB of video RAM. Hmm.. Whoever wrote the code wasted their/our time.. all we need is credit cards and new hardware? Thanks, CJ |
|
From: Łukasz L. <vol...@gm...> - 2009-04-21 17:47:29
|
On Sat, 2009-04-18 at 10:30 -0600, Brian Paul wrote: > I'm not sure I understand the problem here. The program produced the > same results with Mesa software rendering, Mesa's i965 driver and an > NVIDIA 8300 card. > > I tried disabling the lines you mention and the results were the same. > I've checked how it renders on a Debian box with an older Mesa version (6.5). The results are the same as for Windows XP. http://student.agh.edu.pl/~lukaszl/expected_winxp.png Any ideas how to make 7.3 render it like that? -- Lukasz Lis jid:lukaszl at student dot agh dot edu dot pl |
|
From: STEVE555 <ste...@ho...> - 2009-04-19 09:32:25
|
I have been building the Mesa code along with Nouveau and DRM from the git
repositories.I'm currently on Fedora Alhpa 11 Rawhide.The latest Xorg I have
from their packages is Xorg-1.6.1.My graphics card is a Nvidia Geforce
6,800G.T.My monitor is a A.D.I Microscan G1000.
I have been using the following configure options to build Mesa:
CFLAGS="-O2 -g -pipe -m32 -march=athlon -mtune=generic" CXXFLAGS=$CFLAGS
./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --datadir=/usr/share --sysconfdir=/etc
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec
--localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man
--docdir=/usr/share/doc --enable-selinux --x-libraries=/usr/lib
--enable-32-bit --enable-xcb --enable-gallium-nouveau --with-x
--with-dri-driverdir=/usr/lib/dri
--with-xorg-driver-dir=/usr/lib/xorg/modules/drivers
--with-state-trackers=dri2,egl,xorg,glx --enable-motif
If I have the xorg-state-tracker enabled,make comes up with this error:
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include
-I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-I../../../../src/gallium/drivers -I/src/gallium/include
-I/src/gallium/auxiliary -I/src/gallium/drivers -I../../../../include
-I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common
-I../../../../src/mesa/main -I/usr/include/drm dri_context.c dri_screen.c
dri_drawable.c dri_extensions.c 2> /dev/null
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/dri2'
gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/dri2'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers
-I../../../../include -I../../../../src/mesa
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main
-I/usr/include/drm -O2 -g -pipe -m32 -march=athlon -mtune=generic -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dri_context.c -o dri_context.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers
-I../../../../include -I../../../../src/mesa
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main
-I/usr/include/drm -O2 -g -pipe -m32 -march=athlon -mtune=generic -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dri_screen.c -o dri_screen.o
dri_screen.c:190: warning: no previous prototype for ‘dri_init_screen’
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers
-I../../../../include -I../../../../src/mesa
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main
-I/usr/include/drm -O2 -g -pipe -m32 -march=athlon -mtune=generic -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dri_drawable.c -o dri_drawable.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers
-I../../../../include -I../../../../src/mesa
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main
-I/usr/include/drm -O2 -g -pipe -m32 -march=athlon -mtune=generic -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dri_extensions.c -o dri_extensions.o
/bin/sh ../../../../bin/mklib -o dri2drm -static dri_context.o dri_screen.o
dri_drawable.o dri_extensions.o
mklib: Making Linux static library: libdri2drm.a
ar: creating libdri2drm.a
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/dri2'
gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/egl'
gcc -I../../include -I../../auxiliary
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa
-I../../../../include -I../../../../src/egl/main -I/usr/include/drm -O2 -g
-pipe -m32 -march=athlon -mtune=generic -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -c -o
egl_context.o egl_context.c
gcc -I../../include -I../../auxiliary
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa
-I../../../../include -I../../../../src/egl/main -I/usr/include/drm -O2 -g
-pipe -m32 -march=athlon -mtune=generic -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -c -o
egl_surface.o egl_surface.c
gcc -I../../include -I../../auxiliary
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa
-I../../../../include -I../../../../src/egl/main -I/usr/include/drm -O2 -g
-pipe -m32 -march=athlon -mtune=generic -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -c -o
egl_tracker.o egl_tracker.c
gcc -I../../include -I../../auxiliary
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa
-I../../../../include -I../../../../src/egl/main -I/usr/include/drm -O2 -g
-pipe -m32 -march=athlon -mtune=generic -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -c -o
egl_visual.o egl_visual.c
ar rcs libegldrm.a egl_context.o egl_surface.o egl_tracker.o egl_visual.o
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/egl'
gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/xorg'
gcc -DHAVE_CONFIG_H -g -Wall -Wimplicit-function-declaration -fPIC
-I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm
-I../../include -I../../auxiliary -I../../../../src/mesa/drivers/dri/common
-I../../../../src/mesa -I../../../../include -I../../../../src/egl/main -c
-o xorg_crtc.o xorg_crtc.c
xorg_crtc.c: In function ‘crtc_destroy’:
xorg_crtc.c:174: warning: unused variable ‘ms’
xorg_crtc.c: In function ‘cursor_destroy’:
xorg_crtc.c:265: warning: unused variable ‘ms’
gcc -DHAVE_CONFIG_H -g -Wall -Wimplicit-function-declaration -fPIC
-I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm
-I../../include -I../../auxiliary -I../../../../src/mesa/drivers/dri/common
-I../../../../src/mesa -I../../../../include -I../../../../src/egl/main -c
-o xorg_dri2.o xorg_dri2.c
xorg_dri2.c: In function ‘driCreateBuffers’:
xorg_dri2.c:88: error: ‘struct pipe_texture’ has no member named
‘compressed’
xorg_dri2.c:101: error: ‘struct pipe_texture’ has no member named
‘compressed’
xorg_dri2.c: In function ‘driDestroyBuffers’:
xorg_dri2.c:139: warning: unused variable ‘ms’
gmake[4]: *** [xorg_dri2.o] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
gmake[3]: *** [subdirs] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/mesa/src'
make: *** [default] Error 1
but if I leave out the xorg-state-tracker,Mesa builds fine.Can I ask if the
state-tracker is going to be fixed soon?
I have waited to see if there is going to be a commit to fix the error,so I
thought I would post my problem now.
I will try and post the entire build process in a txt file attached to this
post.
Regards,
STEVE555
http://www.nabble.com/file/p23121097/Compile%2BError.txt Compile+Error.txt
--
View this message in context: http://www.nabble.com/Xorg-state-tracker-error-tp23121097p23121097.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: Łukasz L. <vol...@gm...> - 2009-04-18 18:38:36
|
On Sat, 2009-04-18 at 10:30 -0600, Brian Paul wrote: > Łukasz Lis wrote: > > Hello. > > I've come across a strange rendering glitch and I'm not entirely sure > > what's wrong. When I try to draw a primitive (GL_POINTS, GL_LINES etc.) > > with a solid colour and without lighting then everything else I draw is > > filled with that colour, regardless of lighting settings. The same code > > renders properly on Windows with MinGW. I've noticed that Blender > > suffers from something similar on my machine. > > > > I'm using an Intel GM965 on a Lenovo R61i. I'd appreciate any tips on > > how to fix this. > > > > Attached are: > > - code triggering the glitch > > - my glxinfo print-out > > > > Screenshots of the attached code running on my machine and Blender: > > http://student.agh.edu.pl/~lukaszl/w_light.png > > http://student.agh.edu.pl/~lukaszl/wo_light.png > > http://student.agh.edu.pl/~lukaszl/blender.png > > > > I'm not sure I understand the problem here. The program produced the > same results with Mesa software rendering, Mesa's i965 driver and an > NVIDIA 8300 card. > > I tried disabling the lines you mention and the results were the same. > > Could you repost a program that shows the problem without > modifications (I'm not sure I understand your comments/directions) and > explain how the output is different from what you expect? > > -Brian Sorry, I'll try to rephrase. Attached is a screenshot of the same program compiled under Windows XP with Intel drivers. I expected it to show the same thing when compiled with Mesa under Linux: a red dot and a shaded sphere. Instead I get a red point and a red contour of the sphere that should appear shaded (from what I saw on Windows). I added the key press to illustrate that the sphere is filled only when the red point is drawn. Under Windows the sphere is always shaded. PS. Sorry about the duplicate reply to your address. I missed the proper reply button. -- Lukasz |
|
From: Brian P. <br...@vm...> - 2009-04-18 17:11:28
|
This release just fixes bugs since the 7.4 release. See the release notes page at http://www.mesa3d.org/ for details. -Brian |
|
From: Brian P. <br...@vm...> - 2009-04-18 16:31:30
|
Łukasz Lis wrote: > Hello. > I've come across a strange rendering glitch and I'm not entirely sure > what's wrong. When I try to draw a primitive (GL_POINTS, GL_LINES etc.) > with a solid colour and without lighting then everything else I draw is > filled with that colour, regardless of lighting settings. The same code > renders properly on Windows with MinGW. I've noticed that Blender > suffers from something similar on my machine. > > I'm using an Intel GM965 on a Lenovo R61i. I'd appreciate any tips on > how to fix this. > > Attached are: > - code triggering the glitch > - my glxinfo print-out > > Screenshots of the attached code running on my machine and Blender: > http://student.agh.edu.pl/~lukaszl/w_light.png > http://student.agh.edu.pl/~lukaszl/wo_light.png > http://student.agh.edu.pl/~lukaszl/blender.png > I'm not sure I understand the problem here. The program produced the same results with Mesa software rendering, Mesa's i965 driver and an NVIDIA 8300 card. I tried disabling the lines you mention and the results were the same. Could you repost a program that shows the problem without modifications (I'm not sure I understand your comments/directions) and explain how the output is different from what you expect? -Brian |
|
From: Łukasz L. <vol...@gm...> - 2009-04-18 14:29:42
|
Hello. I've come across a strange rendering glitch and I'm not entirely sure what's wrong. When I try to draw a primitive (GL_POINTS, GL_LINES etc.) with a solid colour and without lighting then everything else I draw is filled with that colour, regardless of lighting settings. The same code renders properly on Windows with MinGW. I've noticed that Blender suffers from something similar on my machine. I'm using an Intel GM965 on a Lenovo R61i. I'd appreciate any tips on how to fix this. Attached are: - code triggering the glitch - my glxinfo print-out Screenshots of the attached code running on my machine and Blender: http://student.agh.edu.pl/~lukaszl/w_light.png http://student.agh.edu.pl/~lukaszl/wo_light.png http://student.agh.edu.pl/~lukaszl/blender.png |
|
From: Brian P. <br...@vm...> - 2009-04-16 16:13:58
|
Lars Henning Wendt wrote:
> Hi,
>
> it seems that I found a Bug in the attrib.c _mesa_PopAttrib()
>
> in Line 1179 it should be
>
>> /* restore clip planes */
>> for (i = 0; i < MAX_CLIP_PLANES; i++) {
>> const GLuint mask = 1 << i;
>
> instead of
>
>> const GLuint mask = 1 << 1;
>
> I'm working with mesa 7.4
Thanks! I'll commit this fix right away.
-Brian
|
|
From: Brian P. <br...@vm...> - 2009-04-16 16:10:26
|
You can't just "enable it". It's supported in later versions of Mesa. The current release, Mesa 7.4 has it. -Brian PHAM Quoc Cuong wrote: > Hi > I am using intel driver on Fedora 9 with DRI > I would like to use extension GL_EXT_framebuffer_object but it seems to > be disabled. > > Any idea ? > > my xorg.conf : > > # Xorg configuration created by pyxf86config > > Section "ServerLayout" > Identifier "Default Layout" > Screen 0 "Screen0" 0 0 > InputDevice "Keyboard0" "CoreKeyboard" > EndSection > > Section "InputDevice" > # keyboard added by rhpxl > Identifier "Keyboard0" > Driver "kbd" > Option "XkbModel" "pc105" > Option "XkbLayout" "fr" > Option "XkbVariant" "latin9" > EndSection > > Section "Device" > Identifier "Videocard0" > Driver "intel" > Option "AddARGBGLXVisuals" "True" > Option "XAANoOffscreenPixmaps" "true" > Option "DRI" "true" > Option "AccelMethod" "EXA" # Xaa old stable, EXA > is new and better. > Option "MigrationHeuristic" "greedy" > # Option "ExaNoComposite" "true" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Virtual 3072 3072 > EndSubSection > EndSection > > Section "Module" > Load "extmod" > Load "glx" > Load "dbe" > Load "dri" > Load "freetype" > EndSection > > > glxinfo shows: > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.2 > server glx extensions: > GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group > client glx vendor string: SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > GLX version: 1.2 > GLX extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, > GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > OpenGL vendor string: Tungsten Graphics, Inc > OpenGL renderer string: Mesa DRI Intel(R) 965GM 20061102 > OpenGL version string: 2.0 Mesa 7.1 rc1 > OpenGL extensions: > GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, > GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, > GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, > GL_ARB_shader_objects, GL_ARB_shading_language_100, > GL_ARB_shading_language_120, GL_ARB_shadow, > GL_ARB_texture_border_clamp, > GL_ARB_texture_compression, GL_ARB_texture_cube_map, > GL_ARB_texture_env_add, GL_ARB_texture_env_combine, > GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, > GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, > GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, > GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, > GL_ARB_vertex_shader, > GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, > GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, > GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, > GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, > GL_EXT_compiled_vertex_array, > GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, > GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, > GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, > GL_EXT_rescale_normal, GL_EXT_secondary_color, > GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, > GL_EXT_stencil_wrap, > GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, > GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, > GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, > GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, > GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, > GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, > GL_APPLE_client_storage, GL_APPLE_packed_pixels, > GL_ATI_blend_equation_separate, GL_ATI_separate_stencil, > GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, > GL_INGR_blend_func_separate, GL_MESA_pack_invert, > GL_MESA_ycbcr_texture, > GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, > GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection, > GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format, > GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, > GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, > GL_SUN_multi_draw_arrays > > 3 GLX Visuals > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > ---------------------------------------------------------------------- > 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x55 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > > 36 GLXFBConfigs: > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > ---------------------------------------------------------------------- > 0x56 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x58 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x5b 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x5c 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x5d 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x5e 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x5f 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x60 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x61 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x62 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x63 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x64 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x65 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x66 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x67 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x68 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x69 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x6a 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x6b 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x6c 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x6d 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x6e 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x6f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x70 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x71 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x72 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x73 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x74 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x75 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x76 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x77 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x78 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x79 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > > |
|
From: PHAM Q. C. <qc...@ya...> - 2009-04-16 15:49:07
|
Hi
I am using intel driver on Fedora 9 with DRI
I would like to use extension GL_EXT_framebuffer_object but it seems to be disabled.
Any idea ?
my xorg.conf :
# Xorg configuration created by pyxf86config
Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
# keyboard added by rhpxl
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "fr"
Option "XkbVariant" "latin9"
EndSection
Section "Device"
Identifier "Videocard0"
Driver "intel"
Option "AddARGBGLXVisuals" "True"
Option "XAANoOffscreenPixmaps" "true"
Option "DRI" "true"
Option "AccelMethod" "EXA" # Xaa old stable, EXA is new and better.
Option "MigrationHeuristic" "greedy"
# Option "ExaNoComposite" "true"
EndSection
Section
"Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Virtual 3072 3072
EndSubSection
EndSection
Section "Module"
Load "extmod"
Load "glx"
Load "dbe"
Load "dri"
Load "freetype"
EndSection
glxinfo shows:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx
extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM 20061102
OpenGL version string: 2.0 Mesa 7.1 rc1
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite,
GL_ARB_shader_objects, GL_ARB_shading_language_100,
GL_ARB_shading_language_120, GL_ARB_shadow, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,
GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array,
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB,
GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1,
GL_APPLE_client_storage, GL_APPLE_packed_pixels,
GL_ATI_blend_equation_separate, GL_ATI_separate_stencil,
GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture,
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent,
GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection,
GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SUN_multi_draw_arrays
3 GLX Visuals
visual x bf lv rg d
st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x55 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
36 GLXFBConfigs:
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b
eat
----------------------------------------------------------------------
0x56 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x57 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x58 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x59 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x5b 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0
Slow
0x5c 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x5d 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x5e 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x5f 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x60 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x61 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x62 0 tc 0 32 0 r . . 8 8 8 8 0
24 8 0 0 0 0 0 0 None
0x63 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x64 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x65 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x66 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x67 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x68 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x69 0 dc 0 32 0
r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6a 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x6b 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6c 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x6d 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6e 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x6f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16
16 0 0 Slow
0x70 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x71 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x72 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x73 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x74 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x75 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x76 0 dc 0 32 0 r y . 8 8 8
8 0 24 8 0 0 0 0 0 0 None
0x77 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x78 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x79 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
|
|
From: Lars H. W. <lh...@ig...> - 2009-04-16 15:29:22
|
Hi,
it seems that I found a Bug in the attrib.c _mesa_PopAttrib()
in Line 1179 it should be
>/* restore clip planes */
>for (i = 0; i < MAX_CLIP_PLANES; i++) {
> const GLuint mask = 1 << i;
instead of
>const GLuint mask = 1 << 1;
I'm working with mesa 7.4
Best regards
Lars Henning Wendt
|
|
From: José J. <lis...@fr...> - 2009-04-07 08:14:30
|
A Tuesday 7 April 2009 09:21:15, c3kkos escreveu: > IRQ 5 is bound to the SOLO-1 at boot time and is bound again to the > drm/mach64 when xorg load up his modules. > As far as I have experimented, IRQ sharing gives no problems on PCI cards... But still you can disable the sound card in the BIOS and see if Mach64 works better. The last time I managed to use it was with a Mandriva 2008 Spring, so a 2.6.24 kernel. Then, 3D never worked on more recent systems. Anyway, the 3D of such a card is so bad, I'd suggest you forgetting using it on Linux. Simple example : most of the 3D open-source games use much more than 8MB of video RAM. |
|
From: c3kkos <c3...@ho...> - 2009-04-07 07:21:29
|
I know i'm filling up your mailboxes but this is now n open challenge for me.
Here i have cat'ed my /proc/interrupts:
CPU0
0: 11869 XT-PIC-XT timer
1: 377 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 2 XT-PIC-XT
4: 2 XT-PIC-XT
5: 0 XT-PIC-XT ES1938, mach64@pci:0000:01:00.0
6: 5 XT-PIC-XT floppy
7: 2 XT-PIC-XT
8: 2 XT-PIC-XT rtc0
9: 0 XT-PIC-XT acpi
10: 5 XT-PIC-XT
11: 743 XT-PIC-XT uhci_hcd:usb1, yenta, yenta
12: 4472 XT-PIC-XT i8042
14: 2659 XT-PIC-XT ide0
15: 1473 XT-PIC-XT ide1
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
----------------------------------------------------------
it's now clear that i'm facing a irq problem. indeed the drm module does not
like sharing the bus with
the audio data trunks. I think trying to have a different pci latency
timings setup is a waste of time. The bios does not have any option to
manipulate the plug-n-play system..
IRQ 5 is bound to the SOLO-1 at boot time and is bound again to the
drm/mach64 when xorg load up his modules.
I've to find out how i can modify the solo-1 irq assignment via software..
cause the other way is the old "jumpers way" but since i'm using a
notebook.. i can hardly think there're some upon my hardware..
any suggestions? i've looked for a script set called rtirq that maybe can be
useful but it can be used, as the name already tells, with the real-time
kernels..
Ahuuuuuu!!!!!!!!
--
View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22922682.html
Sent from the mesa3d-users mailing list archive at Nabble.com.
|
|
From: c3kkos <c3...@ho...> - 2009-04-06 21:01:59
|
just a little update i was too excited to notice that the problems i've encountered are IRQ related. As i write just before in my first post in this thread, i always had a bad feeling about that and i've just checked that in my laptop IRQ 5 is shared between the video adapter and the audio chipset. mach64 and ESS SOLO-1 Tryin to find out how to resolve this problem.. uah... i'm facing a neverending story -- View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22917297.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: c3kkos <c3...@ho...> - 2009-04-06 19:43:36
|
Gotcha, my friends! I'm about to tell you i made a step forward! Well.. just to remind u: running a net-inst (businness card) Debian testing with the latest bleedin' edge kernel 2.6.29 I've installed from the apt system my whole system up to my needs The thing that IS NOT included in the vanilla kernel is the famous drm.ko && mach64.ko which are made by git cloning the latest DRM support sources from the freedesktop.org site. compiling and installing those modules you have kernel support to obtain the DRI layer on your X server Problem was: if you let the system load automatically all those modules the machine hangs with an ugly kernel panic!! BUT... I've killed the X init script from my /etc/rc.2/ to let the system boots in text (bash) old-fashioned-style mode Since i've created my custom-monolithic kernel i've not any modules to load BUT those two drm.ko && mach64.ko that i've compiled separately Those modules will NOT load at boot time. (dmesg|grep drm == NULL) I've found out that if, in this state, i issue from shell the command "startx" the X server LOADS without goin' in PANIC!! I've made it too long so far. it's time to post some logs and outputs, here we go X logs excerp: ============================================= drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables. (II) MACH64(0): [drm] framebuffer handle = 0x81000000 (II) MACH64(0): [drm] added 1 reserved context for kernel (II) MACH64(0): X context handle = 0x1 (II) MACH64(0): [drm] installed DRM signal handler (II) MACH64(0): [drm] Will request asynchronous DMA mode (**) MACH64(0): [dri] Forcing PCI mode (==) MACH64(0): [drm] Using 2 MB for DMA buffers (II) MACH64(0): [pci] ring handle = 0x054e4000 (II) MACH64(0): [pci] Ring mapped at 0xb709c000 (II) MACH64(0): [drm] register handle = 0x80500000 (II) MACH64(0): [dri] Visual configs initi(II) MACH64(0): [dri] Block 0 base at 0x80500400 (II) MACH64(0): Memory manager initialized to (0,0) (1024,4095) (II) MACH64(0): Largest offscreen area available: 1024 x 3327 (II) MACH64(0): Will use 1598 kB of offscreen memory for XAA (II) MACH64(0): Will use back buffer at offset 0x30f800 (II) MACH64(0): Will use depth buffer at offset 0x48f800 (II) MACH64(0): Will use 1985 kB for local textures at offset 0x60f800 (II) MACH64(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Setting up tile and stipple cache: 32 128x128 slots 18 256x256 slots 6 512x512 slots (==) MACH64(0): Backing store disabled (==) MACH64(0): Silken mouse enabled (II) MACH64(0): DPMS enabled (II) MACH64(0): [DRI] installation complete (II) MACH64(0): [drm] Added 128 16384 byte DMA buffers (II) MACH64(0): [drm] Mapped 128 DMA buffers at 0xb6e9c000 (II) MACH64(0): [drm] Installed interrupt handler, using IRQ 5 (II) MACH64(0): Direct rendering enabled (==) RandR enabled ============================================= And here we go with the glxinfo output! ============================================= leech:/home/c3kko# glxinfo name of display: :0.0 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Gareth Hughes, Leif Delgass, Jos Fonseca OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 x86/MMX/SSE OpenGL version string: 1.2 Mesa 7.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_object, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x2d 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2f 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x30 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x31 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x32 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x4c 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon ============================================= Please notice the three most important lines from that amount of text up above: 1) (II) MACH64(0): Direct rendering enabled 2) direct rendering: Yes 3) OpenGL vendor string: Gareth Hughes, Leif Delgass, Jos Fonseca OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 x86/MMX/SSE OpenGL version string: 1.2 Mesa 7.0.4 ============================================= Now.. k i've got DRI on mach64 that's wonderful.. but... i've encountered some problems.. well, glxgears works well, along with all those fancy GL screensavers.. but....... the systems still hangs, goin' panic again, if i make intense use of flash player 10 + iceweasel(firefox) or when i try to fire up extremetuxracer For the flash player.. i know that from the v10 the stream can be hardware-accellerated and there might be some scary problems. Somehow i'm still able to see some frames... the crash occours randomly but after only a few seconds. Extremetuxracer hangs the system without drawing a single colored pixel upon the screen.. it's strange and it can be issued by some erroneous configuration.. WE KNOW very well that our beloved mach64 chip (01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) works only UP TO a 16bit depth and 1024x768 screening configuration.. so if the little wheeled tux tries to overcome (or probe) that settings.. well he has all the reason to spit out a bliking capslock on my laptop! So far, my friend... i'm writing to you on my DRI ENABLED but still very, very and sadly UNSTABLE mach64-powered laptop. Might this little and awful review useful for future development. I want to introduce myself. I'm a 1984 class italian boy my name is Davide and i really can't take a chance on improving the mach64 support code. i'm not familiar in programming, i'm just a linux-lover and i'm using this mailing-list site for the first time, even if i've read TONS of them all 'round the net. I'm about to write some lines or just post the link to this webpage to the authors listed in the glxinfo. I just want to thank those person who helped in the driver development. i want them to know there's still somebody like me that rely upon their code. "Gareth Hughes, Leif Delgass, Jos Fonseca" Davide Ceccherini. Pisa, Italy EOF. -- View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22915795.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Chris J. <cjn...@gm...> - 2009-04-05 03:29:50
|
On Fri, Apr 03, 2009 at 11:53:22AM EDT, c3kkos wrote: > > Ok i've got the same here > > old Acer Travelmate 743tl > > with the ugly mach64 chip on it. the M, agp 2x version...... Same as me, it's the agp version of the card/chip. Only system where I got dri to work on this hardware was debian sarge with a 2.4 kernel and I do remember that I needed to load the agpgart kernel module prior to loading the mach64 kernel module. Two other things that I learned the hard way was that I needed was to run X with 16-bit color and a screen resolution that was compatible with the Mach64's miserly memory. My laptop's LCD's native resolution is 1400x1050 but in order to get dri to work, I had to downgrade to 1024x768. Since I never got it to work on debian "etch" on the same laptop, I still have this old "sarge" system on a separate partition. > i've compilated my own kernel module from the git source.. and that > spits out two .ko listed in: > /lib/modules/'uname -r'/kernel/drivers/char/drm/drm.ko && mach64.ko > well.. everything seems to run fine.. those modules loads with NO > PROBLEMS at all.. [..] > Straight to the point: > at this time, it seems that DRM for mach64 + Xorg cause a kernel panic > (no logs are created from X, so i think that happens BEFORE the > graphical server loads up) In any event, please forget everything I said regarding ubuntu. I don't understand what the ubuntu packagers did in this respect, but having had the time to look more closely at the output of glxinfo, I noticed that although it says "direct rendering: yes" it also has something that doesn't look promising a few lines down: "OpenGL Renderer: Software Rasterizer". Hmm... So, I rebooted to my old sarge system and sure enough, glxinfo says: "Direct Rendering: Yes" _but_ it also says: "OpenGL Renderer: Mesa DRI Mach64". Not knowing exactly what this glxinfo renderer stuff really means, I thought I'd run a few "tests" with some xscreensaver stuff (antinspect, glmatrix, blocktube, dangerball, GLForestFire.. etc.) as well as glxgears on both my old sarge system and the ubuntu system (on the same multi-boot laptop) and compare the results. Well, the difference was immediately noticeable and also quite measurable, at least if you trust the -fps options of these programs. Basically, on my old sarge system I was consistently getting FPS rates that were roughly 5+ times higher than on the ubuntu system where dri is supposedly enabled. True, I'm probably running different versions of these programs, since the stuff in the sarge repositories must be about 5 years older than the ubuntur stuff.. but all the same, there does seem to be a pattern. As an example, at the same color depth, same resolution, glxgears is just short of 300 FPS on my old debian sarge system. When I ran it on ubuntu, it did about 56 FPS..! So, to paraphrase what you said, I thought dri was a matter of 1, you have it, or 0 you don't.. Not so, the ubuntu packagers seem to have it "half-enabled". :-) > my kernel is 2.6.29 on a Debian box. COME ON BOYS LET'S TRY TO SOLVE > THIS!! +1 The "ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)" is probably not powerful enough to make much difference for a lot of stuff, even with dri fully (?) enabled, but on my old "sarge" system I was able to play (or demo) Heretic II with all textures and visual effects enabled via the "GL renderer" and Tuxracer was tolerably responsive.. So, even though getting this to work is not one of my priorities, I would really like to understand this stuff a little better and I _do_ wish someone knowledgeable could spare a couple of minutes and give us a few pointers. Thanks, CJ |
|
From: c3kkos <c3...@ho...> - 2009-04-03 15:53:30
|
Ok i've got the same here old Acer Travelmate 743tl with the ugly mach64 chip on it. the M, agp 2x version...... WELL trouble is: i've compilated my own kernel module from the git source.. and that spits out two .ko listed in: /lib/modules/'uname -r'/kernel/drivers/char/drm/drm.ko && mach64.ko well.. everything seems to run fine.. those modules loads with NO PROBLEMS at all.. when Xorg boots up the computer hangs with blank screen and the blinking caps lock, indicating a tremendous kernel panic.. The BAD thing is i got the entire system running up only ONCE :O THAT'S CRAZY "ONCE" can't just simply happen in a computer... LOL i mean... is 0 or 1 i really dunno what i've done to make it RUN... i simply powered on the laptop... and see everything was ok.. Aterm -> glxinfo... DIRECT RENDERING YES!!! AMAZING...... than.. dunno why.. i switched to the "naked" bash through CTRL+ALT+F1 key combo.. typed "TOP" to see ram usage for a "fully functioning system".. then trying to return to X (CTRL+ALT+F7) the thing crashed down again.. and so on, so on.. with no success for now. I cannot trace the panic. I tryed to load X without the drm module loaded, and it runs fine but of course with DRI SET OFF which is definitely NOT my goal. Straight to the point: at this time, it seems that DRM for mach64 + Xorg cause a kernel panic (no logs are created from X, so i think that happens BEFORE the graphical server loads up) my kernel is 2.6.29 on a Debian box. COME ON BOYS LET'S TRY TO SOLVE THIS!! ps. can this issue be IRQ related?? -- View this message in context: http://www.nabble.com/mach64-kernel-modules-for-2.6.26-kernel-tp22668419p22870470.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
23 messages has been excluded from this view by a project administrator.
