Re: X server steals DRI lock

Thomas Hellstrm wrote: I don't think this is the cause of the problem, since what you're referring to above is IIRC a drawable spinlock, not the heavyweight hardware lock. If a client takes the heavyweight lock and then sleeps even for a couple of seconds, the X server should freeze

Re: DRM_WAIT_ON changed behaviour.

Dave Airlie wrote: I agree, patch should be reverted. The difference between my change and the previous code, fundamentally, is that mine slept as long as possible relative to the passed in timeout until either a signal or wait-queue event happened; the original code, in contrast,

Re: Radeon 9200SE hangs

On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dnzer wrote: On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor wrote: On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dnzer wrote: Did you post the problems you encountered? Yes, on Mon, 14 Feb 2005. You were one of the recipients :)) There was a

Re: Cannot run fgfs using via/unichrome: illegal DMA data

Luke Diamand wrote: I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver. When I do so, fgfs fails at startup saying: fire_buffer: DRM_VIA_CMDBUFFER returned -22 This was a problem in Mesa. A workaround has been comitted to CVS a few days ago. Try a cvs update and rebuild

Re: Cannot run fgfs using via/unichrome: illegal DMA data

Hi! I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver. When I do so, fgfs fails at startup saying: fire_buffer: DRM_VIA_CMDBUFFER returned -22 dmesg reports: [drm:investigate_hazard] *ERROR* Illegal DMA data: 0xfff0 Other programs like glxgears seem to work

Re: [r300] what about *BSD?

On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim [EMAIL PROTECTED] wrote: I have sort of working drm but I always get this from drm when I run glxinfo or glxgears: drm0: ATI Radeon RV300 Mobility 9600 M10 port 0x2000-0x20ff mem \ 0xd010-0xd010,0xd800-0xdfff irq

Re: [r300] what about *BSD?

On Tue, 19 Apr 2005 15:42:43 +0200 Jan Kreuzer [EMAIL PROTECTED] wrote: $ make === drm Warning: Object directory not changed from original /usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915 Warning: Object directory not changed from original

Re: [r300] what about *BSD?

Hi the fix you provided let the module get compiled. However when starting an GL-Application i get the following: glxgears Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes)

Re: [r300] what about *BSD?

Ok after i commented the r300_check_range function (line 256 in r300_cmdbuf.c) glxgears and xscreensaver work. No i am compiling some GL-Progs under FreeBSD and see if they work also. Greetings Jan -- +++ GMX - Die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 10:49 am, jan kreuzer wrote: Hi the fix you provided let the module get compiled. However when starting an GL-Application i get the following: glxgears Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating

Proposed ABI break in libdri for 7.0

The server-side DRI support defined frameBufferPhysicalAddress as a CARD32. This is wrong for 64-bit systems where the framebuffer could be mapped above 4G. The problem is that frameBufferPhysicalAddress is smack in the middle of the DRIInfoRec, and on LP64 systems changing it to a pointer

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote: On Tue, 19 Apr 2005 15:42:43 +0200 Jan Kreuzer [EMAIL PROTECTED] wrote: $ make === drm Warning: Object directory not changed from original /usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915 Warning: Object directory not

Re: [r300] what about *BSD?

On Tue, 19 Apr 2005 12:26:36 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote: On Tue, 19 Apr 2005 15:42:43 +0200 Jan Kreuzer [EMAIL PROTECTED] wrote: $ make === drm Warning: Object directory not changed from original

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote: On Tue, 19 Apr 2005 12:26:36 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote: On Tue, 19 Apr 2005 15:42:43 +0200 Jan Kreuzer [EMAIL PROTECTED] wrote: $ make === drm

Re: Cannot run fgfs using via/unichrome: illegal DMA data

Benno Schulenberg wrote: Luke Diamand wrote: I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver. When I do so, fgfs fails at startup saying: fire_buffer: DRM_VIA_CMDBUFFER returned -22 This was a problem in Mesa. A workaround has been comitted to CVS a few days ago. Try a

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 10:49 am, jan kreuzer wrote: Hi the fix you provided let the module get compiled. However when starting an GL-Application i get the following: glxgears Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32

[Patch] Re: X server steals DRI lock

Thomas Hellstrm wrote: Since the error messages I get indicate that indeed the filp associated with the HW lock has changed, the stealing has probably occured in the kernel DRM code. Hmm, This is a nasty one. What seems to happen is that when the X server waits in the kernel for

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote: On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote: On Tue, 19 Apr 2005 12:26:36 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote: On Tue, 19 Apr 2005 15:42:43 +0200 Jan

Re: [r300] what about *BSD?

On Tue, 19 Apr 2005 16:09:45 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote: On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote: On Tue, 19 Apr 2005 12:26:36 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005

Re: libminidri?

On Friday 15 April 2005 04:37, Thomas Hellström wrote: Hi all! Trying to make unichrome XvMC using the dri extension as opposed to now only the xf86drm API, I've ended up using 1) xf86drm.h and corresponding c files that now make up or will make up libdrm.so 2) xf86dri.h and XF86dri.c that

Re: libminidri?

2) xf86dri.h and XF86dri.c that are part of mesa. 3) Some of the dri utils from mesa, basically to handle basic drawable management and locking. While doing this I notice that some (3) functions in XF86dri.c are depending on Mesa headers and datatypes, and this does not seem to be

Re: [r300] what about *BSD?

On Tuesday 19 April 2005 04:45 pm, Aapo Tahkola wrote: On Tue, 19 Apr 2005 16:09:45 -0400 Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote: On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote: On Tue, 19 Apr 2005 12:26:36 -0400 Jung-uk

Re: libminidri?

On Tuesday 19 April 2005 20:03, Dave Airlie wrote: 2) xf86dri.h and XF86dri.c that are part of mesa. 3) Some of the dri utils from mesa, basically to handle basic drawable management and locking. While doing this I notice that some (3) functions in XF86dri.c are depending on Mesa

Re: libminidri?

My issue with exposing XF86DRI* as they are now is that they're direct bindings to the XFree86-DRI protocol, which I don't think should be app-visible at all. Consider the possibility of someone wanting to write a DRI server that was not an X server. We should be enabling our competition.

Re: libminidri?

Adam Jackson wrote: On Tuesday 19 April 2005 20:03, Dave Airlie wrote: 2) xf86dri.h and XF86dri.c that are part of mesa. 3) Some of the dri utils from mesa, basically to handle basic drawable management and locking. While doing this I notice that some (3)