Replace sizeof(tv_modes) / sizeof (tv_modes[0]) with
ARRAY_SIZE(tv_modes) in drivers/gpu/drm/i915/intel_tv.c
Signed-off-by: Nikitas Angelinas
---
drivers/gpu/drm/i915/intel_tv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/g
Replace sizeof(est3_modes) / sizeof(est3_modes[0]) with
ARRAY_SIZE(est3_modes) in drivers/gpu/drm/drm_edid_modes.h
Signed-off-by: Nikitas Angelinas
---
drivers/gpu/drm/drm_edid_modes.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/dr
snprintf() returns the number of bytes which would have been used if
there was enough space. It can be larger than the size of the buffer.
Obviously in this case the buffer is large enough but everyone just
copy and pastes this code so it's better to limit it and set a good
example.
Signed-off-by
On Wed, 8 Sep 2010 21:44:47 +0200, Dan Carpenter wrote:
> snprintf() returns the number of bytes which would have been used if
> there was enough space. It can be larger than the size of the buffer.
> Obviously in this case the buffer is large enough but everyone just
> copy and pastes this code
On Fri, Aug 13, 2010 at 6:38 AM, Andy Furniss wrote:
> Jon Sturm wrote:
>
>> ut2004 has been having issues for a while so I wouldn't blame this
>> patch 100%, Then again my issues seem to be similar to
>> https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
>> not be related.
>
> On
https://bugs.freedesktop.org/show_bug.cgi?id=30095
Summary: [r300g] Fullscreen OpenGL game now has occasional
flicker (bisected)
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=30095
Summary: [r300g] Fullscreen OpenGL game now has occasional
flicker (bisected)
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi
or platform mechanism w
BenH's fix to correct building on multi-domain systems broke
building DRM for platforms without PCI support. This makes
the call to pci_domain_nr conditional in order to fix compilation.
Signed-off-by: Arnd Bergmann
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7809d23..5ff5819 1006
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-gfx at lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #25 from Rubén Fernández 2010-09-08 15:58:39
PDT ---
Created an attachment (id=38570)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38570)
38569: Log generated with "presub" branch and RADEON_DEBUG=fp, part 2
join with part 1
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #25 from Rub?n Fern?ndez 2010-09-08
15:58:39 PDT ---
Created an attachment (id=38570)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38570)
38569: Log generated with "presub" branch and RADEON_DEBUG=fp, part 2
join with part 1
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #24 from Rubén Fernández 2010-09-08 15:57:15
PDT ---
Created an attachment (id=38569)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38569)
Log generated with RADEON_DEBUG=fp, part 1
--
Configure bugmail: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #24 from Rub?n Fern?ndez 2010-09-08
15:57:15 PDT ---
Created an attachment (id=38569)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38569)
Log generated with RADEON_DEBUG=fp, part 1
--
Configure bugmail: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #23 from Rubén Fernández 2010-09-08 15:56:04
PDT ---
Created an attachment (id=38568)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38568)
Screenshot with the "presub" branch
Your branch seems to improve some things (the tree
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #23 from Rub?n Fern?ndez 2010-09-08
15:56:04 PDT ---
Created an attachment (id=38568)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38568)
Screenshot with the "presub" branch
Your branch seems to improve some things (the tree
On Fri, Aug 13, 2010 at 6:38 AM, Andy Furniss wrote:
> Jon Sturm wrote:
>
>> ut2004 has been having issues for a while so I wouldn't blame this
>> patch 100%, Then again my issues seem to be similar to
>> https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
>> not be related.
>
> On
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #55 from Martin Steigerwald 2010-09-08
14:45:15 PDT ---
Looks very good so far. I will reboot this kernel several times tomorrow - as a
freeze so far only every happened *before* the first hibernation / snapshot
cycle - but I looked
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #55 from Martin Steigerwald 2010-09-08
14:45:15 PDT ---
Looks very good so far. I will reboot this kernel several times tomorrow - as a
freeze so far only every happened *before* the first hibernation / snapshot
cycle - but I looked
Replace sizeof(tv_modes) / sizeof (tv_modes[0]) with
ARRAY_SIZE(tv_modes) in drivers/gpu/drm/i915/intel_tv.c
Signed-off-by: Nikitas Angelinas
---
drivers/gpu/drm/i915/intel_tv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/g
Replace sizeof(est3_modes) / sizeof(est3_modes[0]) with
ARRAY_SIZE(est3_modes) in drivers/gpu/drm/drm_edid_modes.h
Signed-off-by: Nikitas Angelinas
---
drivers/gpu/drm/drm_edid_modes.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/dr
On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett wrote:
> On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
>
>> The only problem with this is that not all oems use the internal
>> backlight controller; systems that don't need to use the acpi methods.
>
> That's why we expose the backli
On Wed, Sep 8, 2010 at 12:32 PM, Matthew Garrett wrote:
> From: Michel D?nzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
The only problem with this is that not all oems use the internal
backlight controller; system
On Wed, 8 Sep 2010 21:44:47 +0200, Dan Carpenter wrote:
> snprintf() returns the number of bytes which would have been used if
> there was enough space. It can be larger than the size of the buffer.
> Obviously in this case the buffer is large enough but everyone just
> copy and pastes this code
snprintf() returns the number of bytes which would have been used if
there was enough space. It can be larger than the size of the buffer.
Obviously in this case the buffer is large enough but everyone just
copy and pastes this code so it's better to limit it and set a good
example.
Signed-off-by
https://bugs.freedesktop.org/show_bug.cgi?id=28402
Martin Steigerwald changed:
What|Removed |Added
Summary|Kernel 2.6.34 freezes |random radeon/kms/drm
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #54 from Martin Steigerwald 2010-09-08
12:42:45 PDT ---
Created an attachment (id=38564)
View: https://bugs.freedesktop.org/attachment.cgi?id=38564
Review: https://bugs.freedesktop.org/review?bug=28402&attachment=38564
vram align
https://bugs.freedesktop.org/show_bug.cgi?id=28402
Martin Steigerwald changed:
What|Removed |Added
Summary|Kernel 2.6.34 freezes |random radeon/kms/drm
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #54 from Martin Steigerwald 2010-09-08
12:42:45 PDT ---
Created an attachment (id=38564)
View: https://bugs.freedesktop.org/attachment.cgi?id=38564
Review: https://bugs.freedesktop.org/review?bug=28402&attachment=38564
vram align
From: Michel D?nzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel D?nzer
Signed-off-by: Matthew Garrett
Cc: dri-devel at
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-gfx at lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #53 from Da Fox 2010-09-08 10:42:06 PDT
---
(In reply to comment #52)
> I am having those freezes on a ThinkPad T42 with
I have the same laptop, I'm glad to someone else still using an old ThinkPad :)
> Da Fox, are d594e46ace22afa16
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #53 from Da Fox 2010-09-08 10:42:06
PDT ---
(In reply to comment #52)
> I am having those freezes on a ThinkPad T42 with
I have the same laptop, I'm glad to someone else still using an old ThinkPad :)
> Da Fox, are d594e46ace22afa16
https://bugs.freedesktop.org/show_bug.cgi?id=30044
Mathieu Belanger changed:
What|Removed |Added
CC||b74...@gmail.com
--- Comment #5 from
https://bugs.freedesktop.org/show_bug.cgi?id=30076
Mathieu Belanger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30076
Mathieu Belanger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30044
Mathieu Belanger changed:
What|Removed |Added
CC||b747xx at gmail.com
--- Comment #5 fr
On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett wrote:
> On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
>
>> The only problem with this is that not all oems use the internal
>> backlight controller; systems that don't need to use the acpi methods.
>
> That's why we expose the backli
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi
or platform mechanism w
On Wed, Sep 8, 2010 at 12:32 PM, Matthew Garrett wrote:
> From: Michel Dänzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
The only problem with this is that not all oems use the internal
backlight controller; system
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #52 from Martin Steigerwald 2010-09-08
09:43:03 PDT ---
random - possibly Radeon DRM KMS related - freezes
https://bugzilla.kernel.org/show_bug.cgi?id=16376
which I reported seems to be a duplicate of this one.
I am having those fr
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #52 from Martin Steigerwald 2010-09-08
09:43:03 PDT ---
random - possibly Radeon DRM KMS related - freezes
https://bugzilla.kernel.org/show_bug.cgi?id=16376
which I reported seems to be a duplicate of this one.
I am having those fr
From: Michel Dänzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel Dänzer
Signed-off-by: Matthew Garrett
Cc: dri-devel@lis
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-...@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #51 from Lukas Schneiderbauer
2010-09-08 09:09:41 PDT ---
(In reply to comment #45)
> I'm testing the 2.6.36-rc3 kernel with airlied's patch at the moment. Looks
> promising for me as well. But I still need some hours to really confi
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #51 from Lukas Schneiderbauer
2010-09-08 09:09:41 PDT ---
(In reply to comment #45)
> I'm testing the 2.6.36-rc3 kernel with airlied's patch at the moment. Looks
> promising for me as well. But I still need some hours to really confi
On Wed, 8 Sep 2010 17:15:02 +0200
Arnd Bergmann wrote:
> BenH's fix to correct building on multi-domain systems broke
> building DRM for platforms without PCI support. This makes
> the call to pci_domain_nr conditional in order to fix compilation.
>
> Signed-off-by: Arnd Bergmann
>
> diff --gi
On Wed, 8 Sep 2010 17:15:02 +0200
Arnd Bergmann wrote:
> BenH's fix to correct building on multi-domain systems broke
> building DRM for platforms without PCI support. This makes
> the call to pci_domain_nr conditional in order to fix compilation.
>
> Signed-off-by: Arnd Bergmann
>
> diff --gi
BenH's fix to correct building on multi-domain systems broke
building DRM for platforms without PCI support. This makes
the call to pci_domain_nr conditional in order to fix compilation.
Signed-off-by: Arnd Bergmann
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7809d23..5ff5819 1006
Am 08.09.2010 00:00, wrote Alex Deucher:
> What card do you have? Can you dump the registers with both kms and
> ums with an interlaced mode set and send them to me? Use avivotool
I have a GA-MA78GM-UD2H mainboard with an onboard RS780 chipset.
I sent the requested dumps in a PM.
While typing
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #22 from Sven Arvidsson 2010-09-08 06:58:31 PDT ---
Created an attachment (id=38549)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38549)
Screenshot with presub
(In reply to comment #21)
> Can you try again with the presub-reb
https://bugs.freedesktop.org/show_bug.cgi?id=28860
--- Comment #22 from Sven Arvidsson 2010-09-08 06:58:31 PDT ---
Created an attachment (id=38549)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38549)
Screenshot with presub
(In reply to comment #21)
> Can you try again with the presub-reb
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #50 from Da Fox 2010-09-08 05:02:14 PDT
---
(In reply to comment #49)
> I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
> tried to wake the PCs from "DPMS OFF", only to find them completely
> unresponsi
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #50 from Da Fox 2010-09-08 05:02:14
PDT ---
(In reply to comment #49)
> I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
> tried to wake the PCs from "DPMS OFF", only to find them completely
> unresponsi
https://bugs.freedesktop.org/show_bug.cgi?id=29978
--- Comment #6 from Nicolas Kaiser 2010-09-08 01:55:05 PDT ---
Created an attachment (id=38540)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38540)
working output of MESA_GLSL=dump
For comparison purposes, this is the same output with me
https://bugs.freedesktop.org/show_bug.cgi?id=29978
--- Comment #6 from Nicolas Kaiser 2010-09-08 01:55:05 PDT
---
Created an attachment (id=38540)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38540)
working output of MESA_GLSL=dump
For comparison purposes, this is the same output with m
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #49 from Chris Rankin 2010-09-08 01:45:45
PDT ---
I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
tried to wake the PCs from "DPMS OFF", only to find them completely
unresponsive and needing a reboot in
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #49 from Chris Rankin 2010-09-08
01:45:45 PDT ---
I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
tried to wake the PCs from "DPMS OFF", only to find them completely
unresponsive and needing a reboot in
58 matches
Mail list logo
