https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|PATCH_ALREAD
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #16 from Florian Mickler 2011-08-08 01:49:13
PDT ---
A patch referencing this bug report has been merged in Linux v3.1-rc1:
commit c41b9ee901bb2c7e3eacfa7e171de50c15d61c0b
Author: Alex Deucher
Date: Sat Jul 30 18:12:24 2011 +
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #13 from Sven Arvidsson 2011-08-08 03:38:00 PDT ---
(In reply to comment #11)
> I have two questions though
> - "32 bit games require a 32 bit 3D driver" : how do we check that ?
> LIBGL_DEBUG=verbose glxinfo ?
> In my case, it opens
https://bugs.freedesktop.org/show_bug.cgi?id=39902
Michel Dänzer changed:
What|Removed |Added
Product|xorg|Mesa
Version|unspecified
https://bugs.freedesktop.org/show_bug.cgi?id=36396
m...@tvk.rwth-aachen.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=39422
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #10
https://bugzilla.kernel.org/show_bug.cgi?id=40622
--- Comment #13 from Torsten Krah
2011-08-08 15:43:11 ---
Oh didn't know this may be possible, my fault, sorry.
If X console is not active all seems to work find - resolution stays the same,
so it seems to be a Xorg only problem.
Do you have
We have two sources of information about panel capabilities on mobile
radeon - the BIOS, which gives us a native mode, and the panel's preferred
mode. In theory these two will always match, but there's some corner cases
where the BIOS hasn't been fully initialised and so the native mode in it
ends
At least some Apples program the GPU into a state that wedges the engine
once userspace starts trying to perform accelerated operations. Executing
the Atom init scripts gets the hardware back into a working state. The
same hardware works fine when booted via BIOS emulation, so let's just
execute th
On Sat, 6 Aug 2011 10:54:05 -0700
Keith Packard wrote:
> During mode setting, check to make sure the panel power sequencing has
> completed before doing further operations on the device. This
> uncovered errors with DPMS not turning the device off as it was left locked.
>
> Signed-off-by: Keith
On Sat, 6 Aug 2011 10:54:06 -0700
Keith Packard wrote:
> There's no reason to relock them; it just makes operations more
> complex. This fixes DPMS where the panel registers were locked making
> the disable not work.
>
> Signed-off-by: Keith Packard
Yep, looks fine. The only think we might w
On Sat, 6 Aug 2011 10:54:07 -0700
Keith Packard wrote:
> CPT pipe select is different from previous generations (using two bits
> instead of one). All of the paths from intel_disable_pch_ports were
> not making this distinction.
>
> Mode setting with pipe A turned off would then also force all
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard wrote:
> Just an extra parameter which isn't actually needed.
>
> Signed-off-by: Keith Packard
> ---
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mail
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett wrote:
> We have two sources of information about panel capabilities on mobile
> radeon - the BIOS, which gives us a native mode, and the panel's preferred
> mode. In theory these two will always match, but there's some corner cases
> where the BIOS
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett wrote:
> At least some Apples program the GPU into a state that wedges the engine
> once userspace starts trying to perform accelerated operations. Executing
> the Atom init scripts gets the hardware back into a working state. The
> same hardware wo
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
wrote:
> Yep, looks fine. The only think we might want to sprinkle about are
> checks for panel off so we can avoid visible corruption if we whack
> timing or fb stuff while the panel is on.
Yeah, could do. Would be nice to somehow get the LVDS c
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
wrote:
> ...to catch places like this where the wrong register gets used. :)
Ouch! There are only two places we *should* have these loops, one when
turning it off, another when turning it on. There's a couple of loops
which just need to be removed
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
wrote:
> Yep, looks fine. The only think we might want to sprinkle about are
> checks for panel off so we can avoid visible corruption if we whack
> timing or fb stuff while the panel is on.
So, I'd like to know if we could unlock the panel regis
On Mon, 08 Aug 2011 11:42:56 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
> wrote:
>
> > Yep, looks fine. The only think we might want to sprinkle about are
> > checks for panel off so we can avoid visible corruption if we whack
> > timing or fb stuff while the
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
> wrote:
>
> > ...to catch places like this where the wrong register gets used. :)
>
> Ouch! There are only two places we *should* have these loops, one when
> turning it off, another whe
https://bugs.freedesktop.org/show_bug.cgi?id=39940
Summary: OilRush shader water artefacts after GLSL-To-TGSI
commit
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=39940
--- Comment #1 from Uriy Zhuravlev 2011-08-08 12:43:36 PDT
---
Created an attachment (id=50038)
--> (https://bugs.freedesktop.org/attachment.cgi?id=50038)
Normal water, before GLSL-To-TGSI
--
Configure bugmail: https://bugs.freedesktop.org/us
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
wrote:
> Yep, it's safe and possible to do on pre-PCH as well. For panel
> fitting we do need to do an actual power cycle when going from
> non-native back to native iirc, but we can still leave them unlocked so
> we don't have to worry about the
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> wrote:
>
> > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > fitting we do need to do an actual power cycle when going from
> > non-native back to native iirc, but w
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
wrote:
> On Mon, 08 Aug 2011 12:53:31 -0700
> Keith Packard wrote:
>
> > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> > wrote:
> >
> > > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > > fitting we do need to do an act
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
> wrote:
> > On Mon, 08 Aug 2011 12:53:31 -0700
> > Keith Packard wrote:
> >
> > > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> > > wrote:
> > >
> > > > Yep, it's safe and possibl
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #14 from Alex 2011-08-08 23:30:18 PDT
---
alex@Leon:~/Projects/Games/CrayonPhysicsDeluxe$ LIBGL_DEBUG=verbose ./launcher
libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL
This patch fixes the following 'make headers_check' errors:
linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without
#include
linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without
#include
linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,1
https://bugs.freedesktop.org/show_bug.cgi?id=39953
Summary: Flicker after waking from DPMS sleep
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medi
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|PATCH_ALREAD
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #16 from Florian Mickler 2011-08-08
01:49:13 PDT ---
A patch referencing this bug report has been merged in Linux v3.1-rc1:
commit c41b9ee901bb2c7e3eacfa7e171de50c15d61c0b
Author: Alex Deucher
Date: Sat Jul 30 18:12:24 2011 +
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #13 from Sven Arvidsson 2011-08-08 03:38:00 PDT ---
(In reply to comment #11)
> I have two questions though
> - "32 bit games require a 32 bit 3D driver" : how do we check that ?
> LIBGL_DEBUG=verbose glxinfo ?
> In my case, it opens
https://bugs.freedesktop.org/show_bug.cgi?id=39902
Michel D?nzer changed:
What|Removed |Added
Product|xorg|Mesa
Version|unspecified
https://bugs.freedesktop.org/show_bug.cgi?id=36396
mark at tvk.rwth-aachen.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=39422
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=40622
--- Comment #13 from Torsten Krah
2011-08-08 15:43:11 ---
Oh didn't know this may be possible, my fault, sorry.
If X console is not active all seems to work find - resolution stays the same,
so it seems to be a Xorg only problem.
Do you have
We have two sources of information about panel capabilities on mobile
radeon - the BIOS, which gives us a native mode, and the panel's preferred
mode. In theory these two will always match, but there's some corner cases
where the BIOS hasn't been fully initialised and so the native mode in it
ends
At least some Apples program the GPU into a state that wedges the engine
once userspace starts trying to perform accelerated operations. Executing
the Atom init scripts gets the hardware back into a working state. The
same hardware works fine when booted via BIOS emulation, so let's just
execute th
On Sat, 6 Aug 2011 10:54:05 -0700
Keith Packard wrote:
> During mode setting, check to make sure the panel power sequencing has
> completed before doing further operations on the device. This
> uncovered errors with DPMS not turning the device off as it was left locked.
>
> Signed-off-by: Keith
On Sat, 6 Aug 2011 10:54:06 -0700
Keith Packard wrote:
> There's no reason to relock them; it just makes operations more
> complex. This fixes DPMS where the panel registers were locked making
> the disable not work.
>
> Signed-off-by: Keith Packard
Yep, looks fine. The only think we might w
On Sat, 6 Aug 2011 10:54:07 -0700
Keith Packard wrote:
> CPT pipe select is different from previous generations (using two bits
> instead of one). All of the paths from intel_disable_pch_ports were
> not making this distinction.
>
> Mode setting with pipe A turned off would then also force all
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard wrote:
> Just an extra parameter which isn't actually needed.
>
> Signed-off-by: Keith Packard
> ---
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett wrote:
> We have two sources of information about panel capabilities on mobile
> radeon - the BIOS, which gives us a native mode, and the panel's preferred
> mode. In theory these two will always match, but there's some corner cases
> where the BIOS
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett wrote:
> At least some Apples program the GPU into a state that wedges the engine
> once userspace starts trying to perform accelerated operations. Executing
> the Atom init scripts gets the hardware back into a working state. The
> same hardware wo
able
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110808/1a6cd59e/attachment.pgp>
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
wrote:
> ...to catch places like this where the wrong register gets used. :)
Ouch! There are only two places we *should* have these loops, one when
turning it off, another when turning it on. There's a couple of loops
which just need to be removed
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
wrote:
> Yep, looks fine. The only think we might want to sprinkle about are
> checks for panel off so we can avoid visible corruption if we whack
> timing or fb stuff while the panel is on.
So, I'd like to know if we could unlock the panel regis
On Mon, 08 Aug 2011 11:42:56 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
> wrote:
>
> > Yep, looks fine. The only think we might want to sprinkle about are
> > checks for panel off so we can avoid visible corruption if we whack
> > timing or fb stuff while the
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
> wrote:
>
> > ...to catch places like this where the wrong register gets used. :)
>
> Ouch! There are only two places we *should* have these loops, one when
> turning it off, another whe
https://bugs.freedesktop.org/show_bug.cgi?id=39940
Summary: OilRush shader water artefacts after GLSL-To-TGSI
commit
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=39940
--- Comment #1 from Uriy Zhuravlev 2011-08-08 12:43:36
PDT ---
Created an attachment (id=50038)
--> (https://bugs.freedesktop.org/attachment.cgi?id=50038)
Normal water, before GLSL-To-TGSI
--
Configure bugmail: https://bugs.freedesktop.org/us
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
wrote:
> Yep, it's safe and possible to do on pre-PCH as well. For panel
> fitting we do need to do an actual power cycle when going from
> non-native back to native iirc, but we can still leave them unlocked so
> we don't have to worry about the
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> wrote:
>
> > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > fitting we do need to do an actual power cycle when going from
> > non-native back to native iirc, but w
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
wrote:
> On Mon, 08 Aug 2011 12:53:31 -0700
> Keith Packard wrote:
>
> > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > > fitting we do ne
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
> wrote:
> > On Mon, 08 Aug 2011 12:53:31 -0700
> > Keith Packard wrote:
> >
> > > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes > > virtuousgeek.org> wrote:
> > >
> > > > Yep, it's s
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #14 from Alex 2011-08-08 23:30:18
PDT ---
alex at Leon:~/Projects/Games/CrayonPhysicsDeluxe$ LIBGL_DEBUG=verbose
./launcher
libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
l
This patch fixes the following 'make headers_check' errors:
linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without
#include
linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without
#include
linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,1
https://bugs.freedesktop.org/show_bug.cgi?id=39953
Summary: Flicker after waking from DPMS sleep
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medi
60 matches
Mail list logo
