On Mon, Jul 20, 2009 at 04:52:26PM +0100, Matthew Garrett wrote:
I think tightly integrated could do with some clarification here.
qcserial was accepted despite not being functional without a closed
userspace component - an open one's since been rewritten to allow it to
work. Do we define
On Thu, Aug 30, 2007 at 12:20:32PM -0400, Kristian H?gsberg wrote:
The wrappers aren't useless the drm alloc/free passes in a memory space
for debugging purposes so we can track memory abuse when developing,
Do we ever use that, though? Having to pass in the pointer, the size
and the
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
Hello,
As there are many places in drm code where drm_alloc + memset is used
this patch series introduces drm_zalloc and also makes use of drm_calloc where
needed. Most of these patches save some bytes so the benefit is
On Thu, May 31, 2007 at 05:11:22PM +0800, Wu, Nian wrote:
Then I compiled DRM kernel module, it reported below error info:
Don't do this. Always use the in-kernel drm.
-
This SF.net email is sponsored by DB2 Express
Folks, could someone explain what the heck is going on here:
static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
{
drm_file_t *priv = filp-private_data;
drm_device_t *dev = priv-head-dev;
drm_i830_buf_priv_t *buf_priv = buf-dev_private;
On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote:
Some of the topics raised include:
- minimum OpenGL version required by libGL
- SONAME change to libGL
- libGL installation path
I think the single most important point is to explicitly disallow
vendor-supplied libGL
On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote:
http://lists.freedesktop.org/archives/dri-egl/2005-July/000565.html
In particular, Andy's response about why they're uninterested in a common
libGL is basically The Last Word on the subject. It would require that
nvidia expend
On Sun, May 29, 2005 at 12:25:10AM -0400, Kyle Moffett wrote:
If DRM is built-in, then AGP _must_ be built-in or not included at
all, modular
won't work. If DRM is modular or not built, then AGP may be built-
in, modular,
or not built at all.
The depends on AGP || AGP=n means that if
On Sat, Dec 18, 2004 at 09:17:14AM -0800, Mike Werner wrote:
The agp_bridge_find function pointer is bogus, that way you can only support
one backend at a time.
Obviously you mean one type of backend here.
I have tried to simplify this patch as much as possible so that it only tries
to do
On Fri, Dec 17, 2004 at 12:55:59PM -0800, Mike Werner wrote:
This new version reduces the number of changes required by users of the
agpgart
such as drm to support the new api for multiple agp bridges.
The first patch doesn't touch any platform specific files and all current
platform
gart
On Tue, Sep 28, 2004 at 11:54:35AM -0400, Jon Smirl wrote:
I've checked two new directories into DRM CVS for Linux 2.6 -
linux-core, shared-core. This code implements a new model for DRM
where DRM is split into a core piece and personality modules that
share the core. The major reason for
On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote:
Christoph Hellwig wrote:
- drm_flush is a noop. a NULL -flush does the same thing, just easier
- dito or -poll
- dito for -read
Pretty sure you couldn't get away with null for these in 2.4, at least.
Umm, of course
On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote:
Thinking about it, it may not have been a problem of crashing, but rather that
the behaviour visible from a program attempting to read (or poll) was
different with noop versions of these functions to NULL versions, and that was
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same hardware for video and not for
anything else..
On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote:
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline. DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth
On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote:
Not to step on toes, but... From what I can tell the idea is to add code
into FB that calles functions in the DRM and vice vers. This would seam
to add another ABI. Unless the code gets linked into one module, this
idea has been
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
You definitly start sounding like Hans ;-)
---
This SF.Net email is sponsored by: YOU
On Sat, Sep 04, 2004 at 01:12:16AM +0100, Dave Airlie wrote:
DRM core - just the stub registration procedure and handling any
shared resources like the device major number, and perhaps parts of sysfs
and class code. This interface gets set in stone as quickly as possible
and is as
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core and module,
On Sat, Sep 04, 2004 at 10:43:39AM +0100, Dave Airlie wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
true but the DRM isn't only about the Linux kernel, the DRM is a
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
But regular users don't tend to pull down new scsi or ata drivers
On Sat, Sep 04, 2004 at 11:48:47AM +0200, Arjan van de Ven wrote:
true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
component of a much larger system, of which the DRM just has to reside in
the kernel,
you seem to be confusing 2 things.
The kernel-userspace
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate kernel or
using a vendor kernel with backports. This model would work for video drivers
aswell.
Sure, explain to me how I should upgrade my RH-9 system to work
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
include a drm update. The last release RH-9 kernel has various security
and data integrity issues anyway, so you'd be a fool to keep running it.
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
I got a file called patch-2.6.8.1.bz2. I tried to install this but
nothing happened. My i915 still doesn't work. What do I do now?
You could
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
You didn't stick with that long Christoph. We're not even past first base
yet. Let's try again?
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me I'm now running
On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote:
A user without a clue should better be using a supported distribution.
If he used Fedora Core2 instead of the totally outdated and unsupported
RH9 he'd already have a kernel with i915 support on his disk.
What about Debian?
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote:
So, I've got this file patch-2.6.8.1.bz2. Lets suppose my older brother
comes in compiles it up for me I'm now running 2.6.8.1 - it's implausible
I know, but let's make it easier for you. Now, why isn't my i915 working?
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote:
Please don't think that I'm talking for Tungsten at this or any other time on
the DRI list. I'm talking for myself and have never attempted to convey here
or elsewhere a company view without explictly flagging it up as such.
On Sat, Sep 04, 2004 at 01:17:54PM +0100, Dave Airlie wrote:
Lets take an example, I'm DA graphics card vendor, I write a DRI driver
for my brand new 3d graphics cards (they rock btw :-), people buy loads of
them, I want to give them something on my website that they can deploy to
use their
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
I've got nothing to do with Tungsten whatsoever, I've never met any of the
other major DRI developers, my worries here is this is turning into a
company issue, people keep mentioning Fedora this and that, Fedora is one
distro, I
On Sat, Sep 04, 2004 at 11:17:40PM +0100, Dave Airlie wrote:
Actually after sleeping on this, I've just realised technically whether
the code is in a core separate module or driver module is only going to
affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
following the
On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote:
fbdev only has one distribution vector - the kernel, DRM has multiple
distribution vectors, kernel, DRI snapshots, X releases, they all contain
their own DRM modules, also people with older kernels should be able to
which is the root
On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote:
Yes, while I support the current rework and de-templatization of the code, I
don't support any attempt to split the drm modules to try and share code at
runtime - ie. I don't support a core/submodule approach.
We had that
On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote:
I guess one (unpleasant) way to make it work would be to add the version to
all the symbols in the device-independent layer. Instead of drm_foo you'd
have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple
On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote:
And thats one of the big reasons its such a mess and doesn't work out.
Nobody is testing or reviewing it until some huge merge point occurs
at which point you run the risk of people saying Actually your design
sucks, or in the 2.6 case
On Sun, Mar 30, 2003 at 09:14:58AM -0500, Nicholas Wourms wrote:
Dave Jones wrote:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,4,2)
#define down_write down
#define up_write up
#if can go, like it did in other parts of the patch.
What will replace it?
Nothing.
On Wed, Mar 12, 2003 at 11:34:08PM +0300, Oleg Drokin wrote:
Hello!
Seems this is right list/person to post this.
I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and
it seems there is a memleak on error exit path.
If DRM(stub_register)(DRIVER_NAME,
38 matches
Mail list logo
