On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> kernel tree. When X is started, the kernel outputs these messages:
>
> [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
> [drm:radeon_unlock] *ERROR* Pr
With this patch textures work again. Thanks!
On Wed, 05 Nov 2003 16:07:01 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-11-05 at 14:39, Felix Kühling wrote:
> > After a cvs update with the new radeon memory layout I get this on all
> > applications that use textures. The applicat
On Wed, 2003-11-05 at 05:07, Felix Kühling wrote:
> Hi,
>
> I get hard lockups when switching from a second Xserver (:1) started on
> vt8 back to the first one (:0) on vt7. It happens on VT switches as
> well as when the second Xserver exits. Sysrq keys don't work, and the
> machine doesn't respo
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.
Mr. Danzer,
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> > I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> > kernel tree. When X is started, the kernel outputs these messages:
> >
> > [drm:radeon_cp_init] *ERROR* rade
Eric Anholt wrote:
This makes me wonder how difficult it would be to get two servers to
cooperatively share a DRM instance (both of them holding the DRM open,
rather than the reinit thing done before).
I thought the reason for the re-init thing was so that you could change
the DRM module without s
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> This makes me wonder how difficult it would be to get two
> servers to cooperatively share a DRM instance (both of them
> holding the DRM open, rather than the reinit thing done
> before).
I'd find this useful. It would let me run X on one VT and the n
On Wed, 2003-11-05 at 05:07, Felix Kühling wrote:
> Hi,
>
> I get hard lockups when switching from a second Xserver (:1) started on
> vt8 back to the first one (:0) on vt7. It happens on VT switches as
> well as when the second Xserver exits. Sysrq keys don't work, and the
> machine doesn't respo
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
--- Mic
I've been wondering a bit about this code in
radeon_emit_packet3_cliprect():
do {
if ( i < cmdbuf->nbox ) {
[...]
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
On Wed, 2003-11-05 at 23:44, Michel DÃnzer wrote:
> > > > There's a patch in -mm2 that does something with drm/agp (haven't looked
> > > > at it yet):
> > > >
> > > > +drm-agp-module-dependency-fix.patch
> > > >
> > > > Maybe fix DRM<->AGP module dependencies so things autoload nicely.
>
> BTW,
On Thu, 2003-11-06 at 00:36, Felix KÃhling wrote:
> I just ran into another related problem. The xscreensaver demo cage (for
> example) terminated with:
>
> drmCommandWrite: -22
> drmRadeonCmdBuffer: -22 (exiting)
>
> before rendering the first frame. The kernel log shows:
>
> [drm:radeon_check_
I just ran into another related problem. The xscreensaver demo cage (for
example) terminated with:
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)
before rendering the first frame. The kernel log shows:
[drm:radeon_check_and_fixup_packets] *ERROR* Invalid R100 texture offset
[drm:radeon_e
Michel DÃnzer wrote:
On Thu, 2003-10-30 at 20:17, Alex Deucher wrote:
Hopefully I'll have some time this weekend to look into this, what
files in the r200 client driver should I be looking at? Having looked
at the code I'm guessing r200_state. Scissor and cliprect stuff.
Yes, I'd say split
On Thu, 2003-10-30 at 20:17, Alex Deucher wrote:
> Hopefully I'll have some time this weekend to look into this, what
> files in the r200 client driver should I be looking at? Having looked
> at the code I'm guessing r200_state. Scissor and cliprect stuff.
Yes, I'd say split the cliprects int
On Wed, 2003-11-05 at 22:24, Bradley Chapman wrote:
> Mr. Danzer,
FYI, the correct transliteration of my last name would be 'Daenzer', but
I feel more comfortable if people simply call me Michel.
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Wed, 2003-11-05 at 19:20, Ronny V. Vindenes wrot
On Wed, 2003-11-05 at 19:20, Ronny V. Vindenes wrote:
> On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> > I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> > kernel tree. When X is started, the kernel outputs these messages:
> >
> > [drm:radeon_cp_init] *ERROR* radeon_
On Wed, 2003-11-05 at 03:49, Otto Solares wrote:
> I am trying to deviate from windows and use instead workspaces, i really
> think that windows are counter-productive, workspaces would be a
> better way to manage different apps and tabs within apps, and yes,
> it will be a workspace called "deskt
Mr. Danzer,
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-11-05 at 19:20, Ronny V. Vindenes wrote:
> > On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> > > I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> > > kernel tree. When X is started, the kernel out
Mr. Vindenes,
--- "Ronny V. Vindenes" <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> > I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> > kernel tree. When X is started, the kernel outputs these messages:
> >
> > [drm:radeon_cp_init] *ER
On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote:
> I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
> kernel tree. When X is started, the kernel outputs these messages:
>
> [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
> [drm:radeon_unlock] *ERROR* P
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=314
--- Additional Comments From [EMAIL PROTECTED] 2003-05-11 10:10 ---
I haven't made any IRQ
On Wed, 2003-11-05 at 14:39, Felix KÃhling wrote:
> After a cvs update with the new radeon memory layout I get this on all
> applications that use textures. The application reports:
>
> DRM_RADEON_TEXTURE: return = -22
>offset=0x00c0
>image width=64 height=64
> blit width=1024 heig
On Wed, 2003-11-05 at 02:49, Michael Dreesen wrote:
> > Would it be better to use xfs to cache the fonts?
>
> Not sure about that one. I'm going for a stand-alone system that can
> run on top of X (or any system with OpenGL conforming to POSIX standards
> for the IPC). The only thing I use X f
I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2
kernel tree. When X is started, the kernel outputs these messages:
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:radeon_unlock] *ERROR* Process 1083 using kernel context 0
The driver did not do this
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 run out of room for
pbuffers you could go back to swapping.
I do have an ATI card, I'm developing on a mobility 9200 w/64MB ( also
testing on nVidia Quadro).
T
After a cvs update with the new radeon memory layout I get this on all
applications that use textures. The application reports:
DRM_RADEON_TEXTURE: return = -22
offset=0x00c0
image width=64 height=64
blit width=1024 height=8 data=0x814b400
In the kernel log I see:
[drm:radeon_cp_di
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=314
--- Additional Comments From [EMAIL PROTECTED] 2003-05-11 08:28 ---
To: Michel Dänzer (re:
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=314
--- Additional Comments From [EMAIL PROTECTED] 2003-05-11 08:03 ---
some more tests for ke
Hi,
I get hard lockups when switching from a second Xserver (:1) started on
vt8 back to the first one (:0) on vt7. It happens on VT switches as
well as when the second Xserver exits. Sysrq keys don't work, and the
machine doesn't respond to ping any more. I had a look at the
XFree86.1.log from th
30 matches
Mail list logo
