This has originally been added in
commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
Author: Dave Airlie
Date: Mon Aug 31 15:16:30 2009 +1000
drm/kms: add explicit encoder disable function and detach harder.
I think it's the wrong thing to do for a few reasons:
- It's policy in the kernel. U
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
On Sat, Jun 15, 2013 at 10:27:06PM +0200, Rafael J. Wysocki wrote:
> On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> > Hi all,
> >
> > So to me it looks like the discussion is going in circles a bit, hence let
> > me drop my maintainer-opinion here:
> >
> > 1. Matthew's patch series
On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> Hi all,
>
> So to me it looks like the discussion is going in circles a bit, hence let
> me drop my maintainer-opinion here:
>
> 1. Matthew's patch series here looks reasonable, and if it fixes a bunch
> of systems (which it seems to)
ions of the game worked.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130615/7f281461/attachment-0001.html>
On Fri, Jun 14, 2013 at 01:39:05PM -0700, St?phane Marchesin wrote:
> The structure was kzalloced, so prev == next == NULL by default which
> is invalid.
>
> Signed-off-by: St?phane Marchesin
We do a list_add_tail which doesn't seem to care about unitizalized list
items, and when removing it we
Hi all,
So to me it looks like the discussion is going in circles a bit, hence let
me drop my maintainer-opinion here:
1. Matthew's patch series here looks reasonable, and if it fixes a bunch
of systems (which it seems to) it has my Ack and imo should go in. If acpi
maintainers can smash their Ac
On 06/15/2013 12:19 PM, Matthew Garrett wrote:
> On Sat, Jun 15, 2013 at 12:14:42PM +0800, Aaron Lu wrote:
>> On 06/15/2013 09:38 AM, Matthew Garrett wrote:
>>> Well, Windows 8 will only use the ACPI backlight interface if the GPU
>>> driver decides to, right? So the logic for deciding whether to r
https://bugs.freedesktop.org/show_bug.cgi?id=63520
Tom Stellard changed:
What|Removed |Added
Attachment #79572|0 |1
is obsolete|
On Sat, Jun 15, 2013 at 08:29:42PM +0200, Daniel Vetter wrote:
> Aside at the end: If the gnome tool indeed has its own backlight code and
> doesn't just use that as a fallback if the xrandr backligh property isn't
> available, then that's just a serious bug in gnome and should be fixed
> asap. Bu
https://bugzilla.kernel.org/show_bug.cgi?id=59761
Summary: Kernel fails to reset AMD HD5770 GPU properly and
encounters OOPS. GPU reset fails - system remains in
unusable state.
Product: Drivers
Version: 2.5
Kernel Versio
When cleanup extra stat if this object was a notifier,it should free the
notifier.
Signed-off-by: Jianpeng Ma
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nou
On Sat, Jun 15, 2013 at 08:29:15PM +0800, Aaron Lu wrote:
> On 06/15/2013 12:19 PM, Matthew Garrett wrote:
> > The vendor will presumably have tested that backlight control works - if
> > the GPU driver uses the ACPI interface and backlight control is broken,
> > then the vendor would fix it.
>
https://bugs.freedesktop.org/show_bug.cgi?id=65803
Priority: medium
Bug ID: 65803
Assignee: dri-devel@lists.freedesktop.org
Summary: r600g: segfault with Kerbal Space Program
Severity: normal
Classification: Unclassified
OS:
This has originally been added in
commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
Author: Dave Airlie
Date: Mon Aug 31 15:16:30 2009 +1000
drm/kms: add explicit encoder disable function and detach harder.
I think it's the wrong thing to do for a few reasons:
- It's policy in the kernel. U
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
On Sat, Jun 15, 2013 at 10:27:06PM +0200, Rafael J. Wysocki wrote:
> On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> > Hi all,
> >
> > So to me it looks like the discussion is going in circles a bit, hence let
> > me drop my maintainer-opinion here:
> >
> > 1. Matthew's patch series
On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> Hi all,
>
> So to me it looks like the discussion is going in circles a bit, hence let
> me drop my maintainer-opinion here:
>
> 1. Matthew's patch series here looks reasonable, and if it fixes a bunch
> of systems (which it seems to)
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130615/31917053/attachment.html>
ML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130615/0a16972f/attachment.html>
On 06/15/2013 09:38 AM, Matthew Garrett wrote:
> On Sat, 2013-06-15 at 09:26 +0800, Aaron Lu wrote:
>> It's not easy to decide if they work or not sometimes, e.g. I came
>> across a system that claims win8 in ACPI table and has an Intel GPU,
>> while its ACPI video interface also works. With this p
is needed or not, the typo should
be fixed, so:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130615/444b2f3f/attachment.pgp>
On Fri, Jun 14, 2013 at 01:39:05PM -0700, Stéphane Marchesin wrote:
> The structure was kzalloced, so prev == next == NULL by default which
> is invalid.
>
> Signed-off-by: Stéphane Marchesin
We do a list_add_tail which doesn't seem to care about unitizalized list
items, and when removing it we
On Sat, Jun 15, 2013 at 08:29:42PM +0200, Daniel Vetter wrote:
> Aside at the end: If the gnome tool indeed has its own backlight code and
> doesn't just use that as a fallback if the xrandr backligh property isn't
> available, then that's just a serious bug in gnome and should be fixed
> asap. Bu
Hi all,
So to me it looks like the discussion is going in circles a bit, hence let
me drop my maintainer-opinion here:
1. Matthew's patch series here looks reasonable, and if it fixes a bunch
of systems (which it seems to) it has my Ack and imo should go in. If acpi
maintainers can smash their Ac
https://bugzilla.kernel.org/show_bug.cgi?id=59761
Summary: Kernel fails to reset AMD HD5770 GPU properly and
encounters OOPS. GPU reset fails - system remains in
unusable state.
Product: Drivers
Version: 2.5
Kernel Versio
On 06/15/2013 01:29 AM, Matthew Garrett wrote:
> On Fri, 2013-06-14 at 14:47 +0800, Aaron Lu wrote:
>
>> What about a priority based solution? We can introduce a new field named
>> priority to backlight_device and instead of calling another module's
>> function like the unregister one here(which c
On Thu, Jun 13, 2013 at 6:31 AM, Paul Bolle wrote:
> On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote:
>> Signed-off-by: Paul Bolle
>> ---
>> Untested. Perhaps the first test that people with access to the relevant
>> hardware might do, is to test _before applying this patch_ with FB_OMAP2
>>
On Sat, Jun 15, 2013 at 08:29:15PM +0800, Aaron Lu wrote:
> On 06/15/2013 12:19 PM, Matthew Garrett wrote:
> > The vendor will presumably have tested that backlight control works - if
> > the GPU driver uses the ACPI interface and backlight control is broken,
> > then the vendor would fix it.
>
On 06/15/2013 12:19 PM, Matthew Garrett wrote:
> On Sat, Jun 15, 2013 at 12:14:42PM +0800, Aaron Lu wrote:
>> On 06/15/2013 09:38 AM, Matthew Garrett wrote:
>>> Well, Windows 8 will only use the ACPI backlight interface if the GPU
>>> driver decides to, right? So the logic for deciding whether to r
When cleanup extra stat if this object was a notifier,it should free the
notifier.
Signed-off-by: Jianpeng Ma
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouv
On 06/15/2013 09:38 AM, Matthew Garrett wrote:
> On Sat, 2013-06-15 at 09:26 +0800, Aaron Lu wrote:
>> It's not easy to decide if they work or not sometimes, e.g. I came
>> across a system that claims win8 in ACPI table and has an Intel GPU,
>> while its ACPI video interface also works. With this p
On Sat, 2013-06-15 at 09:26 +0800, Aaron Lu wrote:
> On 06/15/2013 01:29 AM, Matthew Garrett wrote:
> > How would that work with existing userspace?
>
> User space tool will need to be updated to use this as stated in the
> gist page, I've patches for gsd-backlight-helper and xorg-x11-drv-intel,
On 06/15/2013 01:29 AM, Matthew Garrett wrote:
> On Fri, 2013-06-14 at 14:47 +0800, Aaron Lu wrote:
>
>> What about a priority based solution? We can introduce a new field named
>> priority to backlight_device and instead of calling another module's
>> function like the unregister one here(which c
On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
> wrote:
> > If you're happy with the patch I supplied, that's probably the minimal fix
> > which should go to stable kernels (I'm using 3.9 here) - this also counts
> > as a
The structure was kzalloced, so prev == next == NULL by default which
is invalid.
Signed-off-by: Stéphane Marchesin
---
drivers/gpu/drm/drm_irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8bcce78..143a311 100644
--- a/drivers/
On Fri, 2013-06-14 at 14:47 +0800, Aaron Lu wrote:
> What about a priority based solution? We can introduce a new field named
> priority to backlight_device and instead of calling another module's
> function like the unregister one here(which cause unnecessary module
> dependency), we only need to
On Friday 14 June 2013 12:39 AM, Stephen Warren wrote:
On 06/13/2013 12:49 PM, Thierry Reding wrote:
On Thu, Jun 13, 2013 at 03:23:37PM +0530, Mayuresh Kulkarni wrote:
[...]
diff --git a/drivers/gpu/host1x/drm/dc.c
b/drivers/gpu/host1x/drm/dc.c
[...]
@@ -1128,9 +1129,7 @@ static int tegra_dc_
On Thursday 13 June 2013 08:44 PM, Stephen Warren wrote:
On 06/13/2013 03:53 AM, Mayuresh Kulkarni wrote:
Patch description?
I thought the patch subject is sufficient to tell what it is it doing.
Description here would be repetition in my opinion.
Also, the cover letter for the patch-set se
On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
> wrote:
> > There's a bigger issue here - if it's possible for
> > drm_crtc_helper_set_config()
> > to be called with set->fb set but set->mode NULL, then we overwrite
> > s
On Fri, Jun 14, 2013 at 03:53:41PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > > a
On 06/10/2013 07:01 AM, Matthew Garrett wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's brok
https://bugs.freedesktop.org/show_bug.cgi?id=65787
--- Comment #1 from Harald Judt ---
Problem with similar elements in game. But other texts are readable.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=65787
Priority: medium
Bug ID: 65787
Assignee: dri-devel@lists.freedesktop.org
Summary: r600g: corruption in menu in "stunt rally"
Severity: normal
Classification: Unclassified
OS:
On Thu, Jun 13, 2013 at 6:31 AM, Paul Bolle wrote:
> On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote:
>> Signed-off-by: Paul Bolle
>> ---
>> Untested. Perhaps the first test that people with access to the relevant
>> hardware might do, is to test _before applying this patch_ with FB_OMAP2
>>
On Sat, Jun 15, 2013 at 12:14:42PM +0800, Aaron Lu wrote:
> On 06/15/2013 09:38 AM, Matthew Garrett wrote:
> > Well, Windows 8 will only use the ACPI backlight interface if the GPU
> > driver decides to, right? So the logic for deciding whether to remove
> > the ACPI backlight control or not should
On Wed, Mar 13, 2013 at 08:48:22PM +0100, Paul Bolle wrote:
> Signed-off-by: Paul Bolle
> ---
> Untested. Perhaps the first test that people with access to the relevant
> hardware might do, is to test _before applying this patch_ with FB_OMAP2
> set. Perhaps this negative dependency isn't needed a
On Sat, 2013-06-15 at 09:26 +0800, Aaron Lu wrote:
> On 06/15/2013 01:29 AM, Matthew Garrett wrote:
> > How would that work with existing userspace?
>
> User space tool will need to be updated to use this as stated in the
> gist page, I've patches for gsd-backlight-helper and xorg-x11-drv-intel,
On Sat, Jun 15, 2013 at 12:15 AM, Russell King - ARM Linux
wrote:
> On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
>> wrote:
>> > If you're happy with the patch I supplied, that's probably the minimal fix
>> > which shou
Drivers are allowed (actually have to) disable unrelated crtcs in
their ->set_config callback (when we steal all the connectors from
that crtc). If they do that they'll clear crtc->fb to NULL.
Which results in a refcount leak, since the drm core is keeping track
of that reference.
To fix this tra
Historically drm lacked fb refcounting, so the updating of crtc->fb
was done by the lower levels at a point convenient to get their own
refcounting (e.g. refcounts for the underlying gem bo, pinning
refcounts) right. With the introduction of refcounted fbs the drm core
handled the fb refcounts, but
This has originally been added in
commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
Author: Dave Airlie
Date: Mon Aug 31 15:16:30 2009 +1000
drm/kms: add explicit encoder disable function and detach harder.
I think it's the wrong thing to do for a few reasons:
- It's policy in the kernel. U
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
... since we already check for fb->pixel_format, which encodes all
this. The other two fields are only for backwards compat of older
drivers (and we might want to look into eventually just killing them).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |5 -
1 file chan
There's no point in trying to clean up after driver-bugs, so just blow
up. Furthermore it's an interface abuse to set no mode but have an fb
and aslo to try to set an fb without enough connectors. These two
spefici cases of interface abuse have been committed by the fb helper,
but that's been fixed
Hi all,
Russell found a refcount bug in my fb refcounting conversion, but to also fix
i915.ko I've opted for a slightly different approach.
While at it I've thought it would be good to backport some of the semantic
changes we've implented in i915's ->set_config callback since we've forked our
own
56 matches
Mail list logo
