(The call-e) is built so it's
forward and backward compat.
So a fue tweaks here and there it's farely straight forward. I'm amazed
that any features ever get added to Linux.
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-06-14 at 20:34, Mike Mestnik wrote:
Ohh, is it realy that hard
--- Stephane Marchesin [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns
a pointer to a dispatch function. If you request an unknown function,
it will dynamically generate a dispatch for it. Try calling
In r200_lock.c r200UpdatePageFlipping:
rmesa-pClipRects[0].x2 seams to allways have the correct value while x1
dose not. Here is the code I added.
if ( rmesa-numClipRects == 1 )
{
printf(%d\n, rmesa-pClipRects[0].x1);
}
Here is the output I got...
930 --- Move
779 ---
How about a copy/rename of teh X include and then s/X/dri/ it till it's
good to go. This would make (re)porting a no task task.
--- Dave Airlie [EMAIL PROTECTED] wrote:
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to
I found that rb3d_coloroffset:0x1c40 gets emited in both the [1]client
and the [2]DRM.
1. At init time and 3 other places.
2. At emit state from the ctx.
I was wondering how I should procede in making changes to the way this reg
gets used(how to set it to a diffrent value, globaly). I think the
--- Patrick McFarland [EMAIL PROTECTED] wrote:
On 05-Jun-2004, Michel D?nzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrj??l?? wrote:
The client should just use a surface id (handed out by the memory
allocator)
instead of a real address. The kernel would then check if the
--- Patrick McFarland [EMAIL PROTECTED] wrote:
On 05-Jun-2004, Ville Syrj?l? wrote:
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel D?nzer wrote:
I'm not sure about that; pseudo-command buffers that the DRM parses
and
generates the actual DMA buffers from on the fly might be better for
--- Ian Romanick [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
Couldn't it just use the largest GART size possible (set by the bios),
or would this have some negative consequences?
I think the Idea Here is to fallback after a failed bind!!! I.E. AGPSize
== 124MB where only a 64MB largest
--- Ian Romanick [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
It could waste a lot of RAM.
Yup. This is one of the bad parts of the AGP implementation on Linux.
Once the AGP aperture is setup, it always has non-swappable
http://www.eff.org/IP/Video/DVDCCA_case/20040227_eff_pr.php
I found this article amusing, it showes that the DeCSS DVD decryption
computer code is in the public domain and no longer a trade secret. It
dose also say that there will be an appeal.
I was wondering where we where with the s3tc? The
--- Tomas Carnecky [EMAIL PROTECTED] wrote:
David Bronaugh wrote:
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking
(ever
read chip docs? You try
Attached is the patch I made to make more cliprects when 2048. It
dosen't have any code to move the 3d-viewport, I'm still looking into how
that will work.
Where can I find docs on debuging the client GL driver? Just using ddd
didn't work and gave me a broken bt.
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard for me to recognize anything; can you describe your
observations?
The data was shifted to the right
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset.
It's hard
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset. I still have to find where rmesa-state.color.drawOffset
comes from and what effect the first 4 bits(define RADEON_COLOROFFSET_MASK
0xfff0) are for(Why RADEON_COLOROFFSET_MASK was missing from
_lock.c and
The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
for debian. What I found shoking is that there is support for SuSE, as
well as RedHat. I don't think it's at all whise to duplicate this work.
Surely there is an autoconf ./configure script that will detect the
As tehre are no debian specific remarksections the Makefile dose support
Debian. There is no make install function thought.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
for debian. What I found shoking
I think every thing Tomas Carnecky has said here about device driver
design is valid and dose apply to the DRM/dri. He may not know every
thing about system security, but we also all have our strangths and his
strangth is oviously device design. One way of interpeting what he is
trying to say
After finding the 3 places where the reg I wanted to control was changed I
went about normalising the code by creating a function
r200UpdateColorOffset.
Added it to the .h and used in in other files that included that .h.
After a succsesfull build I got this error??? I then verrified the output
you fav gripe here.
1e. Even if hell has frozen over and a nutron boom has damaged your video
card.
--- Holger Waechtler [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only practical
to
have
C code I needed to replace it with.
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It
looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
. glibc is built for both 64bit and 32bit binarys.
Normally the differance is...
sparc32 make all; # vs just running make all and this is needed for many
programs that don't take into account 64bit systems.
--- Ian Romanick [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Ian Romanick [EMAIL
Thank you for your informative reply.
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
I'm currently unable to define a clone mode where one screen is
smaller
then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs
1024x768-1024x768.
You
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
Thank you for your informative reply.
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
I'm currently unable to define a clone mode where one screen is
smaller
then the other
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Thank you for your informative reply.
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
The problem I have is that my settup is lopsided, one monitor has
I think I finaly get it. When we have a window grater then 2048, we need
to run a GL command move the cliprect and run it again? The only way to
find out where we need is to SW render the cmd. Won't this cut our
framerate in half? Plus moving the cliprect for most of the drawing cmds,
what
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Thank you for your informative reply.
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
I think I finaly get it. When we have a window grater then 2048, we
need
to run a GL command move the cliprect and run it again? The only way
to
find out where we need is to SW render the cmd
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical
to have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
--- Ian Romanick [EMAIL PROTECTED] wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version. I wasn't
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
The 3D driver already handles several cliprects for when a window is
partially obscured, SHAPE windows, ... That would just need to be
extended
Can the GART apperture be moved physicaly? I don't think a logical move
would be much help.
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text
the answer too these problems is runnaway rendering, where the
openGL calls simply return as thought they didn't do any thing.
--- Holger Waechtler [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only
the answer too these problems is runnaway rendering, where the
openGL calls simply return as thought they didn't do any thing.
--- Holger Waechtler [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only
Lets just say that this is good fault tolorance. What ever can go wrong
will, all drivers are faulty. This sounds like a good idea and should be
implemented for ordinary use or something like it.
Unless you thing we should KP on a lock being held for more then a given
time(30 seconds)?
---
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
Lets just say that this is good fault tolorance. What ever can go
wrong
will, all drivers are faulty. This sounds like a good idea and should
be
implemented for ordinary use or something like it.
Unless you thing we
I'm currently unable to define a clone mode where one screen is smaller
then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs
1024x768-1024x768.
The problem I have is that my settup is lopsided, one monitor has better
modes than the other. The *larger* monitor is on the right, thus
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can all-ready run X on multiple VTs and with DRI-reinit can
run GL
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be
0.
How does mergedfb work internally? I
:49AM -0700, Mike Mestnik wrote:
A fue other questions, directed at the memory mngmt ppl. What about
2d
only page fliping, ModeX and the like? Where these ever supported
outside
of libsvga? Are thay rellecs from the past that can die?
Page flipping is important. DirectFB uses
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- David Bronaugh [EMAIL PROTECTED] wrote:
I think this design allows for mergedfb to work however we need it
to
by encapsulating all
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
How does mergedfb work internally? I
--- David Bronaugh [EMAIL PROTECTED] wrote:
- Format of messages might be something like device identifier,
resx, resy, colour depth, refresh (optional), extra_params (optional)
Did you talk at all about memory mngmt? For instance when setting a mode
is it needed to have a frame buffer or
as well as mem total.
- Returning hardware capabilitys(like in a termcap type way), not just
mem sizes. I.E. zbuffer type(how to know it's size).
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- David Bronaugh [EMAIL PROTECTED] wrote:
- Format of messages might
I could be wrong, but is not allocating framebuffers and mmaping memory
diffrent than setting up framebuffers and configuring DACs?
--- Jon Smirl [EMAIL PROTECTED] wrote:
It's not just bloat, the network code is used millions of times per
second. Mode
setting happens occaisonally.
The
Firstly I'm glad to see that DRI will stop replacing all of Xfree86, as it
will cut down on bug reports like this one. There is a bug in DRI's
libX11.so.6 that causes it to stall in a select, bt included.
I don't realy care that it is fglrx the problem is that it should NEVER
just wait for the
) I'm talking about are open source it would seam proper to
have them be interchangable, as thay both come from the same root source.
--- Adam Jackson [EMAIL PROTECTED] wrote:
On Thursday 29 April 2004 12:11, Mike Mestnik wrote:
Firstly I'm glad to see that DRI will stop replacing all of Xfree86
I have a sparc64 running linux. I do not have a Creator3D card I'm using
the on-board mach64(Rage 3D Pro). I do have a sun video card expanshion
slot. At this time I can't build the Mesa tree due to solaris asm not
being compilable on linux. Only Debian's Xfree86(and maby Xfree86) will
build
disable it. There's ordinary C code to fall back to.
-Brian
Mike Mestnik wrote:
I have a sparc64 running linux. I do not have a Creator3D card I'm
using
the on-board mach64(Rage 3D Pro). I do have a sun video card
expanshion
slot. At this time I can't build the Mesa tree due
--- Ian Romanick [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
These PCI changes duplicate things that are in framebuffer. Shouldn't
we be
having a giant argument about them? I would think that is worse that
DRM is is
Heh...you sure do like to start fights, don't you? :)
duplicating
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2004-04-16 at 23:02, Nathanael Nerode wrote:
Michel Dänzer wrote:
On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use
userland-loadable
firmware.
Sigh, is this really
I was under the impresion that several bugs where found in 4.3.99.902 that
need patching. This work has allready been done twice I shuder to think
any one would bother a third.
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Thu, Apr 15, 2004 at 08:13:53AM -0700, Alex Deucher wrote:
Speaking
Do you mean something like...
sed 's/0x111, 0x/0x111, 0x, The dev name/'
You could do this in place or on a radeon-ids.h.
I'm sure it would be better ro use an awk script to prune the info from
radeon.h and just have it distributed by default. My vote is to have it
bloat the kernel
And don't forget that pci.ids and the code that uses it could be portet to
BSD as part of the DRM.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Do you mean something like...
sed 's/0x111, 0x/0x111, 0x, The dev name/'
You could do this in place or on a radeon-ids.h.
I'm sure
--- Dave Airlie [EMAIL PROTECTED] wrote:
My main worry is that this stuff break BSD compat, and without Eric
around
I'd say fixing it mightn't be the easiest, also for the 2.6 merge I've
removed all the device ID strings as as Dave J pointed out they are
duplicating pci.ids, can we not get
no
response.
--- Anish Mistry [EMAIL PROTECTED] wrote:
On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote:
This is nothing more than a HUNK fixed copy of the TVOut patch
found
on
leif's linux page. With this patch the TVOut and other related
options
are evaluated
I have seen this also on my laptop(mach64) and my desktop(radeon). It
just started happining recently.
--- Daniele Boffi [EMAIL PROTECTED] wrote:
At the beginning I thought is was a hardware problem, even if it started
immediately after I upgraded to CVS radeon driver. But then, I noticed
do VBE calles.
--- Anish Mistry [EMAIL PROTECTED] wrote:
On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote:
This is nothing more than a HUNK fixed copy of the TVOut patch found
on
leif's linux page. With this patch the TVOut and other related
options
are evaluated and it is posible
This is nothing more than a HUNK fixed copy of the TVOut patch found on
leif's linux page. With this patch the TVOut and other related options
are evaluated and it is posible to use atitvout while in X. However I
notesed some problems with this patch that only a reboot would fix. There
was
Just a side note, is the history of these files needed in the mesa tree?
I would think it would only be uasable in the DRI tree and it's archived
there so no need to duplicate that.
The DRM is another storry, ppl may wish to build older versions from the
new module.
--- Michel Dänzer [EMAIL
At first I thought it just might have been my system. In debuging the
problem I found ought that my chip dose not have triangle setup. It's not
likely that it will be supported by DRI. However the 2d driver gave me
xrendr support, this will help with TV out for me.
As for the kmod if you post
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the ?2d driver? or X
server to keep track of pending swaps for all dri clients, but if it were
GLX it would be
Dose most DACs have dublebuffering or do you realy only have from the
start of the vtrace to the end to do your update? If you can having from
the start of the vtrace untill the end of the next vtrace todo your
swaping is optimal.
- If you only have one FB. Pad each, or some, commands with
I was building mach64 drm for 2.6.3. I had the worst time convincing
Makefile.linux and inturn Makefile.kernel that it was not lessthan25 and
lessthan2552. I finaly gave up once I saw I had to gointo all the .h and
.c files and add #defines there as well. Also I don't have a mach64 pro
so I
2004 04:08:11 -0800 (PST)
Mike Mestnik [EMAIL PROTECTED] wrote:
I was building mach64 drm for 2.6.3. I had the worst time convincing
Makefile.linux and inturn Makefile.kernel that it was not lessthan25
and
lessthan2552. I finaly gave up once I saw I had to gointo all the .h
and
.c files
I have a UltraSparc5 with an onboard Rage3D, workes with the mach64
driver. There are some problems with the kernel and PCI domains, but I
got thoes cleared out. There is still a problem that the chip is stuck in
whaterver mode is set by openboot(the bios), but I can change the bit
depth. Other
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote:
[...] Other than that and endianess and byte size issues is there any
thing else that might not work?
FWIW, people have been running Mach64 DRI on PPC for a while (only with
MMIO though, not DMA
: Error: detected global register
use not covered by .register pseudo-op
../../../../lib/GL/mesa/sparc/xform.S:30: Error: detected global register
use not covered by .register pseudo-op
--- Ian Romanick [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
I have a UltraSparc5 with an onboard Rage3D
I'm no expert, but with mtex dose more TMUs help?
If so you should try with the patch, I have had 6 enabled with no problems or use.
Also how can I help get this patch commited? I can run test programs.
The patch should be in list arcives dated...
Sat, 3 Jan 2004 00:30:35 +0100
Sun, 4 Jan 2004
Three things I don't know are.
1. What needs to be donated so IP issues are paid for?
2. Can programs like UT200? contain there own decompressor for software fallbacks?
3. Has there been any contact from S3?
It's not my intention to flame, don't bother if all you can say in response is NO.
--- Roland Scheidegger [EMAIL PROTECTED] wrote:
copypaste job, I didn't touch anything in the code at all (except
replacing r200 with radeon a couple of times...). That said, I
I'v heard this alot so I just thought I'd say even thought it's not my place. Don't
you think it
would be nicer
be overcome, application hotkey to run xset for example.
Must CC me in reply.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Date: Sun, 18 Jan 2004 10:10:28 -0800 (PST)
From: Mike Mestnik [EMAIL PROTECTED]
Subject: driconfig: TMU(s) and s3tc.
To: lists.sourceforge.net dri-users [EMAIL PROTECTED
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into
Not that I know of.
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Mike,
Have there been any changes to the status of the off-by-one
problem (ie, 3d rendering works only for apps that don't extend beyond
that 2047th pixel)?
Adam
__
Do you
I'm trying to build mach64-0-0-6-branch on my sparc. I'm building on Debian
sid/sarge. In the
mesa building I get this...
make[6]: Entering directory `/root/xfree86/xc-current/lib/GL/mesa/src/SPARC'
rm -f xform.i
/usr/bin/cpp -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L
lspci -vvv
--- Chris Ison [EMAIL PROTECTED] wrote:
After a couple of kernel recompiles I got oprofile to work, and it was
reporting that most of its time was spend in default_idle for both
glxgears and qw-client-glx (from QuakeForge CVS).
After speaking to one of the oprofile ppl, they seem
PROTECTED] wrote:
On Sat, 2003-12-06 at 07:57, Mike Mestnik wrote:
lspci -vvv
That just tells me the card is capable of using it, doesn't actually
tell my if DRI is taking advantage of it.
With and without DRI installed it tells me the same thing
Control: I/O+ Mem+ BusMaster+ SpecCycle
--- Alex Deucher [EMAIL PROTECTED] wrote:
--- Mike Mestnik [EMAIL PROTECTED] wrote:
The screen size(in pixels or mm) is now x1 + x2 by (y1 y2) * y1 +
(y1 y2) * y2. Swap (y and
x) and (1 and 2) where needed. Then the DPI should be calculated
using the largest or the default
Not at this time, however the work around I have been using is setting up more than
one layout in
my XF86Config. Then I write scripts for common apps/tasks that call the right
xSession and
layout.
I had a dream that apps would be free from persecution of color depth and of
screen/root
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-11-21 at 21:58, Mike Mestnik wrote:
I don't expect GL apps to know what ProjectRoot is set to, would thay be able
to find the right client side driver?
All you have to do is install the one which works (best) for you.
I do run DRI
This is a MFB problem, I think.
I had just setup gamecon for my nintendo controlers and wanted a fullscreen
experiance. I'm told
I want [EMAIL PROTECTED] for the best view. I also want to be able to use my other
head for normal
things. I have a radeon8900. I hooked my Xconfig up with a good
to use
modes they have to be listed in the screen section of your config. if
you are looking for two separate heads (ie, host:0.0 and host:0.1) you
can't use mergedfb. mergedfb only provides a single logical screen.
Alex
--- Mike Mestnik [EMAIL PROTECTED] wrote:
This is a MFB problem, I
I get it too, maby letters and then numbers if it's not just anyone /w yahoo.
--- Alexander Stohr [EMAIL PROTECTED] wrote:
you were the only one that hit those problem.
i only have the very same problem report.
the rest is driven by source forge internals.
maybe its the yahoo origin paired
Any way it's gone now, the world may never know.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
I get it too, maby letters and then numbers if it's not just anyone /w yahoo.
--- Alexander Stohr [EMAIL PROTECTED] wrote:
you were the only one that hit those problem.
i only have the very same
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
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-11-07 at 23:05, Andrew Morton wrote:
Has anyone actually tested the functionality which this patch is supposed
to provide? That loading the DRM module magically triggers a load of AGP?
Haven't tried it, but I doubt it does
--- Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Wed, 29 Oct 2003 08:56:09 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I've been thinking about ways to implement a combined wait for vblank
and buffer swap operation. But somehow I can't get
I am, posted Oct 22, 8:14PM CST
--- Alex Deucher [EMAIL PROTECTED] wrote:
Is anyone else getting every meesage that is sent to dri-devel twice or
sometimes even 3 or 4 times? It just started happening over the last
couple days.
Alex
__
Do you Yahoo!?
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote:
Keith Whitwell wrote:
Alex Deucher wrote:
As I recall KDE preloads libGL for some reason. that might have
something to do with it.
If you make sure that the old driver.so file
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Fri, 17 Oct 2003 12:10:05 -0700 (PDT)
Alex Deucher [EMAIL PROTECTED] wrote:
you need to change the DRI config settings:
http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure
perhaps we shouldn't make sync to refresh
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote:
Keith Whitwell wrote:
Well, I've never tried to install the whole XFree86 when it's running,
but I'm often lazy and just compile the mesa/src/drv/r200 if only small
changes happen and copy
I just updated CVS and patched in
http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff
Most everything that warked b4 still workes, there is a small problem with quake3.
Small meaning
not ought of the ordinary for DRICVS, things like textures on the floor appere to be
Hello Laurent,
The main goal is to get a working DRI that has the new API, and maby some gatos bells
and
whistles. I'm assuming you read my post that recent DRI is to different from gatos.
My plan was
to diff gatos and DRI and weed ought all the changes that where depreciated. With
that
is the
Xfree86 date in radeon_driver.c) copy of DRI and see if there is a smaller change set.
I was
looking at a unified diff /w 42000+ lines. From the gatos web page I can only find
Xdrivers and a
kernel mod, and no GLlib.
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Michel
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
I have something to add to this. Recently I tested gatos drivers going
from dri to gatos
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
I have something to add to this. Recently I tested gatos drivers going
from dri to gatos was painless. However when I went back my computer
locked up.
That's because they have made
I have something to add to this. Recently I tested gatos drivers going from dri to
gatos was
painless. However when I went back my computer locked up. I sent a report off to
gatos of my
findings. If it's helpfull I could try a gatos to fglrx and back to see if there are
any lockups.
Would
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-08-09 at 02:24, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Fri, 2003-08-08 at 04:27, Mike Mestnik wrote:
I have made patches for DRI, but thay never seam to get maintained.
What are those patches
101 - 200 of 246 matches
Mail list logo
