dri-devel March 2011

dri-devel@lists.freedesktop.org

88 participants
477 discussions

[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
by bugzilla-daemon＠freedesktop.org 03 Mar '11

03 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=32006 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Drivers/DRI/Radeon AssignedTo|mesa-dev(a)lists.freedesktop. |dri-devel(a)lists.freedesktop |org |.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 8640] Driver does not support GLX_SGI_make_current_read
by bugzilla-daemon＠freedesktop.org 03 Mar '11

03 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=8640 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[810] Driver does not |Driver does not support |support |GLX_SGI_make_current_read |GLX_SGI_make_current_read | Status|NEW |RESOLVED Resolution| |FIXED Component|Drivers/DRI/i810 |GLX AssignedTo|dri-devel(a)lists.freedesktop |mesa-dev(a)lists.freedesktop. |.org |org --- Comment #4 from Marek Olšák <maraeo(a)gmail.com> 2011-03-03 05:40:43 PST --- The extension is available on swrast and the hardware drivers I have here, so I guess it's also available on i810. This issue doesn't seem to be driver-specific at all. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Re: 2.6.37.2 : Font corruption and [drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
by Andrew Morton 03 Mar '11

03 Mar '11

(cc dri-devel) On Mon, 28 Feb 2011 12:26:08 +0100 Paul Rolland <rol(a)as2917.net> wrote: > Hello, > > I'm using 2.6.37.2 and I'm getting loads of this error in my messages, > while at the same time I can observe font display corruption in a GTK > application (Claws-Mail) while running X, compiz and this app. > > I was previously using 2.6.36 and never experienced such a problem. > > Video is : > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) > 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) > > I can provide additional information as needed (such a .config or details > on userland env. if asked for precise details). > > If this message warns about a badly acting userland, then why was it ok > with 2.6.36 and the same userland env. ? > > Best, > Paul > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/

1 0

[git pull] drm fixes
by Dave Airlie 03 Mar '11

03 Mar '11

Hi Linus, just an intel fix for some chipsets with > 4GB RAM. Dave. The following changes since commit dd9c1549edef02290edced639f67b54a25abbe0e: Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Dave Airlie (1): Merge remote branch 'intel/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes Jan Niehusmann (1): drm/i915: fix memory corruption with GM965 and >4GB RAM drivers/gpu/drm/i915/i915_dma.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)

1 0

[PATCH 01/15] drm/radeon/kms: add cayman chip family
by Alex Deucher 03 Mar '11

03 Mar '11

Cayman is DCE5 display plus a new 4-way shader block. 3D state programming is similar to evergreen. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_device.c | 1 + drivers/gpu/drm/radeon/radeon_family.h | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 4954e2d..207d43f 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -85,6 +85,7 @@ static const char radeon_family_name[][16] = { "BARTS", "TURKS", "CAICOS", + "CAYMAN", "LAST", }; diff --git a/drivers/gpu/drm/radeon/radeon_family.h b/drivers/gpu/drm/radeon/radeon_family.h index 1ca55eb..6f1d9e5 100644 --- a/drivers/gpu/drm/radeon/radeon_family.h +++ b/drivers/gpu/drm/radeon/radeon_family.h @@ -84,6 +84,7 @@ enum radeon_family { CHIP_BARTS, CHIP_TURKS, CHIP_CAICOS, + CHIP_CAYMAN, CHIP_LAST, }; -- 1.7.1.1

1 14

[Bug 34237] New: External LCD monitor flickers every 30 seconds radeon mobility x1400
by bugzilla-daemon＠freedesktop.org 02 Mar '11

02 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=34237 Summary: External LCD monitor flickers every 30 seconds radeon mobility x1400 Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: prijatelj.mp3(a)gmail.com OS: ArchLnux driver: 6.14.0-1 kernel: 2.6.37-5 libdrm: 2.4.23-1 mesa: 7.10.0.git20110206-2 KMS: yes graphic card: mobility x1400 ----------------------- To reproduce. LCD monitor is plugged into laptop. While KDE4 is loading external monitor flickeres once. When KDE4 is already loaded external monitor flickers twice in a row with 2 seconds delay. One flick is lasting about one second. Then external lcd monitor flickers every 30 seconds. It also flickeres if I just type a command: 'xrandr'. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 15

