On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
> Hi Dave,
>
> I think this change is causing a regression I'm seeing in panic.
> Before this change, I'd get a
> reboot on panic (we've configured as such).
>
> With this change, my machine gets wedged if the machine is running in
> X when the pa
received. Obviously this approach
does not work with DVI-I where the analog and digital outputs share a
common DDC bus.
The patch below adds an additional check to make sure that there is
really an analog device attached (similar to the "Mac mini hack" in
intel_sdvo.c)
Signed-off-by: Dav
On Thu, 13 May 2010, Tvrtko Ursulin wrote:
> > You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs
> > and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so.
>
> I could do it if radeon/drm guys would be interested in those results? (Given
> how 2.6.34-rc7 is not
From: Jesse Barnes
Date: Fri, 5 Mar 2010 10:02:44 -0800
> So from that perspective, the graphics stack is the most complex one in
> Linux by a long shot. It's even worse than if we had STREAMS
> networking with a ton of different modules up in userspace messing with
> protocol. :)
Maybe :-)
--
From: Xavier Bestel
Date: Fri, 05 Mar 2010 18:50:24 +0100
> On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
>> From: Daniel Stone
>> Date: Fri, 5 Mar 2010 17:41:43 +0200
>>
>> > I understand that you guys are upset about this, so maybe you'd li
From: Daniel Stone
Date: Fri, 5 Mar 2010 18:04:34 +0200
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for
From: Alan Cox
Date: Fri, 5 Mar 2010 16:02:17 +
>> You can't unleash something like this on a userbase of this magnitude
>> and then throw your hands up in the air and say "I'm not willing to
>> support this in a reasonable way."
>
> Not to belabour the obvious - they didn't. Linus ordered t
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:41:43 +0200
> I understand that you guys are upset about this, so maybe you'd like to
> donate, say, 10% of your developer base to help out? That'd be pretty
> ace.
You have to support less than %10 of the amount of hardware we have to
support.
--
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:40:09 +0200
> On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
>> In fact, I argue that the moment nouveau went into Fedora and
>> was turned on by default, the interfaces needed to be frozen.
>
> That's a ma
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:17:54 +0200
> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone. And the way it's breaking
>>
From: Alan Cox
Date: Fri, 5 Mar 2010 15:09:34 +
> I think you miss a bigger picture ?
>
> If Fedora hadn't merged it then it wouldn't have gotten to the state of
> usability it had. If Fedora hadn't merged it then several hundred
> thousand users wouldn't have had useful working machines.
I
From: Alan Cox
Date: Fri, 5 Mar 2010 12:38:34 +
>> The conclusion is crystal clear, breaking an ABI via a "flag day"
>> cleanup/feature/etc is:
>
> Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> junk that is in there being cleaned up it would be *insane* to keep
-line summary
> sounds useful i enable it. Especially if the Kconfig help entry says it's
> safe with a new distro, it's not CONFIG_EXPERIMENTAL, it's not marked
> CONFIG_BROKEN, it's not in CONFIG_STAGING, etc. )
forget the people testing the rc kernels, what abou
On 01/07/2010 12:42 AM, Johan Hovold wrote:
>> Yeap. The fix uncovered a bug in your driver. I haven't heard of problems
>> with the other drm drivers.
>>
>>> The backlight is handled via the DRI driver I assume. At least
>>> i9xx_crtc_dpms is called on powerdown.
>>
>> Can you post your dmesg a
On 12/31/2009 12:00 PM, David John wrote:
> With the current DRM code, an output that has been powered off
> from userspace will automatically power back on when resuming
> from suspend. This patch fixes this behaviour.
>
> Tested only with the Intel i915 driver on an Intel GM45 Ex
From: Alan Cox
Date: Fri, 11 Dec 2009 09:18:43 +
> However the fundamental point stands. The only people who can sign it off
> are the people who wrote it. Those are the rules. Red Hat didn't write the
> code, Red Hat cannot sign it off however much you rant at them. You also
> previously sai
> Cc: Al Viro
> Cc: Arnd Bergmann
> Reported-by: David Miller
> Signed-off-by: Heiko Carstens
Acked-by: David S. Miller
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 16:40:18 +0100
> I'm pretty sure it was ok when we started adding the compat_ioctl
> handlers years ago. I think most people just ignored these for
> the majority of drivers that can't possibly run on s390. Even
> on s390, gcc will always do the right th
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 13:13:32 +0100
> The ioctl argument actually needs a compat_ptr() conversion as well.
> For the s390 case, we can't do that in common code, because some
> ioctl methods put a 32 bit integer into the argument. Not sure if we
> want to fix that everywhere,
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 13:13:32 +0100
> IMHO a better way to handle the radeon specific ioctls would be to
> avoid the compat_alloc_user_space and just define the common
> function taking a kernel pointer, with two implementations of the
> copy operation:
Agreed, that would b
From: Andi Kleen
Date: Wed, 28 Oct 2009 09:19:09 +0100
> On Wed, Oct 28, 2009 at 01:11:41AM -0700, David Miller wrote:
>> From: Andi Kleen
>> Date: Wed, 28 Oct 2009 08:59:08 +0100
>>
>> >> }
>> >> - chunk_array_ptr = (uint64_t *)(unsigned l
From: Andi Kleen
Date: Wed, 28 Oct 2009 08:59:08 +0100
>> }
>> -chunk_array_ptr = (uint64_t *)(unsigned long)(cs->chunks);
>> +#ifdef CONFIG_COMPAT
>> +if (is_compat_task())
>
> Are the COMPAT ifdefs really needed? The compiler should optimize that
> away anyways on non compat aware
From: David Miller
Date: Tue, 27 Oct 2009 23:04:50 -0700 (PDT)
> From: Dave Airlie
> Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
>
>> I'll add this to my TODO for before the next merge window as its
>> definitely more than I can manage now.
>
> I'll do it
From: Dave Airlie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
> I'll add this to my TODO for before the next merge window as its
> definitely more than I can manage now.
I'll do it.
--
Come build with us! The BlackBerry
From: Andi Kleen
Date: Wed, 28 Oct 2009 05:36:11 +0100
> On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
>> On sparc64, in order to make debugging easier, we trap any time
>> the kernel does a userspace access to a compat task and any
>> of the upper
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
>>
>> > we already opencoded this (probably before it was macroisied or we just
>> > pasted it), so the radeon one is buggy, I should just go and compat_* all
>> > of these then and we should be all happy?
>>
>> It should be, it's
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
> we already opencoded this (probably before it was macroisied or we just
> pasted it), so the radeon one is buggy, I should just go and compat_* all
> of these then and we should be all happy?
It should be, it's only working becaus
From: Andi Kleen
Date: Wed, 28 Oct 2009 04:34:55 +0100
> On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
>> Well this was what I was trying to gather, so maybe I just need to write
>> something up to state that compat_ioctl is always required for new ioctls
>> that pass pointers or 6
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:28:10 +1000
> On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen wrote:
>> On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
>>> We've designed that into a/c also, we pad all 64-bit values to 64-bit
>>> alignment on all the
>>> ioctls we've added t
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:05:08 +1000
> DrNick on irc suggested just doing:
> if (is_compat_task()) ptr &= 0x;
>
> Is there a one liner I can just do in the actual ioctls instead of
> adding 20 compat
> ones?
Just do the right thing and pass all userland compat
From: Andi Kleen
Date: Wed, 28 Oct 2009 03:53:17 +0100
> Dave Airlie writes:
>
>> Now I thought cool I don't need to worry about compat ioctl hackery I can
>> run 32 on 64 bit apps fine and it'll all just work.
>>
>> Now Dave Miller points out that I'm obivously deluded and we really need
>> to
From: Dave Airlie
Date: Wed, 28 Oct 2009 11:22:18 +1000
> Is there really no way to avoid compat ioctls? was I delusional in
> thinking there was?
If you use pointers in your interfaces in any way, no.
And for this drm_radeon_info thing the pointer is "pointless",
you're just returning 32-bit v
Hello
Changelog:
Use VBT information to determine which DDC bus to use for CRTDCC.
Fall back to GPIOA if VBT info is not available.
Reviewed-by: Jesse Barnes
Signed-off-by: David Müller
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc8.patched/drivers/gpu
something like this?
Signed-off-by: David Müller
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/i915_drv.h
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.
Hello
Any news regarding this issue?
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core a
Hello
What about a patch like the attached one; would this be acceptable?
Signed-off-by: David Müller
diff -dpruN linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/i915_drv.h
--- linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/i915_drv.h
Eric Anholt wrote:
> There have been bugfixes in load detect since .30, could you try
> master and see if it's fixed?
Yes, you are right. Problem seems to me fixed in 2.6.31-rc1.
Thanks for the hint
--
--
__
Ma, Ling wrote:
>> What about 855GM or 945GME platforms? Can the "crt_ddc_gmbus_pin" field
>> use on these platforms?
> On those platforms they always use GPIOA, at least we don't find similar bugs.
> If you have some related bugs, could you please tell us?
There are (at least) two boards on this
Ma, Ling wrote:
> We have one DG45ID board connected VGA by DVI-I port, however
> bmp_CRT_DDC_Pins from vbt is always 0x02 which means GPIOA, so we can
> not depend on the value, and have to try GPIOD or GPIOE. It only
> impact G4X series platform.
So if i understand you correctly, the "crt_ddc_
Hello
While testing Linux kernel 2.6.30 and the i915 driver, i noticed that
GPIOA is hardwired to be used as the only possible CRTDDC bus.
code snippet from drivers/gpu/drm/i915/intel_crt.c:
441 /* Set up the DDC bus. */
442 intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
Hello
While testing Linux kernel 2.6.30 on a Intel 855GME platform i noticed a
3 minute delay during the Linux boot process in the case DDC support is
not available.
I've tracked the problem down to the following lines in
driver/gpu/drm/i915/intel_crt.c:
289 /*
290
The only question is in whose code. :)
Yes :)
Yours,
David HENRY.
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
mesa libs for xorg-edgers, has reproduced
it too with mesa 7.6/git.
Also, I could get it running on another box running Ubuntu Intrepid with
nvidia 177.82.
Cordialy,
David HENRY
Le mercredi 24 juin 2009 à 15:57 -0700, Ian Romanick a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash
hes for the next one. If I use glBufferData it
works fine.
Is it expected, or is it a bug?
Note that it works with LIBGL_ALWAYS_SOFTWARE=1. It worked before too
(Mesa 7.4). It crashes with linux 2.6.30 as well as 2.6.28, both KMS and
UMS tested.
Yours,
David HENRY.
/*
* gcc -Wall -ansi -lGL -l
From: Andrew Morton
Date: Thu, 19 Feb 2009 15:27:26 -0800
> eg:
>
> arch/xtensa/include/asm/shmparam.h
> #define SHMLBA ((PAGE_SIZE > DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE)
>
>
> But including linux/shm.h here seems a bit silly. We'll see..
If DRM even builds on XTENSA, let alone i
From: Arnd Bergmann
Date: Thu, 19 Feb 2009 15:19:01 +0100
> On Wednesday 18 February 2009, David Miller wrote:
> > drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
> >
> > Only X86 32-bit uses a different alignment for "unsigned long long"
&
ago this bug didn't exist because we
used to just use the low 32-bits of the address as the hash and just
hope for the best. This preserved the SHMLBA bits properly. But when
the hashtab code was added to DRM, this was no longer the case.
Signed-off-by: David S. Miller
---
dri
From: Benjamin Herrenschmidt
Date: Thu, 19 Feb 2009 08:59:50 +1100
> Could that be related to the kernel spewing a bunch of
>
> [drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace
Yep, that is exactly caused by this bug.
--
drm: radeon: Fix unaligned access in r300_scratch().
In compat mode, the cmdbuf->buf 64-bit address cookie can
potentially be only 32-bit aligned. Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.
Use get_unaligned() to fix.
Signed-off-by: Davi
n it's 64-bit counterpart.
Therefore this compat translation is only correct, and only needed,
when either CONFIG_X86 or CONFIG_IA64.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/drm_ioc32.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm
From: Sedat Dilek
Date: Sun, 15 Feb 2009 10:28:29 +0100
> unfortunately, your latest DRM patch [1] is broken while building
> against Linux-2.6.25-rc5.
>
> This is my patch-series:
Did you read my patch postings? I said my work was relative
to dri-next, as sparc64 also needs the c
From: Michel Dänzer
Date: Sat, 14 Feb 2009 10:59:59 +0100
> On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
> > This allocates a physical surface for the PCI GART table, this way no
> > matter what other surface configurations exist the GART table will
> > always be
From: David Miller
Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST)
> From: Benjamin Herrenschmidt
> Date: Sat, 14 Feb 2009 20:07:54 +1100
>
> > We can do that by registering a surface from the kernel to cover the
> > GART I suppose, and clean things a bit so that when using t
the last close, we
release that surface.
Just to be doubly safe, we run the pcigart table setup with the main
surface control register clear.
Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt.
Signed-off-by: David S. Miller
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b
From: Benjamin Herrenschmidt
Date: Sat, 14 Feb 2009 20:07:54 +1100
> > I did some research, and it does appear that the GART does read the
> > PTEs from the VRAM using the Host Data Path. This means the surface
> > control byte swapping settings are applied.
> >
> > So for depths of 16 and 24,
From: Dave Airlie
Date: Sat, 14 Feb 2009 17:42:02 +1000
> On Sat, Feb 14, 2009 at 4:09 PM, David Miller wrote:
> > 1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead
> > of the constant 4096 to determine how many GART entries there
> > are. The PCI
SIZE.
Eliminate the confusion by creating max_ati_pages and
max_real_pages. Calculate and use them as appropriate.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/ati_pcigart.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart
From: Benjamin Herrenschmidt
Date: Thu, 12 Feb 2009 21:35:59 +1100
> Oh BTW something else to be careful with, though I suppose it's working
> some what by accident right now... when the GART is in the frame buffer
> it gets applied the current fb swapper setting... ouch !
>
> So it might be a g
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:26:51 +1000
> On Thu, Feb 12, 2009 at 8:15 PM, David Miller wrote:
> >
> > David, this work is against your drm-next branch.
> >
> > Here are a collection of bug fixes for the Radeon DRM support. Most
> > of them
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:23:13 +1000
> are you on a PCI or PCIE card, I've no idea what buses you have on sparc64.
>
> On the PCI cards the GART table will always be in main memory.
> PCIE always in VRAM.
PCI-E
From: Benjamin Herrenschmidt
Date: Thu, 12 Feb 2009 21:35:59 +1100
> Oh BTW something else to be careful with, though I suppose it's working
> some what by accident right now... when the GART is in the frame buffer
> it gets applied the current fb swapper setting... ouch !
>
> So it might be a g
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_cp.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm
x27;s
vmalloc'd memory.
Adjust all of the ring_rptr access code as needed.
While we're here, kill the 'scratch' pointer in drm_radeon_private.
It's only used in the one place where it is initialized.
Signed-off-by: David S. Miller
---
driv
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller
---
drive
David, this work is against your drm-next branch.
Here are a collection of bug fixes for the Radeon DRM support. Most
of them have to do with trying to access kernel virtual addresses
using DRM_READ32() and DRM_WRITE32().
With these patches at least the writeback test works on sparc64 and
the
some system types (such as
sparc64 where the ioremap() return value is actually a physical I/O
address).
So access the area correctly, using gart_info->gart_table_location as
our guide.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/ati_pcigart.c | 26 --
1 files cha
se RCU directly rather than a convenient wrapper; these will be
addressed by later patches.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
Reviewed-by: James Morris <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
Cc: David Airlie <[EMAIL PROTECTED]>
Cc: d
LE as well.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
drivers/char/drm/sis_mm.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/drm/sis_mm.c b/drivers/char/drm/sis_mm.c
index b387877..c4debfd 100644
--- a/drivers/char/drm/sis_mm.c
+++ b/d
Fix a pointer cast warning in the SIS DRM code.
This was introduced in patch ce65a44de07f73ceda1749812b75086b7add408d.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
drivers/char/drm/sis_mm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ch
On Thu, 2008-05-29 at 10:46 +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.
>
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 15:15:48 +1000
> > Perhaps we'll have to create something ugly like vmalloc_nobounce().
> >
> > Remind me again why you're ending up with swiotlb'd pages?
> > vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus
> > RA
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 14:08:13 +1000
> > >
> > > So when swiotlb happens, as you can guess it all falls apart as the
> > > drm never calls sync functions at any stage...
> >
> > You would have hit this on any platform that does caching
> > in the PCI control
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 09:44:41 +1000
> Okay I've got a bug reported before and now again about > 4GB + radeon
> blows up the DRM... on Intel hw...
>
> What the drm currently does for the PCI GART table is it allocates a
> chunk of memory (8MB) with vmalloc_
ng I guess I'll just enjoy my bzflag in 3D... B)
-David Oftedal
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on
copic output could be achieved in a
wide range of games even today.
At any rate, I was wondering if something like this has ever been attempted, or
implemented, in DRI?
Best regards
David J. Oftedal
-
Take Surveys. Earn
,
David Nielsen
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
signature.asc
Description: Dette er en digitalt underskrevet br
l text
rendering in X today) we can actually pass all alpha channels to the
blending stage and achieve per-component alpha blending with the solid
source color in one pass by using GL blend color. I've got code in glitz
for doing this as well.
-David
-
an R100 QD (7200)
> and it seems fine there as well.
>
> I'll keep an eye out for future versions of the patch for further
> testing.
Awesome. Would you mind putting the info that this patch fixed your problem
in the Debian bug? I'm
Hello again
Just for the record I have downgraded to debian stable just to check a few
things and the speed difference is definitely noticeable. glxgears cogs fly
in debian stable and in blender a simple textured round shape moves with no
delay/jitter. with latest X and 2.4.15 kernel the same
On Tuesday 03 Jan 2006 18:02, Ian Romanick wrote:
> David Mulcahy wrote:
> > I have been experiencing problems getting drm to work again with my
> > matrox g4oo card. The problem started around this post.
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_i
On Tuesday 03 Jan 2006 18:02, Ian Romanick wrote:
> David Mulcahy wrote:
> > I have been experiencing problems getting drm to work again with my
> > matrox g4oo card. The problem started around this post.
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_i
Hello all
I have been experiencing problems getting drm to work again with my matrox
g4oo card. The problem started around this post.
http://sourceforge.net/mailarchive/forum.php?thread_id=8163981&forum_id=7177
Now although That particular problem has stopped I still cannot get drm
working ag
Hello
Not sure if this is the right list to post to but i am just reporting a
problem I am experiencing with current unstable version of xorg and xfree.
The problem is with mga and dri (I think)
The output from glxgears is
libGL warning: 3D driver claims to not support visual 0x23
libGL warn
I've found a few places where strings.h is included. When I use some
versions of the gcc complier I get a 'file not found' error. I changed
some to string.h and the compile is working ok. The files I changed were
t_vp_build.c and main/texenvprogram.c.
Should these be string.h or st
ODE_MUL, tmp, 0, tmp, swizzle1(params,X));
emit_op2(p, VP_OPCODE_POW, fog, WRITEMASK_X,
register_const1f(p, M_E), negate(tmp));
^^^
Thanks,
David Kesselring
Atmel MMC
[EMAIL PROTECTED]
919-462-6587
---
This SF.Net email is spon
I've downloaded the latest code from cvs and built using 'make
linux-fbdev'. It does not look like progs/fbdev dir was built. Is that
expected or should it be built with the linux-fbdev option?
Thanks,
David
David Kesselring
Atmel MMC
[EMAIL PROTECTE
When looking at the Mesa source I see processor specific directories in
Mesa-x.x.x/src/mesa. I see x86,sparc,ppc. What happens in a build for ARM?
Thanks,
David Kesselring
Atmel MMC
[EMAIL PROTECTED]
919-462-6587
---
This SF.Net email is
Thanks Keith.
David
On Thu, 28 Apr 2005, Keith Whitwell wrote:
> Keith Whitwell wrote:
> > David Kesselring wrote:
> >
> >> Hello,
> >> My project is to get opengl/mesa on an embedded arm7. I am trying to
> >> begin
> >> with the linux-solo
modify
things enough to get a software only build without any OS dependencies
(i.e. just dump data to a psuedo-framebuffer).
Thanks for your help.
David Kesselring
Atmel MMC
[EMAIL PROTECTED]
919-462-6587
---
SF.Net email is sponsored by: Tell us
El Domingo, 27 de Marzo del 2005 9:16 PM, Felix Kühling escribió:
> Am Sonntag, den 27.03.2005, 19:45 +0200 schrieb David:
> > El Domingo, 27 de Marzo del 2005 4:02 PM, Felix Kühling escribió:
> > > The tarball includes a Makefile, which is supposed to make life easier
> &g
, I think that there should be more strings marked for translation.
Anyway here's the .po for the Spanish translation.
See ya.
David Rubio.
es.po.tgz
Description: application/tgz
On Wed, 9 Feb 2005 11:50:43 -0500
Jon Smirl <[EMAIL PROTECTED]> wrote:
> Kconfig matches the underlying kernel directory structure. If we do
> this we should also move the location of the DRM and fbdev in the
> kernel tree. Something like:
>
> drivers/video/drm
> drivers/video./fb
>
> This can
Little bug, little fix.
There is a bug in the install script in the DRM compile section.
It is checking for a linux-2.6 directory. I changed it to linux-core and it
works.
El Lunes, 31 de Enero del 2005 2:04 PM, Felix Kühling escribió:
> Hi all,
>
> I just uploaded a new set of experimental sn
El Lunes, 1 de Noviembre del 2004 4:22 PM, Alex Deucher escribió:
> On Sun, 31 Oct 2004 13:42:32 +0100, David <[EMAIL PROTECTED]> wrote:
> > Hi. While the current Xv implementation is far better than the old one
> > there are still a few glitches I noticed so far:
> >
&g
Hi. While the current Xv implementation is far better than the old one there
are still a few glitches I noticed so far:
* 4 pixels always missing on the right side on the screen
* The old "shadowing" effect is showed on certain conditions (depending on
input sizes). I only tested a few sizes: 76
El Jueves, 14 de Octubre del 2004 5:38 AM, Alex Deucher escribió:
> On Thu, 14 Oct 2004 00:55:51 +0200, David <[EMAIL PROTECTED]> wrote:
> > Hi. Sorry to be too picky, but I've found that after the Xv fix 4 pixels
> > are missing on the right side of the screen.
> >
6 and see the right side. The 4
rightmost pixels (in red) cannot be seen.
Before the Xv fix the problem was also appearing running any program using
overlay surfaces (kdetv, xine, ...). Now is permanent.
Thanks for your time.
David.
---
This S
ort configuration.
A snip of dmesg:
...
PCI: Unable to reserve mem region #2:[EMAIL PROTECTED] for device :01:00.0
mtrr: base(0xda00) is not aligned on a size(0x500) boundary
[drm] Initialized savage 1.0.0 20011023 on minor 0:
[drm] Used old pci detect: framebuff
El Martes, 12 de Octubre del 2004 1:02 AM, Felix Kühling escribió:
> I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It
> contains all (strip -g) modules except the ones included in the binary
> snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers).
1 - 100 of 335 matches
Mail list logo
