On 1 February 2015 at 01:03, CodeSwim OS Development
wrote:
> I'm trying to build libdrm and have an issue when I gmake after
> configuring. Steps to reproduce:
>
> # uname -a
> SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc
>
Where can one get a copy of OmniOS ? Free
I'm trying to build libdrm and have an issue when I gmake after
configuring. Steps to reproduce:
# uname -a
SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc
# cd libdrm-2.4.59
# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is
_* by libEGL.
So I suggest to include it in libdrm for wayland platform.
Eric:
Do you agree to the proposal? If yes, I can follow other changes in mesa and
vaapi.
Thanks
0001-add-wayland-drm-protocol-module.patch
Description: 0001-add-wayland-drm-protocol-module.
x driver to probed drivers in tests
vbltest: Check error codes returned from libdrm
modetest: Check error message from pageflip ioctl
modetest: Print extra info if we fail to create a framebuffer
modetest: Call dirty fb on modeset
Jesse Barnes (1):
modetest: use 2
In order to satisfy a dependency upon a new kernel parameter for mesa,
it is time for a new release of libdrm. The usual bug fixes are a nice
bonus.
-Chris
Ben Skeggs (3):
nouveau: nvc0 drm has no concept of "notifier block"
nouveau: split pushbuf macros specific to nv04-nv5
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
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: Benjamin Herrenschmidt
---
xf86drm.c | 30 +--
Hi,
there is a slight problem when compiling libdrm-2.4.20 with separate source
and object dirs. When compiling "libkms/linux.c" the header file "xf86drm.h"
will not be found since headers are only searched for in top_builddir but not
in top_sourcedir. The attached patch is
):
intel: Propagate some more error returns
intel: Repeat execbuffer if interrupted by signal
Eric Anholt (3):
intel: Only align Y-tiling pitch to the Y tile width.
intel: Align untiled buffer pitch to 64B.
intel: Install the header file in the libdrm/ directory
: gcc -O3 -msse2 -march=pentium4 -mtune=pentium4 -fPIC -z
combreloc -z lazyload -Wl,-M -Wl,/usr/lib/ld/map.pagealign -Wl,-M
-Wl,/usr/lib/ld/map.noexdata -o .libs/dristat dristat.o ../.libs/libdrm.so
-R/tmp/libdrm/lib
Undefined first referenced
symbol
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Mart Raudsepp changed:
What|Removed |Added
CC||[email protected]
--- Comment #4 from M
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Chi-Thanh Christopher Nguyen changed:
What|Removed |Added
CC||[email protected],
Hi,
I was trying to compile latest mesa master GIT:
commit 2a3accb
r300g: fix glean occlusion query test
Unfortunately, the build breaks (see below "investigations").
I suspect the cause is I have here Debian's libdrm-2.4.18 installed.
"radeon: add square-tiling flag&quo
On Fri, 26 Feb 2010 19:07:24 +0100, Julien Cristau wrote:
> Avoids conflicts with kernel headers.
>
> Signed-off-by: Julien Cristau
Applied this series, plus moving the intel file. Thanks!
pgp9aozTfnYtg.pgp
Description: PGP signature
--
Le 10/03/2010 13:13, Julien Cristau a écrit :
> any comments on this?
Reviewed-by: Rémi Cardona
The whole series looks nice. Just got me wondering why libdrm_intel
installs its only header in ${includedir} and not in /drm or /libdrm...
Cheers,
R
On Wed, 10 Mar 2010 18:20:42 +0200, Pauli Nieminen wrote:
> intel_atomic.h includes very usefull atomic operations for
> lock free parrallel access of variables. Moving these to
> core libdrm for code sharing with radeon.
s/xf86/libdrm/ but other than that, cool.
pgp9PLwqTrOT9.pgp
De
On Fri, Mar 12, 2010 at 4:50 AM, Pauli Nieminen wrote:
> Cleanup make system so that all noninstalled headers are put
> to noinst_HEADERS. This quarentees that header will be present
> in tar ball but not installed with make install.
>
> CC: [email protected]
> Signed-off-by: Pauli Nie
Cleanup make system so that all noninstalled headers are put
to noinst_HEADERS. This quarentees that header will be present
in tar ball but not installed with make install.
CC: [email protected]
Signed-off-by: Pauli Nieminen
---
Makefile.am |6 +++---
intel/Makefile.am
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
V2: Fix remaining references to intel_atomic.h and libdrm-intel.
V3: Remove useless wrapper header intel_atomic.h
Signed-off-by: Pauli
> On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen wrote:
> > intel_atomic.h includes very usefull atomic operations for
> > lock free parrallel access of variables. Moving these to
> > core libdrm for code sharing with radeon.
> >
> > Signed-off-by: Pauli N
On Thu, 11 Mar 2010 00:21:13 +0200, Pauli Nieminen wrote:
> On Wed, Mar 10, 2010 at 10:44 PM, Julien Cristau wrote:
> > Should this really get installed? I'm not sure this should be public
> > libdrm interface.
> >
> > Cheers,
> > Julien
> >
>
On Wed, Mar 10, 2010 at 10:44 PM, Julien Cristau wrote:
>> On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen wrote:
>> > intel_atomic.h includes very usefull atomic operations for
>> > lock free parrallel access of variables. Moving these to
>> > core li
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
V2: Fix remaining references to intel_atomic.h and libdrm-intel.
Signed-off-by: Pauli Nieminen
---
Makefile.am |2
On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen wrote:
> intel_atomic.h includes very usefull atomic operations for
> lock free parrallel access of variables. Moving these to
> core libdrm for code sharing with radeon.
>
> Signed-off-by: Pauli Nieminen
> ---
> Makefi
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
Signed-off-by: Pauli Nieminen
---
Makefile.am |2 +-
configure.ac |2 +-
intel/intel_atomic.h | 56
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Bartosz Brachaczek changed:
What|Removed |Added
Keywords||patch
--
Configure bugmail: htt
http://bugs.freedesktop.org/show_bug.cgi?id=26994
--- Comment #2 from Bartosz Brachaczek 2010-03-10
05:33:29 PST ---
Created an attachment (id=33920)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33920)
correct patch for this issue
--
Configure bugmail: http://bugs.freedesktop.org/
URL||http://www.openchrome.org/tr
||ac/ticket/357
Component|DRM/Via |libdrm
OS/Version|Linux (All) |All
Summary|Openchrome r839 does not|xf86-video
On Fri, Feb 26, 2010 at 19:07:24 +0100, Julien Cristau wrote:
> Avoids conflicts with kernel headers.
>
> Signed-off-by: Julien Cristau
> ---
> This was suggested by Eric so distros can let the kernel install drm
> headers, but provide updated headers from libdrm so we can b
On Wednesday 03 of March 2010, Eric Anholt wrote:
> New version for new Intel API that we're about to start using in Mesa.
Unresolved symbols found in: /home/users/arekm/tmp/libdrm-2.4.19-root-
arekm/usr/lib64/libkms.so.1.0.0
drmIoctl
drmCommandWriteRead
drmComm
On Wednesday 03 of March 2010, Arkadiusz Miskiewicz wrote:
> On Wednesday 03 of March 2010, Eric Anholt wrote:
> > New version for new Intel API that we're about to start using in Mesa.
>
> Unresolved symbols found in: /home/users/arekm/tmp/libdrm-2.4.19-root-
> arekm/us
ard version number
Jesse Barnes (1):
libdrm/intel: execbuf2 support
Maarten Maathuis (1):
nouveau: make sure initial kalloc for user bo ends up in the right place
Marcin Kościelnicki (6):
Add config.h macro HAVE_NOUVEAU
libkms/intel: Throw out unused intel_bo fields.
On Fri, Feb 26, 2010 at 13:38:59 -0500, Kristian Høgsberg wrote:
> On Fri, Feb 26, 2010 at 1:07 PM, Julien Cristau wrote:
> > nouveau_drmif.h includes xf86drm.h.
>
> If it's a source level dependency it should be a regular Requires: in
> the .pc. Requires.private: is only for private libraries
2010/2/26 Julien Cristau :
> On Fri, Feb 26, 2010 at 13:38:59 -0500, Kristian Høgsberg wrote:
>
>> On Fri, Feb 26, 2010 at 1:07 PM, Julien Cristau wrote:
>> > nouveau_drmif.h includes xf86drm.h.
>>
>> If it's a source level dependency it should be a regular Requires: in
>> the .pc. Requires.priva
veau.pc.in
> @@ -8,3 +8,4 @@ Description: Userspace interface to nouveau kernel DRM
> services
> Version: 0.6
> Libs: -L${libdir} -ldrm_nouveau
> Cflags: -I${includedir} -I${includedir}/drm -I${include
/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -8,3 +8,4 @@ Description: Userspace interface to nouveau kernel DRM services
Version: 0.6
Libs: -L${libdir} -ldrm_nouveau
Cflags: -I${includedir} -I${includedir}/drm -I${includedir}/nouveau
+Requires.private: libdrm
--
1.6.6.1
Avoids conflicts with kernel headers.
Signed-off-by: Julien Cristau
---
This was suggested by Eric so distros can let the kernel install drm
headers, but provide updated headers from libdrm so we can build new
drivers regardless of the kernel version.
include/drm/Makefile.am |2
http://bugs.freedesktop.org/show_bug.cgi?id=26708
Marcin Slusarz changed:
What|Removed |Added
Attachment #33527|text/x-log |text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=26708
Marcin Slusarz changed:
What|Removed |Added
Attachment #33529|text/x-log |text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=26708
--- Comment #5 from Sundtek 2010-02-24 08:43:55 PST ---
Created an attachment (id=33529)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33529)
valgrind of the application without resizing it
--
Configure bugmail: http://bugs.freedeskt
http://bugs.freedesktop.org/show_bug.cgi?id=26708
--- Comment #4 from Sundtek 2010-02-24 08:29:17 PST ---
Created an attachment (id=33528)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33528)
test.c
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
http://bugs.freedesktop.org/show_bug.cgi?id=26708
--- Comment #3 from Sundtek 2010-02-24 08:28:48 PST ---
Created an attachment (id=33527)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33527)
extensive valgrind logfile
The memory leak only happens during the application runtime, when
http://bugs.freedesktop.org/show_bug.cgi?id=26708
--- Comment #2 from Sundtek 2010-02-24 06:44:45 PST ---
We also experience the same bug with Intel, our application works well with
NVidia though.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
http://bugs.freedesktop.org/show_bug.cgi?id=26708
--- Comment #1 from Lars S 2010-02-23 23:51:32 PST ---
Created an attachment (id=33521)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33521)
full valgrind output of a test run
For completeness I have attached a more complete Valgrind o
/src/radeon_probe.c
+++ b/src/radeon_probe.c
@@ -99,7 +99,13 @@ static Bool radeon_kernel_mode_enabled(ScrnInfoPtr pScrn,
struct pci_device *pci
}
busIdString = DRICreatePCIBusID(pci_dev);
+
+#ifdef HAVE_DRMCHECKMODULEANDMODESETTINGSUPPORTED
+ret = drmCheckModuleAndModesettingSupport
++
4 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index ef7700f..e279885 100644
--- a/configure.ac
+++ b/configure.ac
@@ -19,7 +19,7 @@
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
AC_PREREQ(2.60)
-AC_INIT([libdrm
http://bugs.freedesktop.org/show_bug.cgi?id=26708
Summary: libdrm-intel leaks memory when resizing window
Product: DRI
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority
libdrm-2.4.18.tar.bz2 from http://dri.freedesktop.org/libdrm is missing
file libkms/internal.h:
in git it exist.
libtool: compile:
/home/stephan/projects/openelec/build.OpenELEC-intel.i386.devel/toolchain/bin/i686-openelec-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -I.. -Wall -Wextra -Wsign-compare
libdrm-2.4.18.tar.bz2 from http://dri.freedesktop.org/libdrm is missing
file libkms/internal.h:
in git it exist.
libtool: compile:
/home/stephan/projects/openelec/build.OpenELEC-intel.i386.devel/toolchain/bin/i686-openelec-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -I.. -Wall -Wextra -Wsign-compare
Regards.
- Original Message -
From: "Kristian Høgsberg"
To: "Peter Hanzel"
Cc:
Sent: Tuesday, February 09, 2010 3:14 PM
Subject: Re: vmwgfx + VMWare 7.0 -> libdrm modetest.c
On Tue, Feb 9, 2010 at 8:05 AM, Peter Hanzel
wrote:
Hello.
I have a question abou
On Tue, Feb 9, 2010 at 8:05 AM, Peter Hanzel wrote:
> Hello.
>
> I have a question about libdrm/libkms and test/modetest/modetest.c.
> I am now working with vmwgfx + VMWare 7.0, where vmwgfx had correctly
> initialized framebuffer and also now using fbcon.
> Now I want to test
On 9 feb 2010, at 13.05, Peter Hanzel wrote:
> Hello.
>
> I have a question about libdrm/libkms and test/modetest/modetest.c.
> I am now working with vmwgfx + VMWare 7.0, where vmwgfx had correctly
> initialized framebuffer and also now using fbcon.
> Now I want to test it woth
Hello.
I have a question about libdrm/libkms and test/modetest/modetest.c.
I am now working with vmwgfx + VMWare 7.0, where vmwgfx had correctly
initialized framebuffer and also now using fbcon.
Now I want to test it woth modetest.c
This program is only for intel so i recoded it to use libkms
On Thu, 2010-02-04 at 19:48 -0500, Kristian Høgsberg wrote:
> On Thu, Feb 4, 2010 at 2:23 PM, Matthew W. S. Bell
> > Additionally, the function libdrm/xf86drmSL.c:drmSLLookupNeighbors()
> > appears to be completely broken as it computes on the variable update
> > which is unco
32 bit
> here), as I don't understand the issues here; it would be nice if no
> warnings were emitted if it is safe.
Thanks for the patch, I just applied it.
> Additionally, the function libdrm/xf86drmSL.c:drmSLLookupNeighbors()
> appears to be completely broken as it compu
nings were emitted if it is safe.
Additionally, the function libdrm/xf86drmSL.c:drmSLLookupNeighbors()
appears to be completely broken as it computes on the variable update
which is unconditionally undefined.
Matthew W.S. Bell
From 605963e604b8d7e3aa5ffa9ed87738bf1a0f0b7d Mon Sep 17 00:00:00 2001
the
> business
> > Choose flexible plans and management services without long-term contracts
> > Personal 24x7 support from experience hosting pros just a phone call
> away.
> > http://p.sf.net/sfu/theplanet-com
> > --
> > _
On Tue, Feb 2, 2010 at 4:24 AM, Pauli Nieminen wrote:
> If there is section size mismatch reusing the section object
> makes section start fail.
> Reseting the object before doing error checking prevents the
> possible flood of errors.
>
That can't be right. did you read what your patch does?
of
If there is section size mismatch reusing the section object
makes section start fail.
Reseting the object before doing error checking prevents the
possible flood of errors.
Signed-off-by: Pauli Nieminen
---
radeon/radeon_cs_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Some drivers use DRI2 protocol but implement their own kernel rendering
mananger. For these drivers, libdrm becomes useless.
The only inconvenient right now to put libdrm optional to X server is
concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
symbols from libdrm. So I
On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
>
> The only inconvenient right now to put libdrm optional to X server is
On Tue, Jan 19, 2010 at 2:18 PM, Tiago Vignatti
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
Yeah, I think this could be ok. The drm usage in DRI2 does stick out
a bit, and should probably be pus
http://bugs.freedesktop.org/show_bug.cgi?id=25997
Summary: libdrm builds programs only used during `make check` in
`make all`
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
GDB debugger and doing back-traces of the Compiz
process.
3 out of 4 of these crashes in general was traced back to libdrm,
hence why I'm sending you this email now. I have attached the crashes
we recorded in the hope it proves useful somehow. From what I can see
all the crashes occur when t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Subject: [ANNOUNCE] libdrm 2.4.17
To: [email protected]
CC: [email protected]
The experimental radeon API changed a lot, still experimental,
but I don't think it'll break incompatability again after this.
> 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
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-
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../..-I../../include/drm
-I../../intel/ -I../.. -I/usr/include/cai
Hello,
Here's the 2.4.16 release of libdrm. There are a lot of changes this
time, in particular we dropped the orphaned driver code from Linux and
BSD and this release is now really just libdrm. Going forward, the
drm header files we ship in libdrm will be a straight copy from the
linux k
On Sunday 29 November 2009 19:51:55 Robert Noland wrote:
> On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote:
> > I believe that moving away from the current model makes it more
> > difficult
> > to "... spread the burden ...", hence my objections. If you want to
> > call
> > that ranting or compl
On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote:
> I believe that moving away from the current model makes it more
> difficult
> to "... spread the burden ...", hence my objections. If you want to
> call
> that ranting or complaining, so be it.
We no longer get to share the burden with the mu
On Sun, Nov 29, 2009 at 5:03 PM, vehemens wrote:
> On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote:
>> On Sunday 29 November 2009 18:54:31 vehemens wrote:
>> > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
>> > > On Sunday 29 November 2009 14:16:13 vehemens wrote:
>> > >
>
On Sun, Nov 29, 2009 at 05:03:51PM -0800, vehemens wrote:
> You missing the point as is rnoland. Just because the linux DRM developers
> stopped using a centralized repository, didn't mean FreeBSD shouldn't as the
> intial integration work would be still shared reducing the burden on any one
>
On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote:
> On Sunday 29 November 2009 18:54:31 vehemens wrote:
> > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
> > > On Sunday 29 November 2009 14:16:13 vehemens wrote:
> > >
> > > [snip]
> > >
> > > > Your missing the point of usin
On Sunday 29 November 2009 18:54:31 vehemens wrote:
> On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
> > On Sunday 29 November 2009 14:16:13 vehemens wrote:
> >
> > [snip]
> >
> > > Your missing the point of using a development structure which supports
> > > collobration.
> >
> > [snip
On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
> On Sunday 29 November 2009 14:16:13 vehemens wrote:
>
> [snip]
>
> > Your missing the point of using a development structure which supports
> > collobration.
>
> [snip]
>
> > The difference is that you are the only one doing the work now
On Sunday 29 November 2009 14:16:13 vehemens wrote:
[snip]
> Your missing the point of using a development structure which supports
> collobration.
[snip]
> The difference is that you are the only one doing the work now.
[snip]
> Again, your missing the point of using a development structure
On Sunday 29 November 2009 10:39:34 Maarten Maathuis wrote:
> I enjoy playing the devils advocate occasionally, so take this with a
> grain of salt.
>
> My understanding is that there are roughly 3 bsd kernels that support
> drm userspace interface(free*, open* and netbsd?), each has 1 or 2
> maint
I enjoy playing the devils advocate occasionally, so take this with a
grain of salt.
My understanding is that there are roughly 3 bsd kernels that support
drm userspace interface(free*, open* and netbsd?), each has 1 or 2
maintainers. For better or worse the linux guys/girls have gone their
own wa
>> branching from the commit before its removal, if you think
> > > > > > > >> revival is needed, don't bring back linux-core when you do
> > > > > > > >> please.
> > > > > > > >
> > > > > > &g
On Sunday 29 November 2009 00:31:17 Daniel Stone wrote:
> Hi,
>
> On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote:
> > On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> > > Because unpublished work doesn't exist That goes for the work that
> > > I've done that isn't yet publ
e
> > > > > > >> BSD maintainers used it, you can just get it back by branching
> > > > > > >> from the commit before its removal, if you think revival is
> > > > > > >> needed, don't bring back linux-core when you do plea
Hi,
On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote:
> On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> > Because unpublished work doesn't exist That goes for the work that
> > I've done that isn't yet published as well. Until it is in the hands of
> > someone besides you
> > > >> from the commit before its removal, if you think revival is
> > > > > >> needed, don't bring back linux-core when you do please.
> > > > > >
> > > > > > I already told the both of you that I was planning to use it o
; >> bring back linux-core when you do please.
> > > > >
> > > > > I already told the both of you that I was planning to use it on IRC,
> > > > > I just haven't had time to put anything in.
> > > > >
> > > > > In ad
On Saturday 28 November 2009 13:44:53 Dave Airlie wrote:
> > I haven't published any of my work recently, but that doesn't mean I
> > haven't done anything that I would like to share. Not sure why you feel
> > this is important however.
> >
> > I gave you a number of suggestions in private emails
>
> I haven't published any of my work recently, but that doesn't mean I haven't
> done anything that I would like to share. Not sure why you feel this is
> important however.
>
> I gave you a number of suggestions in private emails on how to fix problems
> such as the merging issue and you we
t; > >> maintainers used it, you can just get it back by branching from the
> > > >> commit before its removal, if you think revival is needed, don't
> > > >> bring back linux-core when you do please.
> > > >
> > > > I already told the
gt; There are more then two BSD maintainers, and your statement that neither of
>> them cared is not correct.
>
> Don't get me wrong here, I don't like the current state of things, but
> given current drm development practices, this change was irrelevant. I
> was a bit frustra
mmit before its removal, if you think revival is needed, don't bring
> > >> back linux-core when you do please.
> > >
> > > I already told the both of you that I was planning to use it on IRC, I
> > > just haven't had time to put anything in.
> >
ck linux-core when you do please.
> >
> > I already told the both of you that I was planning to use it on IRC, I
> > just haven't had time to put anything in.
> >
> > In addition, he's asking for a repro to libdrm. The way I see it, is
> > there were two cho
fferently, and Nouveau manages to fail even in that. :-)
> >
> > What should installed header tree look like?
>
> Yup, as far as I can tell that's what it looked like before my re-org
> and it's what it finally looks like again. I defnitely agree that
> it's
This has come up a few time and it's something I think makes a lot
> >> >> >> > of
> >> >> >> > sense. Since all driver development (afaik) now happens in linux
> >> >> >> > kernel tree, it makes sense to dro
ve their headers installed
> differently, and Nouveau manages to fail even in that. :-)
>
> What should installed header tree look like?
Yup, as far as I can tell that's what it looked like before my re-org
and it's what it finally looks like again. I defnitely agree that
it'
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 instead of the ones in
> > radeon/ since they're what's upstream.
>
; > sense. Since all driver development (afaik) now happens in linux
>> >> >> > kernel tree, it makes sense to drop the driver bits from the drm.git
>> >> >> > repo.
>> >> >>
>> >> >> Ok, here's an update to the proposal.
t; >> >> > kernel tree, it makes sense to drop the driver bits from the drm.git
> >> >> > repo.
> >> >>
> >> >> Ok, here's an update to the proposal. I've rebased the libdrm branch
> >> >> in people.freedesktop.
gt;
>> >> > This has come up a few time and it's something I think makes a lot of
>> >> > sense. Since all driver development (afaik) now happens in linux
>> >> > kernel tree, it makes sense to drop the driver bits from the drm.git
>> >>
and it's something I think makes a lot of
> >> > sense. Since all driver development (afaik) now happens in linux
> >> > kernel tree, it makes sense to drop the driver bits from the drm.git
> >> > repo.
> >>
> >> Ok, here's an updat
core when you do please.
> >
> > I already told the both of you that I was planning to use it on IRC, I just
> > haven't had time to put anything in.
> >
> > In addition, he's asking for a repro to libdrm. The way I see it, is there
> > were two choi
1 - 100 of 359 matches
Mail list logo
