https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #12 from runetmem...@gmail.com 2011-08-07 23:03:44 PDT ---
32 bit games require a 32 bit 3D driver, so make sure you also updated your 32
bit driver.
This bug is not reproduced for me on pure x86 setup of Ubuntu Oneiric with and
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler flor...@mickler.org changed:
What|Removed |Added
Resolution|CODE_FIX
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler flor...@mickler.org changed:
What|Removed |Added
Status|RESOLVED|CLOSED
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #16 from Florian Mickler flor...@mickler.org 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
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #13 from Sven Arvidsson s...@whiz.se 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
https://bugs.freedesktop.org/show_bug.cgi?id=39902
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Product|xorg|Mesa
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 flor...@mickler.org changed:
What|Removed |Added
CC||flor...@mickler.org
https://bugzilla.kernel.org/show_bug.cgi?id=40622
--- Comment #13 from Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de
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
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
On Sat, 6 Aug 2011 10:54:05 -0700
Keith Packard kei...@keithp.com 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.
On Sat, 6 Aug 2011 10:54:06 -0700
Keith Packard kei...@keithp.com 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 kei...@keithp.com
Yep, looks
On Sat, 6 Aug 2011 10:54:07 -0700
Keith Packard kei...@keithp.com 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
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard kei...@keithp.com wrote:
Just an extra parameter which isn't actually needed.
Signed-off-by: Keith Packard kei...@keithp.com
---
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett m...@redhat.com 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
On Mon, Aug 8, 2011 at 12:21 PM, Matthew Garrett m...@redhat.com 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
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
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
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
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
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
...to catch places like this where the wrong register gets used. :)
Ouch! There are only two places we *should* have these loops, one
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 stalk...@gmail.com 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:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
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
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
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
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yep, it's safe and possible to do on pre-PCH as
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #12 from runetmember at gmail.com 2011-08-07 23:03:44 PDT ---
> 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32
bit driver.
This bug is not reproduced for me on pure x86 setup of Ubuntu Oneiric with and
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE
---
https://bugzilla.kernel.org/show_bug.cgi?id=39672
Florian Mickler changed:
What|Removed |Added
Status|RESOLVED|CLOSED
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
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
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
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:
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
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
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
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
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
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
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
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:
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
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
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
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
55 matches
Mail list logo
