> On Fri, 04 Dec 2009 17:22:22 +0100
> Tobias Jakobi wrote:
>
>> Hi there,
>>
>> with a fresh git master from the libdrm repo compilation fails:
>>
>> make[3]: Entering directory
>> `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest'
>> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
On Fri, 04 Dec 2009 17:22:22 +0100
Tobias Jakobi wrote:
> Hi there,
>
> with a fresh git master from the libdrm repo compilation fails:
>
> make[3]: Entering directory
> `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest'
> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..
On Mon, 2009-11-23 at 12:13 -0500, Kristian Høgsberg wrote:
> On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen wrote:
> > On Mon, 23 Nov 2009 17:12:07 +0100
> > Michel Dänzer wrote:
> >
> >> On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote:
> >> > The headers in include/drm will be inst
On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen wrote:
> On Mon, 23 Nov 2009 17:12:07 +0100
> Michel Dänzer wrote:
>
>> On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote:
>> > The headers in include/drm will be installed and libdrm_radeon
>> > should be updated to use those headers inst
On Tue, Jul 21, 2009 at 12:21 PM, Julien Cristau wrote:
> On Mon, Jul 20, 2009 at 19:17:01 +0300, Pauli Nieminen wrote:
>
> > >From b7e77b71d1f2d8ff6741e534911e09f10e3f3d4e Mon Sep 17 00:00:00 2001
> > From: Pauli Nieminen
> > Date: Mon, 20 Jul 2009 14:39:57 +0300
> > Subject: [PATCH 01/15] libdr
On Mon, Jul 20, 2009 at 19:17:01 +0300, Pauli Nieminen wrote:
> >From b7e77b71d1f2d8ff6741e534911e09f10e3f3d4e Mon Sep 17 00:00:00 2001
> From: Pauli Nieminen
> Date: Mon, 20 Jul 2009 14:39:57 +0300
> Subject: [PATCH 01/15] libdrm: Add function attribute for debug
> functions to let gcc check par
And then follows fixes for all tests.
From 1cd7a914be3fc5ee8aabdd2297710f5c781b555f Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 21:36:57 +0300
Subject: [PATCH 1/4] libdrm/tests: Fix compiler warnings in dristat.c.
---
tests/dristat.c | 12
1 files changed,
>From 36aef4bf07154ef6d206f15ff1c036a7f8e368a9 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 18:33:03 +0300
Subject: [PATCH 14/15] libdrm/radeon: Add config.h include to enable
POSIX extensions for strdup call.
---
libdrm/radeon/radeon_track.c |3 +++
1 files changed,
>From 9c0cd0ba5bb5966498cad2c5a8c69ec24c4c8e34 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 18:40:49 +0300
Subject: [PATCH 15/15] Fix signed/unsigned comparison warning
---
libdrm/radeon/radeon_cs_gem.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-
>From 0c8b7939fc95084d77063eb8de78b0724d3d4058 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 17:00:45 +0300
Subject: [PATCH 11/15] libdrm: Make pci id numbers unsigned for sscanf.
---
libdrm/xf86drmMode.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff -
>From dea4cebdb49556ab06930bd5a4d303ce1c0b85c7 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 17:19:55 +0300
Subject: [PATCH 12/15] intel: Move debug output after setting the value.
---
libdrm/intel/intel_bufmgr_fake.c |4 ++--
1 files changed, 2 insertions(+), 2 deleti
>From 9043299720ef5ecac1fe575b0bbda19b81720dd8 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 18:00:43 +0300
Subject: [PATCH 13/15] libdrm/radeon: Remove unussed variables and
make printf happy with explicity void* cast from struct radeon_bo*.
---
libdrm/radeon/radeon_bo.h
>From 6ad9d2f1495df9bbdecbe4e7676da75d48ba3719 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 16:55:21 +0300
Subject: [PATCH 10/15] libdrm: Make drmAllocCpy use only single memcpy
call instead of calling memcpy in loop.
---
libdrm/xf86drmMode.c |4 +---
1 files changed,
>From 69cad004e5355e4adcee753de4da91c98949d3df Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 16:50:20 +0300
Subject: [PATCH 09/15] libdrm: Make drmAllocCpy static.
---
libdrm/xf86drmMode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libdrm/xf8
>From 7fcfbf715644d2268236b8a19d1f2f83c952d72b Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 16:25:59 +0300
Subject: [PATCH 07/15] libdrm: Fix random number generator to use unsigned seed.
This fixes wanring about unsigned/signed comparision.
Also make it easier to compile
>From 10a9bf298be4695242bcdb63bcfad720e03bf040 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 16:31:54 +0300
Subject: [PATCH 08/15] libdrm: Make gcc to understand that pointers
are realy pointers.
---
libdrm/xf86drmSL.c |6 +++---
1 files changed, 3 insertions(+), 3 del
>From 78bfacedfb3b81968b2171a942101d323b1782cb Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 15:48:48 +0300
Subject: [PATCH 06/15] libdrm: Fix loop index variable type to match
the type of count
---
libdrm/xf86drm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletion
>From 3eb4a3493f13c48bee1b2453f5ecead0ba498c51 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 15:45:41 +0300
Subject: [PATCH 05/15] libdrm: Fix drmOpenDevice to take dev_t type as
parameter.
This fixes signed/unsigned comparission between st.st_dev and dev.
---
libdrm/xf86d
>From f20a4ea99e79cd0155a56112c272c228dac463f8 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 15:34:13 +0300
Subject: [PATCH 04/15] libdrm: Fix unsigned/signed coparision of -1 value
gid_t is unsigned in gnu libc this makes it impossible to check if
group id is set to negati
>From 7a737a95e3c9bdfdf18b648678f41911259adceb Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 14:49:38 +0300
Subject: [PATCH 03/15] libdrm: Add function declaration to header for
drmSetDebugMsgFunction.
---
libdrm/xf86drm.h |1 +
1 files changed, 1 insertions(+), 0 dele
>From 7b9950e3e3e4d9a456addcdbbcdefaf4cc44a5c0 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 14:46:06 +0300
Subject: [PATCH 02/15] libdrm: Add __attribute__ macro to hide gcc
specific function attributes for compiler not supporting them.
---
libdrm/xf86drm.c |8 +++
>From b7e77b71d1f2d8ff6741e534911e09f10e3f3d4e Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Mon, 20 Jul 2009 14:39:57 +0300
Subject: [PATCH 01/15] libdrm: Add function attribute for debug
functions to let gcc check parameter correctness.
---
libdrm/xf86drm.c |5 -
1 files changed,
Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
> On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
> >> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]>
wrote:
> >> > kernel openSUSE 10.3 2.6.2
On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
>> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
>> > kernel openSUSE 10.3 2.6.22.19-0.1-default
>> >
>> > /opt/drm> ./configure --prefix=/usr
Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
> > kernel openSUSE 10.3 2.6.22.19-0.1-default
> >
> > /opt/drm> ./configure --prefix=/usr
> >
> > [-]
> >
> > checking whether the g++ linker (/usr/i586-suse-linux/bin/l
On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
> kernel openSUSE 10.3 2.6.22.19-0.1-default
>
> /opt/drm> ./configure --prefix=/usr
>
> [-]
>
> checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared
> libraries... yes
> checking dynamic linker chara
Adam Jackson wrote:
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
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
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
- functionality required by libdrm is made available as
device-independent ioctls
When I was originally spec'ing a bunch of this stuff out, it was my
intention to add a couple device-independent ioct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
> - functionality required by libdrm is made available as
> device-independent ioctls
When I was originally spec'ing a bunch of this stuff out, it was my
intention to add a couple device-independent ioctls to roughly match
N
Keith Whitwell wrote:
Dave,
I'm starting to put some flesh on the bones of this thing, and I'm
wondering about some aspects of situating it in libdrm.
Specifically, things like initialization and dealing with
hardware-specific quirks. As it stands, there's no way I know of to put
hardware-
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
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 they are applied to the 1.0 branch as well.
>
> A roug
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.or
Adam Jackson wrote:
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 a
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
There are still copies of structs/defines in xf86drm.h that are
duplicates of ones in drm.h with with underscore appended. This is
confusing since the first thing xf86drm.h does is include drm.h. I
would like to remove the duplicates in xf86drm.h. This is a great way
to cause bugs if people don't
On Tue, 12 Jul 2005, Adam Jackson wrote:
> 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 so
Roland Mainz wrote:
Adam Jackson wrote:
I have a seventh option for you. Feel free to flame me if it sounds
stupid ...
- Option 7: Run the GLX server as a separate process forked by the
Xserver. This way you get rid of the problem with the same library
linked into the same process multiple times.
P
--- Roland Mainz <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > > glxProxy effectively would put the GL rendering in its own thread.
> And
> > > nothing necessarily prevents us from creating a new thread for
> in-server DRI.
> > >
> > > If the rendering is properly encapsulated, then making i
Jon Smirl wrote:
> > glxProxy effectively would put the GL rendering in its own thread. And
> > nothing necessarily prevents us from creating a new thread for in-server
> > DRI.
> >
> > If the rendering is properly encapsulated, then making it multicore-friendly
> > is cheap and easy; if libglx i
On Thursday 30 December 2004 14:20, Adam Jackson wrote:
> - Option 4: Link libdrm into the DRI drivers dynamically instead.
> Pros: Doesn't change libGL/driver ABI.
> Cons: Requires server control over runtime link path, sketchy. DDX also
> calls into libdrm, so DRI driver would need to be loaded
Felix Kühling wrote:
>
> Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> > The goal: Load DRI drivers from the server's libglx, rather than the
> > software-based libGLcore.
> >
> > Currently there are four server-side modules: dri, drm, glx, and GLcore.
> > There are also three client-side
Adam Jackson wrote:
> > I have a seventh option for you. Feel free to flame me if it sounds
> > stupid ...
> >
> > - Option 7: Run the GLX server as a separate process forked by the
> > Xserver. This way you get rid of the problem with the same library
> > linked into the same process multiple time
On Fri, 31 Dec 2004 14:16:57 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> glxProxy effectively would put the GL rendering in its own thread. And
> nothing necessarily prevents us from creating a new thread for in-server DRI.
>
> If the rendering is properly encapsulated, then making it multic
On Friday 31 December 2004 13:41, Roland Mainz wrote:
> Felix Kühling wrote:
> > - Option 7: Run the GLX server as a separate process forked by the
> > Xserver. This way you get rid of the problem with the same library
> > linked into the same process multiple times.
> >
> > Pros: No existing ABIs
On Friday 31 December 2004 06:04, Michel DÃnzer wrote:
> On Thu, 2004-12-30 at 14:20 -0500, Adam Jackson wrote:
> > - Option 3: Move libdrm from the DRI drivers into libGL (dlopen linkage)
> > Pros: Minimal server impact. New libdrm could be shared between client
> > and server. With a little cle
On Fri, 31 Dec 2004 13:17:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Friday 31 December 2004 09:56, Felix Kühling wrote:
> > I have a seventh option for you. Feel free to flame me if it sounds
> > stupid ...
> >
> > - Option 7: Run the GLX server as a separate process forked by the
> >
On Friday 31 December 2004 09:56, Felix KÃhling wrote:
> I have a seventh option for you. Feel free to flame me if it sounds
> stupid ...
>
> - Option 7: Run the GLX server as a separate process forked by the
> Xserver. This way you get rid of the problem with the same library
> linked into the sam
Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> The goal: Load DRI drivers from the server's libglx, rather than the
> software-based libGLcore.
>
> Currently there are four server-side modules: dri, drm, glx, and GLcore.
> There are also three client-side pieces: libGL, *_dri.so, and (u
Dave Airlie wrote:
There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
on both sides, modulo wrapping some things like malloc to u
Adam Jackson wrote:
On Thursday 30 December 2004 21:44, Jon Smirl wrote:
I've been out of the DRI loop for a while since all I do is help feed
and change two crying babies, but we also need think about the GL
standalone case. libdrm is linked into the dri.so's so that they can
be u
On Thu, 30 Dec 2004 22:03:56 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > If we proceed down the X on
> > GL path this problem would go away since X would stop using libdrm.
>
> No, it won't. For X on GL, the server still loads a DRI driver. It's just
> already loaded early during eglCreat
On Thursday 30 December 2004 21:44, Jon Smirl wrote:
> I've been out of the DRI loop for a while since all I do is help feed
> and change two crying babies, but we also need think about the GL
> standalone case. libdrm is linked into the dri.so's so that they can
> be used standalone. Wouldn't anot
I've been out of the DRI loop for a while since all I do is help feed
and change two crying babies, but we also need think about the GL
standalone case. libdrm is linked into the dri.so's so that they can
be used standalone. Wouldn't another solution be to just fix the
DRI.so's to not export the li
> There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
> 'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
> imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
> on both sides, modulo wrapping some things like malloc to use either
Personally I lean towards 2 or 3. The nice bit about making libdrm a real
DSO
is that it removes the need to have the libdrm source around when building
the -dri targets in Mesa, or when building the server; you just need to have
built it already. You have to handle libdrm versioning anyway. We
57 matches
Mail list logo
