Keith Packard wrote:
Around 2 o'clock on Nov 19, "[EMAIL PROTECTED]" wrote:
Keith, could you put this (being able to specify the interface bindings of
the xserver on the commandline) as a feature request on http://
www.freedesktop.org/Software/XserverWishlist if you find this feature
request usef
ssh uses IP4:127.0.0.1, and as many times as ppl have asked for unix socket support it
has allways
been denied. -nolisten tcp is something for the distros to set up, it should be
*usable by
default.
* Meaning all non-devel features on and nothing extra for the user to do.
--- Keith Whitwell <[
On Wed, Nov 19, 2003 at 12:57:25AM +, Sergey V. Oudaltsov wrote:
>
> > Stock drivers never have. You may want to help with the kernel patches
> > floating around for this?
> Well, I don't really know. I am not a big kernel expert. I just say what
> I see: when I run "standard" Fedora X driver
> pre-install r200 modprobe -k agpgart
Just one question. Should it be "r200" or "radeon"?
Thanks for the config line, I'll try it.
Sergey
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be mor
On Wed, Nov 19, 2003 at 02:02:50PM +, Sergey V. Oudaltsov wrote:
> > pre-install r200 modprobe -k agpgart
> Just one question. Should it be "r200" or "radeon"?
It should be "radeon" actually. My bad...
Jose Fonseca
---
This SF.net email
Hello!
yesterday I got that annoying xserver hang on R200.
XFree86 4.3.99.xx from october, DRI CVS HEAD (a few days old), Kernel 2.4.22 with v4l2.
I verified with a fresh build of XFree86 CVS HEAD (yesterday).
The strange things are the backtraces:
1. "older" XFree and current DRI CVS:
(gdb) bac
> It should be "radeon" actually. My bad...
I knew! I knew! :)
Well, anyway - this does not explain why libGL cannot find dri while
xfree86.0.log says it is there...
Sergey
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does
On Wed, Nov 19, 2003 at 03:25:49PM +, Sergey V. Oudaltsov wrote:
> > It should be "radeon" actually. My bad...
> I knew! I knew! :)
>
> Well, anyway - this does not explain why libGL cannot find dri while
> xfree86.0.log says it is there...
>
> Sergey
It must be the TLS thingy. Do
ldd /
# ldd /usr/bin/X11/glxinfo
...
libGL.so.1 => /usr/X11R6/lib/tls/libGL.so.1 (0x00541000)
...
And this symlink points to the library (libGL.so.1.2) shipped with the
binary snapshot (well, the install.sh script had some problem - but I
fixed it manually).
> LD_LIBRARY_PATH=... ldd /usr/bin/X11/glx
Hello,
my p650 arrived. 2d is great in linux and in windows i get 191 fps in
quake3. i would like to play in linux though...
so i was trying to build the matrox parhelia kernel module on linux
2.6.0-test9. but it did not compile:
Using kernel headers in /lib/modules/2.6.0-beta-test9/build/inclu
Hi,
> quote from the matrox binary drivers README:
> >Matrox Parhelia & Millennium P650/P750
> >LINUX Display Driver
> > V 1.0 Pro
^
> ...
> >Description of this release
> >===
> >
>
Jan Eidtmann wrote:
my p650 arrived. 2d is great in linux and in windows i get 191 fps in
quake3. i would like to play in linux though...
so i was trying to build the matrox parhelia kernel module on linux
2.6.0-test9. but it did not compile:
[snip]
thats all spanish to me, so i ask, i please y
On Wed, 2003-11-19 at 20:46, Dave Jones wrote:
> On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
> > >
> > >
> > > hammers[i++] = loop_dev;
> > > nr_garts = i;
> > >#ifdef CONFIG_SMP
> > > if (i == MAX_HAMMER_GARTS) {
> > > printk(KERN_INFO PFX "Too m
On Wed, Nov 19, 2003 at 11:17:17AM -0800, James Jones wrote:
> diff -ruN linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c
> linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c
> --- linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c 2003-10-08 12:24:04.0
> -0700
> +++ linux-2.6.0-tes
Dave,
Similar patch to Ronny's, but also changes a config check on x86_64
arch. It struck me that this patch is still slightly wrong. It should
check the number of bridges already found before going through the
entire detection routine again shouldn't it?
-James
Dave Jones wrote:
On Fri, O
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX "Too many northbridges for AGP\n");
return -1;
}
Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
1 and 1 gart was
On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
> >
> >
> > hammers[i++] = loop_dev;
> > nr_garts = i;
> >#ifdef CONFIG_SMP
> > if (i == MAX_HAMMER_GARTS) {
> > printk(KERN_INFO PFX "Too many northbridges for AGP\n");
> > return -1;
> >
On Wed, Nov 19, 2003 at 08:56:32PM +0100, Ronny V. Vindenes wrote:
> > If we have an SMP system with an SMP kernel, we add however many
> > GARTs to the table, up to a limit of MAX_HAMMER_GARTS.
> >
>
> It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if
> there is an MAX_
On Wed, Nov 19, 2003 at 12:13:37PM -0800, James Jones wrote:
>
>
> Ronny V. Vindenes wrote
>
> >It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if
> >there is an MAX_HAMMER_GARTS'th GART.
> >
> >
> Yes, thanks for putting it more clearly Ronny.
>
> Dave, try walkin
Ronny V. Vindenes wrote
It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if
there is an MAX_HAMMER_GARTS'th GART.
Yes, thanks for putting it more clearly Ronny.
Dave, try walking through the code with MAX_HAMMER_GARTS=2 and SMP
enabled. You should quickly see what we mean.
The ( i > MAX_HAMMER_GARTS) fix was just an example. The test really
needs to be == and be moved before the
hammers[i++] = loop_dev;
assignment, or hammers will be overflowed, as I mentioned in my previous
email.
Also, it really seems like this test should be done before you go
through all t
> Either that or apps can work around buggy libGLs by checking the client
> extension string for GLX_ARB_get_proc_address. That extension is
> client-side only, so that's good enough.
Well, this is the output of a glxinfo from an user with the bug :
name of display: :0.0
display: :0 screen: 0
On Wed, 2003-11-19 at 17:07, Andreas Stenglein wrote:
>
> yesterday I got that annoying xserver hang on R200.
'That' annoying hang? Have I missed something? *shrug*
> (gdb) back
> #0 0x4011fd54 in ioctl () from /lib/libc.so.6
> #1 0xfc02 in ?? ()
> #2 0x0867d5c6 in ?? ()
> #3 0x084744d1
Lionel Ulmer wrote:
Either that or apps can work around buggy libGLs by checking the client
extension string for GLX_ARB_get_proc_address. That extension is
client-side only, so that's good enough.
Well, this is the output of a glxinfo from an user with the bug :
[snip]
And you can see that no
The attached patch adds alpha blending support to the video overlay on
radeon hardware. It's been tested on my 9200. It adds three new Xv
attributes: XV_ALPHA_MODE, XV_GR_ALPHA, and XV_OV_ALPHA.
XV_ALPHA_MODE - (0 or 1) selects the alpha blending mode. right now it
only supports key and global
25 matches
Mail list logo
