On Tue, 10 Feb 2004, Hod McWuff wrote:
>So, to summarize, I need to know *roughly* what's changed since the
>Gatos folks forked, in terms of what-moved-where and an idea of any
>structural changes. I can read the different sources and figure out the
>code changes myself, but I need to know what I'
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=1169
--- Additional Comments From [EMAIL PROTECTED] 2004-02-11 02:14 ---
Michel Dänzer sa
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=1169
[EMAIL PROTECTED] changed:
What|Removed |Added
-
There are two mainpieces to this that I know of, maybe more.
1) The tuner
2) video overlays
xserver may render video overlays pointless. Once we get hardware compositing
going you should be able to rebuild the entire screen on every TV frame. You may
want to review what is happening with xserver
The problem identified by "DRM+ATI-Radeon-Mobility" appeared already
with kernel 2.4.23-pre8
Freezing takes place when function, gl_init_all_x86_transform_asm
called from /usr/X11R6/lib/modules/dri/radeon_dri.so
is to be executed (see eg., gdb tunnel )
Regards
Wlodek
---
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=1169
[EMAIL PROTECTED] changed:
What|Removed |Added
-
OK, perhaps you could check in the restored version for now. I may
not get to look into this further for a day or two.
-Brian
Oh - such a drastic measure :-(. Is there some way to revert changes in
cvs, or do I just have to submit that as a new version, maybe even with
tricks like update it (w
Ian Romanick wrote:
Log message:
Incorporate all changes from the driinterface-0-0-2-branch.
Obtained from: driinterface-0-0-2-branch
In the past I have had a DRI / non-DRI time split of 90%/10%. As of
last Monday that switched to 10%/90%. This has caused me to change some
of the DRI re
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code? The crash
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code? The crashes sometimes are pr
I'm forwarding this to the devel list.
Alex
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html--- Begin Message ---
Hi all,
Recently I've discovered (after some hours of debugging) that there's a
problem
Using the radeon.o driver from 2.4.22 with 2.4.24 avoids the problem.
Looking at the diffs between the radeon code in 22 and 24 I see:
+ some new CP microcode
+ changes to the initialization of the scratch register pointer
+ changes to the radeon_do_init_pageflip method
+ changes to the radeon_
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll a
Am Dienstag, 10. Februar 2004 23:35 schrieb Brian Paul:
> Roland Scheidegger wrote:
> > Brian Paul wrote:
> >> Roland Scheidegger wrote:
> >>> Brian Paul wrote:
> Keith Whitwell wrote:
> > Roland Scheidegger wrote:
> >> I get a lot of dri crashes, were there some changes very recently
Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
> >> On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
> >>> [ Following up to the dri-devel mailing list, we aren't really
> >>> using the sf.net bu
Did GATOS make changes to the DRM drivers?
Is it using I2C to get to the TV tuner on ATI cards?
What else get changed in the Xfree drivers?
--- Hod McWuff <[EMAIL PROTECTED]> wrote:
>
> OK, onward and upward... I'm starting to investigate what it would take
> to merge the GATOS functionality int
Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
> >> On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
> >>> [ Following up to the dri-devel mailing list, we aren't really
> >>> using the sf.net bu
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll a
OK, onward and upward... I'm starting to investigate what it would take
to merge the GATOS functionality into the current DRI. I'm sure the
XFree side is going to be a pain in the ass, but I'm starting with the
kernel modules.
The first discrepancy I need cleared up is about driver support. The
c
On Tue, 2004-02-10 at 18:33, Hod McWuff wrote:
>
> > Fortunately, the root cause of the incompatibility has been removed in
> > DRI CVS, GATOS just needs to adapt to that.
>
> OK, well I haven't seen a whole lot of activity from the Gatos folks in
> quite a while... what's that incompatibility yo
Okay everything should be checked in and building, it doesn't work yet
though :-)
I'll hopefully get time over the next few days to hack on it again, I'm in
the middle of moving apartments and work only pay me the odd hack to
i810/radeon stuff, the mach64 is personal (as my laptop has it), if I g
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro wh
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer sa
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says
"in twenty-two ninety-"
just tried to run ut2003_demo with radeon_dri.so from current
DRI-cvs/MESA-cvs HEAD and got a SIGSEGV, just before the logo
usually is displayed.
However ut2003_demo worked "well" with an older radeon_dri.so
from xfree-cvs (20031226) I had lying around and it worked
with radeon_dri.so from DRI-CVS
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says "in
twenty-two ninety-" segfault!)
gdb say
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in the
tnl code? The crashes sometimes are predictable (for instance in the old
ut it'll always crash in the intro when the announcer says "in
twenty-two ninety-" segfault!)
gdb says this:
Program receive
I get a lot of dri crashes, were there some changes very recently in the
tnl code? The crashes sometimes are predictable (for instance in the old
ut it'll always crash in the intro when the announcer says "in
twenty-two ninety-" segfault!)
gdb says this:
Program received signal SIGSEGV, Segmenta
Now I've changed the version number in the xc/bleh kernel module. I'm
not getting hard server locks anymore, but now *all* GL apps show an
empty black window that never changes.
Something is definitely still funky. I'm guessing this has something to
do with the ati.2 module I've got installed. Is
> The Radeon DRM and 3D drivers from the GATOS project are incompatible to
> those from the DRI project. Unfortunately, GATOS didn't reflect this
> incompatibility correctly in their DRM version, otherwise the wrong 3D
> driver would refuse to run instead of locking up the machine.
> Fortunately,
OK, I managed to compile just the kernel portion from what I hope is the
new CVS tree (:pserver:[EMAIL PROTECTED]:/cvs/dri)
I get this in the X server output, which is also about what I expect to
see from the ones in the kernel:
(EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a versi
On Tue, 2004-02-10 at 10:17, Michel Dänzer wrote:
> On Tue, 2004-02-10 at 08:45, Email Archive wrote:
> > On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
> > > [ Following up to the dri-devel mailing list, we aren't really using the
> > > sf.net bug tracker anymore but rather the kernel and XFree
On Tue, 2004-02-10 at 17:46, Hod McWuff wrote:
> On Tue, 2004-02-10 at 10:17, Michel DÃnzer wrote:
> > On Tue, 2004-02-10 at 08:45, Email Archive wrote:
> > > On Mon, 2004-02-09 at 20:55, Michel DÃnzer wrote:
> > > > On Mon, 2004-02-09 at 04:55, SourceForge.net wrote:
> >
> > [...] I don't underst
--- James Jones <[EMAIL PROTECTED]> wrote:
> I'm building Dave Airlie's mach64-0-0-7-branch and I notice the build
> guide
> (http://dri.sourceforge.net/doc/building.html) has still not been
> updated to
> include the mesa-newtree stuff. Shouldn't something like the
> following be
> added betw
Michel DÃnzer wrote:
Works perfectly here... Do you have current DRI CVS from
freedesktop.org? If so, please post the errors.
Speaking of that, I've seen some users get dri cvs from sourceforge.net
accidentally. Couldn't someone commit a "fix" so when you try to build
it you just get some error
On Tue, 10 Feb 2004 06:46:16 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Felix K_hling <[EMAIL PROTECTED]> wrote:
[snip]
>
> hmmm... that's probably because I used the SetTextMode() bios call on
> close screen and VT switches. I'll have dig into that more and see if
> I can get
On Tue, 2004-02-10 at 07:37, Ville SyrjÃlà wrote:
> On Sun, Feb 08, 2004 at 08:27:17PM -0800, Jon Smirl wrote:
>
> Here's a quick and dirty chart of how I think things should be organised.
>
> --
> user space
>---
>
I'm building Dave Airlie's mach64-0-0-7-branch and I notice the build guide
(http://dri.sourceforge.net/doc/building.html) has still not been updated to
include the mesa-newtree stuff. Shouldn't something like the following be
added between steps 2 and 3?
-
2.1) You'll also need to check o
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> And finally I find the current situation with multi-head cards quite
> bad. I'd like the ablitity for a user space app to open the whole card
> as one entity. That includes all CRTCs, outputs and the whole memory
> (minus whatever is in use by other
On Tue, 2004-02-10 at 13:36, Greg Wilkins wrote:
> I can confirm that doing a warm reboot from 4.2.22 to 4.2.24
> "solves" the problem and that glxgears works.
Some random ideas to try and further track down the problem:
* make a diff of drivers/char/drm between kernels 2.4.22 and
2
On Tue, 2004-02-10 at 08:45, Email Archive wrote:
> On Mon, 2004-02-09 at 20:55, Michel DÃnzer wrote:
> > [ Following up to the dri-devel mailing list, we aren't really using the
> > sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ]
> > On Mon, 2004-02-09 at 04:55, SourceForg
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Mon, 9 Feb 2004 16:40:19 -0800 (PST)
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > I think I fixed the problem that caused your prosavage to fail. I
> > forgot to add PROSAVAGEDDR and TWISTER to the bci setup function
> > (SavageInitialize2d())
I can confirm that doing a warm reboot from 4.2.22 to 4.2.24
"solves" the problem and that glxgears works.
Greg Wilkins wrote:
I think I'm having a similar problem on my IBM a30p.
I just upgraded the kernel from 2.4.22 to 2.4.24 and now
DRI applications (eg glxgears) lock the machine up. I have
no
Dieter Nützel wrote:
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
[ Following up to the dri-devel mailing list, we aren't really
using the sf.net bug tracker anymore but rather the kernel and
XFree86 bugzillas ]
On Mon, 2004-02-09 at
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
> On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
> > [ Following up to the dri-devel mailing list, we aren't really using the
> > sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ]
> >
> > On Mon, 2004-02-09 at 04:5
On Mon, 9 Feb 2004 16:40:19 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
> I think I fixed the problem that caused your prosavage to fail. I
> forgot to add PROSAVAGEDDR and TWISTER to the bci setup function
> (SavageInitialize2d()) in savage_accel.c. That should fix it, but I
> don't hav
On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
> [ Following up to the dri-devel mailing list, we aren't really using the
> sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ]
> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote:
> >
> > I just ported the latest CVS drm-ker
Roland Scheidegger wrote:
Now that I've commited the lighting changes for r200 (still has the
material fallback though), I've wanted to commit the same changes (well
not exactly the same of course ;-)) to the radeon driver too (some brief
testing showed it worked just fine). But I'm a bit confus
49 matches
Mail list logo
