On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
wrote:
> On 19.02.2009 12:23, Arkadi Shishlov wrote:
>> Roland Scheidegger wrote:
>>> I suspect you're hitting a r200 asic bug, which isn't present in rv250
>>> and other r200 family members. There are workarounds in the driver for
>>> this (see
On Thu, Feb 19, 2009 at 9:51 AM, Stephane Marchesin
wrote:
> On Thu, Feb 19, 2009 at 15:46, Alex Deucher wrote:
>> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
>> wrote:
>>> On 19.02.2009 12:23, Arkadi Shishlov wrote:
>>>> Roland Scheidegger wrote:
&
The following 4 patches against the drm-next branch of Dave's drm-2.6
tree adds support for r6xx and r7xx chips to the radeon drm. It's
currently only used for EXA and Xv in the DDX.
They can also be downloaded directly from here:
http://www.botchco.com/alex/xorg/r6xx_drm/
0001-radeon-prep-for-r
>From 9a3a1352ea4ee08c4f1c5f0eb8c9f204c342da18 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 24 Feb 2009 14:02:13 -0500
Subject: [PATCH] radeon: prep for r6xx/r7xx support
- add r6xx/r7xx regs and macros
- add r6xx/r7xx chip families
- fix register access for regs with offs
This patch is huge and just adds microcode for r6xx/r7xx chips. It
can be downloaded here:
http://www.botchco.com/alex/xorg/r6xx_drm/0002-radeon-add-r6xx-r7xx-microcode.patch
--
Open Source Business Conference (OSBC), Mar
>From 273bbce8cd34e27d63571e9b150f346024e1cb7c Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 24 Feb 2009 17:13:42 -0500
Subject: [PATCH] radeon: add R6xx/R7xx pci ids
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h | 108 ++
for drm-next
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS600-fix-interrupt-handling.patch
>From c2c973f860ceaf8b8491cf541e9ed2126d6673bd Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Fri, 6 Mar 2009 11:43:47 -0500
Subject: [PATCH] RS600: fix interrupt handling
Signed-off-by: A
Please apply to both drm-next and drm-rawhide
http://www.botchco.com/alex/xorg/r6xx_drm/0001-R6xx-R7xx-fix-possible-oops-in-r600_page_table_clea.patch
>From 453ed78a62d3125ecdb2a1e5ea27b3368fa66330 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Sat, 7 Mar 2009 18:16:42 -0500
Subject: [PA
On Mon, Mar 9, 2009 at 12:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This calls the correct idle function for the R600 and previous chips.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cp.c | 2 +-
> 1 fil
On Mon, Mar 9, 2009 at 12:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This realigns the r600 pci mapping calls with the ati pcigart ones,
> fixing the direction and using the correct interface.
>
> Suggested by Jerome Glisse.
>
> Signed-off-by: Dave Airlie
ing incorrectly calculated, this breaks
> it out into a lot more linear steps.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 35 ++-
> 1 files changed, 22 insertions(+), 13 deletions(-)
>
On Tue, Mar 10, 2009 at 3:41 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Until we sort out r600 IRQs don't do this.
>
> Signed-off-by: Dave Airlie
Should be ok since GEN_INT_CNTL is unassigned register space on
r6xx/r7xx, but better safe than sorry.
Ac
On Tue, Mar 10, 2009 at 3:41 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This update was done in mainline radeon, but not in the r600.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 3 ---
> 1 files cha
On Fri, Mar 13, 2009 at 12:14 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/d
[PATCH] radeon: fix logic in r600_page_table_init() to match ati_gart
This fixes page table init on rs600.
Signed-off-by: Alex Deucher
please apply to both drm-next and drm-rawhide
http://www.botchco.com/alex/xorg/drm-rawhide/0001-radeon-fix-logic-in-r600_page_table_init-to-match.patch
>F
http://www.botchco.com/alex/xorg/drm-rawhide/0001-AVIVO-fix-dac-load-detection.patch
>From 543cdebab5266bc45cbda6b431d26fe4ebf89984 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 18 Mar 2009 12:03:16 -0400
Subject: [PATCH] AVIVO: fix dac load detection
Signed-off-by: Alex Deuc
http://www.botchco.com/alex/xorg/0001-radeon-add-some-new-pci-ids.patch
for drm-next
>From 4e91d985755227efcdd6f3ddab90286c3a8ed492 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 19 Mar 2009 20:38:04 -0400
Subject: [PATCH] radeon: add some new pci ids
Signed-off-by: Alex Deuc
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS780-load-the-right-microcode.patch
>From 4299cc7ee205006851a7a791602efa8512613f16 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Sun, 29 Mar 2009 20:40:34 -0400
Subject: [PATCH] RS780: load the right microcode
Copy/paste error. The RV
On 3/30/09, Roland Scheidegger wrote:
> On 30.03.2009 06:23, Dave Airlie wrote:
> > On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie wrote:
> >> Does anyone remember why we've only done macro tiling on the radeon
> >> for the color buffer so far?
> >>
> >
> > /me discovers the reason ouch.
>
On 4/1/09, Eric Anholt wrote:
> On Mon, 2009-03-23 at 11:30 +0800, yakui_zhao wrote:
> > Subject: [DRM/I915]: Sync the default modes for LVDS output device
> > From: Zhao Yakui
> >
> > Sync the default modes for the LVDS output device
> > This covers:
> > Add the default modes for t
http://www.botchco.com/alex/xorg/0001-radeon-Add-RV790-HD-4890-support.patch
>From 668d2937797e8788efbd1225493c65f3e22b5774 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 9 Apr 2009 12:09:40 -0400
Subject: [PATCH] radeon: Add RV790 (HD 4890) support
Signed-off-by: Alex Deuc
Meant to sent this to dri-devel as well. Note, this is not a release
per se. the driver is still incomplete. we are just moving
development out into the public.
Alex
-- Forwarded message --
From: Alex Deucher
Date: Fri, Apr 17, 2009 at 2:49 PM
Subject: Initial R6xx/R7xx Mesa
On Wed, Apr 29, 2009 at 10:32 AM, Abraham Varricatt
wrote:
> As of now, I know it's non-existent. But I want to know the
> difficulties involved in attempting it (KMS+VESA)? At the moment, the
> only chipsets that work with KMS are the intel ones. So, I'm thinking,
> why not find out why no-one se
On Tue, May 26, 2009 at 6:39 PM, Andrew Morton
wrote:
> On Fri, 22 May 2009 17:59:49 GMT
> bugzilla-dae...@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13364
>
> The wheels seem to have fallen off the DRM code lately :(
>
> This one might be related to Alex's r6xx/r7x
rt up to R5xx only here, can we hit
> this bug actually? Can hardware below R6xx use
> ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA?
Only DCE 3.0/3.1 cards have ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA,
so you'll only see this on rv620/rv635/rv780/rv770 hw. The proper fix
is attached. We&
2009/6/30 Rafał Miłecki :
> W dniu 29 czerwca 2009 03:03 użytkownik Alex Deucher
> napisał:
>> 2009/6/24 Rafał Miłecki :
>>> Khem, hi, my first patch here and my first touching kernel code ever.
>>>
>>> I try to make my RV620 work in console using radeon
On Tue, Jun 30, 2009 at 5:33 PM, Jesse Barnes wrote:
> Now that we're using the scaling property in the Intel driver I noticed
> that the names were a bit confusing. I've corrected them according to
> our discussion on IRC, though I've left out potential new additions for
> a new scaling property
On Wed, Jul 1, 2009 at 5:23 AM, Maarten Maathuis wrote:
> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling,
> in case you have a CRT or the monitors scalers are better.
> I think your new name choice is less than ideal.
Good point. I think we should have:
None (sw or monitor
On Wed, Jul 1, 2009 at 12:11 PM, Jesse Barnes wrote:
> On Wed, 1 Jul 2009 11:23:50 +0200
> Maarten Maathuis wrote:
>
>> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling,
>> in case you have a CRT or the monitors scalers are better.
>> I think your new name choice is less than
On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher wrote:
> On Wed, Jul 1, 2009 at 12:11 PM, Jesse Barnes wrote:
>> On Wed, 1 Jul 2009 11:23:50 +0200
>> Maarten Maathuis wrote:
>>
>>> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling,
>>>
On Wed, Jul 1, 2009 at 1:04 PM, Jesse Barnes wrote:
> On Wed, 1 Jul 2009 12:22:17 -0400
> Alex Deucher wrote:
>
>> On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher
>> wrote:
>> > On Wed, Jul 1, 2009 at 12:11 PM, Jesse
>> > Barnes wrote:
>> >> On We
Also, fix ordering for a couple others
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 45c1867..7174818 100644
--- a/include/drm/drm_pciids.h
+++ b
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon
Ignore this one for now. Doesn't hurt, but r6xx dig stuff needs more work.
Alex
2009/7/1 Alex Deucher :
> Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
> panels can be driven by KLDSCP_LVTMA or UNIPHY.
>
> Signed-off-by: Alex Deucher
> ---
>
combined into
the same connector. This should fix bko bug 13720.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon
On Thu, Jul 9, 2009 at 11:15 AM, Keith Packard wrote:
> On Wed, 2009-07-08 at 20:28 +0100, Julien Cristau wrote:
>
>> DRI2 init can fail for various reasons, and it's easier to test if you
>> don't have to hack the driver. No particular opinion on kms without
>> uxa, though.
>
> Right, which is wh
On Thu, Jul 9, 2009 at 4:45 PM, Keith Packard wrote:
> On Thu, 2009-07-09 at 11:37 -0400, Alex Deucher wrote:
>
>> Might be useful to bring up a shadowfb or noaccel X if the user is
>> having accel problems, just to have a desktop.
>
> That's been the traditional answe
This is needed when using fractional feedback dividers on some IGP
chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |6 +-
drivers/gpu/drm/radeon/radeon_mode.h|1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm
Allows us to hit dot clocks much closer, especially on
chips with non-27 Mhz reference clocks like most IGP chips.
This fixes most flickering and blanking problems with
non-exact dot clocks on these chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 ++
1
This should be 1/2. this patch is required for "radeon kms: enable
frac fb divs on rs600/rs690/rs740"
On Mon, Jul 13, 2009 at 11:08 AM, Alex Deucher wrote:
> This is needed when using fractional feedback dividers on some IGP
> chips.
>
> Signed-off-by: Alex Deucher
&g
Need to adjust CUR_OFFSET for xorigin
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cursor.c |9 +++--
drivers/gpu/drm/radeon/radeon_mode.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm
I'm planning to merge this to master soon. It's still pretty raw, but
at this point it will run gears and most of the basic demos. It
shares a lot of the common radeon code so I'd like to get it merged
sooner rather than later to avoid the need to constantly keep it up to
date with the latest cha
On Wed, Jul 15, 2009 at 5:59 PM, Alex Deucher wrote:
> I'm planning to merge this to master soon. It's still pretty raw, but
> at this point it will run gears and most of the basic demos. It
> shares a lot of the common radeon code so I'd like to get it merged
> sooner
On Sun, Jul 26, 2009 at 2:41 PM, wrote:
> Hello all,
>
> I'm not sure of whether I'm mailing this to the correct addresses or not, so
> bare with me. I noticed that the file 'shared-core/drm_pciids.txt' contains
> 2 entries in the 'sis' group that actually have the same pci vender id as
> 'xgi'.
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 7174818..9d4c004 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -257,9 +257,12
These are new AMD IGP chips
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c| 22 +++---
drivers/gpu/drm/radeon/radeon_drv.h |1 +
include/drm/drm_pciids.h|5 +
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers
On Fri, Aug 14, 2009 at 5:09 PM, Yang Zhao wrote:
> Signed-off-by: Yang Zhao
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 ++
> drivers/gpu/drm/radeon/radeon_atombios.c | 28
> drivers/gpu/drm/radeon/radeon_device.c | 5 +
> drivers/gpu/drm/radeo
On Fri, Aug 14, 2009 at 5:09 PM, Yang Zhao wrote:
> Signed-off-by: Yang Zhao
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 ++
> drivers/gpu/drm/radeon/radeon_atombios.c | 28
> drivers/gpu/drm/radeon/radeon_device.c | 5 +
> drivers/gpu/drm/radeo
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminen wrote:
> GCC did war about optimization not possible because possible forever loop.
>
> Signed-off-by: Pauli Nieminen
Acked-by: Alex Deucher
> ---
> libdrm/radeon/radeon_cs_gem.c | 12 ++--
> 1 files changed,
inen
Acked-by: Alex Deucher
> ---
> libdrm/radeon/radeon_cs.h | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/libdrm/radeon/radeon_cs.h b/libdrm/radeon/radeon_cs.h
> index 7efec7e..1117a85 100644
> --- a/libdrm/radeon/radeon_cs.h
> +++
RV530 cards can have up to 2 Z pipes. You need to check
GB_PIPE_SELECT2 to find out how many are enabled. Mesa would need to
be updated as well. Untested.
Alex
From 0f194fff3d5c3d75a2b58b564a2de2a39ea67436 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Aug 2009 16:47:09 -0400
And of course, bump the minor number.
On Wed, Aug 19, 2009 at 5:07 PM, Alex Deucher wrote:
> RV530 cards can have up to 2 Z pipes. You need to check
> GB_PIPE_SELECT2 to find out how many are enabled. Mesa would need to
> be updated as well. Untested.
>
&
Previous drm patches had some problems. Untested.
Alex
From 15562cf73b3d050e82cd9756733106da0f37c1f2 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Aug 2009 19:11:39 -0400
Subject: [PATCH] drm/radeon: add GET_PARAM/INFO support for Z pipes
Needed for occlusion queries on rv530 chips
On Thu, Aug 20, 2009 at 4:59 AM, Maciej Cencora wrote:
> 2009/8/20 Alex Deucher :
>> Previous drm patches had some problems. Untested.
>>
>> Alex
>>
>> --
>> Let Crystal Reports hand
On Wed, Aug 26, 2009 at 9:07 PM, Dave Airlie wrote:
> On Mon, Aug 24, 2009 at 3:58 AM, Ben Hutchings wrote:
>> Based on a patch by Jaswinder Singh Rajput . For Radeon 100- to 500-series,
>> firmware blobs look like:
>> struct { __be32 datah; __be32 datal; } cp_ucode[256];
>>For Radeon 600-series,
I'm not sure they are the "official" maintainers, but as far as I
recall,
Thomas Winischhofer has done a lot with Sis and DRI, etc. (like make
the driver actually work) (http://www.webit.com/tw/linuxsis630.shtml),
and Matthew Sottek has done much of the work for i810/830.
Alex
---
I just saw over at the utah-glx project that the S3 savage 3D driver is
working with XF 4.x. It's not DRI, but for those who are interested, I
thought I'd point it out... maybe a good start for those looking to
port to the DRI.
Alex
__
Do You Yaho
I don't think the docs are much help with regard to 3D. there actually
is a working sis DRI driver for 300 series chips that can be found
here:
http://www.winischhofer.net/linuxsis630.shtml
perhaps it could be synced up to the current DRI tree.
Alex
Might want to post th
I'm pretty unfamiliar with OpenGL programming. I have an idea for an
xfree module that I suspect would not be too hard to implement, but I
wanted to get some other opinions on it. What I'd like to do is create
a module called perhaps ogl-xv or glx-xv that would provide a generic
Xv adapter on th
On Mon, 2002-09-30 at 22:14, Alex Deucher wrote:
> I'm pretty unfamiliar with OpenGL programming. I have an idea for an
> xfree module that I suspect would not be too hard to implement, but I
> wanted to get some other opinions on it. What I'd like to do is
create
> a
yeah xawtv has an opengl plugin as well. I'll take a look if I ever
get a chance to. thanks for the suggestion.
Alex
--- Stefan Lange <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> > I'm pretty unfamiliar with OpenGL programming. I have an idea for
> an
>
I'd be interested in helping out with the savage work. I don't know
much about the DRI, but I can help test. I'm actually working (slowly)
on adding dual head (duoview) support to the savage driver for the
mobile savages. I've started on the code, but I've been so busy lately
that I've had no ti
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> > --- Ian Romanick <[EMAIL PROTECTED]> wrote:
> >>
>
> Close, but not quite exactly. The goal would be to modify the
> interface
> between libglx.a (the part that handles the high-le
XvMC is an extension for Xvideo that does things like motion
compensation and iDCT in hardware. I'm not sure if that has anything
to do with your problem. Also I'm not sure if the savage mx/ix cards
even have hw motion comp, etc. that might have been added in the
savage4 and 2000 cores. regardl
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-08-30 at 13:06, Jouni Tulkki wrote:
> > Is there a way to make moving images and textures to video memory
> faster?
> > Currently I'm using Radeon 9500 Pro and AGP 8x.
>
> Curious, how do use AGP without the DRI being enabled? :) (And h
I have two questions for you about the radeon driver.
the first relates to the CP and accel. I'm attempting to convert the
Xv code to use the CP. how do you check to find out if the driver is
using CP or MMIO accel? I considered using
info->directRenderingEnabled, but as far as I can see the
the open source radeon Xfree drivers do not support tv out yet. You
might check with the GATOS people (http://gatos.sf.net). it works in
the console because the BIOS is driving the outputs rather than the
driver.
Alex
--- Chris Ison <[EMAIL PROTECTED]> wrote:
> I'm wondering if there is a way t
Linus,
Some dell OEM radeon cards offered Dual DVI ports and I believe there
are some other oems (tyan?) that will be offering Dual DVI cards. the
radeon 9000s and newer only have one tdms trandsmitter built in, but an
additional external one can be added on to drive the second DVI port.
for mu
I think it worked in the past, but I think something got broken
recently. I've seen several reports of it being broken recently on the
xfree MLs. there are some bugs for it on xfree bugzilla.
Alex
--- Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Is Xv output supposed to work on i830-based set
An card from the 300 series sis cards should work:
300, 305, 540, 630/S/ST, 730
Alex
--- Martin Spott <[EMAIL PROTECTED]> wrote:
> Eric Anholt <[EMAIL PROTECTED]> wrote:
>
> > If anyone wants to test, [...]
>
> Which video card would you recommend for trying ? I'd see if I can
> get
> one,
>
This is probably better asked on dri-devel (cc:ed).
--- Cheshire Cat Fish <[EMAIL PROTECTED]> wrote:
> I am investigating supporting DRI and OpenGL for the Silicon Motion
> driver.
> I'm new to both of those, so some of these may be newbie sounding
> questions.
>
> 1) I have the OpenGL code from
e or not.
Alex
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > 2) access ROM directly instead of relying on copy
> > > in low RAM. This allows multiple cards. Required
> > > MPP_TB_CONFIG fix in driver.
> >
&
Dualhead...
Right now there is dualhead support for the following cards in xfree86:
radeon
matrox
sis
via
chips
3dlabs (Sven mentioned that he had this quasi-working on the newer
cards, although I don't know the state of his driver)
The following cards have hw dualhead support, but no driver supp
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> Hopefully these is the last versions. They implement:
> 1) add every know PCI ID
> 2) access ROM directly instead of relying on copy in
> low RAM. This allows multiple cards. Required
> MPP_TB_CONFIG fix in driver.
Is this patch necessary for xfree86? I
desktops
(LX-700/800/900) for a while with 630s as well. you can still find
300/305 PCI/AGP cards on some websites usually labeled as "sis 305
32mb" or similar.
Alex
--- Martin Spott <[EMAIL PROTECTED]> wrote:
> Alex Deucher <[EMAIL PROTECTED]> wrote:
> >> Eri
from the log:
To do that we're going to "port" the *OLD* 500TX driver to DRI.
:)
500tx is a what?
anholt: The GLINT before the MX.
...
anholt: It should be *much* faster. The Delta does all the
geometry setup. This is the mode the current gamma driver uses.
hmm
Part of this work may lead i
(5597/5598, 6326/AGP/DVD, 530, 620),
* the 300 series (300, 540, 630/S/ST, 730),
* the 315 series (315/E/H/PRO, 550, 650, 651, M650, 740, 661FX,
M661FX, 741), and
* the Xabre series (330)."
Alex
--- Martin Spott <[EMAIL PROTECTED]> wrote:
> Alex Deucher <[EMAIL PROTECTE
The 2D driver supports all savage chips, but the 3D driver seems to
only support the Prosavage and Twister (savage4 core) integrated chips:
from savage_driver.c:
if ((psav->Chipset == S3_TWISTER)
|| (psav->Chipset == S3_PROSAVAGE)) {
/* Setup DRI after visuals have been establi
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> I'm aware of Sven's work, and I have been in contact with him. I
> haven't persued getting docs form 3dlabs yet, but I may do so in the
> future. IBM's lawyers are *VERY* picky, so getting docs under NDA
> for
> use in open-source projects is *VER
Is there a web based CVS viewer on freedesktop.org like there is on
xfree86 or sourceforge? I personally find it useful when I don't have
access to my PC. it's also nice for reference.
Alex
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design
The r100 and r200 of course. :)
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> Merge which? The r100 & r200 or the 500TX & gamma? I think it would
> be
> a good idea to merge both, but "merging" the GLINT drivers will be
> much
> easier (since one of them hasn't been created yet!). H
looks like the post size limit ate my first attempt to post this.
Anyway, I was finally able to access DRI cvs (from
dri.freedesktop.org), so I pulled the latest tree and created a radeon
mergedfb patch against it. I've done some testing and it seems to work
fine. The patch only touches the 2D d
t;[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 29 Aug 2003 00:31 am, Alex Deucher wrote:
> > The following cards have hw dualhead support, but no driver support
> for
> > it:
> > i830/845
> I'm interested in working
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> > looks like the post size limit ate my first attempt to post this.
> >
> > Anyway, I was finally able to access DRI cvs (from
> > dri.freedesktop.org), so I pulled the latest tree and crea
Eric,
Now that you are finishing up the sis 300 series DRI port, how hard
would it be to add support for the 6326? there were databooks for it
flaoting around and there was a utah-glx driver as well. It's a pretty
basic 3D engine; it's it similar to the 300 series, it might be trivial
to add
Factoring it out is not a problem. the question is what to do with it
when I pull it out. create an external external libray like
libXMergedFB.so or something like that? what's the preferred method?
any existing examples I can look at?
Alex
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> As
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> > basic 3D engine; it's it similar to the 300 series, it might be
> trivial
> > to add support, but then again, I'm not too familiar with sis
> hardware
> > internals.
>
> I actually took a brief look. The 6326 is a simple PIO engine that
> needs
> triang
t the moment I guess I'm
inclined to agree. thoughts?
Alex
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-09-10 at 15:46, Alex Deucher wrote:
> > >
> > > It seems like a lot of cards have this type of capability and
> lots of
> > > dri
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Thu, 2003-09-11 at 17:32, Alex Deucher wrote:
> > I did some basic work on factoring out the common code and
> discussed it
> > with Thomas Winischhofer (Sis maintainer and driving force behind
> > mergedfb devel
How about a mergedfb branch if not the trunk? I'm pretty good about
keeping things up to date. I'm not yet an expert with CVS, but it
won't take long ;)
Alex
--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
>
> you would wonder how other developers could enjoy having
> a look on your updates at
S3/VIA released the source to their 2D/3D/XvMC driver that was based on
xfree86 4.2.0. it has not yet been ported to 4.3.0. if you don't mind
using 4.2.0, you can find instructions on how to build and install
their driver here:
http://probo.probo.com/pipermail/savage40/2003-July/41.html
The
Are you sure have mergedfb set up correctly? 3D should work on both
heads, not just one. check the man page for all the mergedfb options:
http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/radeon.4.html
Are you using pageflipping? If so, turn it off. it has some issues in
certain modes
Is anyone on either of these lists familiar with XGI? It seems to be a
new GPU manufacturer consisting of a merger of Trident and the SiS
graphics division.
here's their website:
http://www.xgitech.com/index.htm
They have some interesting products products (dual GPU solution). Some
of their oth
I wonder how the new company will be with respect to giving out
datasheets? like sis or like trident?
Alex
--- Thomas Winischhofer <[EMAIL PROTECTED]> wrote:
> Russ Dill wrote:
> > On Mon, 2003-09-15 at 11:03, Alex Deucher wrote:
> >
> >>Is anyone on either of thes
be re-coded.
>
> Also, both trident and Sis have the linux driver, which is release
> with
> Linux OS, for almost all their own chips.
>
> -Original Message-
> From: Alex Deucher [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 15, 2003 5:30 PM
> To: T
2003 21:10 Dimitry N. Naldaev ���:
> > � ����� �� 10
2003 02:16 Alex Deucher ���:
> > > The 2D driver supports all savage chips,
> >
> yesterday I did more testing S3 driver on my motebook and there is
> results
> by default DRI is not en
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
--- Ra
If you are getting version mismatch errors with the sanpshots, you need
a newer version of the xfree86 server. DRI just merged in the changes
from the Xfree86 tree and a newer XFree86 binary is needed. you can
either build it yourself from CVS, or download the gcc 3.x one I've
provided here:
http
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 an
1 - 100 of 1248 matches
Mail list logo
