th CHANGE=1 set in the event, to allow for it.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Adam Jackson
- ajax
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use o
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
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 1
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 da
* 8) + (7 - j);
> - if (m > num_est3_modes)
> + if (m >= num_est3_modes)
> break;
> if (est[i] & (1 << j)) {
> mode = drm_find_dmt(connector->dev,
Revi
... and not the global list.
Signed-off-by: Adam Jackson
---
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
+++ b/drivers
Signed-off-by: Adam Jackson
---
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/drm_modes.c
Claims 1280x1024 preferred, physically 1600x1200
cf. http://bugzilla.redhat.com/530399
Signed-off-by: Adam Jackson
---
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 7e608f4
Height in frame size, not field size, and trailed with an 'i'. Matches
the X server behaviour.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
drivers/gpu/drm/drm_modes.c | 21 -
2 files changed, 14 insertions(+), 11 deletions(-)
di
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
---
drivers/gpu/drm
ower pixel clock and therefore possibly better image
quality on analog links.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 119 +--
drivers/gpu/drm/drm_modes.c | 81 +++--
include/drm/drm_crtc.h |4 ++
3 fil
ned-off-by: Adam Jackson
---
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
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
---
drivers/gpu/drm/drm_edid.c | 47 ---
1 files changed, 43 insertions(+), 4 deletions(-)
diff --
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
---
drivers/gpu/drm/drm_edid.c | 101 ++--
1 files changed, 78 insertions(+), 23 dele
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
---
drivers/gpu/drm/drm_edid.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
Signed-off-by: Adam Jackson
---
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/gpu/drm
Signed-off-by: Adam Jackson
---
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/drm_edid.h
Also, document what the spec says to do.
Signed-off-by: Adam Jackson
---
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
--- a/drivers/gpu
Signed-off-by: Adam Jackson
---
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/drm/drm_edid.c
Signed-off-by: Adam Jackson
---
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/drm_edid.c
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
---
drivers/gpu/drm/drm_edid.c |
Signed-off-by: Adam Jackson
---
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/drm_edid.c
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 tol
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
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 k
On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote:
> > # sed -i 's/\.*/& 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 component,
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 remot
cf. https://bugzilla.redhat.com/show_bug.cgi?id=533561
Signed-off-by: Adam Jackson
---
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/drm_edid.c
index
Signed-off-by: Adam Jackson
---
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/drm_edid.c
Signed-off-by: Adam Jackson
---
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/drm_edid.c
Signed-off-by: Adam Jackson
---
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 cc8e696..30af8f3
Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 163 ---
1 files changed, 61 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm
Signed-off-by: Adam Jackson
---
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..6d81a02 100644
See also: http://bugzilla.redhat.com/539785
Signed-off-by: Adam Jackson
---
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 999571a
Signed-off-by: Adam Jackson
---
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 +120,9 @@ struct
Signed-off-by: Adam Jackson
---
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 ee84ffe..0f00fa0
Signed-off-by: Adam Jackson
---
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 +120,9 @@ struct
See also: http://bugzilla.redhat.com/539785
Signed-off-by: Adam Jackson
---
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 e655916
Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 159 +---
1 files changed, 61 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm
Signed-off-by: Adam Jackson
---
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..6d81a02 100644
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 drm
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
---
drivers/gpu/drm/drm_edid.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edi
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
---
drivers/gpu/drm/drm_edi
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
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/dr
See also: http://bugzilla.redhat.com/514600
Signed-off-by: Adam Jackson
---
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/drm/drm_edid.c
Signed-off-by: Adam Jackson
---
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/drm_edid.c
@@ -847,8
Signed-off-by: Adam Jackson
---
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/drm_edid.c
@@ -109,7
Signed-off-by: Adam Jackson
---
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/gpu/drm
Aspect ratio code of 0 means 1:1 before EDID 1.3.
Signed-off-by: Adam Jackson
---
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 100644
--- a
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
http://dri.freedesktop.org/libdrm/libdrm-2.0.2.tar.bz2
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
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
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 Xserv
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
s
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 enti
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. I
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 muc
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
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 a
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
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 sig
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 a
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
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
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
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
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...) sh
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
> &g
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
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
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 c
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 xscreensav
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 depe
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
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
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 signa
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 infr
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
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 s
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
The OpenFullScreen and CloseFullScreen requests in the DRI protocol are
deprecated in the client for some time now (shipped disabled in Xorg 6.7 and
later, and in XFree86 4.5; initially disabled in the old DRI tree about 21
months ago). As far as I know these functions are intended to be
drive
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 app
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
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 b
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
libd
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 somethi
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 betwee
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
ARB_
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?
W
On Wednesday 27 July 2005 18:05, Patrick McFarland wrote:
> So why can Doom 3 use R200 pixel shaders, and DRI can't?
Doom3's r200 shader pipeline gives different (read: worse) output than their
arb shader pipeline. They have the liberty of knowing what visual quality
they can sacrifice. The dr
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 installin
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 instea
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 linux
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
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.
/c
On Sunday 03 July 2005 19:21, Matthew Tippett wrote:
> There is a standard name the library.
>
> See Section 8.2 - Packaging/Libraries of the OpenGL|ES spec on Khronos' web
> page.
>
> It should be libGLES_xx.so where xx is CM or CL.
Those correspond to libraries that implement OpenGL|ES. We're n
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
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
> > serv
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
>
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 stat
1 - 100 of 238 matches
Mail list logo
