for 3D, what version of mesa are you using? are you using the right
libGL?
For 2D look in xc/programs/Xserver/hw/xfree86/drivers/savage
Try the 2D driver with 3D disabled and see if you still get corruption.
it may be that the 3D side is stomping on the something from the 2D
side.
Alex
---
you might compare it to Tim's old 2D driver (shipped with 4.3.0) and
see what's changed...assuming his driver works for you in 2D.
Alex
--- Rafael Maximo [EMAIL PROTECTED] wrote:
Hi,
I decided to focus on 2D problem first but i don't know how
I can
debug the 2D driver and found
Keith I think this fixes a problem with the LCD not working on Asus
notebooks. I seem to recall this problem from a while back on some of
the xfree MLs. I don't know for sure however.
Alex
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Bellegueulle Damien wrote:
---
I'm thinking about implementing a textured video option on radeon for
mergedfb (or non-mergedfb too for that matter). It would be useful
since video windows could span heads in mergedfb mode and you could
also have multiple Xv windows at the same time rather than just one
with the overlay unit.
I believe there was some discussion of this on the directfb mailing
list. I think the savage chips require a tile based framebuffer for
acceleration, but this is incompatible with things that assume a linear
based framebuffer.
Alex
--- Felix K�hling [EMAIL PROTECTED] wrote:
I found at least a
The DRM changed between xfree86 4.0.x and 4.1.0 in an incompatible way.
some kernel trees retained both DRMs so that you could build the
appropriate DRM depending on what version of xfree86 you were using.
Alex
--- John Dennis [EMAIL PROTECTED] wrote:
In the linux 2.4 kernel tree under
you can either patch DRI cvs with the 9200se patch you tried or force
the chipID to another radeon 9200.
any of these chould work:
0x5963
0x5962
0x5961
0x5960
Also I believe Michel added the patch to CVS so it should show up in
the snapshots soon.
Alex
--- maestro [EMAIL PROTECTED] wrote:
hi
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-09-26 at 18:16, Alex Deucher wrote:
1. looking at the mga textured video code, it disables the DRI
when it
is in use. is there any reason for this? is it possible to use
the
texture engine for Xv and DRI at the smae time
--- Ian Romanick [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
I'm thinking about implementing a textured video option on radeon
for
mergedfb (or non-mergedfb too for that matter). It would be useful
since video windows could span heads in mergedfb mode and you could
also have multiple
just remove the '#include radeon_pci.h' line from those files.
Also radeon_dri.c contains some references to AMD_SOMETHING that is
undefined. if you comment out that statement all works fine.
Alex
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Fri, 26 Sep 2003 10:26:40 -0700
Alan Hourihane
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Sat, 2003-09-27 at 23:10, Alex Deucher wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Fri, 2003-09-26 at 18:16, Alex Deucher wrote:
When implemeting this on radeon, would I have to use the CP
to program the texture registers
Nevermind the 8/4 ring question, I figured that part out. one question
though, how do you know whether to use OUT_REG_RING() or OUT_RING()? I
take it OUT_REG_RING() is for register writes and I'm guessing
OUT_RING() is for commands. I just want to verify.
Thanks,
Alex
--- Michel D�nzer
unless someone beats me to it, I was planning on messing with the virge
driver at some point going forward. I got a hold of the Duoview info
from the virge databook, so I'm planning to add support for dualhead
and probably mergedfb. after that I'll mess with the 3D driver. (does
anyone know if
It might be better to import the 2D driver from xfree86 CVS since there
have been some major changes and fixes since the original release. see
bugzilla:
http://bugs.xfree86.org/show_bug.cgi?id=525
Alex
--- José Fonseca [EMAIL PROTECTED] wrote:
OK. I've imported your tarball plus the 2D and
I'm attempting to fix pageflipping in certain mergedfb modes. right
now it only works in when crtc2 is right of crtc1. I suspect the
problem has to do with the CRTC offsets that are set in
RADEONDoAdjustFrame()
for instance if I have crtc2 left of or above crtc1, I would need to
adjust
With my latest patch the just about all the outstanding bugs have been
fixed. the only thing remaining is that pagflipping doesn't always
work in some mergedfb configurations. I'm working on that one, but
then again, pageflipping doesn't work for everyone anyway. The driver
currently supports
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-02 at 18:41, Alex Deucher wrote:
I'm attempting to fix pageflipping in certain mergedfb modes.
right
now it only works in when crtc2 is right of crtc1. I suspect the
problem has to do with the CRTC offsets that are set
FWIW, the 2D drivers from the trunk and the code drop from VIA are VERY
different. I'm not sure where you are seeing the conflicts... just an
FYI...
--- Eric Anholt [EMAIL PROTECTED] wrote:
Okay, I was going to merge trunk to the savage-1_0_0-branch, since
updates to the savage driver in trunk
xfree86 and DRI CVS have 2D support for m10 already. 3D is not
possible as no one has sponsored development of an opensource driver
and no one has the databooks for the r300 yet. So, if you want 3D,
you'll have to use the ati binary driver.
Alex
--- Jason Dagit [EMAIL PROTECTED] wrote:
Who is
--- Jason Dagit [EMAIL PROTECTED] wrote:
Alex Deucher wrote (on Sat, 4 Oct 2003 at 08:49 -0700):
xfree86 and DRI CVS have 2D support for m10 already. 3D is not
possible as no one has sponsored development of an opensource
driver
and no one has the databooks for the r300 yet. So
I just commited mergedfb to DRI cvs. Let me know if there are any
problems.
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This sf.net email is
Sorry, I forgot to post a patch of what went in. I committed this
patch:
http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Yeah. I'll work on that this week unless anyone has any objections.
Alex
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote:
Log message:
Add Merged Framebuffer (MergedFB) support to the radeon driver.
On
dualhead cards
/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25
2003/08/29 21:07:57 tsi Exp $ */
thanks,
Alex
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote:
Log message:
Add Merged Framebuffer (MergedFB) support to the radeon driver
it's be nice if we could merge radeon and r200 into one driver when we
did this as well.
Alex
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Wed, Oct 08, 2003 at 12:53:29AM -0600, Otto Solares wrote:
Hi!
I am trying to merge the r200 driver from dri-cvs to mesa-miniglx,
finally i had
that's my fault. there's a small bug that I missed that breaks Xv in
non-mergedfb mode. I have the fix. it will be committed ASAP.
Alex
--- Stefan Lange [EMAIL PROTECTED] wrote:
Hello,
if I try to use Xv (via mplayer, or with xawtv using the v4l-module)
with current cvs (trunk) the X server
A fix just went into xfree86 CVS earlier today that fixed several
things related to Xv on i8xx hardware. that code hasn't been synced
with DRI CVS yet. I don't have intel hardware so I can't test. The
problem with Xv on radeon was a bug in my mergedfb code, but it's fixed
now.
Alex
--- Linus
I recently synced up my DRI tree with Hui's latest patch from xfree86
cvs. I need the DVI code for my new 9200. Would anyone object to me
adding this to DRI cvs? I'm using it now with no problems so far.
Thanks,
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping -
I just got my 9200 up and running but I'm seeing some weird behavior.
3d works fine if I run in single head mode. however, if I run with
mergedfb I get weird corruption in fullscreen apps like screen savers.
for example, if I run the atlantis screen saver, there appears to be
junk from previous
Well, I solved the problem...sort of... it happens when I'm using a
merged mode that's 2048 wide. Does anyone know why there would be
corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a
single head at 2048x1536? Mergedfb works at 2048x768, it just shows
that corruption I described
Further info on this. Not all GL apps are affected. I've only tried
xscreensavers. of the GL screensavers most show that corruption I
spoke of, but some seem unaffected (many from the rss package:
http://rss-glx.sourceforge.net/).
Those that work:
BusySpheres
Cage
Colorfire
Hufos smoke
hufos
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2003-10-12 at 17:27, Alex Deucher wrote:
Well, I solved the problem...sort of... it happens when I'm using a
merged mode that's 2048 wide. Does anyone know why there would be
corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried
You can have as big a virtual desktop as you want so long as the total
3D contexts are not greater than 2048 in either direction.
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2003-10-13 at 01:26, Alex Deucher wrote:
-- Michel Dnzer [EMAIL PROTECTED] wrote:
On Sun, 2003-10-12
I just committed a major rework of mergedfb to CVS. almost all of the
code is now in radeon_mergedfb.c/h. I also committed Hui's latest code
drop from xfree86 CVS. Let me know if anyone has any problems.
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with
Oct 2003, Alex Deucher wrote:
I just committed a major rework of mergedfb to CVS. almost all
of the
code is now in radeon_mergedfb.c/h. I also committed Hui's
latest code
drop from xfree86 CVS. Let me know if anyone has any problems.
Alex
if that fixes
it.
Send a copy of your log file.
Alex
--- Martin Spott [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
I just committed a major rework of mergedfb to CVS. almost all of
the
code is now in radeon_mergedfb.c/h. I also committed Hui's latest
code
drop from xfree86 CVS
with 2048.
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2003-10-13 at 06:13, Alex Deucher wrote:
You can have as big a virtual desktop as you want so long as the
total
3D contexts are not greater than 2048 in either direction.
Wrong. The 2048 limit is for the virtual location
[EMAIL PROTECTED] wrote:
On Mon, 2003-10-13 at 06:13, Alex Deucher wrote:
You can have as big a virtual desktop as you want so long as the
total
3D contexts are not greater than 2048 in either direction.
Wrong. The 2048 limit is for the virtual location of the right and
bottom edges of 3D
this is a patent issue:
http://dri.sourceforge.net/cgi-bin/moin.cgi/S3TC
--- Csan [EMAIL PROTECTED] wrote:
Hello all,
I've been wondering whether DXTC/S3TC will be implemented in the DRI
(Radeon)
drivers. I got an ATI Radeon Mobility M9 Lf (AGP).
I haven't been able to find any info in
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2003-10-13 at 16:26, Alex Deucher wrote:
perhaps the limit is actually 2047?
No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of
the rightmost column and bottommost line. There may be off-by-one
errors
in the code
--- Martin Spott [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote:
Can you clarify what you tried and what the problem is?
When I restart the 'new' (with MergedFB) XFree86 X server binary with
the old XF86Config (attached) I get a flickering screen
driver to drive your hardware.
somehow validating the mode for crtc2 must be messing up the mode for
crtc1. I rewrote some of that code, so it's possible I messed
something up.
Alex
--- Martin Spott [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2003 at 09:03:38AM -0700, Alex Deucher wrote:
That's
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
On Mon, 13 Oct 2003, Alex Deucher wrote:
it seems to crash while validaing the modes on the second head.
Which is odd since, if I turn off mergedfb and just use normal
xinerama,
it works fine, it has no problems validating the modes
I've uploaded some screenshots as an example:
http://www.botchco.com/alex/2048-error/
the new version of xscreensaver displays a separate instance on each
head of a xinerama desktop. so in this case only the context running up
again the 2048 limit (the right side) shows the error. When I turn
what's the difference between the two? why does linux have it's own
version? why couldn't the linux version be used with BSD? something to
do with the kernel?
Alex
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2003-10-13 at 09:14, Alex Deucher wrote:
If the mode validation interacts
--- Roland Scheidegger [EMAIL PROTECTED] wrote:
Martin Spott wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
I just committed a major rework of mergedfb to CVS. almost all of
the
code is now in radeon_mergedfb.c/h. I also committed Hui's latest
code
drop from xfree86 CVS. Let me know
As I recall, no. As it is now, only a single instance of Xfree86 can
use the DRI. I think it might be possible by adapting the resume code
to reinitialize state and agp on a VT switch, however, I may be wrong.
Alex
--- Jon Smirl [EMAIL PROTECTED] wrote:
If I am running two copies of Xfree/DRI
on the second head).
So, in theory, you should be able to reproduce the problem really
easily, Alex, by moving that file, too. Of course, I'm more than
willing
to test or try anything on my end.
Adam
On Mon, 13 Oct 2003, Eric Anholt wrote:
On Mon, 2003-10-13 at 09:14, Alex Deucher
work fine on my hardware. testing will prove what works best I
suppose.
Alex
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior in the old driver. perhaps this should
to find the bugs :)
if we move to a branch, perhaps we could add it to the snapshots?
Alex
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior
Sounds good. I may play around with it when I get a chance. Any other
thoughts on what it might be if not clears?
Alex
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
I've uploaded some screenshots as an example:
http://www.botchco.com/alex
if
you do...
Alex
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
That's fine with me. we can revert back to xfree86 CVS for the
trunk
and I can move to a branch. I wouldn't have put it on the trunk if
I
had know the mode stuff was cause so much trouble, but then again
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to false
That's probably a good idea, but then it should default to clone mode
as
pre-MergedFB. Driving both heads with a single CRTC
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:58, Alex Deucher wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to
false
That's probably a good idea
there's also this driver:
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP...
Alex
--- Ville_Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote:
Has any one checked the PC IDs
the 3D drvier needs to be updated to mesa 5.x. Not much work has been
done on it and I think there are some issues with the 2D driver.
There's no way it will make it into 4.4.0. the current code is on a
branch in DRI cvs. If you are interested in helping, please do.
Alex
--- Tim Roberts
[EMAIL PROTECTED] wrote:
On Mer, 2003-10-15 at 21:07, Alex Deucher wrote:
the 3D drvier needs to be updated to mesa 5.x. Not much work has
been
done on it and I think there are some issues with the 2D driver.
There's no way it will make it into 4.4.0. the current code is on
a
branch
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Alex
--- Martin Spott [EMAIL PROTECTED] wrote:
Ville Syrj?l? [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
http
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote:
Log message:
Clean up of the mode validation code for MergedFB.
Does it behave the same as pre-MergedFB by default now?
I haven't put back the old clone code, although the code that's
no worries... I was just curious.
--- Martin Spott [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might
Before I go grepping through the tree, where would I find this code (in
the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a
r200_cp_dispatch_clear()?
thanks,
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
I've uploaded
I just noticed this app today:
http://meld.sourceforge.net/index.html
Looks pretty nice.
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Fri, 2003-10-17 at 04:41, Alex Deucher wrote:
Log message:
*Re-wrote MergedFB validate mode function from scratch based on
crt1 validation
rather than the old clone validation code.
So does it work more or less like the old clone
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Fri, 2003-10-17 at 05:14, Eric Anholt wrote:
Log message:
- Converted Linux drivers to initialize DRM instances based on
PCI IDs, not
just a single instance. Moved the PCI ID lists from card_drv.c
in BSD to
card.h. The PCI ID
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 the default.
Alex
--- Paul Zaremba [EMAIL PROTECTED] wrote:
Hello,
I have a Radeon 8500 LE with an LCD attached to the CRT output.
plus there is a certain machismo element to the number of FPS your card
can render...
--- Mike Mestnik [EMAIL PROTECTED] wrote:
--- 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
I've had several mergedfb users complain about the 2048 DRI limit
put in yesterday:
else if ( pScrn-virtualX 2048 || pScrn-virtualY 2048 ) {
info-directRenderingEnabled = FALSE;
xf86DrvMsg(scrnIndex, X_WARNING,
Direct
Sorry. I documented the MergedDPI option.
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-10-18 at 18:53, Alex Deucher wrote:
Log message:
Update radeon man page.
Sorry to be pedantic, but this log message is redundant:
Modified files:
xc/xc/programs
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick [EMAIL PROTECTED] wrote:
Jens Owen wrote:
We can definitely remove the xf86drmCompat layer for XFree86 5.0.
I
believe it's well understood that major version changes
:
On Fri, 2003-10-24 at 23:39, Mike A. Harris wrote:
On Fri, 24 Oct 2003, Alex Deucher wrote:
...
Why doesn't somebody implement one of the discussed workarounds in
the
3D drivers? :)
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product
it's hard to say if it's worth pursuing or not since no one that I know
of has the docs for the 3D engine on r300.
Alex
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
I'm curious if anyone has attempted to get an R300 card working with
the
r200 driver? :-)
I was fooling around today with
I've talked to quite a few people that have had problems getting
dualhead to work on radeon IGP chips. Specifically, the crt port seems
to go into powersave mode when dualhead is enabled. I talked to Hui Yu
at ATI about the problem and he hasn't seen it on his IGP boards using
the lastest code
--- Robert Woerle [EMAIL PROTECTED] wrote:
Hi
I am now in contact with Keith packard and checked out his latest
stuff ..
it looks promising since there is already a SMI Server there ..
unfortunately it crashes when i use the hw acceleration ...without it
works ..
Alex Deucher
-10-25 at 17:25, Alex Deucher wrote:
I'll give keith's suggestion a shot, but I don't really understand
how
it's supposed to work. I'm not really much of an expert when it
comes
to the 3D driver. If someone could give me some pointers as to
where
to look and maybe a 500 foot description
I'll take a look at fixing this in the radeon driver. What needs to be
done to play nice with the DRI?
Alex
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote:
Alan Hourihane ([EMAIL PROTECTED]):
Well, if someone else has a chip, or
I tried to add dualhead support for this chip a while back, but got no
where with docs from S3/VIA. I was able to find out basically how it
worked, but I was never able to get it working (I think I wasn't
setting the second DAC right). I eventually got databooks for the
duoview portion of the
sounds good to me.
Alex
--- Felix Kühling [EMAIL PROTECTED] wrote:
...
Does anyone object if I make a new
savage-2-0-0-branch
with the (for me) working 2D driver and kernel module?
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Interesting... could these be used in combination? perhaps to get
around the 2048 limit? or if we were to implement the iterative zone
approach, process serveral zones at once? I just requested r200
databooks from ati now that I'm a registered developer (got my fingers
crossed).
Alex
---
you might consider putting your project on freedesktop.org rather than
sourceforge...at least for CVS.
Alex
--- Michael Dreesen [EMAIL PROTECTED] wrote:
Do you have an ATI card? The ATI proprietary driver has pbuffers
implemented.
pbuffers would let you avoid a lot of the swapping. If you
that's the weirdest thing! I swear I remember seeing it defined, now I
can't find it anywhere.
Alex
--- Jon Smirl [EMAIL PROTECTED] wrote:
Can someone give me a clue as to where RADEONWaitForIdleMMIO is
defined?
I can't find it via grep, maybe a macro is building it.
=
Jon Smirl
Didn't keith do some agp 8x work a while back?
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-11-08 at 18:32, Jon Smirl wrote:
This is set to 4, should it be 8 now?
#define RADEON_AGP_MAX_MODE 4
No, it means 'maximum AGP mode supported by the radeon driver', not
make sure you add the dri and glx modules under the modules section of
your config file. It doesn't look like anything dri related is loading
in the driver. Did you apply the latest code drop from alan or VIA to
your xfree86 tree? you might want to try the code in the savage-2-0-0
branch of the
I recenly wrote a patch (with some help from Andreas) to a allow for
gamma adjustment of the video overlay. It adds the XV_GAMMA attribute.
The current patch works, but I'm not sure I'm programming the registers
right. Could someone with databooks verify how they should be
programmed? The
--- Ville_Syrj�l� [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote:
Ville Syrj�l� wrote:
I must say that I am very impressed with how far the MGA driver has
come
since you started working on it. Now the only thing that's missing
is
support for
I doubt many developers are going to work on it because the rest of the
drivers are closed source and few if any developers have parhelia
hardware. you'd probably be best off trying to port it yourself. you
can look at how the drm modules differ from linux to freebsd for other
drivers (radeon,
Currently all my mergedfb work has been in the 2D driver, but I'd like
to start working on some 3d stuff (time permitting). however, I don't
have write access to the mesa tree. It's not real important at this
point I guess, but eventually... Also isn't mesa hosted on
sourceforge? will there be
while it might be possible to add support for freebsd to the apparently
opensource kernel module, adding support for unsupported cards to the
2D/3D drivers is impossible since it is a binary only driver! Ask
matrox to add support. that's your only option right now.
Alex
--- Jan Eidtmann [EMAIL
PROTECTED] wrote:
On Fri, 14 Nov 2003, Alex Deucher wrote:
This was an issue with 4.3.0 as I recall. It was fixed in DRI cvs,
I'm
not sure if the fix has made it's way to fedora.
I don't recall hearing about this issue before, so it probably
isn't fixed in our packages unless it is fixed
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
Is anyone else having problems posting to the list?
Alex
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/---BeginMessage---
Your mail to 'Dri-devel' with the subject
Re: [Dri-devel] Latest CVS in non-xinerama or dual screen
Are you using mergedfb or not? It's unclear to me. if you are using
mergedfb, what problems are you having exactly? if you enable the
Xinerama extenstion, tht will disable the built in mergedfb xinerama
extension. that might be part of the problem. Also what problems are
you having with Xv?
use Xv
from time to time it flakes ought and I can't realy tell if it's X,
the app, or the file i'm
trying to play.
--- Alex Deucher [EMAIL PROTECTED] wrote:
Are you using mergedfb or not? It's unclear to me. if you are
using
mergedfb, what problems are you having exactly? if you
daily binary snapshots are available here:
http://dri.sourceforge.net/snapshots/
--- Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 22 Nov 2003, Michel [ISO-8859-1] Dänzer wrote:
However, it appears that XFree86 is in feature freeze for 4.4.0
(since
yesterday), which implies
The attached patch converts radeon_video.c to use the CP rather than
MMIO if direct rendering is enabled. I wanted to get some feedback
before committing to DRI cvs. I doubt this will affect overall
performance much, but it will reduce the overhead involved in stalling
the CP when switching
I would never commit any thing non-trivial with out some validation
first. that's why I posted it here. Thanks for your comments.
Alex
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Mon, 2003-11-24 at 00:31, Alex Deucher wrote:
The attached patch converts radeon_video.c to use the CP rather
--- Chris Ison [EMAIL PROTECTED] wrote:
I know you can't give details under NDA, but do the specs for the
r200
show any API for PCI, or has the PCI work on the driver been done by
trial and error.
I'll have to check the docs when I get home. The original PCI GART
work does done for HP for
Your best bet, if you can find one, is a fireGL 8800. It's basically
an overclocked 8500. barring that the 8500's and 9100's are the next
fastest.
Alex
--- Torgeir Veimo [EMAIL PROTECTED] wrote:
On Fri, 2003-11-28 at 07:37, Alex Deucher wrote:
I'd say the best supported cards are r200
the 2048 limitation of the scissor registers can be worked around.
check the dri-devel archives for messages with 2048 in the subject.
basically what we need to do is look at the cliprects in the client
driver and everytime they are a multiple of 2048 divide into a zone.
then when you are
--- Mike Mestnik [EMAIL PROTECTED] wrote:
I attached my log and config, just incase.
This is a short list of the things I have found odd with DRI.
1. Screen size and DPI, I never understood how this was going to work
with dual heads.
2. A bug that won't let me use 256x240 in MFB, workes
XGI is a joint venture from the trident and sis people. Sis has
released zero documentation in the past. trident is somewhat better.
As far as I know XGI has not released any databooks for these chips.
they may be developing drivers in house. whether they will be
opensource or binary (or
101 - 200 of 1146 matches
Mail list logo
