On Fri, Apr 22, 2011 at 4:17 PM, Jesse Barnes
wrote:
> On Sat, 16 Apr 2011 06:42:44 +1000
> Dave Airlie wrote:
>
>> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
>> wrote:
>> > On Sat, 16 Apr 2011 06:10:07 +1000
>> > Dave Airlie wrote:
>> >
>> >> > -
>> >> > +#define DRM_COLOR_FORMAT_RGB444 ?
On Tue, Apr 19, 2011 at 11:47:47PM +0200, Marcin Slusarz wrote:
> On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote:
> > On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
> > wrote:
> > >
> > > It's some nasty corruption:
> >
> > Looks like something wrote 0x to free'd memory.
On Fri, Apr 22, 2011 at 4:17 PM, Jesse Barnes wrote:
> On Sat, 16 Apr 2011 06:42:44 +1000
> Dave Airlie wrote:
>
>> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
>> wrote:
>> > On Sat, 16 Apr 2011 06:10:07 +1000
>> > Dave Airlie wrote:
>> >
>> >> > -
>> >> > +#define DRM_COLOR_FORMAT_RGB444
On Fri, Apr 22, 2011 at 3:58 PM, Chris Wilson
wrote:
> On Thu, 21 Apr 2011 16:08:14 -0600, Alex Williamson redhat.com> wrote:
>> If we're using vga switcheroo, the device may be turned off
>> and poking at it can cause an oops.
>
> I'm unfamiliar with what actually happens here after it is turne
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches
v3: no really, fix disable ordering
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_reg.h | 123 ++
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #6 from Alex Deucher 2011-04-22 14:45:06 PDT ---
Does mesa 7.10.2 work any better? Does your mesa tree have this patch:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.10&id=ed4aa47d429fdb682bec9b64e6350601aa7e5bc3
--
Configure b
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #6 from Alex Deucher 2011-04-22 14:45:06 PDT
---
Does mesa 7.10.2 work any better? Does your mesa tree have this patch:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.10&id=ed4aa47d429fdb682bec9b64e6350601aa7e5bc3
--
Configure
> > Any other changes you'd like? Or do the patches look ok now (though I
> > probably should have made the subject drm/edid rather than just drm).
>
>
> Was going to put them in -next as soon as I open it, its holidays I
> for one won't be doing squat until next Wednesday.
Np, thanks. Just wa
> > Any other changes you'd like? ?Or do the patches look ok now (though I
> > probably should have made the subject drm/edid rather than just drm).
>
>
> Was going to put them in -next as soon as I open it, its holidays I
> for one won't be doing squat until next Wednesday.
Np, thanks. Just wa
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #5 from Bryce Harrington 2011-04-22 13:43:26
PDT ---
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV620
OpenGL version string: 2.1 Mesa 7.10.1
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #5 from Bryce Harrington 2011-04-22
13:43:26 PDT ---
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV620
OpenGL version string: 2.1 Mesa 7.10.1
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #4 from Bryce Harrington 2011-04-22 13:41:20
PDT ---
Photos of the oops are on the upstream bug. Here's links to two of the clearer
photos (too big for bugzilla):
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bu
On Sat, Apr 23, 2011 at 6:17 AM, Jesse Barnes wrote:
> On Sat, 16 Apr 2011 06:42:44 +1000
> Dave Airlie wrote:
>
>> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
>> wrote:
>> > On Sat, 16 Apr 2011 06:10:07 +1000
>> > Dave Airlie wrote:
>> >
>> >> > -
>> >> > +#define DRM_COLOR_FORMAT_RGB444
https://bugs.freedesktop.org/show_bug.cgi?id=36508
--- Comment #4 from Bryce Harrington 2011-04-22
13:41:20 PDT ---
Photos of the oops are on the upstream bug. Here's links to two of the clearer
photos (too big for bugzilla):
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bu
https://bugs.freedesktop.org/show_bug.cgi?id=36508
Alex Deucher changed:
What|Removed |Added
Product|xorg|DRI
Version|7.6
https://bugs.freedesktop.org/show_bug.cgi?id=36508
Alex Deucher changed:
What|Removed |Added
Product|xorg|DRI
Version|7.6
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie wrote:
> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444 (1<<0)
> >> > +#define DRM_COLOR_FORMAT_YCRCB444
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie wrote:
> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444 ? ? ? ? ? ? ? ?(1<<0)
> >> > +#define DRM_COLOR_FORMAT_YCRCB444 ? ?
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #3 from Sven Arvidsson 2011-04-22 12:33:19 PDT ---
(In reply to comment #2)
> Yes it is still relevant, unfortunately. On my Thinkpad T41 at least (ATI
> Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]).
Isn't this r20
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #3 from Sven Arvidsson 2011-04-22 12:33:19 PDT ---
(In reply to comment #2)
> Yes it is still relevant, unfortunately. On my Thinkpad T41 at least (ATI
> Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]).
Isn't this r20
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #2 from Mario Blättermann 2011-04-22 12:20:31
PDT ---
(In reply to comment #1)
> Is this bug still relevant? At least on my system Clutter apps (GNOME Games,
> GNOME Shell) seems to work without problems.
Yes it is still relevant, u
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #2 from Mario Bl?ttermann 2011-04-22
12:20:31 PDT ---
(In reply to comment #1)
> Is this bug still relevant? At least on my system Clutter apps (GNOME Games,
> GNOME Shell) seems to work without problems.
Yes it is still relevant, u
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding
On Tue, Apr 19, 2011 at 11:47:47PM +0200, Marcin Slusarz wrote:
> On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote:
> > On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz
> > wrote:
> > >
> > > It's some nasty corruption:
> >
> > Looks like something wrote 0x to free'd memory.
Calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE is broken if the
macro is used directly, because the define contains a typo. When using
libdrm you do not hit the bug, since libdrm handles the ioctl encoding
internally.
The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl
struct
From: Dave Airlie
Multi-gpu/switcheroo relies on this option to get the console on the
correct GPU at bootup, some distros enable it but it seems some get
it wrong.
cc: stable at kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Kconfig |1 +
1 files changed, 1 insertions(+), 0 del
On Fri, 22 Apr 2011 16:13:27 +1000, Dave Airlie wrote:
> On Fri, Apr 22, 2011 at 3:58 PM, Chris Wilson
> wrote:
> > On Thu, 21 Apr 2011 16:08:14 -0600, Alex Williamson > redhat.com> wrote:
> >> If we're using vga switcheroo, the device may be turned off
> >> and poking at it can cause an oops.
On Thu, 21 Apr 2011 16:08:14 -0600, Alex Williamson wrote:
> If we're using vga switcheroo, the device may be turned off
> and poking at it can cause an oops.
I'm unfamiliar with what actually happens here after it is turned off. Can
you post an OOPS for an example?
-Chris
--
Chris Wilson, Inte
Calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE is broken if the
macro is used directly, because the define contains a typo. When using
libdrm you do not hit the bug, since libdrm handles the ioctl encoding
internally.
The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl
struct
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding
31 matches
Mail list logo
