https://bugzilla.kernel.org/show_bug.cgi?id=33912
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #9 f
On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote:
> On Thu, 09 Jun 2011 14:05:59 +1000
> Dave Airlie wrote:
>
> > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > > To properly support the various plane formats supported by different
> > > hardware, the kernel must know the pixel forma
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
https://bugzilla.kernel.org/show_bug.cgi?id=33912
Vish changed:
What|Removed |Added
Kernel Version|.35 .36 .37 .38 |.35, .36, .37, .38, .39
--- Comment #8 from Vi
https://bugs.freedesktop.org/show_bug.cgi?id=38089
--- Comment #2 from Alexandre Demers 2011-06-09
19:58:59 PDT ---
Since it only happens when I use Diablo 2 with Glide, it is probably related to
the Glide to OpenGL wrapper. If indeed the extension is not supported in r600g,
then it is related t
https://bugs.freedesktop.org/show_bug.cgi?id=38089
--- Comment #2 from Alexandre Demers
2011-06-09 19:58:59 PDT ---
Since it only happens when I use Diablo 2 with Glide, it is probably related to
the Glide to OpenGL wrapper. If indeed the extension is not supported in r600g,
then it is related t
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook
wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> ?alpha, drm: Update Alpha DRM support
> ?alpha, drm: Cleanup
Alpha needs to have the system bus address for the device's local
memory available, so that it can be returned to user-level, where
it may be used in an mmap(). So, we make bus.addr hold the ioremap()
return for kernel use, and then we can modify bus.base appropriately.
Signed-off-by: Jay Estabro
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/mga/mga_drv.h | 19 ---
1 file changed, 19 deletions(-)
diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h
--- a/drivers/gpu/drm/mga/mga_
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/drm_bufs.c|3 ---
drivers/gpu/drm/drm_vm.c |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff -Naurp a/drivers/
This patch set fixes Alpha-specific support in the DRM code,
allowing Radeon KMS and the MGA driver to work properly on
Alpha-based machines.
Jay
Jay Estabrook (3):
alpha, drm: Update Alpha DRM support
alpha, drm: Cleanup Alpha support in DRM generic code
alpha, drm: Remove obsolete Alpha
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> alpha, drm: Update Alpha DRM support
> alpha, drm: Cleanup A
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/mga/mga_drv.h | 19 ---
1 file changed, 19 deletions(-)
diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h
--- a/drivers/gpu/drm/mga/mga_
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/drm_bufs.c|3 ---
drivers/gpu/drm/drm_vm.c |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff -Naurp a/drivers/
This patch set fixes Alpha-specific support in the DRM code,
allowing Radeon KMS and the MGA driver to work properly on
Alpha-based machines.
Jay
Jay Estabrook (3):
alpha, drm: Update Alpha DRM support
alpha, drm: Cleanup Alpha support in DRM generic code
alpha, drm: Remove obsolete Alpha
Alpha needs to have the system bus address for the device's local
memory available, so that it can be returned to user-level, where
it may be used in an mmap(). So, we make bus.addr hold the ioremap()
return for kernel use, and then we can modify bus.base appropriately.
Signed-off-by: Jay Estabro
> [ 10.169900] [drm] radeon kernel modesetting enabled.
> [ 10.170270] radeon :02:00.0: enabling device (0080 -> 0083)
> [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
> [ 10.171044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> [ 1
> > So it decides this modeline is usable for the console while it is not.
>
> Ah, ok. yeah, that mode has a much higher clock than those chips can
> handle. Where is that mode even coming from? I don't see it in the
> EDID. The attached patch should filter out that mode.
It works, thank you!
On Fri, 2011-06-03 at 12:54 +0200, Sascha Hauer wrote:
> The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
> That is because the framebuffers for each file are in the filp_head
> member of struct drm_framebuffer, not in the head member.
>
> Signed-off-by: Sascha Hauer
> ---
On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> To properly support the various plane formats supported by different
> hardware, the kernel must know the pixel format of a framebuffer object.
> So add a new ioctl taking a format argument corresponding to a fourcc
> name from videodev2.h.
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> > You also don't need a headwer with a complete list of fourcc names in it,
> > that is the half the point of FourCC.
>
> #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> RGB-3-3-2 */
>
> See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just hel
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
> On Wed, 8 Jun 2011 11:41:17 +0200
> Marcus Lorentzon wrote:
>
>
>> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
>>
>>> On Tue, 7 Jun 2011 13:07:39 -0700
>>> Jesse Barnes wrote:
>>>
>>>
>>>
+/* Planes blend with or override othe
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #10 from Harald Judt 2011-06-09 10:36:13 PDT ---
Bug 27523 seems similar, but not identical to this one.
https://bugs.freedesktop.org/show_bug.cgi?id=27523
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #10 from Harald Judt 2011-06-09 10:36:13 PDT ---
Bug 27523 seems similar, but not identical to this one.
https://bugs.freedesktop.org/show_bug.cgi?id=27523
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=38089
--- Comment #1 from Ian Romanick 2011-06-09 10:18:17 PDT
---
That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support
GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is
an application bug.
I'll leave it to
On Thu, 2011-06-09 at 10:24 +1000, skeggsb at gmail.com wrote:
> From: Ben Skeggs
>
> Nouveau is going to use these hooks to map/unmap objects from a client's
> private GPU address space.
Forgot the v2 notes.. inlined below..
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/drm_gem.c |
From: Ben Skeggs
Nouveau is going to use these hooks to map/unmap objects from a client's
private GPU address space.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/drm_gem.c | 21 +++--
include/drm/drmP.h|2 ++
2 files changed, 21 insertions(+), 2 deletions(-)
dif
https://bugs.freedesktop.org/show_bug.cgi?id=38089
--- Comment #1 from Ian Romanick 2011-06-09 10:18:17
PDT ---
That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support
GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is
an application bug.
I'll leave it to
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #9 from Harald Judt 2011-06-09 10:13:49 PDT ---
> However, it's a bit better now, as it did not happen during normal
> desktop usage (till now).
I spoke too soon. Problem is still there :-(
--
Configure bugmail: https://bugs.freede
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #9 from Harald Judt 2011-06-09 10:13:49 PDT ---
> However, it's a bit better now, as it did not happen during normal
> desktop usage (till now).
I spoke too soon. Problem is still there :-(
--
Configure bugmail: https://bugs.freede
On Thu, 09 Jun 2011 14:05:59 +1000
Dave Airlie wrote:
> On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > To properly support the various plane formats supported by different
> > hardware, the kernel must know the pixel format of a framebuffer object.
> > So add a new ioctl taking a form
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
> [ 10.169900] [drm] radeon kernel modesetting enabled.
> [ 10.170270] radeon :02:00.0: enabling device (0080 -> 0083)
> [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
> [ 10.171044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> [ 1
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #8 from almos 2011-06-09 07:59:43 PDT ---
(In reply to comment #6)
> > I don't consider Hyper-Z ready yet but thanks for testing it.
>
> It is enabled by default now, is it by accident?
Perhaps you mean that it always reports this?
r
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #8 from almos 2011-06-09 07:59:43 PDT ---
(In reply to comment #6)
> > I don't consider Hyper-Z ready yet but thanks for testing it.
>
> It is enabled by default now, is it by accident?
Perhaps you mean that it always reports this?
r
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #7 from Marek Olšák 2011-06-09 07:21:05 PDT ---
(In reply to comment #6)
> > I don't consider Hyper-Z ready yet but thanks for testing it.
>
> It is enabled by default now, is it by accident?
It's disabled. There are some annoying b
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #7 from Marek Ol??k 2011-06-09 07:21:05 PDT
---
(In reply to comment #6)
> > I don't consider Hyper-Z ready yet but thanks for testing it.
>
> It is enabled by default now, is it by accident?
It's disabled. There are some annoying
https://bugs.freedesktop.org/show_bug.cgi?id=37168
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--- Comment #5 from Sven A
https://bugs.freedesktop.org/show_bug.cgi?id=37168
Sven Arvidsson changed:
What|Removed |Added
CC||sa at whiz.se
--- Comment #5 from Sven
https://bugzilla.kernel.org/show_bug.cgi?id=37032
Andrew Morton changed:
What|Removed |Added
CC||akpm at linux-foundation.org
Co
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> > You also don't need a headwer with a complete list of fourcc names in it,
> > that is the half the point of FourCC.
>
> #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> RGB-3-3-2 */
>
> See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just hel
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> > So it decides this modeline is usable for the console while it is not.
>
> Ah, ok. yeah, that mode has a much higher clock than those chips can
> handle. Where is that mode even coming from? I don't see it in the
> EDID. The attached patch should filter out that mode.
It works, thank you!
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #6 from Fabio Pedretti 2011-06-09 04:37:34
PDT ---
> I don't consider Hyper-Z ready yet but thanks for testing it.
It is enabled by default now, is it by accident?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?t
https://bugs.freedesktop.org/show_bug.cgi?id=37724
--- Comment #6 from Fabio Pedretti 2011-06-09 04:37:34
PDT ---
> I don't consider Hyper-Z ready yet but thanks for testing it.
It is enabled by default now, is it by accident?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?t
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #17 from Henri Verbeet 2011-06-09 04:30:29 PDT
---
I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to
Wine first for that to work.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #17 from Henri Verbeet 2011-06-09 04:30:29
PDT ---
I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to
Wine first for that to work.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #16 from Henri Verbeet 2011-06-09 04:27:59 PDT
---
(In reply to comment #15)
> Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
>
> So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod"
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #16 from Henri Verbeet 2011-06-09 04:27:59
PDT ---
(In reply to comment #15)
> Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
>
> So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod"
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #15 from Sven Arvidsson 2011-06-09 04:02:32 PDT ---
Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod"
would cause it to fall back to
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #15 from Sven Arvidsson 2011-06-09 04:02:32 PDT ---
Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod"
would cause it to fall back to
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #14 from Henri Verbeet 2011-06-09 03:57:31 PDT
---
(In reply to comment #10)
> Is there a way to disable the shader model 3.0 in Wine/DX9?
Not at the moment, but I'm considering adding a registry key to limit the
maximum exposed shad
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #14 from Henri Verbeet 2011-06-09 03:57:31
PDT ---
(In reply to comment #10)
> Is there a way to disable the shader model 3.0 in Wine/DX9?
Not at the moment, but I'm considering adding a registry key to limit the
maximum exposed shad
On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote:
> On Thu, 09 Jun 2011 14:05:59 +1000
> Dave Airlie wrote:
>
> > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > > To properly support the various plane formats supported by different
> > > hardware, the kernel must know the pixel forma
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #13 from Marek Olšák 2011-06-09 03:38:24 PDT ---
(In reply to comment #12)
> (In reply to comment #10)
> > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300
> > error messages seem to be unfixable hardware li
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #13 from Marek Ol??k 2011-06-09 03:38:24 PDT
---
(In reply to comment #12)
> (In reply to comment #10)
> > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300
> > error messages seem to be unfixable hardware l
Hi Alan
Just a thought. Shouldn't we use the DRM macros for printing debug info?
-Patrik
On Wed, Jun 8, 2011 at 12:15 PM, Alan Cox wrote:
> From: Alan Cox
>
> Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
> drivers if and when we need debug on stuff.
>
> Signed-off
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #12 from almos 2011-06-09 02:31:46 PDT ---
(In reply to comment #10)
> The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300
> error messages seem to be unfixable hardware limitations.
OK, but why does it hardloc
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #12 from almos 2011-06-09 02:31:46 PDT ---
(In reply to comment #10)
> The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300
> error messages seem to be unfixable hardware limitations.
OK, but why does it hardloc
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
+/* Planes blend with or override other bits on the CRTC */
+struct d
https://bugs.freedesktop.org/show_bug.cgi?id=37075
almos changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #8 from almos 2011-06-09 0
https://bugs.freedesktop.org/show_bug.cgi?id=37075
almos changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #8 from almos 2011-06-09 0
On Thu, 09 Jun 2011 14:05:59 +1000
Dave Airlie wrote:
> On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > To properly support the various plane formats supported by different
> > hardware, the kernel must know the pixel format of a framebuffer object.
> > So add a new ioctl taking a form
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
70 matches
Mail list logo
