Hi Jesse !
On Mon, 7 Mar 2005, Jesse Barnes wrote:
Ok, so I've applied Stephane's fixes and sample_server comes up and
miniglxtest no longer segfaults. However, after setting the mode,
sample_server seems to die and wedge my display. miniglxtest just fails
right away with this message:
[EMAIL
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2673
Summary: Missing memset lets setversion ioctl corrupt memory.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2673
--- Additional Comments From [EMAIL PROTECTED] 2005-03-08 02:38 ---
Finaly get 5min to test lastest cvs and it works perfectly
here. Could you send me your xorg log file showing that
dri is disable.
Jerome Glisse
On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger
[EMAIL PROTECTED] wrote:
Hi Guys,
Sorry should have noted this. As of the time of my intitial
Hi,
Yes agpgart and uninorth_agp are both loaded before drm. I'll try
removing them first and email back.
Keith
On Tue, 2005-03-08 at 12:45 +0100, Jerome Glisse wrote:
Do you have agpgart running before drm ? Try with without
agpgart this maybe related to this. Moreover have you try to
do a
Hi,
I have attached my X log and dmesg log of when I run r300_demo.
Keith
On Tue, 2005-03-08 at 12:23 +0100, Jerome Glisse wrote:
Finaly get 5min to test lastest cvs and it works perfectly
here. Could you send me your xorg log file showing that
dri is disable.
Jerome Glisse
On Mon, 07
(WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and
newer cards
seems you got a xorg 6.8.1 you should use lastest cvs xorg or at least
a 6.8.2 if my memory is rigth there have been change in xorg for r300 since
then and now i think that you need a 6.8.2 or a recent cvs checkout.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=788
--- Additional Comments From [EMAIL PROTECTED] 2005-03-08 07:40 ---
(In
Hi,
I tried loading drm w/o agpgart but in needs agpgart to load. Btw I
actually replaced the old drm.ko with the r300 cvs version. So I don't
think an old drm is causing any issues.
Thanks
Keith
On Tue, 2005-03-08 at 12:45 +0100, Jerome Glisse wrote:
Do you have agpgart running before drm ?
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=788
--- Additional Comments From [EMAIL PROTECTED] 2005-03-08 08:04 ---
(
On Tue, 8 Mar 2005, Jerome Glisse wrote:
(WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and
newer cards
seems you got a xorg 6.8.1 you should use lastest cvs xorg or at least
a 6.8.2 if my memory is rigth there have been change in xorg for r300 since
then and now i think that
On Tuesday, March 8, 2005 12:01 am, Vladimir Dergachev wrote:
Hi Jesse !
On Mon, 7 Mar 2005, Jesse Barnes wrote:
Ok, so I've applied Stephane's fixes and sample_server comes up and
miniglxtest no longer segfaults. However, after setting the mode,
sample_server seems to die and wedge my
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=788
--- Additional Comments From [EMAIL PROTECTED] 2005-03-08 09:01 ---
Hi,
Doh, sorry to waste everyones time. I installed cvs X over 6.8.1 and it
was picking up some old stuff. I moved 6.8.1 and reinstall cvs and all
is well. Now anything I can help test on PPC?
Keith
On Tue, 2005-03-08 at 16:40 +0100, Jerome Glisse wrote:
(WW) RADEON(0): Direct rendering not yet
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid mixing code declarations warnings and
adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for
pointing out the resource size mismatch. The patch just fixes that (PCI
resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and
adds the checking for write combining regions I posted earlier
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds the
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds the
Hi,
Ok currently I've noticed the following issues:
1) Xv Color issues
2) Text rendering problems in mozilla
3) Textures in 3d apps are upside down and show 4copies when there
should be one.
Let me know If you need more details.
--
Keith Conger
[EMAIL PROTECTED]
http://pimpstation.org
On Tuesday, March 8, 2005 10:43 am, Jesse Barnes wrote:
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid mixing code declarations warnings
and adds vmalloc.h
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are
On Tuesday, March 8, 2005 12:24 pm, Jesse Barnes wrote:
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to
Stephane for pointing out the resource size mismatch.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=788
--- Additional Comments From [EMAIL PROTECTED] 2005-03-08 14:14 ---
(In
Am Mittwoch, den 09.03.2005, 02:08 +0300 schrieb Sergey Zharkov:
Felix,
Sorry for reporting bug on this address - just culd not find any place t
report for DRI, and you seems to be the only man who actually program
the driver.
The DRI developers list is [EMAIL PROTECTED] Savage
issues can
On Wed, 09 Mar 2005 00:31:02 +0100, Felix Kühling [EMAIL PROTECTED] wrote:
Am Mittwoch, den 09.03.2005, 02:08 +0300 schrieb Sergey Zharkov:
Felix,
Sorry for reporting bug on this address - just culd not find any place t
report for DRI, and you seems to be the only man who actually program
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=788
[EMAIL PROTECTED] changed:
What|Removed |Added
I started looking into the issue of how we handle various texture
formats on R300 on big-endian machines. It became evident that
textures were getting byte-swapped on their way to the framebuffer.
Setting RADEON_HOST_DATA_SWAP_32BIT in RADEON_RBBM_GUICNTL doesn't
seem to have any effect on R300.
I have updated the table of texture formats in r300_texstate.c based
on the definitions and comments in Mesa/src/mesa/main/texformat.h.
These changes assume that radeon_cp_dispatch_texture doesn't
byte-swap, i.e. that the patch I just posted has been applied.
I have tested formats 1, 13, 16 and
Jesse Barnes writes:
Anyone have a preference on this stuff? Should we remove the checks
altogether or just the ones against the highmem variable? If we did the
latter, we could remove the #ifdefs altogether, though I'm not sure how
useful that check is--seems like we'd run into trouble
Alex Deucher [EMAIL PROTECTED] writes:
radeon has support for suspect resume as well. you need to add pm
hooks into your agp module to re-initialize it on resume (some agp
drivers may already have this). you also need to re-init the video
hardware properly. the radeon DDX does this in the
On Tuesday, March 08, 2005 4:24 pm, Paul Mackerras wrote:
Jesse Barnes writes:
Anyone have a preference on this stuff? Should we remove the checks
altogether or just the ones against the highmem variable? If we did the
latter, we could remove the #ifdefs altogether, though I'm not sure
31 matches
Mail list logo
