On Wed, 2005-03-16 at 00:21 -0500, Michel Dänzer wrote:
> > >
> > > Actually people do use it on big-endian systems but since neither the
> > > mach64, ati128 or radeon drivers play with the swapper settings I can
> > > only
> > > assume that they haven't been tested very extensively.
> >
> >
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
On Tue, 2005-03-15 at 20:07 -0500, Vladimir Dergachev wrote:
>
> On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
>
> > My understanding was that for MMI
On Wed, 2005-03-16 at 00:17 +0100, Richard Stellingwerff wrote:
>
> Anyway, the driver works, but it's VERY unstable for me.
If you're using MergedFB (which includes clone mode), see the current
thread '[r200] Lockups...'.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI devel
On Wed, 2005-03-16 at 10:33 +1100, Benjamin Herrenschmidt wrote:
>
> Now, I agree that cutting the vram in half, and reserving both halves
> to the "offscreen" needs to each head may help avoiding mode switch on
> one head busting things used by whoever works on the second head, but
> I'm not sur
> It's ugly, but that's not the point. The point is that all deployed
> versions of X (and even current X.org CVS head still, in fact) make this
> assumption.
Oh, that's fine and that's not a problem. I will only repaint the
framebuffer on bit depth or line lenght changes. I'm trying to talk
abou
On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:
> There's also the case with Matrox Millennium I/II cards. They must place
> the visible frame buffer so that no line crosses the boundary of memory
> banks. matroxfb deals with that by moving the buffer and changing
> smem_start and smem_
On Wed, Mar 16, 2005 at 10:50:52AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
> > On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
> > > On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> > > > On Tue, 15 Mar 2005, Vill
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
This would mean that on r300 this fix is not needed,
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case per
On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
> On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
> > On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> > > On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
> > > > If radeonfb will allocate the buffer for the
On Wed, 2005-03-16 at 01:05 +0200, Ville Syrjälä wrote:
> True. Currently DirectFB doesn't handle this correctly. But that could be
> easily fixed if only line_length wasn't totally misplaced. It really
> belongs to fb_var_screeninfo. We could first test the mode with
> FB_ACTIVATE_TEST and act
On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
> On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> > On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
> > > If radeonfb will allocate the buffer for the second head from the top
> > > of the memory users would basically h
On Tue, 2005-03-15 at 16:00 +0200, Ville Syrjälä wrote:
> DirectFB has it's own asbitration mechanism. It doesn't support using
> multiple framebuffer devices at the same time. For that to work DirectFB
> would just have to know if some of the framebuffer devices are actually
> different output
On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote:
> > After reading all the promising success stories about the r300
> > project, I am
> > wondering whether anybody successfully tried it on a *BSD.
> > Some time ago I tried on DragonFly BSD and in Xorg.0.log I found
> > a message that DRI was
> > I once did a similar thing for an embedded prototype: take a fixed amount of
> > memory for both frame buffers (this was a UMA system), fb0 starts from the
> > top,
> > fb1 starts from the bottom. You can enlarge each frame buffer, until you
> > read
> > the memory of the other. Each fix.sme
Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> > We're hoping that davem's fix (committed yesterday) fixed that.
> >
> >
> > ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL PROTECTED]
> >
> > [MM]: Restore pgd_index() iteration to clear_page_range().
>
> Yep, seems to have worked (at least m
On Tue, 15 Mar 2005 23:41:14 +0100, khaqq <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Mar 2005 22:22:32 +0100
> Richard Stellingwerff <[EMAIL PROTECTED]> wrote:
> > Ah, I'll try that. I got confused, because it used to work with the
> > radeon driver that comes with Xorg 6.8.
>
> Radeon is the name of
On Wed, Mar 16, 2005 at 09:44:19AM +1100, Benjamin Herrenschmidt wrote:
>
> > DirectFB assumes all memory outside var.yres_virtual * fix.line_length is
> > preserved. A totally valid assumption in my opinion.
>
> Except that you can't know in advance how much fix.line_length will be.
> The "fix
> DirectFB assumes all memory outside var.yres_virtual * fix.line_length is
> preserved. A totally valid assumption in my opinion.
Except that you can't know in advance how much fix.line_length will be.
The "fix" isn't really "fixed". Different cards will have different
requirements depending o
Am Dienstag, den 15.03.2005, 15:59 -0500 schrieb Michel Dänzer:
> On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote:
> > I added to the Installation instructions:
> >
> > Packages are available for Linux distributions utilizing RPM package
> > management in the Download section. We currently do
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=2702
[EMAIL PROTECTED] changed:
What|Removed |Added
--
> After reading all the promising success stories about the r300 project, I
> am
> wondering whether anybody successfully tried it on a *BSD.
> Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message
> that DRI was enabled, but glxinfo said "direct rendering: No".
DRMs BSD supp
Jon Smirl wrote:
Can we put in our own fault handler for the mmap, trap the directfb
accesses and do the proper locking?
Some SGI hardware used to work like that. When they asked Linus for
some kernel hooks to support that type of thing, well...I'm just glad
*I* wasn't in the line of fire. ;) I
On Tue, 15 Mar 2005 16:13:21 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote:
> > [drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies
> > Inc RV250 5c61 [Radeon Mobility 9200 M9+]
>
> You need an r200 snapshot for t
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
> On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
> <[EMAIL PROTECTED]> wrote:
> >
> > This would mean that on r300 this fix is not needed, but rv350 locks up
> > without it.
>
> In that case perhaps it makes sense to only wait f
On Tue, 2005-03-15 at 22:10 +0100, Richard Stellingwerff wrote:
>
> I just installed the latest snapshot of the radeon DRI driver from
> http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2.
>
> Installation went without problems, but direct rendering is disabled.
>
> output o
Hi All,
I just installed the latest snapshot of the radeon DRI driver from
http://dri.freedesktop.org/snapshots/radeon-20050314-linux.i386.tar.bz2.
Installation went without problems, but direct rendering is disabled.
output of 'dmesg':
[drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Te
On Tue, 2005-03-15 at 11:37 -0600, D. Hageman wrote:
> I added to the Installation instructions:
>
> Packages are available for Linux distributions utilizing RPM package
> management in the Download section. We currently do not have Debian
> packages available. If you are interested in the role
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I'd be happy to test and fix things, but the page table walker patches
> > broke ia64... Once that's cleared up I can go digging.
>
> We're hoping that davem's fix (committed yesterday) fixed th
Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> I'd be happy to test and fix things, but the page table walker patches broke
> ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed that.
ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL P
Johannes Hofmann wrote:
After reading all the promising success stories about the r300 project, I am
wondering whether anybody successfully tried it on a *BSD.
Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said "direct rendering: No".
After reading all the promising success stories about the r300 project, I am
wondering whether anybody successfully tried it on a *BSD.
Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said "direct rendering: No".
Thanks,
Johannes
---
Dave Jones <[EMAIL PROTECTED]> writes:
> I've fixed this in my tree. Will ask Linus to pull for the next
> -bk snapshot.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
On Tue, 2005-03-15 at 11:53 -0500, Dave Jones wrote:
> On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
> >
> > > >
> > > > I might get time to do a code review, my main worry is that all the
> > > > problems reported with those patches in -mm made it into the patchset
> that
>
Am Dienstag, den 15.03.2005, 11:37 -0600 schrieb D. Hageman:
> I added to the Installation instructions:
>
> Packages are available for Linux distributions utilizing RPM package
> management in the Download section. We currently do not have Debian
> packages available. If you are interested in t
On Tuesday, March 15, 2005 6:36 am, Dave Jones wrote:
> I saw one report where the recent drm security hole fix broke dri
> for one user. Whilst it seems an isolated incident, could this have
> more impact than we first realised ?
>
> Worse case scenario we can drop out the multi-bridge support fo
I added to the Installation instructions:
Packages are available for Linux distributions utilizing RPM package
management in the Download section. We currently do not have Debian
packages available. If you are interested in the role of Debian package
manager for this project please send an e-mai
On Tue, 2005-03-15 at 09:29 -0500, Jon Smirl wrote:
> Aonther approach would be to just say you have to choose to run one of
> X, DirectFB, FBUI, XGL and you can't switch between them. Other than
> developers I don't know if anyone really runs more than one of these
> at a time.
FWIW, yes we do.
G'Day,
I've just committed the start of multitexturing support to CVS.
The code works for me, but I've left the old code intact, and can be
re-enabled by changing a couple of ifdefs in r300_state.c.
Here's what remains to be done:
1. Implement the remaining texenv functions, I believe I left out
On Tue, 2005-03-15 at 12:30 +0100, Roland Scheidegger wrote:
> Ville SyrjÃlà wrote:
> > I think that making the assumption that all memory is preserved when
> the
> > memory layout (virtual resolution and depth) doesn't change is perfectly
> > valid too. That would allow X to do it's Ctrl-Alt-+
> > the multi-bridge stuff is definitely broken as I've seen radeon and r128
> > reports on it .. and it looks most like 2.6.11-bk2 broke things and I
> > haven't merged anything until -bk7 ...
>
> Wait, -bk2 broke things ? The big agp changes went into -bk3,
> so this seems odd.
sorry bk2-bk
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
>
> > >
> > > I might get time to do a code review, my main worry is that all the
> > > problems reported with those patches in -mm made it into the patchset
> > that
> > > went into Linus.. mainly things like forgetting to me
Dave Jones <[EMAIL PROTECTED]> writes:
> On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
> > Thanks,
> >
> > I have CCed the relevant maintainers for their comment.
Thanks.
> The AGP change already went into Linus' tree, along with
> removal of the _MCH driver.
I just grabbed 2.6.11.
On Tue, Mar 15, 2005 at 09:37:35AM -0500, Dave Jones wrote:
> On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
> > Thanks,
> >
> > I have CCed the relevant maintainers for their comment.
>
> The AGP change already went into Linus' tree, along with
> removal of the _MCH driver.
Thanks, I
Dave Jones <[EMAIL PROTECTED]> writes:
> > I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver
> > has indeed disappeared, the Kconfig stanza for AGP_INTEL still
> > specifies !X86_64 AFAICT.
>
> It went into Linus' tree, not GregKH's.
I've also checked 2.6.11-bk10; same deal.
On Tue, Mar 15, 2005 at 11:18:17AM -0500, Aaron M. Ucko wrote:
> Dave Jones <[EMAIL PROTECTED]> writes:
>
> > > I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver
> > > has indeed disappeared, the Kconfig stanza for AGP_INTEL still
> > > specifies !X86_64 AFAICT.
> >
>
Am Dienstag, den 15.03.2005, 10:36 -0600 schrieb D. Hageman:
> I have made a RPM, SRPM and SPEC file of driconf available. The RPM
> was made under Fedora Core 3. The link is in the Download section on
> this page:
>
> http://dri.freedesktop.org/wiki/DriConf
Could you also add a note near the
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote:
> > I saw one report where the recent drm security hole fix broke dri
> > for one user. Whilst it seems an isolated incident, could this have
> > more impact than we first realised ?
>
> the radeon security changes? I've gotten no
I have made a RPM, SRPM and SPEC file of driconf available. The RPM
was made under Fedora Core 3. The link is in the Download section on
this page:
http://dri.freedesktop.org/wiki/DriConf
I will do my best to track releases to keep them updated, but if you can't
wait it should be easy to modif
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 08:18 ---
-bk2 works fine, bk6 (and the current .3-bk1) have the same problem (or a
similar^^) the screen is black in the upper part (to be exact 1/4, not 1/3)
and the system is very
> >
> > I might get time to do a code review, my main worry is that all the
> > problems reported with those patches in -mm made it into the patchset that
> > went into Linus.. mainly things like forgetting to memset certain
> > structures to 0 and sillies like that...
>
> I saw one report wh
On Tue, Mar 15, 2005 at 10:29:22AM -0500, Aaron M. Ucko wrote:
> Dave Jones <[EMAIL PROTECTED]> writes:
>
> > On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
> > > Thanks,
> > >
> > > I have CCed the relevant maintainers for their comment.
>
> Thanks.
>
> > The AGP change al
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
>
> > Michel Dänzer wrote:
> >
> >> On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
> >>
> >>> I am unsure of how to fix it though, as the call
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened with
the r300 driver in a
Well, I thought I'd also point out that this solves the lockups I was
experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened with the
r300 driver in a very long time :-)
Almos
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote:
> Thanks,
>
> I have CCed the relevant maintainers for their comment.
The AGP change already went into Linus' tree, along with
removal of the _MCH driver.
Dave
---
SF
On Tue, Mar 15, 2005 at 10:38:30AM +, Dave Airlie wrote:
>
> Hi all,
> Andrew Clayton reported lockups on the dri list issues since -bk2
> and bug 4337 on bugzilla.kernel.org looks like it might be the same
> thing..
>
> This leads me to think the AGP multi-bridge patches are at f
On Tue, 15 Mar 2005 16:00:05 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> DirectFB has it's own asbitration mechanism. It doesn't support using
> multiple framebuffer devices at the same time. For that to work DirectFB
> would just have to know if some of the framebuffer devices are actually
>
On Tue, Mar 15, 2005 at 05:59:42PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote:
>
> > If radeonfb will allocate the buffer for the second head from the top of
> > the memory users would basically have to guess it's location. matroxfb
> > simply c
On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
> > If radeonfb will allocate the buffer for the second head from the top of
> > the memory users would basically have to guess it's location. matroxfb
> > simply cuts the me
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=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 05:34 ---
(In r
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we
should not be reading from registers with engine busy.
Something may be needed
On Tue, Mar 15, 2005 at 12:30:56PM +0100, Roland Scheidegger wrote:
> Ville Syrjälä wrote:
> > I think that making the assumption that all memory is preserved when
> the
> >memory layout (virtual resolution and depth) doesn't change is perfectly
> >valid too. That would allow X to do it's Ctrl-A
Am Dienstag, den 15.03.2005, 01:41 +0100 schrieb Roland Scheidegger:
> Felix Kühling wrote:
> > Hi all,
> >
> > I just uploaded a new DRIconf version (0.2.3), which features better
> > support for floating-point ranges like the brilinear option proposed
> > by Roland Scheidegger. There are also a
Ville Syrjälä wrote:
> I think that making the assumption that all memory is preserved when
the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the whole screen.
I'm not sure I agree her
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrjälä wrote:
> I think that making the assumption that all memory is preserved when the
> memory layout (virtual resolution and depth) doesn't change is perfectly
> valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
> repainting the
Thanks,
I have CCed the relevant maintainers for their comment.
On Fri, Mar 04, 2005 at 12:31:34PM -0500, Aaron M. Ucko wrote:
> Package: kernel
> Severity: normal
> Tags: patch upstream
>
> The kernel's build system insists that users of x86_64 hardware use
> AGP_INTEL_MCH rather than AGP_INTEL
Hello.
I'm locking /drivers/char/drm/(on last 2.6.11-bkX) and I
found some problems (bugs?)
in file drivers/char/drm/drm_ioctl.c :
/**
* Setversion ioctl.
*
* \param inode device inode.
* \param filp file pointer.
* \param cmd command.
* \param arg user argument, pointing to a drm_lock struct
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=2733
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 02:40 ---
It's
Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..
This leads me to think the AGP multi-bridge patches are at fault... (for
once my laziness in merging late instead of early gave a good gap
http://bugme.osdl.org/show_bug.cgi?id=4337
--- Additional Comments From [EMAIL PROTECTED] 2005-03-15 02:26 ---
Can you do some testing of -bk2, -bk6 as well?
-bk2 should be fine, if -bk6 is broken then it is the multi-bridge AGP stuff
that is broken, and if -bk6 works but -bk8 doesn'
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=2733
Summary: Blender crashes after using renderer for more than 2
72 matches
Mail list logo