[PATCH] drm/radeon/kms: allow max clock of 340 Mhz on hdmi 1.3+
by Alex Deucher 02 Mar '11

02 Mar '11

hdmi 1.3 raises the max clock from 165 Mhz to 340 Mhz. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_connectors.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 22b7e3d..3f3c9aa 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -972,7 +972,16 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D) || (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_HDMI_TYPE_B)) return MODE_OK; - else + else if (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_HDMI_TYPE_A) { + if (ASIC_IS_DCE3(rdev)) { + /* HDMI 1.3+ supports max clock of 340 Mhz */ + if (mode->clock > 340000) + return MODE_CLOCK_HIGH; + else + return MODE_OK; + } else + return MODE_CLOCK_HIGH; + } else return MODE_CLOCK_HIGH; } return MODE_OK; -- 1.7.1.1

1 0

[Bug 27340] mesa deadlocks with latest HoN game
by bugzilla-daemon＠freedesktop.org 02 Mar '11

02 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=27340 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Marek Olšák <maraeo(a)gmail.com> 2011-03-02 06:12:49 PST --- HoN works according to a lot of feedback from users lately. The patch was pushed per Brian's comment, and the fixes from 7.8 have been merged to master. Closing. Feel free to reopen if you still encounter any issues. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 25898] glEvalPoint causes glEnd to throw GL_INVALID_OPERATION
by bugzilla-daemon＠freedesktop.org 02 Mar '11

02 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=25898 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|glEvalPoint within display |glEvalPoint causes glEnd to |list fails assertion in |throw GL_INVALID_OPERATION |vbo_save_api.c | Version|unspecified |git --- Comment #3 from Marek Olšák <maraeo(a)gmail.com> 2011-03-02 04:14:11 PST --- The assertion failure is gone. The only remaining issue is the error on glEnd. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
by Geert Uytterhoeven 02 Mar '11

02 Mar '11

On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm(a)gmail.com> wrote: > On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven > <geert(a)linux-m68k.org> wrote: >> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm(a)gmail.com> wrote: >>> Please ditch the SH_FB_YUV constant all together. No need to build >>> some abstraction on top of a hackish interface. Just check if nonstd >>> is non-zero in the driver and assume that means YUV for now. That's >>> good enough. >> >> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new FB_VISUAL_* >> type instead, which indicates the fb_var_screeninfo.{red,green,blue} fields are >> YCbCr instead of RGB. >> Depending on the frame buffer organization, you also need new FB_TYPE_*/FB_AUX_* >> types. > > I'm all for extending the common code instead of hiding code in > drivers. But I wonder how much overlap there is with V4L2 for > instance. I remember adding support for some NVxx formats for V4L2 > some years ago. It's mainly used for Video input on Renesas SoCs > though: > > http://kerneltrap.org/mailarchive/git-commits-head/2008/12/31/4560474 > > So I was hoping that something like the above could be added to fbdev > too, but it looks like more code is needed. > > Do you have any idea on how to tie in the valid range of each color > channel? The LCDC hardware block can select between 0->255 range or > 16->235/240 for the YUV channels. In V4L2 this is handled by > v4l2_colorspace, the 0->255 maps directly to V4L2_COLORSPACE_JPEG. Unfortunately not. Unlike for the YCbCr visual, I don't see a field we can easily (ab)use for that. Except if it's limited to standard 16-235/240 Y vs. full 0-255 Y, for which we could just have 2 different visual types. > And how does all this relate to KMS? I'd prefer to keep this code in > one place if possible. Good question! I'm still puzzled about this KMS thing. If the name "Kernel Mode Setting" covers it, then how does it compare to plain fbdev? Just additional frame buffer memory management? Furthermore, everybody states that "future X/desktop" will require KMS drivers. How do/will we handle this on dumb frame buffers? It's not like we can't do "advanced" things like compositing using the CPU. Transparency may stretch it a bit on lower end CPUs, but you don't always need that. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2011