Re: [RFC] drm: emit change events when mode config changes

, to allow for it. Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org Reviewed-by: Adam Jackson a...@redhat.com - ajax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing

Re: [PATCH] libdrm: Fix PCI domain domain support

On Fri, 2010-08-06 at 13:55 +1000, Benjamin Herrenschmidt wrote: This works in conjunction with newer kernels. If we succeed in requesting interface 1.4, the we know the kernel provides proper domain numbers. If not, ignore the domain number as it's bogus (except on Alpha). Signed-off-by:

Re: [patch] drm_edid: There should be 6 Standard Timings

On Fri, 2010-05-14 at 13:06 +0200, Dan Carpenter wrote: Smatch complained that we initialize 6 elements in add_detailed_modes() but the timings[] array is declared with 5 elements. Adam Jackson verified that 6 is the correct number of timings. On Mon, May 10, 2010 at 12:08:24PM -0400

Re: [patch -next] drm: off by one in drm_edid.c

num_est3_modes) + if (m = num_est3_modes) break; if (est[i] (1 j)) { mode = drm_find_dmt(connector-dev, Reviewed-by: Adam Jackson a...@redhat.com - ajax signature.asc Description

Re: drm_edid: potential range checking issue?

On Fri, 2010-05-07 at 10:35 +0200, Dan Carpenter wrote: In include/drm/drm_edid.h this array has 5 elements not 6. struct detailed_non_pixel { u8 pad1; u8 type; /* ff=serial, fe=string, fd=monitor range, fc=monitor name fb=color point data,

[PATCH] drm/edid: When checking duplicate standard modes, walked the probed list

... and not the global list. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index c4a578e..b407eef 100644 --- a/drivers/gpu/drm/drm_edid.c

[PATCH] drm/edid: Fix sync polarity for secondary GTF curve

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_modes.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 8840066..f1f473e 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm

[PATCH] drm/edid/quirks: Envision EN2028

Claims 1280x1024 preferred, physically 1600x1200 cf. http://bugzilla.redhat.com/530399 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

[PATCH 02/14] drm/edid: Remove some misleading comments

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 8e3bd50..7707a6a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[PATCH 01/14] drm/edid: Fix secondary block fetch.

This makes fetching the second EDID block on HDMI monitors actually work. DDC can't transfer more than 128 bytes at a time. Also, rearrange the code so the pure DDC bits are separate from block parse. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 337

[PATCH 03/14] drm/edid: Remove a redundant check

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7707a6a..a465c1d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[PATCH 05/14] drm/edid: Add modes for Established Timings III section

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 91 1 files changed, 91 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 3ecddbb..e0c37fb 100644 --- a/drivers/gpu

[PATCH 04/14] drm/edid: Reshuffle mode list construction to closer match the spec

Also, document what the spec says to do. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a465c1d..3ecddbb 100644

[PATCH 06/14] drm/edid: Remove arbitrary EDID extension limit

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_crtc.c |7 +-- drivers/gpu/drm/drm_edid.c | 19 +-- drivers/gpu/drm/drm_sysfs.c |2 +- drivers/gpu/drm/radeon/radeon_combios.c |8 include/drm

[PATCH 07/14] drm/edid: Remove some silly comments

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 17 +++-- 1 files changed, 3 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9974638..c052623 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers

[PATCH 08/14] drm/edid: Fix preferred mode parse for EDID 1.4

In 1.4, the first detailed mode is always the preferred mode. The bit that used to mean that, now means this mode is the physical size in pixels. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git

[PATCH 10/14] drm/edid: Extend range-based mode addition for EDID 1.4

1.4 adds better pixel clock precision, explicit reduced blanking awareness, and extended sync ranges. It's almost like a real spec. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 101 ++-- 1 files changed, 78 insertions

[PATCH 09/14] drm/edid: Add test for monitor reduced blanking support.

The generic block walk callback looks like overkill, but we'll need it for other detailed block walks in the future. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 47 --- 1 files changed, 43 insertions(+), 4 deletions

[PATCH 11/14] drm/edid: Fix the HDTV hack.

-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5ba470e..93ddc9a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c

[PATCH 13/14] drm/edid: Add secondary GTF curve support

and therefore possibly better image quality on analog links. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 119 +-- drivers/gpu/drm/drm_modes.c | 81 +++-- include/drm/drm_crtc.h |4 ++ 3

[PATCH 12/14] drm/edid: Strengthen the algorithm for standard mode codes

If you have 1920x1200 in both detailed (probably RB) and standard variants, you probably only want the RB version. But we have no way of guessing that from standard mode parse. So, if a mode already exists for a given w/h/r, skip adding it. Signed-off-by: Adam Jackson a...@redhat.com

[PATCH 14/14] drm/modes: Fix interlaced mode names

Height in frame size, not field size, and trailed with an 'i'. Matches the X server behaviour. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |4 ++-- drivers/gpu/drm/drm_modes.c | 21 - 2 files changed, 14 insertions(+), 11 deletions

Re: [git pull] drm request 3

On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote: On 03/04/2010 05:59 PM, Adam Jackson wrote: in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X

Re: [git pull] drm request 3

On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). Read

Re: [git pull] drm request 3

On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely

Re: [git pull] drm request 3

On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf Never tried this part. The bug I'm assuming you're referring to is https://bugzilla.redhat.com/show_bug.cgi?id=519298 in which you merely remove the nouveau userspace

Re: [git pull] drm request 3

On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of

[PATCH] drm/edid: Fix interlaced detailed timings to be frame size, not field.

cf. https://bugzilla.redhat.com/show_bug.cgi?id=533561 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 47 ++- 1 files changed, 45 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm

[PATCH 2/2] drm/edid: Fix CVT width/height decode

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9402b92..3a8b648 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[PATCH 1/2] drm/edid: Skip empty CVT codepoints

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5c9f798..9402b92 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[PATCH 4/5] drm/edid: Add new detailed block types from EDID 1.4

Signed-off-by: Adam Jackson a...@redhat.com --- include/drm/drm_edid.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 7d6c9a2..9087557 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -120,6

[PATCH 3/5] drm/edid: Add DMT modes to the pool if the monitor is GTF-capable

See also: http://bugzilla.redhat.com/539785 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 69 +-- 1 files changed, 65 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

[PATCH 2/5] drm/modes: Add drm_mode_hsync()

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_modes.c | 28 +++- include/drm/drm_crtc.h |7 --- 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 51f6772

[PATCH 1/5] drm/edid: Unify detailed block parsing between base and extension blocks

Also fix an embarassing bug in standard timing subblock parsing that would result in an infinite loop. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 163 --- 1 files changed, 61 insertions(+), 102 deletions(-) diff --git

[PATCH 5/5] drm/edid: Decode 3-byte CVT codes from EDID 1.4

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 48 include/drm/drm_edid.h |5 2 files changed, 53 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

Re: [PATCH 1/4] drm/modes: Limit fallback modes to 60Hz

On Mon, 2009-11-23 at 20:32 +0100, Rafał Miłecki wrote: diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index cea665d..dd95edf 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct

[PATCH 1/5] drm/edid: Unify detailed block parsing between base and extension blocks

Also fix an embarassing bug in standard timing subblock parsing that would result in an infinite loop. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 159 +--- 1 files changed, 61 insertions(+), 98 deletions(-) diff --git

[PATCH 2/5] drm/modes: Add drm_mode_hsync()

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_modes.c | 28 +++- include/drm/drm_crtc.h |7 --- 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 51f6772

[PATCH 5/5] drm/edid: Decode 3-byte CVT codes from EDID 1.4

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 48 include/drm/drm_edid.h |5 2 files changed, 53 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

[PATCH 4/5] drm/edid: Add new detailed block types from EDID 1.4

Signed-off-by: Adam Jackson a...@redhat.com --- include/drm/drm_edid.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 7d6c9a2..9087557 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -120,6

[PATCH 3/5] drm/edid: Add DMT modes to the pool if the monitor is GTF-capable

See also: http://bugzilla.redhat.com/539785 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 69 +-- 1 files changed, 65 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

[PATCH 4/4] drm/modes: Fall back to 1024x768 instead of 800x600

This matches the X server's fallback modes when using RANDR 1.2. See also: http://bugzilla.redhat.com/538761 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_crtc_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 1/4] drm/modes: Limit fallback modes to 60Hz

See also: http://bugzilla.redhat.com/514600 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index cea665d..dd95edf 100644 --- a/drivers/gpu

[PATCH 2/4] drm/edid: Retry EDID fetch up to four times

This matches the X server's retry logic. Note that we'll only retry if we get a DDC response but fail validation; legitimately disconnected outputs will bomb out early. See also: http://bugzilla.redhat.com/532957 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 28

[PATCH 3/4] drm/edid: Fix up partially corrupted headers

We'll still fail the block if it fails the EDID checksum though. See also: http://bugzilla.redhat.com/534120 Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 22 -- 1 files changed, 16 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 4/4] drm/edid: Fix standard timing parse for EDID = 1.2

Aspect ratio code of 0 means 1:1 before EDID 1.3. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 8ed732a..9888c20

[PATCH 2/4] drm/edid: Ignore bad standard timings.

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 3326987..dd35dc1 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers

[PATCH 1/4] drm/edid: const cleanup

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 90d76ba..3326987 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[PATCH 3/4] drm/edid: Detailed standard timing blocks have six timings, not five.

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index dd35dc1..8ed732a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm

[ANNOUNCE] libdrm 2.0.2

Disable building static library by default. Updated kernel DRM headers. http://dri.freedesktop.org/libdrm/libdrm-2.0.2.tar.gz f198bf2dfa224e1fbe6aa9c0df08cbfe libdrm-2.0.2.tar.gz 99f406e2bbc6ee1f87e32d0c815ba8b6454fed1d libdrm-2.0.2.tar.gz

Re: [r300] problems leaving the game (Quake 3 + Doom 3)

On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: Ensure all GART allocations are

Re: two X servers

On Tuesday 18 April 2006 10:05, Alex Deucher wrote: On 4/18/06, Adam Sulmicki [EMAIL PROTECTED] wrote: hello, It seems only the first copy of X gets drm enabled. Is this something to live with or this can be fixed? Currently only one instance of the X server can have the

Re: PCI Express command paths?

On Wednesday 22 March 2006 09:55, [EMAIL PROTECTED] wrote: Hey all, I was wondering, how exactly do DRI drivers interact with the PCIe bus? Pretty much the same way they interact with the PCI or AGP busses. Various resource ranges of each device are memory-mapped into the drivers' address

Re: libglx requires new symbol in loader (Was: problem with binary dri snapshots)

On Thursday 23 March 2006 11:33, Felix Kühling wrote: It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver

Re: DMA scheduling

On Thursday 16 March 2006 14:03, Felix Kühling wrote: Am Donnerstag, den 16.03.2006, 15:52 + schrieb Keith Whitwell: 1) Fairness. We can currently have situations where one 3d applications manages to dominate the GPU while a second app in another window is locked out entirely.

Re: radeon page flipping fixed BUT ...

On Sunday 26 February 2006 05:16, Benjamin Herrenschmidt wrote: Now I move the window around, the content heavily flickers, alternating between the gears and a black content. When I drop the window (stop moving it), it will either be the gears running happily ... or the black content. In that

Re: Enabling Direct Rendering at CVS tip

On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a

Re: Enabling Direct Rendering at CVS tip

On Saturday 18 February 2006 19:41, Adam Jackson wrote: On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping

Re: libdrm, memory manager

On Friday 13 January 2006 11:09, Keith Whitwell wrote: Yes, that seems to be the best approach. The only wrinkle is that if you're doing fences, it'd be nice to have a regularly updated completed fence id in the device independent sarea, which is currently full. So maybe a new shared area

Re: [Bug 1709] mesa_test_os_sse_exception_support fails inside gdb

On Thursday 15 December 2005 19:18, Sergio Monteiro Basto wrote: Hi Ajax, Please also see bug #5057 At my point of view defines IN_DRI_DRIVER and USE_EXTERNAL_DXTN_LIB=1 are very specific and only used in Mesa. So the patch on bug #5057 ( the last one ) or something similar, don't see what

Re: Tiny patch for a typedef...

On Thursday 08 December 2005 09:13, Brian Paul wrote: I've checked in the fix. It was a typo. I'm curious what platform you're compiling on that C99 isn't supported. Strictly speaking, no shipping compiler implements all of c99, gcc included. - ajax pgp3VFzPkbiL6.pgp Description: PGP

libdrm 2.0

It turns out Egbert's changes to enable mixed 32 and 64 bit client and server represent an ABI break for libdrm, since they hadn't made their way into the libdrm upstream before now. D'oh. libdrm 2.0 is out, having been resynced with all the changes from Xorg CVS (I hope). The 2.0 branch is

Re: drm_handle_t vs. unsigned long

On Tuesday 29 November 2005 10:52, Brian Paul wrote: Looks like the whole Mesa/src/mesa/drivers/dri/dri_client/ directory should go away. Is that right? Yes. - ajax pgpGtCkbkGN4s.pgp Description: PGP signature

Re: [PATCH] drmStrdup doesn't check for failed allocation

On Tuesday 29 November 2005 14:38, Tilman Sauerbeck wrote: Hi, drmStrdup() doesn't check for an allocation failure. I attached a patch that also tries to improve readability of the code. Feel free to disagree on that :) I realize the chances of drmStrdup() failing are probably low, but it

Re: drm_handle_t vs. unsigned long

On Friday 25 November 2005 17:51, Brian Paul wrote: I've been poking around in the DRM code a bit. One thing I've noticed is that the xf86drm.h file in the DRI/drm tree is a bit out of sync with the xf86drm.h file in the X.org tree. In particular, the use of unsigned long vs. drm_handle_t.

Re: Mach64 still not in kernel tree

On Wednesday 23 November 2005 07:48, Michael Frank wrote: Testing 2.6.15-rc2 in-kernel DRM, why still no mach64 support which works fine for me from snapshots/cvs? Because it's still insecure. - ajax pgpRVEStYxIcP.pgp Description: PGP signature

libdrm stable branch created

Please note that libdrm now has a 1.0 branch. If you make changes to the DRM headers like the recent via_drm.h updates, such that drivers will need them to build, make sure they are applied to the 1.0 branch as well. A rough roadmap for libdrm 1.1: - Build and install the test apps by default

Re: libdrm stable branch created

On Friday 11 November 2005 14:51, Felix Kühling wrote: Am Freitag, den 11.11.2005, 13:38 -0500 schrieb Adam Jackson: Please note that libdrm now has a 1.0 branch. If you make changes to the DRM headers like the recent via_drm.h updates, such that drivers will need them to build, make sure

Re: Questions on libdrm Future

On Friday 11 November 2005 14:22, Matt Sottek wrote: 1) Is libdrm intended to be staticly linked with a libGL, libXvMC etc. Or are you invisioning a dynamic library available on all systems? Intended to be dynamic. Any layer that needs to talk to the DRM driver (server, libGL, libXvMC...)

Re: libdrm

On Wednesday 26 October 2005 02:31, Thomas Hellström wrote: Adam Jackson wrote: Sure, if I can assume that the via header isn't going to need more changes before 7.0. Otherwise I'd prefer to wait until via has settled. Nope, there are no more changes pending. http://dri.freedesktop.org

Re: libdrm

On Tuesday 25 October 2005 03:34, Thomas Hellström wrote: Hi! Newly released Mesa 6.4 requires libdrm HEAD due to a cleanup I made to the unichrome dri driver, is there a chance to have a new patchlevel release of libdrm? There are no binary incompatibilities as far as I can see; only

Re: radeon 9600 with RV350 AQ chip works

On Sunday 23 October 2005 17:58, Popolon wrote: Popolon wrote: on some xscreensaver-4.16 mode, there are strange mapping of picture a band from picture and some reduced version at different scales. The bug was from xscreensaver as textures works perfectly on RV350_AQ with xscreensaver-4.22

Re: Changes to xf86drm.c (was Re: CVS Update: drm (branch: trunk))

On Thursday 20 October 2005 15:01, Ian Romanick wrote: Adam Jackson wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/libdrm/ Changes by: [EMAIL PROTECTED] 05/10/20 10:32:32 Log message: Remove bogus Xlib dependency. Modified files: drm/libdrm

Re: My experience with the r300 driver

On Thursday 13 October 2005 07:51, Michel Dänzer wrote: There's no question that the override is useful for developers, the question is whether it isn't more harm- than useful for users. I've often thought it'd be nice to have the VideoRAM option in the config file be clamped to the max(user

Re: Mesa 6.4 release was: ([PATCH] Fix memory corruption in ycbcr texture swap)

On Sunday 09 October 2005 12:45, Sergio Monteiro Basto wrote: Just wondering since libdrm is to be imported into X.org tree, how this will be compiled on X.org monolithic tree ? The same as in 6.8: There will be a copy of libdrm in xc/extras/. - ajax pgpVlrriRmZq9.pgp Description: PGP

Re: where is libdrm

On Monday 10 October 2005 02:41, Vladimir Dergachev wrote: Stupid question - what is the official place to get libdrm from ? I read through the webpages (both mesa3d and DRI) and searched on Google, but I dont' seem to find it. http://dri.freedesktop.org/libdrm/ - ajax pgp6JcYlxiebT.pgp

Re: Linux OpenGL ABI discussion

On Thursday 29 September 2005 04:35, Dave Airlie wrote: I have to agree with Christoph, the libGL should be a one-size-fits-all and capable of loading drivers from any vendor, I'm not sure what is so hard about this apart from the fact that neither vendor has seemed willing to help out

Re: [DEPRECATION] Fullscreen entrypoints in DRI protocol

On Sunday 11 September 2005 18:29, Keith Whitwell wrote: Yes I believe it is dead and can should be removed. Nuked, despite the lack of commit email (nggh...) I'm debating whether this is worthy of a protocol number bump. The fallback paths in the 3d driver code seem to DTRT when fullscreen

Re: problem while installing Mesa

On Wednesday 21 September 2005 06:51, Vitaliy A. Matuschenko wrote: So i've decided to install libdrm manually. I've downloaded libdrm-1.0.3 but it also didn't want to install at any way. If you'd tell me how it failed to install I'd get it fixed. - ajax pgpzwjlJLapOw.pgp Description: PGP

Re: Wondering about PC graphics that implements SGI style virtual graphics

On Monday 12 September 2005 22:24, Tim Long wrote: I am wondering if any PC level hardware implements the same features? For the ones that don't what sort of performance impact does it take switch GL threads if the pipeline has to be flushed on a context switch. I am guessing that at least

Re: drm ioctl flags cleanup

On Friday 02 September 2005 23:00, Dave Airlie wrote: With the root only/master split the flags looked ugly Any objections to a cleanup along the lines of this patch? None here. +1. - ajax pgprCu1OkanLe.pgp Description: PGP signature

Re: Xorg Mesa update.

On Tuesday 06 September 2005 16:09, Thomas Hellström wrote: Hi! What are the procedures of updating the Mesa code in Xorg for the upcoming 6.9/7.0 release? Current situation is that a change was made to the unichrome DDX which required changes to Mesa, which went into Mesa CVS but

Re: _glthread_TSD problem [was: display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem]

On Tuesday 30 August 2005 11:31, Ian Romanick wrote: Daniel Stone wrote: On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: The only way this could happen is if *both* PTHREADS and XTHREADS are defined. I suspect the Xthreads.h problem was always there, but it was never hit because

libdrm [was Re: GRONK???]

On Thursday 18 August 2005 16:38, Alan Grimes wrote: [notice the path names and nearly identical files] So what's the story here? The copy in libdrm is canonical. The versions in xc and in Mesa are clones. They all go away in about five hours when I switch the DRI build to requiring

Re: Xegl on old hardware?

On Sunday 14 August 2005 16:59, Roland Scheidegger wrote: Those are quite stiff requirements though. None of the old chips support all of that fully. Especially ARB_texture_env_combine (or even the EXT variant) could be tricky. I'm not sure what parts of it Xegl really needs, but on something

Re: Xegl on old hardware?

On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture

Re: Xegl on old hardware?

On Sunday 14 August 2005 14:15, Philipp Klaus Krause wrote: Adam Jackson schrieb: NV_texture_rectangle This shouldn't be really necessary if one is willing to waste some texture memory. In some cases, quite a lot of memory. A 513x513 texture wastes between 1.5 and 3M of memory depending

Re: AAAARRRGH!!!

On Thursday 28 July 2005 01:09, Alan Grimes wrote: I spent all day dl'ing and installing: # This is a pre-release version of the The X.Org Foundation X11. X Window System Version 6.8.99.1 # And my reward for spending $40 on a card that appeared to be supported by Linux? Why you

Re: Build DRI exactly like X needs

On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? Huh? How is 'make

Re: Build DRI exactly like X needs

On Tuesday 12 July 2005 11:17, Jon Smirl wrote: On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote: On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set

libdrm 1.0

http://people.freedesktop.org/~ajax/libdrm/libdrm-1.0.0.gz I'll soon be switching Mesa to require this to build the DRI drivers and the DRI-capable libGL. This means you need pkg-config. This also means we can get rid of the copy of the drm source in drivers/dri/dri_client, and after

Re: Current DRM CVS ?

On Monday 11 July 2005 11:01, Vladimir Dergachev wrote: Hi all, Would anyone know which DRM CVS tree I should submit patches against ? I wanted to give a try at making a patch with R300 DRM driver changes as the source has mostly stabilized. I didn't know there was more than one.

Re: Current DRM CVS ?

On Monday 11 July 2005 13:29, Vladimir Dergachev wrote: On Mon, 11 Jul 2005, Adam Jackson wrote: I didn't know there was more than one. /cvs/dri co drm Thank you ! What about code that Jon is working on ? Is it in ? If his changes aren't in CVS then I don't know where they are. Jon

Re: DRI vs DRM

On Sunday 03 July 2005 12:31, Jon Smirl wrote: On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding

Re: DRI vs DRM

On Sunday 03 July 2005 18:40, Brian Paul wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. I'm still not

Re: DRI vs DRM

On Sunday 03 July 2005 00:04, Jon Smirl wrote: Is this table right? DRMDRI ffb ffb i810i830 i830i830 i915i915 With the caveat that i830 is old and deprecated. There are three DRI drivers with no DRM. What is up with these? gamma s3v trident

Re: [R300] drm driver: merge upstream, security, etc

On Sunday 26 June 2005 21:51, Eric Anholt wrote: Heh. One of the suggestions of BSD style is that when 80 columns becomes too little, you probably need another function. In the diff I'm currently testing for cleaning up map handling (which net removes 200 lines), I've removed that if

Re: Removing the root priv requirement from DRM

On Monday 20 June 2005 00:03, Jon Smirl wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: Obviously determining which sets of registers can be mapped through the drm is a card-by-card problem. Different cards have different register maps, by definition. But the DRI drivers work

Re: Removing the root priv requirement from DRM

On Saturday 18 June 2005 11:20, Jon Smirl wrote: Access to the registers is something that should require root priv right? Once I can get to the registers I can program them to contol the DMA hardware and then muck with the kernel's memory and escalate my priveldge level. EGL avoids this

Re: radeon DST_LINE

On Saturday 18 June 2005 13:38, Jerome Glisse wrote: On 6/18/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Jerome Glisse wrote: DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) From the name, I guess that they initiate line drawing in 2d engine.

  1   2   3   >