Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 12:48:32PM -0500, Ben Collins wrote: > On Wed, Dec 20, 2000 at 10:28:44AM -0700, Joshua Shagam wrote: > > On Wed, Dec 20, 2000 at 12:07:31PM -0500, Ben Collins wrote: > > > > > > No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of > > > m68k) and it also does not build on all of our supported archs (m68k and > > > arm). > > > > On an x86 system running Woody: > > Obviously if you installed this before the "testing" dist was started, you > will have it installed. Okay, in this case, pardon my ignorance, but testing dist? When did this happen? :) I didn't think Woody was really old enough to warrant getting ready for a freeze... This is the first I'd heard of 'sid'. Actually, what character in Toy Story is that? > This is on ftp-master. So, yes, the old woody used to have it (when woody > was "unstable"), but the new woody doesn't (since it is now "testing"). > "Sid" is not "unstable". Okay, now I'm just confused. :) > You are probably looking at "unstable" and assuming it is "woody", when > now it isn't. Unstable is "sid". Yeah, that's what was going on. My bad. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 12:07:31PM -0500, Ben Collins wrote: > On Wed, Dec 20, 2000 at 05:51:15PM +0100, Charl P. Botha wrote: > > On Wed, Dec 20, 2000 at 04:58:06PM +0100, Michel Dänzer wrote: > > > "Charl P. Botha" wrote: > > > > > > > > On Wed, Dec 20, 2000 at 09:49:34AM -0500, Branden Robinson wrote: > > > > > I couldn´t find a Debian-package for XFree86 4.01 neither for potato > > > > > nor > > > > > for woody. > > > > > > > > You should've searched a bit harder. The XFree86 packages are > > > > available on > > > > any woody mirror in /dists/woody/main/binary-i386/x11/. > > > > > > Not anymore. woody is now testing, and doesn't have the new X yet. (it > > > doesn't > > > build on m68k and arm) > > > > > > It's currently only in unstable aka sid (right?). > > > > Wrong. Woody, aka testing, has XFree86-4.0.1-11. > > No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of > m68k) and it also does not build on all of our supported archs (m68k and > arm). On an x86 system running Woody: Package: libc6 Status: install ok installed Priority: required Section: base Installed-Size: 8226 Maintainer: Ben Collins <[EMAIL PROTECTED]> Source: glibc Version: 2.2-5 Package: xfree86-common Status: install ok installed Priority: optional Section: x11 Installed-Size: 716 Maintainer: Branden Robinson <[EMAIL PROTECTED]> Source: xfree86 Version: 4.0.1-11 > So there is no way it can be in testing. But the packages are in Woody (on the x86 architecture, anyway) nontheless. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 12:48:32PM -0500, Ben Collins wrote: > On Wed, Dec 20, 2000 at 10:28:44AM -0700, Joshua Shagam wrote: > > On Wed, Dec 20, 2000 at 12:07:31PM -0500, Ben Collins wrote: > > > > > > No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of > > > m68k) and it also does not build on all of our supported archs (m68k and > > > arm). > > > > On an x86 system running Woody: > > Obviously if you installed this before the "testing" dist was started, you > will have it installed. Okay, in this case, pardon my ignorance, but testing dist? When did this happen? :) I didn't think Woody was really old enough to warrant getting ready for a freeze... This is the first I'd heard of 'sid'. Actually, what character in Toy Story is that? > This is on ftp-master. So, yes, the old woody used to have it (when woody > was "unstable"), but the new woody doesn't (since it is now "testing"). > "Sid" is not "unstable". Okay, now I'm just confused. :) > You are probably looking at "unstable" and assuming it is "woody", when > now it isn't. Unstable is "sid". Yeah, that's what was going on. My bad. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 12:07:31PM -0500, Ben Collins wrote: > On Wed, Dec 20, 2000 at 05:51:15PM +0100, Charl P. Botha wrote: > > On Wed, Dec 20, 2000 at 04:58:06PM +0100, Michel Dänzer wrote: > > > "Charl P. Botha" wrote: > > > > > > > > On Wed, Dec 20, 2000 at 09:49:34AM -0500, Branden Robinson wrote: > > > > > I couldn´t find a Debian-package for XFree86 4.01 neither for potato nor > > > > > for woody. > > > > > > > > You should've searched a bit harder. The XFree86 packages are available on > > > > any woody mirror in /dists/woody/main/binary-i386/x11/. > > > > > > Not anymore. woody is now testing, and doesn't have the new X yet. (it doesn't > > > build on m68k and arm) > > > > > > It's currently only in unstable aka sid (right?). > > > > Wrong. Woody, aka testing, has XFree86-4.0.1-11. > > No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of > m68k) and it also does not build on all of our supported archs (m68k and > arm). On an x86 system running Woody: Package: libc6 Status: install ok installed Priority: required Section: base Installed-Size: 8226 Maintainer: Ben Collins <[EMAIL PROTECTED]> Source: glibc Version: 2.2-5 Package: xfree86-common Status: install ok installed Priority: optional Section: x11 Installed-Size: 716 Maintainer: Branden Robinson <[EMAIL PROTECTED]> Source: xfree86 Version: 4.0.1-11 > So there is no way it can be in testing. But the packages are in Woody (on the x86 architecture, anyway) nontheless. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Major texturing bugs in G400 DRI driver
It seems that the problem in the G400 texturing bug is fixed in the current CVS version of XFree 4 DRI. I went and downloaded the CVS source tree last night (modems have enough bandwidth when you're not sitting there waiting :) and built the server myself... it seems that there's a bug in the relatively-new fullscreen functions in the MGA driver, however; in order to get direct rendering to work at all (rather than libGL getting 'unresolved symbol' errors), I had to comment out the XF86DRICloseFullScreen and XF86DRIOpenFullScreen bits in xc/lib/GL/mesa/dri/dri_mesa.c (for some reason, mga_dri.o isn't exporting those symbols). Stencils are still broken, but that was to be expected. At least textures work again. They still don't respond to glTexEnv* though (changing the filters has no effect for example), but that's a relatively minor issue in the grand scheme of things. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: Major texturing bugs in G400 DRI driver
It seems that the problem in the G400 texturing bug is fixed in the current CVS version of XFree 4 DRI. I went and downloaded the CVS source tree last night (modems have enough bandwidth when you're not sitting there waiting :) and built the server myself... it seems that there's a bug in the relatively-new fullscreen functions in the MGA driver, however; in order to get direct rendering to work at all (rather than libGL getting 'unresolved symbol' errors), I had to comment out the XF86DRICloseFullScreen and XF86DRIOpenFullScreen bits in xc/lib/GL/mesa/dri/dri_mesa.c (for some reason, mga_dri.o isn't exporting those symbols). Stencils are still broken, but that was to be expected. At least textures work again. They still don't respond to glTexEnv* though (changing the filters has no effect for example), but that's a relatively minor issue in the grand scheme of things. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 04:20:30PM -0500, Daniel Jacobowitz wrote: > On Tue, Dec 12, 2000 at 12:47:29PM -0700, Joshua Shagam wrote: > > > Actually, I read the archives about a week ago when this first popped up, > > > and > > > didn't find the answer. > > > > When I had these problems (I wasn't paying attention when it came up the > > first time) it took me a while to find the exact thread which answers it. > > You want to do dpkg --reconfigure xfree86-common. > > That's dpkg-reconfigure, actually... Oops. My bad. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 04:20:30PM -0500, Daniel Jacobowitz wrote: > On Tue, Dec 12, 2000 at 12:47:29PM -0700, Joshua Shagam wrote: > > > Actually, I read the archives about a week ago when this first popped up, and > > > didn't find the answer. > > > > When I had these problems (I wasn't paying attention when it came up the > > first time) it took me a while to find the exact thread which answers it. > > You want to do dpkg --reconfigure xfree86-common. > > That's dpkg-reconfigure, actually... Oops. My bad. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 11:45:10AM -0800, Bruce Perens wrote: > From: Joshua Shagam <[EMAIL PROTECTED]> > > Hey Bruce, are you really such a newbie that you can't read the list > > archives? ;) > > Well, you read the archives with a web browser, and my web browser happens > to run under the x server that I'm not authorized to run right now. You want > me to use LYNX Eeewww! That's what w3m is for. :) > Actually, I read the archives about a week ago when this first popped up, and > didn't find the answer. When I had these problems (I wasn't paying attention when it came up the first time) it took me a while to find the exact thread which answers it. You want to do dpkg --reconfigure xfree86-common. > So, for the moment, I made XFree86 setuid-root and started it by hand, and > then started the window manager and the panel. But since I'm demonstrating > this system to two vice-presidents of HP in the near future, and I'm writing > an article for ZDNet on why Free Software is so cool today, you folks could > be nice and save me some searching. ZDNet? Wow, good thing I don't read Slashdot anymore, or I'd have to consider flaming you for that. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [bruce@perens.com: user not authorized to run the X server]
> I am seeing "user not authorized to run the X server" from xinit using the new > Progeny X packages. I've tried editing Xsession so that anybody can start the > server, and that doesn't help. Any clues? Hey Bruce, are you really such a newbie that you can't read the list archives? ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 11:45:10AM -0800, Bruce Perens wrote: > From: Joshua Shagam <[EMAIL PROTECTED]> > > Hey Bruce, are you really such a newbie that you can't read the list > > archives? ;) > > Well, you read the archives with a web browser, and my web browser happens > to run under the x server that I'm not authorized to run right now. You want > me to use LYNX Eeewww! That's what w3m is for. :) > Actually, I read the archives about a week ago when this first popped up, and > didn't find the answer. When I had these problems (I wasn't paying attention when it came up the first time) it took me a while to find the exact thread which answers it. You want to do dpkg --reconfigure xfree86-common. > So, for the moment, I made XFree86 setuid-root and started it by hand, and > then started the window manager and the panel. But since I'm demonstrating > this system to two vice-presidents of HP in the near future, and I'm writing > an article for ZDNet on why Free Software is so cool today, you folks could > be nice and save me some searching. ZDNet? Wow, good thing I don't read Slashdot anymore, or I'd have to consider flaming you for that. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [bruce@perens.com: user not authorized to run the X server]
> I am seeing "user not authorized to run the X server" from xinit using the new > Progeny X packages. I've tried editing Xsession so that anybody can start the > server, and that doesn't help. Any clues? Hey Bruce, are you really such a newbie that you can't read the list archives? ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, Dec 12, 2000 at 02:38:06AM -0500, Terry 'Mongoose' Hendrix II wrote: > On Mon, 11 Dec 2000, Seth Arnold wrote: > > >Terry, a few quick comments -- first, Utah-glx is in the past. While > >their work may have been nifty at one point, and for people running > >3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. > > This is about poor forethought. I complained months ago about how the X > team was moving to lock out utah-glx. Utah has more users than DRI - why > do this? I woke up from an overnight upgrade of gtk to find my X install > made unusable. Well, it was also a poor forethought for you to not issue a package hold on the XFree packages. It's easy enough to use dselect to request that a package not be upgraded... (hint: = key) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, Dec 12, 2000 at 02:38:06AM -0500, Terry 'Mongoose' Hendrix II wrote: > On Mon, 11 Dec 2000, Seth Arnold wrote: > > >Terry, a few quick comments -- first, Utah-glx is in the past. While > >their work may have been nifty at one point, and for people running > >3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. > > This is about poor forethought. I complained months ago about how the X > team was moving to lock out utah-glx. Utah has more users than DRI - why > do this? I woke up from an overnight upgrade of gtk to find my X install > made unusable. Well, it was also a poor forethought for you to not issue a package hold on the XFree packages. It's easy enough to use dselect to request that a package not be upgraded... (hint: = key) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Not to mention that the G400 driver for XFree 4 has 3D acceleration as well. It's currently kinda broken (stencils don't work at all (not even in software fallback - they're borked), and there are some pretty icky persistent texturing bugs, but it's usable. Just not very. Personally, I'm annoyed by the persistent brokenness of the DRI drivers, but I'm making do in my projects, and if I want to verify my code's correctness I can always use an LD_PRELOAD to force software mesa to check accuracy. It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Not to mention that the G400 driver for XFree 4 has 3D acceleration as well. It's currently kinda broken (stencils don't work at all (not even in software fallback - they're borked), and there are some pretty icky persistent texturing bugs, but it's usable. Just not very. Personally, I'm annoyed by the persistent brokenness of the DRI drivers, but I'm making do in my projects, and if I want to verify my code's correctness I can always use an LD_PRELOAD to force software mesa to check accuracy. It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 09:51:07AM +0100, Cajus Pollmeier wrote:
> Am Friday 08 December 2000 09:33 schrieb Joshua Shagam:
> > Ah, okay, that makes more sense. The shellscript is probably the easiest
> > way in that case. Try starting up a getty using your shellscript instead
> > of /bin/login; I believe you'd want to add '-l /path/to/the/shellscript' to
> > the end of one of your getty lines in your /etc/inittab.
>
> Currently I'm trying it this way:
> X:2:respawn:/etc/init.d/kiosk
>
> But it doesn't work the way as expected - same error than before. What do you
> mean with "-l "? I can't find any options starting with "-l" for getty.
At least in the version of getty I have installed (in util-linux 2.10q-1),
-l specifies an alternate to /bin/login:
getty [-ihLmnw] [-f issue_file] [-l login_program] [-I
init] [-t timeout] [-H login_host] port baud_rate,...
[term]
...
-l login_program
Invoke the specified login_program instead of
/bin/login. This allows the use of a non-standard
login program (for example, one that asks for a
dial-up password or that uses a different password
file).
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
mp3.com/fluffyporcupine/ \ Respect for open standards
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 09:51:07AM +0100, Cajus Pollmeier wrote:
> Am Friday 08 December 2000 09:33 schrieb Joshua Shagam:
> > Ah, okay, that makes more sense. The shellscript is probably the easiest
> > way in that case. Try starting up a getty using your shellscript instead
> > of /bin/login; I believe you'd want to add '-l /path/to/the/shellscript' to
> > the end of one of your getty lines in your /etc/inittab.
>
> Currently I'm trying it this way:
> X:2:respawn:/etc/init.d/kiosk
>
> But it doesn't work the way as expected - same error than before. What do you
> mean with "-l "? I can't find any options starting with "-l" for getty.
At least in the version of getty I have installed (in util-linux 2.10q-1),
-l specifies an alternate to /bin/login:
getty [-ihLmnw] [-f issue_file] [-l login_program] [-I
init] [-t timeout] [-H login_host] port baud_rate,...
[term]
...
-l login_program
Invoke the specified login_program instead of
/bin/login. This allows the use of a non-standard
login program (for example, one that asks for a
dial-up password or that uses a different password
file).
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
mp3.com/fluffyporcupine/ \ Respect for open standards
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 09:26:47AM +0100, Cajus Pollmeier wrote: > Am Friday 08 December 2000 09:22 schrieb Joshua Shagam: > > On Fri, Dec 08, 2000 at 08:42:57AM +0100, Cajus Pollmeier wrote: > > > Hi! > > > > > > I'm trying to run X from an init script during boot up like this: > > > > > > #!/bin/bash > > > while true; do > > > su - kiosk -c /usr/X11R6/bin/startx > > > done > > > > Why are you doing this? Why not run xdm? It's not THAT time-consuming to > > log in when you need the computer. Unless you run Enlightenment, in which > > case the amount of time it takes you to log in is the least of your > > problems. ;) > > Well - this if for a kind of kiosk system. The user will run into a prog > where he/she will only be able to press the finger on the screen. > The Touchscreen is the only device connected to this box, so logging > in makes no sense here. Ah, okay, that makes more sense. The shellscript is probably the easiest way in that case. Try starting up a getty using your shellscript instead of /bin/login; I believe you'd want to add '-l /path/to/the/shellscript' to the end of one of your getty lines in your /etc/inittab. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 08:42:57AM +0100, Cajus Pollmeier wrote: > Hi! > > I'm trying to run X from an init script during boot up like this: > > #!/bin/bash > while true; do > su - kiosk -c /usr/X11R6/bin/startx > done Why are you doing this? Why not run xdm? It's not THAT time-consuming to log in when you need the computer. Unless you run Enlightenment, in which case the amount of time it takes you to log in is the least of your problems. ;) Personally, I prefer not running xdm, and just doing startx when I need to. That way it's easy for me to change bitdepths or whatever. That is, of course, a personal preference, but there's much cleaner ways to keep your system in X at all times anyway. > Starting this manually as root works as expected. While booting I get: > X: user not authorized to run the X server, aborting. > var: allowed_users, value: rootonly. > var: nice_value, value: -10. > > Changing from rootonly to anybody makes no difference. > Ok - that's no login shell from there, but... It probably has to do with the fact that you're not starting it up from a terminal or something. But, again, it's a bad idea to do that anyway. Just use xdm or gdm or the like if it's that important that your system be in X at all times... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 09:26:47AM +0100, Cajus Pollmeier wrote: > Am Friday 08 December 2000 09:22 schrieb Joshua Shagam: > > On Fri, Dec 08, 2000 at 08:42:57AM +0100, Cajus Pollmeier wrote: > > > Hi! > > > > > > I'm trying to run X from an init script during boot up like this: > > > > > > #!/bin/bash > > > while true; do > > > su - kiosk -c /usr/X11R6/bin/startx > > > done > > > > Why are you doing this? Why not run xdm? It's not THAT time-consuming to > > log in when you need the computer. Unless you run Enlightenment, in which > > case the amount of time it takes you to log in is the least of your > > problems. ;) > > Well - this if for a kind of kiosk system. The user will run into a prog > where he/she will only be able to press the finger on the screen. > The Touchscreen is the only device connected to this box, so logging > in makes no sense here. Ah, okay, that makes more sense. The shellscript is probably the easiest way in that case. Try starting up a getty using your shellscript instead of /bin/login; I believe you'd want to add '-l /path/to/the/shellscript' to the end of one of your getty lines in your /etc/inittab. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start X during bootup as user
On Fri, Dec 08, 2000 at 08:42:57AM +0100, Cajus Pollmeier wrote: > Hi! > > I'm trying to run X from an init script during boot up like this: > > #!/bin/bash > while true; do > su - kiosk -c /usr/X11R6/bin/startx > done Why are you doing this? Why not run xdm? It's not THAT time-consuming to log in when you need the computer. Unless you run Enlightenment, in which case the amount of time it takes you to log in is the least of your problems. ;) Personally, I prefer not running xdm, and just doing startx when I need to. That way it's easy for me to change bitdepths or whatever. That is, of course, a personal preference, but there's much cleaner ways to keep your system in X at all times anyway. > Starting this manually as root works as expected. While booting I get: > X: user not authorized to run the X server, aborting. > var: allowed_users, value: rootonly. > var: nice_value, value: -10. > > Changing from rootonly to anybody makes no difference. > Ok - that's no login shell from there, but... It probably has to do with the fact that you're not starting it up from a terminal or something. But, again, it's a bad idea to do that anyway. Just use xdm or gdm or the like if it's that important that your system be in X at all times... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Major texturing bugs in G400 DRI driver
On Thu, Dec 07, 2000 at 09:54:20AM -0600, Thomas E. Vaughan wrote: > On Wed, Dec 06, 2000 at 01:21:15PM -0700, Joshua Shagam wrote: > > > > I've completely lost track of where DRI bugs should go, but this seems > > like the kind of thing which might just be due to something bad in the > > Debian build anyway. Basically, texturing on the G400 DRI driver is > > completely borked up in that it seems that texture coordinates aren't > > getting to the card properly. I have some screenshots comparing the G400 > > driver with software Mesa at > > > > http://www.cs.nmsu.edu/~joshagam/temp/texture-hw.jpg (G400 driver) > > http://www.cs.nmsu.edu/~joshagam/temp/texture-sw.jpg (software) > > > > Basically, vertices which are a certain distance from the camera and are > > within the clipping planes seem to get their texture coordinates shoved > > to 0,0. As the camera moves around the broken texture coordinates change > > quite a bit. > > > > Has anyone else been having problems like these? This seems like the > > sort of thing that the DRI project wouldn't miss noticing before making a > > release. Or are the Debian packages still built from CVS? > > I have noticed texture-coordinate problems, but I don't know if it's the > same thing. What I have noticed is that when a polygon loses a vertex as > that vertex crosses the edge of the viewport, the polygon to which that > vertex belongs suddenly has its texture mapped incorrectly. Yeah, that's probably the same behavior, based on some of the stuff I've been observing. The texture used in that screenshot made it hard to tell, but when I used a checkerboard texture I noticed that it looked more like texture coordinates were being dropped or something, like you've observed... the reason all of the polygons are getting messed up in my renderer is because everything's sent as strips, and it seems that the entire strip gets borked. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: Major texturing bugs in G400 DRI driver
On Thu, Dec 07, 2000 at 09:54:20AM -0600, Thomas E. Vaughan wrote: > On Wed, Dec 06, 2000 at 01:21:15PM -0700, Joshua Shagam wrote: > > > > I've completely lost track of where DRI bugs should go, but this seems > > like the kind of thing which might just be due to something bad in the > > Debian build anyway. Basically, texturing on the G400 DRI driver is > > completely borked up in that it seems that texture coordinates aren't > > getting to the card properly. I have some screenshots comparing the G400 > > driver with software Mesa at > > > > http://www.cs.nmsu.edu/~joshagam/temp/texture-hw.jpg (G400 driver) > > http://www.cs.nmsu.edu/~joshagam/temp/texture-sw.jpg (software) > > > > Basically, vertices which are a certain distance from the camera and are > > within the clipping planes seem to get their texture coordinates shoved > > to 0,0. As the camera moves around the broken texture coordinates change > > quite a bit. > > > > Has anyone else been having problems like these? This seems like the > > sort of thing that the DRI project wouldn't miss noticing before making a > > release. Or are the Debian packages still built from CVS? > > I have noticed texture-coordinate problems, but I don't know if it's the > same thing. What I have noticed is that when a polygon loses a vertex as > that vertex crosses the edge of the viewport, the polygon to which that > vertex belongs suddenly has its texture mapped incorrectly. Yeah, that's probably the same behavior, based on some of the stuff I've been observing. The texture used in that screenshot made it hard to tell, but when I used a checkerboard texture I noticed that it looked more like texture coordinates were being dropped or something, like you've observed... the reason all of the polygons are getting messed up in my renderer is because everything's sent as strips, and it seems that the entire strip gets borked. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Major texturing bugs in G400 DRI driver
I've completely lost track of where DRI bugs should go, but this seems like the kind of thing which might just be due to something bad in the Debian build anyway. Basically, texturing on the G400 DRI driver is completely borked up in that it seems that texture coordinates aren't getting to the card properly. I have some screenshots comparing the G400 driver with software Mesa at http://www.cs.nmsu.edu/~joshagam/temp/texture-hw.jpg (G400 driver) http://www.cs.nmsu.edu/~joshagam/temp/texture-sw.jpg (software) Basically, vertices which are a certain distance from the camera and are within the clipping planes seem to get their texture coordinates shoved to 0,0. As the camera moves around the broken texture coordinates change quite a bit. Has anyone else been having problems like these? This seems like the sort of thing that the DRI project wouldn't miss noticing before making a release. Or are the Debian packages still built from CVS? The only other thing which could have affected this is that since the last time I ran this code (successfully) I've upgraded from kernel 2.4.0-test9 to 2.4.0-test11, and the DRM module has apparently changed between them, but I don't think that would make a difference since it's the DRI driver which does the command buffer setup, not the DRM, and by grepping through the kernel patches it looks like it was just some buffer locking code which was changed anyway. So this goes back to the original theory that it's within the DRI driver that things are breaking... Any ideas? Many thanks in advance. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Major texturing bugs in G400 DRI driver
I've completely lost track of where DRI bugs should go, but this seems like the kind of thing which might just be due to something bad in the Debian build anyway. Basically, texturing on the G400 DRI driver is completely borked up in that it seems that texture coordinates aren't getting to the card properly. I have some screenshots comparing the G400 driver with software Mesa at http://www.cs.nmsu.edu/~joshagam/temp/texture-hw.jpg (G400 driver) http://www.cs.nmsu.edu/~joshagam/temp/texture-sw.jpg (software) Basically, vertices which are a certain distance from the camera and are within the clipping planes seem to get their texture coordinates shoved to 0,0. As the camera moves around the broken texture coordinates change quite a bit. Has anyone else been having problems like these? This seems like the sort of thing that the DRI project wouldn't miss noticing before making a release. Or are the Debian packages still built from CVS? The only other thing which could have affected this is that since the last time I ran this code (successfully) I've upgraded from kernel 2.4.0-test9 to 2.4.0-test11, and the DRM module has apparently changed between them, but I don't think that would make a difference since it's the DRI driver which does the command buffer setup, not the DRM, and by grepping through the kernel patches it looks like it was just some buffer locking code which was changed anyway. So this goes back to the original theory that it's within the DRI driver that things are breaking... Any ideas? Many thanks in advance. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FW: [otto.wyss@csam.com: XFree 4.0.1-8 crashes my systemcompletl y, how can I retrieve inf ormation fora bug report]
On Thu, Nov 30, 2000 at 11:59:19PM +0100, Otto Wyss wrote: > > > Goodness; what a horrible .signature. That would be a real incentive for > > > me to find a different employer. :) [Branden: it isn't Craig that you > > > > Sorry if I had known, that '[EMAIL PROTECTED]' gets relayed to > debian-x, I wouldn't have sent it. Usually I send everything first at my > home address and than out to the world. It doesn't, Branden forwards it to the list as he is far too busy to answer every mail sent to him personally regarding the Xfree packages, especially for every little issue which his system may or may not have (such as, for example, USB). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: FW: [otto.wyss@csam.com: XFree 4.0.1-8 crashes my systemcompletl y, how can I retrieve inf ormation fora bug report]
On Thu, Nov 30, 2000 at 11:59:19PM +0100, Otto Wyss wrote: > > > Goodness; what a horrible .signature. That would be a real incentive for > > > me to find a different employer. :) [Branden: it isn't Craig that you > > > > Sorry if I had known, that '[EMAIL PROTECTED]' gets relayed to > debian-x, I wouldn't have sent it. Usually I send everything first at my > home address and than out to the world. It doesn't, Branden forwards it to the list as he is far too busy to answer every mail sent to him personally regarding the Xfree packages, especially for every little issue which his system may or may not have (such as, for example, USB). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Off Topic] Virus warning!
On Sat, Nov 18, 2000 at 05:24:37PM +0900, Hajime Saito wrote: > > It appears that someone on this list has just been infected by the > Navidad virus. > Do not open attachments named navidad.exe. Details can be found here. Okay, who's the closet Windows user? ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [Off Topic] Virus warning!
On Sat, Nov 18, 2000 at 05:24:37PM +0900, Hajime Saito wrote: > > It appears that someone on this list has just been infected by the > Navidad virus. > Do not open attachments named navidad.exe. Details can be found here. Okay, who's the closet Windows user? ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: performance drop with running xosview
On Mon, Nov 06, 2000 at 11:50:36PM +0100, reiner wrote: > Hello all, > > > Has someone get a significant performance drop in an open-gl application That would likely be because xosview puts a HUGE drain on the xserver in sending out a lot of drawing events and XFlush()es. Every XFlush() means that the OpenGL stuff has to stop what it's doing in order to synchronize with the X server again, if my understanding of the DRI architecture is correct. __ Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: performance drop with running xosview
On Mon, Nov 06, 2000 at 11:50:36PM +0100, reiner wrote: > Hello all, > > > Has someone get a significant performance drop in an open-gl application That would likely be because xosview puts a HUGE drain on the xserver in sending out a lot of drawing events and XFlush()es. Every XFlush() means that the OpenGL stuff has to stop what it's doing in order to synchronize with the X server again, if my understanding of the DRI architecture is correct. __ Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about r128 server
On Fri, Oct 27, 2000 at 03:22:52PM -0600, Jeff Lessem wrote: > In your message of: Fri, 27 Oct 2000 11:22:26 PDT, you write: > >% man xset > > > > -dpms The -dpms option disables DPMS (Energy Star) > > features. > > > > +dpms The +dpms option enables DPMS (Energy Star) > > Thanks for the response, but unfortunately it is a bit more complex > than that. xset +dpms runs without an error, but xset q continues to > report "not capable of DPMS" and something like xset dpms force off > will fail with an error. The magic thingy you need is in your XF86Config file, add Option "DPMS" "on" to your Monitor section. Unfortunately, XFree 4's documentation is woefully...lacking. I didn't know this (not for lack of trying) until someone had mentioned it in passing on this list. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: Questions about r128 server
On Fri, Oct 27, 2000 at 03:22:52PM -0600, Jeff Lessem wrote: > In your message of: Fri, 27 Oct 2000 11:22:26 PDT, you write: > >% man xset > > > > -dpms The -dpms option disables DPMS (Energy Star) > > features. > > > > +dpms The +dpms option enables DPMS (Energy Star) > > Thanks for the response, but unfortunately it is a bit more complex > than that. xset +dpms runs without an error, but xset q continues to > report "not capable of DPMS" and something like xset dpms force off > will fail with an error. The magic thingy you need is in your XF86Config file, add Option "DPMS" "on" to your Monitor section. Unfortunately, XFree 4's documentation is woefully...lacking. I didn't know this (not for lack of trying) until someone had mentioned it in passing on this list. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VSZ memory of X
On Sun, Oct 22, 2000 at 07:59:09PM +0200, Christian Hammers wrote: > Hi > > My X uses 80M of VSZ but only 8M of RSS memory. The eight megabytes seams > reasonably for an X server but why is the VSZ part so high? Does every > program that runs under X request it from X and so raises X's memory > statistic? Requested size is just the size of the memory footprint as it appears in the page table. My X server always reports about 160MB 'usage', likely because of the way AGP is implemented in the kernel; similarly, my 3D engine reports 160MB usage (for probably the same reason) when its RSS is only 32 (and even that's when my LOD cache has become oversaturated, but that's another matter). Basically, the VSZ is just the *potential* usage, whereas the RSS is *actual* usage. Pay no mind to VSZ for anything which does funky memory mapper tricks. As a simple test of this, do a malloc() on some egregriously large amount of memory (say, 64MB), but don't actually use it, and look as the VSZ vs. RSS of the program. Linux uses an allocate-on-demand policy for large allocations (technically, it mmap()s /dev/zero, and mmap is a nice generic interface to the pagetable), so even though it has 64MB of *potential* memory usage, only the memory which has actually been touched is actually allocated. It's a similar issue with the X server et al. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: VSZ memory of X
On Sun, Oct 22, 2000 at 07:59:09PM +0200, Christian Hammers wrote: > Hi > > My X uses 80M of VSZ but only 8M of RSS memory. The eight megabytes seams > reasonably for an X server but why is the VSZ part so high? Does every > program that runs under X request it from X and so raises X's memory > statistic? Requested size is just the size of the memory footprint as it appears in the page table. My X server always reports about 160MB 'usage', likely because of the way AGP is implemented in the kernel; similarly, my 3D engine reports 160MB usage (for probably the same reason) when its RSS is only 32 (and even that's when my LOD cache has become oversaturated, but that's another matter). Basically, the VSZ is just the *potential* usage, whereas the RSS is *actual* usage. Pay no mind to VSZ for anything which does funky memory mapper tricks. As a simple test of this, do a malloc() on some egregriously large amount of memory (say, 64MB), but don't actually use it, and look as the VSZ vs. RSS of the program. Linux uses an allocate-on-demand policy for large allocations (technically, it mmap()s /dev/zero, and mmap is a nice generic interface to the pagetable), so even though it has 64MB of *potential* memory usage, only the memory which has actually been touched is actually allocated. It's a similar issue with the X server et al. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Congrats/Thanks, and a question...?
On Thu, Oct 19, 2000 at 11:42:53AM -0700, A.J. Rossini wrote: > > I've been "lucky" recently to cease co-habiting my desk with an AMD > K6-2/350, and had that replaced with a new Dell 220 workstation (with > a GeForce-2 video card along with other marvelous features). > > Reading the list (and reading the XFree lists) seemed to imply > non-support for this video card, except for through the CVS version of > XFree86 4.x.x; however, on "upgrading" to Branden's XFree86 4.0.1 >From what I understand, the only way to support this card is to install XFree 4 (Branden's packages would be fine) and then downloading, installing and using nVidia's binary-only nvidia.o driver (rather than the XFree-supplied nv.o). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: Congrats/Thanks, and a question...?
On Thu, Oct 19, 2000 at 11:42:53AM -0700, A.J. Rossini wrote: > > I've been "lucky" recently to cease co-habiting my desk with an AMD > K6-2/350, and had that replaced with a new Dell 220 workstation (with > a GeForce-2 video card along with other marvelous features). > > Reading the list (and reading the XFree lists) seemed to imply > non-support for this video card, except for through the CVS version of > XFree86 4.x.x; however, on "upgrading" to Branden's XFree86 4.0.1 >From what I understand, the only way to support this card is to install XFree 4 (Branden's packages would be fine) and then downloading, installing and using nVidia's binary-only nvidia.o driver (rather than the XFree-supplied nv.o). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do you want non-i386 handled in dexter? (+ mouse types)
On Sat, Oct 14, 2000 at 09:03:20AM -0400, Ben Collins wrote: > Obviously the server list in dexter needs to be different on non-i386, > aswell as the generated keyboard lines (on sun there are two default > possibilies, i386 and type5). > > How do you forsee this happening? There isn't a clean way right now, > expect for outputting a complete list of servers for each arch (lots of > duplication). I don't think it can be handled cleanly in shell, so will > you change to perl (the var/string handling in shell loses in this case). Why not have dexter generate the list at runtime based on the files in /usr/X11R6/lib/modules/drivers? > > Also, sunmouse is an option. Problem is, xf4 currently has no idea what > "Sun" type is. On top of that, I tried a ppc build, and it has no idea > what a "USB" mouse is. Known problem? > > -- > ---===-=-==-=---==-=-- > / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ > ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' > `---=--===-=-=-=-===-==---=--=---' > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: How do you want non-i386 handled in dexter? (+ mouse types)
On Sat, Oct 14, 2000 at 09:03:20AM -0400, Ben Collins wrote: > Obviously the server list in dexter needs to be different on non-i386, > aswell as the generated keyboard lines (on sun there are two default > possibilies, i386 and type5). > > How do you forsee this happening? There isn't a clean way right now, > expect for outputting a complete list of servers for each arch (lots of > duplication). I don't think it can be handled cleanly in shell, so will > you change to perl (the var/string handling in shell loses in this case). Why not have dexter generate the list at runtime based on the files in /usr/X11R6/lib/modules/drivers? > > Also, sunmouse is an option. Problem is, xf4 currently has no idea what > "Sun" type is. On top of that, I tried a ppc build, and it has no idea > what a "USB" mouse is. Known problem? > > -- > ---===-=-==-=---==-=-- > / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ > ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' > `---=--===-=-=-=-===-==---=--=---' > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
On Mon, Oct 09, 2000 at 11:20:37AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. :) > > Thanks for the good counterargument. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? Ur, although they're separate files from the video drivers, aren't they considered part of the video driver? > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) Oh, I was under the impression that xlibmesa was more than just mesa (i.e. that it was the client-side libGL, which handled all the communication with the X server, be it through GLX or whatever). > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. Ah. > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. Can't be any worse than XF86Setup was. ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: Suggestion
On Mon, Oct 09, 2000 at 11:20:37AM -0500, Branden Robinson wrote: > On Mon, Oct 09, 2000 at 09:17:05AM -0600, Joshua Shagam wrote: > > It's not the compiled code which has to match between DRI and DRM, > > just the interface. I'm using a DRM module compiled along with my > > 2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so > > which came in the X packages. After all, it all goes through a /dev/ > > interface - if the compilation had to match, then you'd have to recompile > > *all* your binaries whenever you recompile your kernel, and that makes > > absolutely no sense whatsoever. > > > > And since DRM is already distributed as part of the kernel, there's really > > no point in putting it in a separate package. :) > > Thanks for the good counterargument. > > I'm still apprehensive about moving *_dri.so out of /usr/X11R6/lib/modules. > If they aren't really X server modules, then they don't belong in that > directory (maybe /usr/lib/xlibmesa3 ?). Should I ask upstream? Ur, although they're separate files from the video drivers, aren't they considered part of the video driver? > > > Also very interresting, the mesa package (xlibmesa3) must also be > > > "compileable" whitout > > > compiling the whole X. > > > > Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not > > Mesa. > > Well, actually it is. It's just not generally the exact same version of > Mesa that the Mesa developers have released. (That and the fact that the X > build doesn't create libGLU yet.) Oh, I was under the impression that xlibmesa was more than just mesa (i.e. that it was the client-side libGL, which handled all the communication with the X server, be it through GLX or whatever). > > Isn't the current X server autodetection stuff good enough? > > Actually, it isn't. But I've written a program called "dexter" (which > replaces the old xserver-configure script) which does the prompting this > person wanted to see. Ah. > > I'm sure there'll eventually be (if there isn't already) XF86Setup for > > XFree 4, which will let people graphically mangle their conffiles once > > again... > > Yes, xf86cfg, but it is not complete yet. Can't be any worse than XF86Setup was. ;) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggestion
On Mon, Oct 09, 2000 at 11:16:40AM -0100, Sven Heyll wrote:
> Hi,
>
> why not splitting the xfree86-server package, so that the drm/dri stuff
> is in an extra package and can be compiled before installing. Dri
> modules have to be
> compiled with the corresponding drm version, which is provided by the
> kernel.
> I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
> I tried to compile (apt-get source xlib6g(or what ever) --compile)
> X by myself, but this failed because of missing glide librarys. I dont
> see the reason why
> one would have to recompile whole X only to get DRI working. So one
> possible solution
> would be, that there is a
> default DRI package, available also in binary version and compiled for
> the current debian
> kernel, or to let the user choose, during install of the binarypackage
> to get and compile
> and install the source package. This could be done after a test for the
> kernel version.
And, of course, it could be setup as a make-kpkg module package (like
alsa-source. But:
It's not the compiled code which has to match between DRI and DRM,
just the interface. I'm using a DRM module compiled along with my
2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so
which came in the X packages. After all, it all goes through a /dev/
interface - if the compilation had to match, then you'd have to recompile
*all* your binaries whenever you recompile your kernel, and that makes
absolutely no sense whatsoever.
And since DRM is already distributed as part of the kernel, there's really
no point in putting it in a separate package. :)
> Also very interresting, the mesa package (xlibmesa3) must also be
> "compileable" whitout
> compiling the whole X.
Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not
Mesa.
> Maybe this causes the need for a virtual package which containts a
> script that interactivly generates
> the right configfiles and installs them in the source directoy of X
> parts( like mesa, dri ...).
> This package contains debian specific config file
> templates ("xc/config/.../host.def" ... etc) and
> perl script may askyou quesations like "Do you have a < ...> card
> ?" "Should <...> be activated ?" etc
> very simple and basic.
Isn't the current X server autodetection stuff good enough? I'm sure
there'll eventually be (if there isn't already) XF86Setup for XFree 4,
which will let people graphically mangle their conffiles once again...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
Re: Suggestion
On Mon, Oct 09, 2000 at 11:16:40AM -0100, Sven Heyll wrote:
> Hi,
>
> why not splitting the xfree86-server package, so that the drm/dri stuff
> is in an extra package and can be compiled before installing. Dri
> modules have to be
> compiled with the corresponding drm version, which is provided by the
> kernel.
> I have kernel 2.4.0test6 and the X binarys forbid me to use dri.
> I tried to compile (apt-get source xlib6g(or what ever) --compile)
> X by myself, but this failed because of missing glide librarys. I dont
> see the reason why
> one would have to recompile whole X only to get DRI working. So one
> possible solution
> would be, that there is a
> default DRI package, available also in binary version and compiled for
> the current debian
> kernel, or to let the user choose, during install of the binarypackage
> to get and compile
> and install the source package. This could be done after a test for the
> kernel version.
And, of course, it could be setup as a make-kpkg module package (like
alsa-source. But:
It's not the compiled code which has to match between DRI and DRM,
just the interface. I'm using a DRM module compiled along with my
2.4.0-test8 kernel just fine with the precompiled mga.so and mga_dri.so
which came in the X packages. After all, it all goes through a /dev/
interface - if the compilation had to match, then you'd have to recompile
*all* your binaries whenever you recompile your kernel, and that makes
absolutely no sense whatsoever.
And since DRM is already distributed as part of the kernel, there's really
no point in putting it in a separate package. :)
> Also very interresting, the mesa package (xlibmesa3) must also be
> "compileable" whitout
> compiling the whole X.
Why? xlibmesa3 is part of the X server. It's based on Mesa, but it's not
Mesa.
> Maybe this causes the need for a virtual package which containts a
> script that interactivly generates
> the right configfiles and installs them in the source directoy of X
> parts( like mesa, dri ...).
> This package contains debian specific config file
> templates ("xc/config/.../host.def" ... etc) and
> perl script may askyou quesations like "Do you have a < ...> card
> ?" "Should <...> be activated ?" etc
> very simple and basic.
Isn't the current X server autodetection stuff good enough? I'm sure
there'll eventually be (if there isn't already) XF86Setup for XFree 4,
which will let people graphically mangle their conffiles once again...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AKennedy@bursteinlabs.com: GeForce2 divers for XFree86 4.x/Debian]
On Sun, Oct 08, 2000 at 09:15:48AM +0200, Marcelo E. Magallon wrote: > >> Branden Robinson <[EMAIL PROTECTED]> writes: > > > Someone with an appropriate NVidia card want to do this? > > > > I think he's probably talking about NVidia's non-free driver(s). > > JFTR: > > > > If someone wants to make and distribute .deb's, he must get permission > from NVIDIA first. Or setup an installer-wrapping package like Netscape used to have and Realplayer currently does have... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: [AKennedy@bursteinlabs.com: GeForce2 divers for XFree86 4.x/Debian]
On Sun, Oct 08, 2000 at 09:15:48AM +0200, Marcelo E. Magallon wrote: > >> Branden Robinson <[EMAIL PROTECTED]> writes: > > > Someone with an appropriate NVidia card want to do this? > > > > I think he's probably talking about NVidia's non-free driver(s). > > JFTR: > > > > If someone wants to make and distribute .deb's, he must get permission > from NVIDIA first. Or setup an installer-wrapping package like Netscape used to have and Realplayer currently does have... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trouble with DRI on G200
On Fri, Oct 06, 2000 at 10:06:48AM -0500, David Engel wrote: > Hi All, > > I'm trying to get DRI working on my Matrox G200 and not having much > luck. Most of this is probably due to my ignorance of Linux 3d > support, but since it involves Debian specific changes to X, I thought > I'd ask here first. > > I first tried using the stock 4.0.1-0phase2v13 X packages with kernel > 2.2.18pre15 and got the following message from the X server: > > (EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 1.0.0, > expected 2.0.x). Disabling DRI. > > It seems the Debian diff for 4.0.1-0phase2v13 has patched the mga_drv > X module to require a newer version of the mga kernel module, which > AFAICT, is only available in the 2.4 kernel. I'd rather not switch to > the 2.4 kernel yet. Does anyone know of a newer version of the mga > kernel module for the 2.2 kernel? Even if you do get a version match between DRI and DRM, you still won't get it to work under a 2.2 kernel, because 2.2's memory mapper doesn't support some of the stuff needed by the DRM (I'm not sure of the details of this, but this was mentioned on the DRI bugtracker) - so DMA will always fail to initialize. Upgrading to 2.4 is really your only choice, sorry. > However, glxinfo claimed direct rendering was not enabled, and sure > enough, there was no improvement over software renedering when running > 3d apps. Did you later see 'DMA initialization failed?' That would be the kernel-specific issue. Also, make sure you're using the correct libGL.so. :) > FYI, another partly related problem I've run into is that the mesag3 > package contains libGL and libGLU but the xlibmesa3 package only > contains libGL. What package is supposed to provide libGLU when > xlibmesa3 is used? What I do is I use the libGL from xlibmesa3 and the libGLU compiled from Mesa's sources (which I already have on-hand because of formerly using Utah-GLX). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: Trouble with DRI on G200
On Fri, Oct 06, 2000 at 10:06:48AM -0500, David Engel wrote: > Hi All, > > I'm trying to get DRI working on my Matrox G200 and not having much > luck. Most of this is probably due to my ignorance of Linux 3d > support, but since it involves Debian specific changes to X, I thought > I'd ask here first. > > I first tried using the stock 4.0.1-0phase2v13 X packages with kernel > 2.2.18pre15 and got the following message from the X server: > > (EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 1.0.0, > expected 2.0.x). Disabling DRI. > > It seems the Debian diff for 4.0.1-0phase2v13 has patched the mga_drv > X module to require a newer version of the mga kernel module, which > AFAICT, is only available in the 2.4 kernel. I'd rather not switch to > the 2.4 kernel yet. Does anyone know of a newer version of the mga > kernel module for the 2.2 kernel? Even if you do get a version match between DRI and DRM, you still won't get it to work under a 2.2 kernel, because 2.2's memory mapper doesn't support some of the stuff needed by the DRM (I'm not sure of the details of this, but this was mentioned on the DRI bugtracker) - so DMA will always fail to initialize. Upgrading to 2.4 is really your only choice, sorry. > However, glxinfo claimed direct rendering was not enabled, and sure > enough, there was no improvement over software renedering when running > 3d apps. Did you later see 'DMA initialization failed?' That would be the kernel-specific issue. Also, make sure you're using the correct libGL.so. :) > FYI, another partly related problem I've run into is that the mesag3 > package contains libGL and libGLU but the xlibmesa3 package only > contains libGL. What package is supposed to provide libGLU when > xlibmesa3 is used? What I do is I use the libGL from xlibmesa3 and the libGLU compiled from Mesa's sources (which I already have on-hand because of formerly using Utah-GLX). -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Tue, Sep 26, 2000 at 05:47:02PM +0100, Jules Bean wrote: > On Tue, Sep 26, 2000 at 10:20:38AM -0600, Joshua Shagam wrote: > > > > And, if I'm not mistaken, imlib is one of Rasterman's over-glitzy > > under-functional piles of code... :) > > Well, I don't think this is a very productive thread, but... No. > Imlib may have had some bugs (what doesn't) but raster was quite > correct to observe the need for it, and he wrote a library to handle a > variety of image formats at any colour depth, and the fast copying of > them to the screen, and memory management of them. I didn't say it was a bad idea. Just that Rasterman didn't do a very good job of programming it. :) > The GNOME project realised that he was right about its necessity, > although they eventually diverged from him over implementation issues > (differing priorities). But I don't think it was particularly glitzy, > no. 'Glitzy' can refer to a number of things. Such as the ego involved in its presentation. > And imlib2 offers transparency, which you probably think is glitzy, > but I think it is a useful user interface element given that modern > graphics hardware is up to the task. Again, 'glitzy' can refer to a number of things. Features isn't glitz - overglorified presentation of shoddily-implemented features is glitz. If it's implemented right and in a nice, non-obtrusive way, it's not glitz - and as long as imlib2's interface is done in a non-obtrusive way, I wouldn't consider it glitzy. Anyway. Sorry for hijacking this thread to be so off-topic. I'll shut up now. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Tue, Sep 26, 2000 at 09:35:50AM +0100, Jules Bean wrote: > On Mon, Sep 25, 2000 at 10:36:02AM -0600, Joshua Shagam wrote: > > > How recent are we talking about here? I never noticed any problem with > > > phase2v8, but in the past few days I haven't been running much X > > > applications > > > apart from WindowMaker, xpdf, emacs, xterm and xscreensaver, and it has > > > never > > > occured to me before to wonder how much any of these rely on shared > > > memory. > > > > Not at all. Shm is used msotly for things which do a lot of blitting, like > > games and Rasterman's over-glitzy under-functional piles of code. > > Well, anything which uses MIT-SHM. > > In fact, if I'm not much mistaken, it's imlib which uses SHM (by > default, can be turned off), so some versions of gnome will trigger > the memory leaks too. And, if I'm not mistaken, imlib is one of Rasterman's over-glitzy under-functional piles of code... :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Tue, Sep 26, 2000 at 05:47:02PM +0100, Jules Bean wrote: > On Tue, Sep 26, 2000 at 10:20:38AM -0600, Joshua Shagam wrote: > > > > And, if I'm not mistaken, imlib is one of Rasterman's over-glitzy > > under-functional piles of code... :) > > Well, I don't think this is a very productive thread, but... No. > Imlib may have had some bugs (what doesn't) but raster was quite > correct to observe the need for it, and he wrote a library to handle a > variety of image formats at any colour depth, and the fast copying of > them to the screen, and memory management of them. I didn't say it was a bad idea. Just that Rasterman didn't do a very good job of programming it. :) > The GNOME project realised that he was right about its necessity, > although they eventually diverged from him over implementation issues > (differing priorities). But I don't think it was particularly glitzy, > no. 'Glitzy' can refer to a number of things. Such as the ego involved in its presentation. > And imlib2 offers transparency, which you probably think is glitzy, > but I think it is a useful user interface element given that modern > graphics hardware is up to the task. Again, 'glitzy' can refer to a number of things. Features isn't glitz - overglorified presentation of shoddily-implemented features is glitz. If it's implemented right and in a nice, non-obtrusive way, it's not glitz - and as long as imlib2's interface is done in a non-obtrusive way, I wouldn't consider it glitzy. Anyway. Sorry for hijacking this thread to be so off-topic. I'll shut up now. :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Tue, Sep 26, 2000 at 09:35:50AM +0100, Jules Bean wrote: > On Mon, Sep 25, 2000 at 10:36:02AM -0600, Joshua Shagam wrote: > > > How recent are we talking about here? I never noticed any problem with > > > phase2v8, but in the past few days I haven't been running much X applications > > > apart from WindowMaker, xpdf, emacs, xterm and xscreensaver, and it has never > > > occured to me before to wonder how much any of these rely on shared memory. > > > > Not at all. Shm is used msotly for things which do a lot of blitting, like > > games and Rasterman's over-glitzy under-functional piles of code. > > Well, anything which uses MIT-SHM. > > In fact, if I'm not much mistaken, it's imlib which uses SHM (by > default, can be turned off), so some versions of gnome will trigger > the memory leaks too. And, if I'm not mistaken, imlib is one of Rasterman's over-glitzy under-functional piles of code... :) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 04:47:09PM +0200, Torbjörn Andersson wrote: > Branden Robinson wrote: > > > * Yes, the shared memory extension is broken in recent phase2 packages. > > This is a recent development in upstream CVS. If you'd like to help fix > > it, subscribe to xpert@xfree86.org and pursue the issue there; please try > > to submit helpful bug reports to upstream, they could use them. > > How recent are we talking about here? I never noticed any problem with > phase2v8, but in the past few days I haven't been running much X applications > apart from WindowMaker, xpdf, emacs, xterm and xscreensaver, and it has never > occured to me before to wonder how much any of these rely on shared memory. Not at all. Shm is used msotly for things which do a lot of blitting, like games and Rasterman's over-glitzy under-functional piles of code. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: SV: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 04:47:09PM +0200, Torbjörn Andersson wrote: > Branden Robinson wrote: > > > * Yes, the shared memory extension is broken in recent phase2 packages. > > This is a recent development in upstream CVS. If you'd like to help fix > > it, subscribe to [EMAIL PROTECTED] and pursue the issue there; please try > > to submit helpful bug reports to upstream, they could use them. > > How recent are we talking about here? I never noticed any problem with > phase2v8, but in the past few days I haven't been running much X applications > apart from WindowMaker, xpdf, emacs, xterm and xscreensaver, and it has never > occured to me before to wonder how much any of these rely on shared memory. Not at all. Shm is used msotly for things which do a lot of blitting, like games and Rasterman's over-glitzy under-functional piles of code. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 10:23:55PM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > I see no reason that libGLU *as it stands now* needs to be bundled > > with any specific OpenGL implementation or driver. > > It's just what the Linux OGL base decided. Playing along is the most > sensible thing to do as incompatibilities between different OGL > implementations has been one of the largest sources of headaches in > the past (glXCreatePixmapMESA anyone?) Well, glXCreatePixmapMESA is clearly a divergence from the OpenGL spec. That's also part of glX, not of GLU (which doesn't even make calls to glX). > > (Myself, I only use one libGLU call in my entire 3D engine, and > > even that could be easily replaced with a raw OpenGL call if I > > weren't so lazy.) > > That very one call is probably the reason some large ammount of > programs link against libGLU. I guess a rather small ammout of those > programs use the mipmap functions, and a even smaller use the > tessellation or nurbs functions. Oh, my bad, two calls. :) (gluPerspective is the one I was thinking of - I forgot about gluBuildMipmaps.) > > Basically, I think there should just be one libGLU which is > > packaged on its own (for now), and any program which uses GLU > > should just have it as a requirement. > > The OGL base specifies you should provide both. It is true that you > can mix and match any libGL (xlibmesa3, NVIDIA's, ...) with any > libGLU, but IMO it's cleaner if the vendor provides both. Saying > it's ok to do otherwise leads you a step closer to the current > situation with the NVIDIA drivers, where you don't get a proper > development environment from them. > > You could argue that it could be possible to split libGLU into it's > own package. Technically there's nothing wrong with that, except > that every package providing libgl would have to have a 'Depends: > libglu' introduced (since the one package providing libgl had libGLU > in it) and this gratutiously breaks the possibility of installing > woody compiled packages on a potato system (because of other factors > this probably has already happened, but introducing yet another one > is not nice). Good point, and it's not like libGLU is very big to begin with. What's the current rationale for XFree 4's libGL not including libGLU, then? I guess in all the discussion of it needing to go in, I've lost track of why it isn't been in there to begin with... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 10:23:55PM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > I see no reason that libGLU *as it stands now* needs to be bundled > > with any specific OpenGL implementation or driver. > > It's just what the Linux OGL base decided. Playing along is the most > sensible thing to do as incompatibilities between different OGL > implementations has been one of the largest sources of headaches in > the past (glXCreatePixmapMESA anyone?) Well, glXCreatePixmapMESA is clearly a divergence from the OpenGL spec. That's also part of glX, not of GLU (which doesn't even make calls to glX). > > (Myself, I only use one libGLU call in my entire 3D engine, and > > even that could be easily replaced with a raw OpenGL call if I > > weren't so lazy.) > > That very one call is probably the reason some large ammount of > programs link against libGLU. I guess a rather small ammout of those > programs use the mipmap functions, and a even smaller use the > tessellation or nurbs functions. Oh, my bad, two calls. :) (gluPerspective is the one I was thinking of - I forgot about gluBuildMipmaps.) > > Basically, I think there should just be one libGLU which is > > packaged on its own (for now), and any program which uses GLU > > should just have it as a requirement. > > The OGL base specifies you should provide both. It is true that you > can mix and match any libGL (xlibmesa3, NVIDIA's, ...) with any > libGLU, but IMO it's cleaner if the vendor provides both. Saying > it's ok to do otherwise leads you a step closer to the current > situation with the NVIDIA drivers, where you don't get a proper > development environment from them. > > You could argue that it could be possible to split libGLU into it's > own package. Technically there's nothing wrong with that, except > that every package providing libgl would have to have a 'Depends: > libglu' introduced (since the one package providing libgl had libGLU > in it) and this gratutiously breaks the possibility of installing > woody compiled packages on a potato system (because of other factors > this probably has already happened, but introducing yet another one > is not nice). Good point, and it's not like libGLU is very big to begin with. What's the current rationale for XFree 4's libGL not including libGLU, then? I guess in all the discussion of it needing to go in, I've lost track of why it isn't been in there to begin with... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 03:40:03AM -0500, Branden Robinson wrote: > * The Mesa problem (specifically, the lack of libGLU.so) really has to be IMNSHOIANALIIRC, every implementation of libGLU I've ever seen has just been a simple, software-only, non-hardware-pipelinable algorithmic wrapper around OpenGL calls. I see no reason that libGLU *as it stands now* needs to be bundled with any specific OpenGL implementation or driver. Although SGI says otherwise, libGLU really is just a separate thingy which a lot of OpenGL applications happen to use. (Myself, I only use one libGLU call in my entire 3D engine, and even that could be easily replaced with a raw OpenGL call if I weren't so lazy.) Of course, some people use the tesselator and the like, but those still aren't really reliant on any specific impementation of libGL, they just require that there be a libGL to link against. Basically, I think there should just be one libGLU which is packaged on its own (for now), and any program which uses GLU should just have it as a requirement. If it ever changes and some video card implements part of GLU in hardware (which is incredibly unlikely), then it could be sorted out later. As it stands, though, I don't think that GLU even cares about the current OpenGL context, since it just makes raw OpenGL calls anyway. Of course, it could be that I'm totally off-base, and the only functions I've been looking at in the GLU source happen to not need low-level OpenGL access. However, some parts of GLU (such as the tesselator) don't even seem to rely on OpenGL at all... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: G400 DRI?
On Sun, Sep 24, 2000 at 11:33:24AM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > And wouldn't the DRM modules in the kernel source be both > > quickly-outdated with respect to the actual drivers? I tend to > > need the bleeding-edge features of the 3D drivers (for me, 'Quake 3 > > working' isn't good enough). > > Hmm... I know the feeling. > > I think this is what you've got wrong. The kernel modules do > housekeeping work: manage DMA buffers, context switches, states, > hardware locking, etc. As you can imagine, this is all card > dependent. That's the reason why there's a kernel module for each > card. > > The DRI modules (those in /usr/X11R6/lib/modules/dri) do the work. Okay, thanks for clearing that up. I wasn't quite sure what the relationship between DRI and DRM was. In that case, I guess bleeding-edge DRM isn't as necessary. :) Where is the kernel's CVS repository so I can just grab the DRM out of it? Not wanting to download entire kernel source to rebuild a kernel for one feature applies to not wanting to download entire kernel source to grab one kernel module out of it. I suppose that at the very worst I could just download the kernel source at the university and repackage the useful parts myself, though... > > Unfortunately, their whole source distribution seem sincredibly > > half-assed. All they're doing is taking the CVS version of the > > XFree driver (including DRM) and adding in their closed-source card > > init stuff which adds in DualHead and video out but seems to break > > returning into textmode (and I use neither DualHead nor video out). > > For all I know, you'll be happier using the drivers supplied with > Branden's packages instead of the Matrox's ones. Yeah, I've already figured that much out. :) I was originally hoping that Matrox's drivers would actually be a proper set of 3D drivers like what nVidia did, but it looks like they're just doing the cheesy "let's take advantage of open source and roll in our own proprietary crap and take credit for all of it!" crap that 3Dfx and Creative Labs are so known for. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 03:40:03AM -0500, Branden Robinson wrote: > * The Mesa problem (specifically, the lack of libGLU.so) really has to be IMNSHOIANALIIRC, every implementation of libGLU I've ever seen has just been a simple, software-only, non-hardware-pipelinable algorithmic wrapper around OpenGL calls. I see no reason that libGLU *as it stands now* needs to be bundled with any specific OpenGL implementation or driver. Although SGI says otherwise, libGLU really is just a separate thingy which a lot of OpenGL applications happen to use. (Myself, I only use one libGLU call in my entire 3D engine, and even that could be easily replaced with a raw OpenGL call if I weren't so lazy.) Of course, some people use the tesselator and the like, but those still aren't really reliant on any specific impementation of libGL, they just require that there be a libGL to link against. Basically, I think there should just be one libGLU which is packaged on its own (for now), and any program which uses GLU should just have it as a requirement. If it ever changes and some video card implements part of GLU in hardware (which is incredibly unlikely), then it could be sorted out later. As it stands, though, I don't think that GLU even cares about the current OpenGL context, since it just makes raw OpenGL calls anyway. Of course, it could be that I'm totally off-base, and the only functions I've been looking at in the GLU source happen to not need low-level OpenGL access. However, some parts of GLU (such as the tesselator) don't even seem to rely on OpenGL at all... -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G400 DRI?
On Sun, Sep 24, 2000 at 11:33:24AM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > And wouldn't the DRM modules in the kernel source be both > > quickly-outdated with respect to the actual drivers? I tend to > > need the bleeding-edge features of the 3D drivers (for me, 'Quake 3 > > working' isn't good enough). > > Hmm... I know the feeling. > > I think this is what you've got wrong. The kernel modules do > housekeeping work: manage DMA buffers, context switches, states, > hardware locking, etc. As you can imagine, this is all card > dependent. That's the reason why there's a kernel module for each > card. > > The DRI modules (those in /usr/X11R6/lib/modules/dri) do the work. Okay, thanks for clearing that up. I wasn't quite sure what the relationship between DRI and DRM was. In that case, I guess bleeding-edge DRM isn't as necessary. :) Where is the kernel's CVS repository so I can just grab the DRM out of it? Not wanting to download entire kernel source to rebuild a kernel for one feature applies to not wanting to download entire kernel source to grab one kernel module out of it. I suppose that at the very worst I could just download the kernel source at the university and repackage the useful parts myself, though... > > Unfortunately, their whole source distribution seem sincredibly > > half-assed. All they're doing is taking the CVS version of the > > XFree driver (including DRM) and adding in their closed-source card > > init stuff which adds in DualHead and video out but seems to break > > returning into textmode (and I use neither DualHead nor video out). > > For all I know, you'll be happier using the drivers supplied with > Branden's packages instead of the Matrox's ones. Yeah, I've already figured that much out. :) I was originally hoping that Matrox's drivers would actually be a proper set of 3D drivers like what nVidia did, but it looks like they're just doing the cheesy "let's take advantage of open source and roll in our own proprietary crap and take credit for all of it!" crap that 3Dfx and Creative Labs are so known for. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G400 DRI?
On Sun, Sep 24, 2000 at 01:12:48AM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > Okay, since posting my original message, I've found out (with > > Marcelo Magallon's help) that I need to get a DRI driver which > > matches interfaces with the XFree server. As far as I can tell, > > the current Matrox driver (which is based on PI's CVS-current > > driver) uses the 2.0.0 interface, whereas the .debs' server only > > groks the 1.0.x interface. I have the mga.o kernel module from the > > DRI project on Sourceforge compiled and everything, but there's the > > interface mismatch so it does me no good... > > Somehow I got the impression you need/want to run 2.2.17. As someone > else pointed out, the DRM modules have been incorporated into the > 2.2.18 kernel source. I have no idea which version, though. The DRM > modules out of the DRI CVS do compile with a whole range of kernels. I want to run 2.2.17. I've had bad luck trying to get 2.4 working (I can't seem to get it to boot all the way without a kernel panic), and 2.2.18 doesn't seem to have any Debian packages (isn't it still in pre?). And wouldn't the DRM modules in the kernel source be both quickly-outdated with respect to the actual drivers? I tend to need the bleeding-edge features of the 3D drivers (for me, 'Quake 3 working' isn't good enough). > What I said was that the current XFree86 CVS tree got merged into the > current DRI CVS tree recently. As far as I have noticed, the reverse > has not happened yet. Branden takes updates from the XFree86 tree. > That means you'll have to wait until the DRI CVS tree is merged on > the XFree86 CVS tree. The other possilibity is, I just realized, > take the DRM modules from a not-so-recent 2.4 kernel (test8 does the > trick) because the modules with the 2.0.0 interface hasn't been > merged on the current kernel source. Last time I checked this would > compile on a 2.2 kernel provided you use the correct Makefile. Hm, there's an idea. (And that gets back to why I'm not too happy about the kernel including the DRM drivers. :) > If Matrox is providing source, it's possible that they are providing > the sources with the old interface, too. I wish I could give you > more precise information but I have a Matrox card, but I'm sticking > to the DRI CVS for work-related reasons. Unfortunately, their whole source distribution seem sincredibly half-assed. All they're doing is taking the CVS version of the XFree driver (including DRM) and adding in their closed-source card init stuff which adds in DualHead and video out but seems to break returning into textmode (and I use neither DualHead nor video out). > > private email. Also, why would I want to use the 1.0.x version > > which comes in the kernel source when it's probably outdated and > > not full-featured, and not likely to get updated very often anyway? > > The two versions are not that different in fact. The interfaces are > just not compatible with each other. Okay, so for now the 1.0.x driver should have all the same rendering features as the 2.0.0 driver? I'll have to see if the Beta1 from Matrox includes the old 1.0.0 DRM, then, since that seem sto be the general impression... (I've only tried their Beta3, which is 2.0.0.) Thanks. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: G400 DRI?
On Sun, Sep 24, 2000 at 01:12:48AM +0200, Marcelo E. Magallon wrote: > >> Joshua Shagam <[EMAIL PROTECTED]> writes: > > > Okay, since posting my original message, I've found out (with > > Marcelo Magallon's help) that I need to get a DRI driver which > > matches interfaces with the XFree server. As far as I can tell, > > the current Matrox driver (which is based on PI's CVS-current > > driver) uses the 2.0.0 interface, whereas the .debs' server only > > groks the 1.0.x interface. I have the mga.o kernel module from the > > DRI project on Sourceforge compiled and everything, but there's the > > interface mismatch so it does me no good... > > Somehow I got the impression you need/want to run 2.2.17. As someone > else pointed out, the DRM modules have been incorporated into the > 2.2.18 kernel source. I have no idea which version, though. The DRM > modules out of the DRI CVS do compile with a whole range of kernels. I want to run 2.2.17. I've had bad luck trying to get 2.4 working (I can't seem to get it to boot all the way without a kernel panic), and 2.2.18 doesn't seem to have any Debian packages (isn't it still in pre?). And wouldn't the DRM modules in the kernel source be both quickly-outdated with respect to the actual drivers? I tend to need the bleeding-edge features of the 3D drivers (for me, 'Quake 3 working' isn't good enough). > What I said was that the current XFree86 CVS tree got merged into the > current DRI CVS tree recently. As far as I have noticed, the reverse > has not happened yet. Branden takes updates from the XFree86 tree. > That means you'll have to wait until the DRI CVS tree is merged on > the XFree86 CVS tree. The other possilibity is, I just realized, > take the DRM modules from a not-so-recent 2.4 kernel (test8 does the > trick) because the modules with the 2.0.0 interface hasn't been > merged on the current kernel source. Last time I checked this would > compile on a 2.2 kernel provided you use the correct Makefile. Hm, there's an idea. (And that gets back to why I'm not too happy about the kernel including the DRM drivers. :) > If Matrox is providing source, it's possible that they are providing > the sources with the old interface, too. I wish I could give you > more precise information but I have a Matrox card, but I'm sticking > to the DRI CVS for work-related reasons. Unfortunately, their whole source distribution seem sincredibly half-assed. All they're doing is taking the CVS version of the XFree driver (including DRM) and adding in their closed-source card init stuff which adds in DualHead and video out but seems to break returning into textmode (and I use neither DualHead nor video out). > > private email. Also, why would I want to use the 1.0.x version > > which comes in the kernel source when it's probably outdated and > > not full-featured, and not likely to get updated very often anyway? > > The two versions are not that different in fact. The interfaces are > just not compatible with each other. Okay, so for now the 1.0.x driver should have all the same rendering features as the 2.0.0 driver? I'll have to see if the Beta1 from Matrox includes the old 1.0.0 DRM, then, since that seem sto be the general impression... (I've only tried their Beta3, which is 2.0.0.) Thanks. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G400 DRI?
Okay, since posting my original message, I've found out (with Marcelo Magallon's help) that I need to get a DRI driver which matches interfaces with the XFree server. As far as I can tell, the current Matrox driver (which is based on PI's CVS-current driver) uses the 2.0.0 interface, whereas the .debs' server only groks the 1.0.x interface. I have the mga.o kernel module from the DRI project on Sourceforge compiled and everything, but there's the interface mismatch so it does me no good... When will the .debs' server grok DRM 2.0.0? Apparently this just requires it being updated with the latest XFree source tree, but I'm not quite sure I understood what Marcello had told me in private email. Also, why would I want to use the 1.0.x version which comes in the kernel source when it's probably outdated and not full-featured, and not likely to get updated very often anyway? FWIW, having the DRI source distributed along with the kernel source offends my sensibilities, for the same reason that distributing scanner and joystick drivers et al with the kernel does - these things aren't part of the kernel, they need to be updated separately and more often, and I don't want to have to download the entire kernel source to update my video driver. :P The whole current state of what's in the kernel source package is a rant for another day, though. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
Re: G400 DRI?
Okay, since posting my original message, I've found out (with Marcelo Magallon's help) that I need to get a DRI driver which matches interfaces with the XFree server. As far as I can tell, the current Matrox driver (which is based on PI's CVS-current driver) uses the 2.0.0 interface, whereas the .debs' server only groks the 1.0.x interface. I have the mga.o kernel module from the DRI project on Sourceforge compiled and everything, but there's the interface mismatch so it does me no good... When will the .debs' server grok DRM 2.0.0? Apparently this just requires it being updated with the latest XFree source tree, but I'm not quite sure I understood what Marcello had told me in private email. Also, why would I want to use the 1.0.x version which comes in the kernel source when it's probably outdated and not full-featured, and not likely to get updated very often anyway? FWIW, having the DRI source distributed along with the kernel source offends my sensibilities, for the same reason that distributing scanner and joystick drivers et al with the kernel does - these things aren't part of the kernel, they need to be updated separately and more often, and I don't want to have to download the entire kernel source to update my video driver. :P The whole current state of what's in the kernel source package is a rant for another day, though. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
G400 DRI?
Hello, I've just upgraded my XFree 3.3.6 to 4.0.1 using these wonderful packages, and haven't had any problems. Except one... I need the DRI driver for my G400. Specifically, I'm trying to use Matrox's binary-distributed one, and as it turns out, they only distribute a binary version of the 2D driver (which makes sense, given the DRI's kernel module nature). The DRI driver is only in source. But I don't want to download 50 megs of XFree86 source on my 28.8 modem. :) Has anyone built the G400 DRI module against kernel 2.2.17? I don't even need this for game playing - I need this for my research. 3D graphics research really sucks on software Mesa. :) Any help would be greatly appreciated. Or perhaps if I could just get the necessary header files to build the module myself (I have the kernel source and I can always just make-kpkg). Also, in the future, how will DRI modules be packaged? Perhaps there will be an xfree-server-heards package so that one can simply download their favorite DRI module's source and then use make-kpkg to build it alongside their kernel? That seems to me to be the simplest way... Many thanks in advance. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards
G400 DRI?
Hello, I've just upgraded my XFree 3.3.6 to 4.0.1 using these wonderful packages, and haven't had any problems. Except one... I need the DRI driver for my G400. Specifically, I'm trying to use Matrox's binary-distributed one, and as it turns out, they only distribute a binary version of the 2D driver (which makes sense, given the DRI's kernel module nature). The DRI driver is only in source. But I don't want to download 50 megs of XFree86 source on my 28.8 modem. :) Has anyone built the G400 DRI module against kernel 2.2.17? I don't even need this for game playing - I need this for my research. 3D graphics research really sucks on software Mesa. :) Any help would be greatly appreciated. Or perhaps if I could just get the necessary header files to build the module myself (I have the kernel source and I can always just make-kpkg). Also, in the future, how will DRI modules be packaged? Perhaps there will be an xfree-server-heards package so that one can simply download their favorite DRI module's source and then use make-kpkg to build it alongside their kernel? That seems to me to be the simplest way... Many thanks in advance. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email / \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
