Re: [debian-x] DRI device permissions
Hello, If you want to be able to access the dri by a normal user you need to either create a dri group or open the premissions up to everybody with a chmod -R 666 /dev/dri Gordon. * Will Newton ([EMAIL PROTECTED]) wrote: Direct rendering is only working for root on my system (unstable/4.1.0). The permissions for the DRI device files are: /dev/dri: drwxrwx---2 root root 4096 Aug 1 15:22 dri /dev/dri/*: crw-rw1 root root 10, 63 Aug 1 15:22 card0 glxinfo as non-root: [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering Are my permissions incorrect? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Gordon Heydon [EMAIL PROTECTED]
dri and shared memory
Hello, I have installed the new dri packages, and at last I have 3gl, I am getting ~100 fps with the evas_test on my g400. but I do have on problem. With enlightenment and imlib1 it can't seem to detect the shared memory, which also seems to cause the latest version of gnome panel crash as well. Can anyone give me any ideas on how to resolve this problem -- Gordon Heydon [EMAIL PROTECTED]
dri and shared memory
Hello, I have installed the new dri packages, and at last I have 3gl, I am getting ~100 fps with the evas_test on my g400. but I do have on problem. With enlightenment and imlib1 it can't seem to detect the shared memory, which also seems to cause the latest version of gnome panel crash as well. Can anyone give me any ideas on how to resolve this problem -- Gordon Heydon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [E-devel] Problem when testing for XShmAttach()
Hello, Thanks for the help, it actually proved handy, the libc5-compat was the key, I had some stuff handing around, from where I don't know, but I get rid of it, and not everything is working.. Cool. Thanks Gordon * Matt Schalit ([EMAIL PROTECTED]) wrote: Gordon Heydon wrote: Thanks for your help, but I didn't really get me too far, I checked it and it looked a bit wierd (well to me) libX11.so.6 = /usr/lib/libc5-compat/libX11.so.6 (0x4001b000) libc.so.6 = /lib/libc.so.6 (0x400b7000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2000) The dependancy on the libc5-compat version of libX11 looks funny to me, and I did have libc5 on my system and I not so long ago I had removed it as I wasn't using it. I did try to reinstall it, but still the same problem. I am not really sure still where to go from here, but I will keep on working. Thanks Gordon. No problem Gordon. I know it's not fun to get stuck on these. I tried a google search for _XLockMutex_fn and for the other functions it was choking on, trying to find what lib they come from. I got some hits, but gave up. You'd probably get somewhere with a bit of digging. FWIW, I can't get my Shm stuff to work correctly with E16 and Gnome, even though I solved all my dependancy problems. Regards, Matthew ___ Enlightenment-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [E-devel] Problem when testing for XShmAttach()
Hello, Thanks for the help, it actually proved handy, the libc5-compat was the key, I had some stuff handing around, from where I don't know, but I get rid of it, and not everything is working.. Cool. Thanks Gordon * Matt Schalit ([EMAIL PROTECTED]) wrote: Gordon Heydon wrote: Thanks for your help, but I didn't really get me too far, I checked it and it looked a bit wierd (well to me) libX11.so.6 = /usr/lib/libc5-compat/libX11.so.6 (0x4001b000) libc.so.6 = /lib/libc.so.6 (0x400b7000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2000) The dependancy on the libc5-compat version of libX11 looks funny to me, and I did have libc5 on my system and I not so long ago I had removed it as I wasn't using it. I did try to reinstall it, but still the same problem. I am not really sure still where to go from here, but I will keep on working. Thanks Gordon. No problem Gordon. I know it's not fun to get stuck on these. I tried a google search for _XLockMutex_fn and for the other functions it was choking on, trying to find what lib they come from. I got some hits, but gave up. You'd probably get somewhere with a bit of digging. FWIW, I can't get my Shm stuff to work correctly with E16 and Gnome, even though I solved all my dependancy problems. Regards, Matthew ___ Enlightenment-devel mailing list Enlightenment-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem when testing for XShmAttach()
Thanks for your help, but I didn't really get me too far, I checked it
and it looked a bit wierd (well to me)
libX11.so.6 = /usr/lib/libc5-compat/libX11.so.6 (0x4001b000)
libc.so.6 = /lib/libc.so.6 (0x400b7000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2000)
The dependancy on the libc5-compat version of libX11 looks funny to me,
and I did have libc5 on my system and I not so long ago I had removed it
as I wasn't using it. I did try to reinstall it, but still the same
problem.
I am not really sure still where to go from here, but I will keep on
working.
Thanks
Gordon.
* Matt Schalit ([EMAIL PROTECTED]) wrote:
Gordon Heydon wrote:
Hello,
I am posting this to both the e-development and the debian-x as I am not
exactly not which list to send it too.
When I am triing to build imlib2 it fails during the configure I get the
error below from the config.log :-
configure:2964: checking for XShmAttach in -lXext
configure:2983: gcc -o conftest -g -O2 conftest.c -lXext
-L/usr/X11R6/lib 1
5
/usr/X11R6/lib/libXext.so: undefined reference to `_Xglobal_lock'
/usr/X11R6/lib/libXext.so: undefined reference to `_XUnlockMutex_fn'
/usr/X11R6/lib/libXext.so: undefined reference to `_XLockMutex_fn'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2972 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char XShmAttach();
int main() {
XShmAttach()
; return 0; }
So either there is unmet dependancies in Xext or imlib2 is not including
something that it should be. maybe I am right, maybe I am wrong, but can
someone help me.
Now I am not too sure where to go from here, Could some please help me.
Gordon.
You probably got the answer by now, but if not, the answer is that
you can do an ldd /usr/X11R6/lib/libXext.so and see what all the
dependancies are.
Usually what I also do is just do a man on the function it can't find,
like man mutex_lock. It was likely that you Xext was compiled to use
threads, so you need to add a LIBS=-lthread or -lpthread or whatever
you find with man or ldd.
Take it easy,
Matt
Problem when testing for XShmAttach()
Hello,
I am posting this to both the e-development and the debian-x as I am not
exactly not which list to send it too.
When I am triing to build imlib2 it fails during the configure I get the
error below from the config.log :-
configure:2964: checking for XShmAttach in -lXext
configure:2983: gcc -o conftest -g -O2 conftest.c -lXext -L/usr/X11R6/lib 1
5
/usr/X11R6/lib/libXext.so: undefined reference to `_Xglobal_lock'
/usr/X11R6/lib/libXext.so: undefined reference to `_XUnlockMutex_fn'
/usr/X11R6/lib/libXext.so: undefined reference to `_XLockMutex_fn'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2972 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char XShmAttach();
int main() {
XShmAttach()
; return 0; }
So either there is unmet dependancies in Xext or imlib2 is not including
something that it should be. maybe I am right, maybe I am wrong, but can
someone help me.
Now I am not too sure where to go from here, Could some please help me.
Gordon.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem when testing for XShmAttach()
Hello,
I am posting this to both the e-development and the debian-x as I am not
exactly not which list to send it too.
When I am triing to build imlib2 it fails during the configure I get the
error below from the config.log :-
configure:2964: checking for XShmAttach in -lXext
configure:2983: gcc -o conftest -g -O2 conftest.c -lXext -L/usr/X11R6/lib 1
5
/usr/X11R6/lib/libXext.so: undefined reference to `_Xglobal_lock'
/usr/X11R6/lib/libXext.so: undefined reference to `_XUnlockMutex_fn'
/usr/X11R6/lib/libXext.so: undefined reference to `_XLockMutex_fn'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2972 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char XShmAttach();
int main() {
XShmAttach()
; return 0; }
So either there is unmet dependancies in Xext or imlib2 is not including
something that it should be. maybe I am right, maybe I am wrong, but can
someone help me.
Now I am not too sure where to go from here, Could some please help me.
Gordon.
compile problems.
Hello, I am having a problem compiling imlib2 it seems that the XShmAttach doesn't seem to exist anymore. I have the latest version of the deb's from brandens development area. Gordon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
compile problems.
Hello, I am having a problem compiling imlib2 it seems that the XShmAttach doesn't seem to exist anymore. I have the latest version of the deb's from brandens development area. Gordon.
Re: [debian-x] 3gl working extremely slow.
* Seth Arnold ([EMAIL PROTECTED]) wrote: * Gordon Heydon [EMAIL PROTECTED] [00 23:06]: I am having some problem getting 3gl to work correctly on my matrox g400. I have installed the mesa drivers that come with the XFree 4.0.1 debs, and I have also gotting the libglu from the current unstable version of mesa. Gordon, getting everything right is damn near impossible. Thank your own deity that Branden has done most of the work for us already. :) Currently, I don't use libGLU, but copying the one libGLU library out of the package is probably sufficient. From Reading this list and studding the archives it sujested getting from another package. What I have found about getting my g400Max to do GLX is that it requires using XFree86's mga_drv.o driver, loading the agpgart and mga kernel modules (I use 2.4.0-test10 with good success, and perhaps 2.2.18-presomething would have the same effect, but that may require kernel drivers from dri.sourceforge.net) and having the right mix of packages installed. I don't think it takes any of the mesa packages. As I am only using a single head with my dual head card this is what I am using, I am going to play with dual head sometime when I get a bit of a chance. I basically have the same setup, 2.4.0-test10, the latest debs, and the agpgart and the mga modules loaded, but one thing does puzzle me, it the the mga module is not in use, So I don't think something is quite right. To get the g400Max to do dual-head requires using matrox's mga_drv.o file. I'm not sure if agpgart and mga need to be unloaded or not from the kernel, but I do, to save memory. You will also need to tweak your XF86Config-4 file to load the glx, dri, GLCore, and dbe modules. (I have two config files, one to describe both monitors, one to describe only one monitor, and I switch between the two when I want GL to work.) I have all these modules loaded. Yes, it is a bit annoying, but not enough to cause me to learn how to program these things for the accelerated OpenGL while running dual-head. Thanks for the help. Gordon. HTH Some useful package information: $ dpkg -l '*mesa*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- un mesa-dev none (no description available) pn mesademos none (no description available) pn mesag-dev none (no description available) pn mesag-glide2-d none (no description available) pn mesag-widgets- none (no description available) pn mesag3 none (no description available) pn mesag3+ggi none (no description available) pn mesag3+ggi-dev none (no description available) un mesag3-glide none (no description available) pn mesag3-glide2 none (no description available) pn mesag3-widgets none (no description available) ii xlibmesa3 4.0.1-1XFree86 version of Mesa 3D graphics library ii xlibosmesa34.0.1-1XFree86 version of Mesa off-screen rendering $ dpkg -l 'x*' | grep 4.0 ii xbase-clients 4.0.1-1miscellaneous X clients ii xfonts-75dpi 4.0.1-175 dpi fonts for X ii xfonts-base4.0.1-1standard fonts for X ii xfonts-pex 4.0.1-1fonts for minimal PEX support in X ii xfonts-scalabl 4.0.1-1scalable fonts for X ii xfree86-common 4.0.1-1X Window System (XFree86) infrastructure ii xfwp 4.0.1-1X firewall proxy server ii xlib6g 4.0.1-1pseudopackage providing X libraries ii xlib6g-dev 4.0.1-1pseudopackage providing X library developmen ii xlibmesa3 4.0.1-1XFree86 version of Mesa 3D graphics library ii xlibosmesa34.0.1-1XFree86 version of Mesa off-screen rendering ii xlibs 4.0.1-1X Window System client libraries ii xlibs-dev 4.0.1-1X Window System client library development f ii xnest 4.0.1-1nested X server ii xprt 4.0.1-1X print server ii xserver-common 4.0.1-1files and utilities common to all X servers ii xserver-xfree8 4.0.1-1the XFree86 X server ii xterm 4.0.1-1X terminal emulator ii xutils 4.0.1-1XFree86 utility programs ii xvfb 4.0.1-1virtual framebuffer X server -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
3gl working extremely slow.
hello, I am having some problem getting 3gl to work correctly on my matrox g400. I have installed the mesa drivers that come with the XFree 4.0.1 debs, and I have also gotting the libglu from the current unstable version of mesa. The problem comes when I run the new enlightenment 3gl programs such as evas and in hardware mode it is jumpy and seems to only about 1 or 2 frames per second. I am not too sure what is wrong as I have seen some other people who are getting much much higher frame rates. I home someone can help me. Thanks Gordon.
Re: [debian-x] 3gl working extremely slow.
* Seth Arnold ([EMAIL PROTECTED]) wrote: * Gordon Heydon [EMAIL PROTECTED] [00 23:06]: I am having some problem getting 3gl to work correctly on my matrox g400. I have installed the mesa drivers that come with the XFree 4.0.1 debs, and I have also gotting the libglu from the current unstable version of mesa. Gordon, getting everything right is damn near impossible. Thank your own deity that Branden has done most of the work for us already. :) Currently, I don't use libGLU, but copying the one libGLU library out of the package is probably sufficient. From Reading this list and studding the archives it sujested getting from another package. What I have found about getting my g400Max to do GLX is that it requires using XFree86's mga_drv.o driver, loading the agpgart and mga kernel modules (I use 2.4.0-test10 with good success, and perhaps 2.2.18-presomething would have the same effect, but that may require kernel drivers from dri.sourceforge.net) and having the right mix of packages installed. I don't think it takes any of the mesa packages. As I am only using a single head with my dual head card this is what I am using, I am going to play with dual head sometime when I get a bit of a chance. I basically have the same setup, 2.4.0-test10, the latest debs, and the agpgart and the mga modules loaded, but one thing does puzzle me, it the the mga module is not in use, So I don't think something is quite right. To get the g400Max to do dual-head requires using matrox's mga_drv.o file. I'm not sure if agpgart and mga need to be unloaded or not from the kernel, but I do, to save memory. You will also need to tweak your XF86Config-4 file to load the glx, dri, GLCore, and dbe modules. (I have two config files, one to describe both monitors, one to describe only one monitor, and I switch between the two when I want GL to work.) I have all these modules loaded. Yes, it is a bit annoying, but not enough to cause me to learn how to program these things for the accelerated OpenGL while running dual-head. Thanks for the help. Gordon. HTH Some useful package information: $ dpkg -l '*mesa*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- un mesa-dev none (no description available) pn mesademos none (no description available) pn mesag-dev none (no description available) pn mesag-glide2-d none (no description available) pn mesag-widgets- none (no description available) pn mesag3 none (no description available) pn mesag3+ggi none (no description available) pn mesag3+ggi-dev none (no description available) un mesag3-glide none (no description available) pn mesag3-glide2 none (no description available) pn mesag3-widgets none (no description available) ii xlibmesa3 4.0.1-1XFree86 version of Mesa 3D graphics library ii xlibosmesa34.0.1-1XFree86 version of Mesa off-screen rendering $ dpkg -l 'x*' | grep 4.0 ii xbase-clients 4.0.1-1miscellaneous X clients ii xfonts-75dpi 4.0.1-175 dpi fonts for X ii xfonts-base4.0.1-1standard fonts for X ii xfonts-pex 4.0.1-1fonts for minimal PEX support in X ii xfonts-scalabl 4.0.1-1scalable fonts for X ii xfree86-common 4.0.1-1X Window System (XFree86) infrastructure ii xfwp 4.0.1-1X firewall proxy server ii xlib6g 4.0.1-1pseudopackage providing X libraries ii xlib6g-dev 4.0.1-1pseudopackage providing X library developmen ii xlibmesa3 4.0.1-1XFree86 version of Mesa 3D graphics library ii xlibosmesa34.0.1-1XFree86 version of Mesa off-screen rendering ii xlibs 4.0.1-1X Window System client libraries ii xlibs-dev 4.0.1-1X Window System client library development f ii xnest 4.0.1-1nested X server ii xprt 4.0.1-1X print server ii xserver-common 4.0.1-1files and utilities common to all X servers ii xserver-xfree8 4.0.1-1the XFree86 X server ii xterm 4.0.1-1X terminal emulator ii xutils 4.0.1-1XFree86 utility programs ii xvfb 4.0.1-1virtual framebuffer X server -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Hardware GL with a G400
Hello, This is a simple question, can anyone tell me how to or better point me in the direction of some documentation on how to get hardware 3gl going with my dual head g400 (I am only using 1 head at the moment) with the Xfree 4.0.1 debs found here. Thanks in advance Gordon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-x] Hardware GL with a G400
Hello, Thanks, but what about the libGLU and libGL libraries? don't you need those. At the moment I have the Utah ones is that enough. Gordon. * Seth Arnold ([EMAIL PROTECTED]) wrote: Gordon, you are in luck, this was my situation exactly. Go to matrox.com, find their drivers section, and download their linux driver. It should be one file. Be sure to take a look at their readme, it is good enough to get you installed. (except for the bit about groups and DRI don't bother with setting a group for DRI.) You will need a recent kernel. I use 2.4.0-test7. I built my kernel with agpgart and mga modules available. They may or may not be needed. I'd bet agpgart is required, mga isn't. shrug There are two ways of getting Matrox's mga_drv.o into use -- replace XFree86's version in /usr/X11R6/lib/modules/drivers/ with matrox's (clunky, will get overwritten with each new xf86 upgrade unless you use dpkg diversions...) -or- (the recommended way) is to use a direct path in your /etc/X11/XF86Config-4 file to load the new module. I haven't gone this route (lazy) but suggest you do. Sadly, I don't know the syntax for this, so I suggest you look for all of Branden's postings in the archives for more information about this. (Perhaps he mentioned it in a thread with someone from nvidia...) Once things are in place, modprobe agpgart, modprobe mga, and startx. I have attached my XF86Config file for reference... * Gordon Heydon [EMAIL PROTECTED] [001013 00:14]: Hello, This is a simple question, can anyone tell me how to or better point me in the direction of some documentation on how to get hardware 3gl going with my dual head g400 (I am only using 1 head at the moment) with the Xfree 4.0.1 debs found here. Thanks in advance Gordon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Section ServerLayout Identifier Dual Screen Screen0 RightOf Screen1 Screen Screen1 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard Option Xinerama EndSection Section ServerLayout Identifier Single Screen Screen0 InputDevice Mouse0 CorePointer InputDevice Keyboard0 CoreKeyboard EndSection Section Files FontPath /usr/X11R6/lib/X11/fonts/freefont/ FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/Speedo/ FontPath /usr/X11R6/lib/X11/fonts/PEX/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/:noscale FontPath /usr/X11R6/lib/X11/fonts/misc/:noscale EndSection Section Module Load GLcore Load dbe Load dri Load extmod Load glx Load pex5 Load record Load xie Load freetype Load type1 EndSection Section InputDevice Identifier Keyboard0 Driver keyboard EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device /dev/mouse Option ZAxisMapping 4 5 EndSection Section Monitor Identifier Mitsubishi VendorName MEL ModelName42c0 HorizSync30.0 - 105.0 VertRefresh 70.0 - 152.0 Option DPMS #ModeLine 640x480 45.8 640 672 768 864 480 488 494 530 -HSync -VSync EndSection Section Monitor Identifier Sony HorizSync60.5 - 82.0 VertRefresh 65.0 - 100.0 Option DPMS EndSection Section Device Identifier G400_0 Driver mga VendorName Matrox BoardName MGA G400 AGP BusID PCI:1:0:0 Screen 0 EndSection Section Device Identifier G400_1 Driver mga VendorName Matrox BoardName MGA G400 AGP BusID PCI:1:0:0 Screen 1 EndSection Section Screen Identifier Screen0 Device G400_0 MonitorMitsubishi DefaultDepth 16 SubSection Display Depth 1 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection EndSection Section Screen
Re: [debian-x] Hardware GL with a G400
* Michael Epting ([EMAIL PROTECTED]) wrote: On Fri, Oct 13, 2000 at 08:06:45AM -0500, Thomas E. Vaughan wrote: On Fri, Oct 13, 2000 at 06:11:47PM +1100, Gordon Heydon wrote: This is a simple question, can anyone tell me how to or better point me in the direction of some documentation on how to get hardware 3gl going with my dual head g400 (I am only using 1 head at the moment) with the Xfree 4.0.1 debs found here. If you haven't done so already, then get the source code to kernel 2.4.0-test9. I compiled support for my AGP chipset directly into the kernel, and I recommend compiling the matrox DRI support as a module. I may be wrong, but it seems that, at least in the past, the X server liked to load the kernel module itself. After installing the new kernel and DRI module, remember to reboot. Dexter, the X configuration program that ran when I installed the most recent debs, made a fairly good approximation of an XF86Config-4 file for me. Make sure that you add the following lines: Section DRI Mode 0666 EndSection I have had an off-list exchange with Thomas that clarified but did not resolve a problem I have with DRI. I get hardware 3d acceleration, as he does, with 2.4.0-test9, which resolved the version mismatch of earlier kernel 2.4 releases. However, while X is running, my virtual consoles are not usable. It turns out that the major difference between our installations is hardware -- I have an ASUS P5A motherboard with the ALI chipset. Does anybody have DRI working with the G400/P5A combination? (or any other ALI-based motherboard?) Hello, I have a ALI based board and it does the some thing, but when I try to get run the evas test with hardware I get [EMAIL PROTECTED]:~/src/evas/test$ ./evas_test @@Created GLX Context.. X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 145 () Serial number of failed request: 894 Current serial number in output stream: 894 [EMAIL PROTECTED]:~/src/evas/test$ and the evas_test_old onlu gets about 8.6 frames per second. I must have missed something or it is in the libraries, I have a funny feeling I need different ones to the utah ones that I triied to use when I first go the G400. Gordon.
Re: [debian-x] A small question
Thanks - I didn't relise that it did that now in my smaller resolutions did the pan and scan thing Oh well I will have to play with the fonts and stuff so I can use it quite easily. Thanks again Gordon. * Seth Arnold ([EMAIL PROTECTED]) wrote: Gorden, I have a suggestion; while I have 1600x1200 in my Modes line, I also run 1600x1200 all the time. So, I can't say one way or another if this will work. But, if I were a programmer at XFree86, I would start up in the first resolution listed with a desktop that size. Resolution changes downward would use a virtual desktop, resolution changes upward would increase (temporarily) the screen resolution. So, try putting 1600x1200 at the end of your Modes list. If that doesn't work, there is a Virtual entry in the display subsection. Full details are in XF86Config(5) (well, some details. Full details are in the source code. :) It might be able to help you. :) * Gordon Heydon [EMAIL PROTECTED] [000930 18:07]: Hello, First off I would like to thank Branden for all the great work he is doing. Secound I am having a little problem. I doing think it is a problem with the packages but more of a configuration problem. When I put the more 1600x1200 into my list of mode lines I get as expected 1600x1200 except that in all other resulutions I get a 1600x1200 screen size on a what ever resolution screen, the screen then does a pan and scan of the 1600x1200 area. I don't use 1600x1200 that offen but I do like to have it there without having to edit my XF86Config nd restart my X Server everytime. Thanks in advance Gordon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A small question
Hello, First off I would like to thank Branden for all the great work he is doing. Secound I am having a little problem. I doing think it is a problem with the packages but more of a configuration problem. When I put the more "1600x1200" into my list of mode lines I get as expected 1600x1200 except that in all other resulutions I get a 1600x1200 screen size on a what ever resolution screen, the screen then does a pan and scan of the 1600x1200 area. I don't use 1600x1200 that offen but I do like to have it there without having to edit my XF86Config nd restart my X Server everytime. Thanks in advance Gordon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A small question
Hello, First off I would like to thank Branden for all the great work he is doing. Secound I am having a little problem. I doing think it is a problem with the packages but more of a configuration problem. When I put the more 1600x1200 into my list of mode lines I get as expected 1600x1200 except that in all other resulutions I get a 1600x1200 screen size on a what ever resolution screen, the screen then does a pan and scan of the 1600x1200 area. I don't use 1600x1200 that offen but I do like to have it there without having to edit my XF86Config nd restart my X Server everytime. Thanks in advance Gordon.
