Well I'm not 100% sure what happened for this patch, I suspect,
jbarnes sent patch a week
or two ago, it misapplied against the tree I had currently when
applied with git-am, it didn't work so I hand
applied the patch with patch and then did git commit
--author=jbarnes as he did write it,
On Mon, Dec 15, 2008 at 10:26:27PM +0100, Thomas Hellström wrote:
Hi!
Sam Ravnborg wrote:
On Sun, Dec 14, 2008 at 04:57:34PM +0100, Thomas Hellström wrote:
Hi!
The intention is for via_drm.h to be self-containing when included both
for a kernel build and for a user-space build
Hi David et al.
After improving the headers_check.pl script to do a
check for files included with:
#include foo.h
it reported the following error:
/home/sam/kernel/knext.git/usr/include/drm/via_drm.h:34: included file
'/home/sam/kernel/knext.git/usr/include/drm/via_drmclient.h' is not
Makefie bits:
5 EXTRA_CFLAGS = -Iinclude/drm
Use ccflags-y := -Iinclude/drm
I assume this is a temporary workaround and you plan to fix
up all includes to use #include drm/fo.h
I'd rather not do that due the fact that a lot of these files are
shared with other OSes upstream and
On Thu, May 29, 2008 at 10:46:22AM +1000, Dave Airlie wrote:
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it lives under char.
b) everything in one directory.
c) header files in one directory.
d) no header files exposed to userspace.
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote:
Just out of interest, what would the scenario be if you do if you could
get a compatible driver?
you just grab a DRI snapshot which contains new userspace and DRM, and
install it... it builds the DRM against your current
On Wed, Sep 01, 2004 at 01:42:17PM -0700, Ian Romanick wrote:
Sam Ravnborg wrote:
On Wed, Sep 01, 2004 at 09:33:05AM -0700, Ian Romanick wrote:
Jon Smirl wrote:
Why don't we just address the real problem and split DRM into
core/personalities. Doing this would eliminate the whole intermodule
On Wed, Sep 01, 2004 at 02:22:28PM -0700, Ian Romanick wrote:
So, you have x_ata.ko and y_ata.ko that are both linked with libata.
What happens when when the user loads both modules at once? How do you
avoid symbol conflicts from the libata linked to both drivers? This is
basically what
On Tue, Aug 31, 2004 at 08:41:19AM -0700, Ian Romanick wrote:
Keith Whitwell wrote:
It should be possible to avoid the whole DRM(fff) thing using linker
directives to designate what symbols are exported from the final
drm_xyz.o object, in the same way that static symbols don't get exported
On Sat, Aug 28, 2004 at 04:17:32PM -0700, Jon Smirl wrote:
I'm just starting to look at the bug, but the code involved has been
rewritten in a patch that isn't checked in yet. You might want to give
the new code a try.
Hi Jon - a few comments.
Sam
-
#ifndef MODULE
/** Use an
On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote:
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets up an area in AGP memory that will be used as the
ring buffer. The second call
On Fri, Aug 20, 2004 at 11:32:06AM -0700, Erdi Chen wrote:
3) What's the purpose of #define __NO_VERSION__
Came from the i915_dma.c that I've used as a template. I have no idea
what it is for. It seems to exist in many drm source files.
I was not sure but google confirmed.
__NO_VERSION__ was
On Fri, Aug 20, 2004 at 07:48:44PM +0100, Keith Whitwell wrote:
Sam Ravnborg wrote:
On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote:
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets
On Wed, Aug 18, 2004 at 01:10:56PM +0100, Dave Airlie wrote:
A few points (based only on the diff).
1) Rename CONFIG_MTRR to CONFIG_DRM_MTRR to provide better context
well we are using the kernels CONFIG_MTRR so if the kernel has MTRR
built-in we want to use it
Back home with access
On Mon, Aug 16, 2004 at 01:39:20PM -0700, Ian Romanick wrote:
Jon Smirl wrote:
Do we really need the DRM() macro around function names? With Linux the
only exported symbols are the ones marked with EXPORT_SYMBOL. Is this a
work around for another OS to stop symbol conflicts when the OS
15 matches
Mail list logo
