dri-devel April 2011

dri-devel@lists.freedesktop.org

93 participants
440 discussions

[Bug 36270] New: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used
by bugzilla-daemon＠freedesktop.org 09 Jun '11

09 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=36270 Summary: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used Product: Mesa Version: git Platform: x86 (IA32) URL: http://unigine.com/download/#sanctuary OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pavel.ondracka(a)email.cz When HDR is used fires from torches in Unigine an various other light sources are rendered checkered instead of "smooth pixels". This is also visible with sun in Unigine Tropics. GPU: RV530 Mesa: 41b38bd21c1031e65799c888a97d8a0c14ea2aaa with --enable-texture-float Kernel: 2.6.38.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 33389] New: Amesia (closed source game) segfaults
by bugzilla-daemon＠freedesktop.org 04 Jun '11

04 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=33389 Summary: Amesia (closed source game) segfaults Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: r0ugh_l(a)yahoo.de When trying to run Amnesia (http://www.amnesiagame.com/#demo) on my system it gives me this output: [1] 619 segmentation fault ./Amnesia.bin64 It runs fine until the loading screen and then crashes. Steps to reproduce: Run Amnesia with r600 driver Additional information: It doesn't crash if I'm using the llvm-pipe driver. I've tested it at the lowest possible graphics settings. Backtrace: #0 0x000000000082ab08 in hpl::iParticleEmitter::GetMaterial() () #1 0x0000000000805de2 in hpl::iRenderer::RenderObjectZAndAddToRenderList(hpl::iRenderable*) () #2 0x0000000000805e59 in hpl::iRenderer::RenderObjectZAndAddToRenderListStaticCallback(hpl::iRenderer*, hpl::iRenderable*) () #3 0x0000000000807d8f in hpl::iRenderer::RenderAndAddNodeObjects(hpl::iRenderableContainerNode*, bool (*)(hpl::iRenderer*, hpl::iRenderable*), unsigned int) () #4 0x000000000080808a in hpl::iRenderer::CheckForVisibleObjectsAddToListAndRenderZ(hpl::cVisibleRCNodeTracker*, unsigned int, unsigned int, bool, bool (*)(hpl::iRenderer*, hpl::iRenderable*)) () #5 0x00000000007e4841 in hpl::cRendererDeferred::RenderObjects() () #6 0x0000000000809334 in hpl::iRenderer::Render(float, hpl::cFrustum*, hpl::cWorld*, hpl::cRenderSettings*, hpl::cRenderTarget*, bool, std::list<hpl::iRendererCallback*, std::allocator<hpl::iRendererCallback*> >*) () #7 0x000000000082496d in hpl::cScene::Render(float, unsigned int) () #8 0x0000000000925423 in hpl::cEngine::Run() () #9 0x0000000000689890 in hplMain(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () #10 0x000000000090ff29 in main () Version Information: mesa: git 835c4ea1053730c8eea98337c9da1b14fcff6b5e OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 7.11-devel OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 12

[Bug 35935] New: since 2.6.38.1, screen become garbled after some times (RV770)
by bugzilla-daemon＠freedesktop.org 30 May '11

30 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=35935 Summary: since 2.6.38.1, screen become garbled after some times (RV770) Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: mjulien.m(a)gmail.com Created an attachment (id=45194) --> (https://bugs.freedesktop.org/attachment.cgi?id=45194) garbled screen Hi, Since I'm using kernel 2.6.38.1, Xorg screen became garbled after some times (see screenshot). It occurs on 2.6.38.2 but seems to be less frequent (3-4 hours for 2.6.38.1 ; 8-10 for 2.6.38.2) I didn't get this bug with 2.6.38 TTY stay fine and after I close and start X, everything is fine again. No need to reboot. I can't find anything precise which can trigger this bug, it simply occurs. Maybe an hint, it seems to be when I try to display a minimized window. There is nothing obvious in the logs (but I'm not using debug option), kernel or X. kernel 2.6.38.2 (kernel-linus-2.6.38.2-1mdv-1-1 ; vanilla kernel packaged by my distro) xorg 1.9.3 ati 6.14.1 mesa 7.9 libdrm 2.4.24 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[Bug 33222] New: [RADEON] Oops in worker thread for radeon_unpin_work_func
by bugzilla-daemon＠bugzilla.kernel.org 29 May '11

29 May '11

https://bugzilla.kernel.org/show_bug.cgi?id=33222 Summary: [RADEON] Oops in worker thread for radeon_unpin_work_func Product: Drivers Version: 2.5 Kernel Version: 2.6.38.2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: thomas(a)m3y3r.de Regression: No Created an attachment (id=54282) --> (https://bugzilla.kernel.org/attachment.cgi?id=54282) Oops - Part 1 Few days ago I stumbled upon the attached oops. Just images. sorry for that. This is the first time I saw this oops. I just hit it once for 2.6.38. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 3

[Bug 29942] New: oops at drivers/gpu/drm/ttm/ttm_bo.c:272
by bugzilla-daemon＠bugzilla.kernel.org 29 May '11

29 May '11

https://bugzilla.kernel.org/show_bug.cgi?id=29942 Summary: oops at drivers/gpu/drm/ttm/ttm_bo.c:272 Product: Drivers Version: 2.5 Kernel Version: 2.6.38-rc6-wl-00360-gcf65005 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: rossi.f(a)inwind.it Regression: No Created an attachment (id=49232) --> (https://bugzilla.kernel.org/attachment.cgi?id=49232) snapshot of kernel OOPS Kernel OOPS, attached a snapshot. Bug not reproducible, the kernel version is 2.6.38-rc6-wl-00360-gcf65005, latest wireless-testing.git -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 2

[Bug 30901] New: Heroes of Newerth won't start when mesa is compiled with --enable-gallium-llvm
by bugzilla-daemon＠freedesktop.org 26 May '11

26 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=30901 Summary: Heroes of Newerth won't start when mesa is compiled with --enable-gallium-llvm Product: Mesa Version: git Platform: x86 (IA32) URL: http://dl.heroesofnewerth.com/HoNClient-1.0.14.sh OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: drakkk(a)centrum.cz I usually configure mesa like this: "--enable-debug --enable-gallium-radeon --with-dri-drivers= --with-state-trackers=dri,glx", with this HoN starts and runs fine with r300g driver. However I was trying llvmpipe with some other apps and I noticed, when I add "--enable-gallium-llvm", HoN won't start with "K2 - Fatal Error: ARB_vertex_buffer_object not available." This is quite strange because glxinfo is identical and shows GL_ARB_vertex_buffer_object in both cases (and OpenGL vendor string: X.Org R300 Project, OpenGL renderer string: Gallium 0.4 on RV530, so its not like I was using some other driver). I'm quite sure I didn't messed up anything I even asked at #radeon if I'm doing something wrong. LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH are both pointing to right mesa directories and I did git clean -fdx between builds. So far I wasn't able to reproduce this with any other app. This is with Fedora 14 i686, kernel 2.6.35.6-39.fc14, mesa from git, RV530. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 28876] New: [radeon HD4250] Frequent lockups while screen locked
by bugzilla-daemon＠freedesktop.org 20 May '11

20 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=28876 Summary: [radeon HD4250] Frequent lockups while screen locked Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: ydirson(a)altern.org Created an attachment (id=36664) --> (https://bugs.freedesktop.org/attachment.cgi?id=36664) Xorg log file, with nearly 30k lines of repeated messages stripped Direct symptoms: - display left unattended with xscreensaver in simple blank mode - DPMS disabled (checked both with xset and xscreensaver-demo) - when coming back to my keyboard the monitor does not get a video signal - I can still login remotely through ssh and reboot the machine properly Hardware is an Asus "M4A88TD-V EVO/USB3" motherboard, featuring radeon HD4250 (RS780). OS is uptodate Debian/testing. syslog contains lines like the following. In this case, although I was not here, it may be that someone tried to use the box. In the 2 other occurences I have traces for, it I may even have been myself, but I did not dig at that time. However, although the Xorg.0.log error lines are not timestamped, the file timestamp itself matches the box' reboot. Since there are ~15000 occurences of the error, X may have been experiencing them since the error reported by the drm module. I can try to get more detailed facts next time (unless unnecessary, just tell). Jun 30 10:17:01 home /USR/SBIN/CRON[27295]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jun 30 10:18:10 home kernel: [130052.418150] executing set pll Jun 30 10:18:10 home kernel: [130052.424023] executing set crtc timing Jun 30 10:18:10 home kernel: [130052.424072] [drm] TMDS-11: set mode 1920x1200 1b Jun 30 10:18:10 home acpid: client 2095[0:0] has disconnected Jun 30 10:18:10 home acpid: client connected from 27304[0:0] Jun 30 10:18:10 home acpid: 1 client rule loaded Jun 30 10:18:13 home kernel: [130055.829085] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 30 10:18:13 home kernel: [130055.829088] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 30 10:18:13 home kernel: [130055.829090] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! [...] Jun 30 10:18:42 home kernel: [130084.275900] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 30 10:18:42 home kernel: [130084.275906] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 30 10:18:42 home kernel: [130084.275912] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 30 11:17:01 home /USR/SBIN/CRON[27329]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) In older occurences (do not recall the precise set of events, although the "wishing to unlock screen" event has always been the only way to see the problem), the 3 error lines occur on a longer timespan, some in sync with the clock (??): Jun 27 19:17:01 home /USR/SBIN/CRON[26082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jun 27 19:18:09 home kernel: [21853.241075] executing set pll Jun 27 19:18:09 home kernel: [21853.248025] executing set crtc timing Jun 27 19:18:09 home kernel: [21853.248076] [drm] TMDS-11: set mode 1920x1200 1b Jun 27 19:18:12 home kernel: [21856.334252] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:18:12 home kernel: [21856.334261] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:18:12 home kernel: [21856.334269] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! [...] Jun 27 19:18:32 home kernel: [21876.279726] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:18:32 home kernel: [21876.279733] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:18:32 home kernel: [21876.279739] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:19:00 home kernel: [21904.282670] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:19:00 home kernel: [21904.282678] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:19:00 home kernel: [21904.282685] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:20:00 home kernel: [21964.322037] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:20:00 home kernel: [21964.322045] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:20:00 home kernel: [21964.322052] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:21:00 home kernel: [22024.321528] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:21:00 home kernel: [22024.321537] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:21:00 home kernel: [22024.321544] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:22:00 home kernel: [22084.321217] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:22:00 home kernel: [22084.321225] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:22:00 home kernel: [22084.321232] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:23:00 home kernel: [22144.367818] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:23:00 home kernel: [22144.367827] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:23:00 home kernel: [22144.367833] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:24:00 home kernel: [22204.414007] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:24:00 home kernel: [22204.414015] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:24:00 home kernel: [22204.414022] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Jun 27 19:24:12 home kernel: [22216.304962] [drm:radeon_ib_get] *ERROR* radeon: IB(0:0x0000000010101000:668) Jun 27 19:24:12 home kernel: [22216.304970] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB Jun 27 19:24:12 home kernel: [22216.304977] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! Xorg.0.log repeated messages are: (EE) RADEON(0): Timeout trying to update memory controller settings ! (EE) RADEON(0): You will probably crash now ... Package versions are as follows (dpkg -l|grep xserver): x11-xserver-utils 7.5+1 xserver-common 2:1.7.7-2 xserver-xephyr 2:1.7.7-2 xserver-xorg 1:7.5+6 xserver-xorg-core 2:1.7.7-2 xserver-xorg-core-dbg 2:1.7.7-2 xserver-xorg-input-all 1:7.5+6 xserver-xorg-input-evdev 1:2.3.2-6 xserver-xorg-input-synaptics 1.2.2-2 xserver-xorg-input-wacom 0.10.5+20100416-1 xserver-xorg-video-ati 1:6.13.0-2 xserver-xorg-video-fbdev 1:0.4.2-2 xserver-xorg-video-mach64 6.8.2-3 xserver-xorg-video-mga 1:1.4.11.dfsg-4 xserver-xorg-video-r128 6.8.1-3 xserver-xorg-video-radeon 1:6.13.0-2 xserver-xorg-video-radeon-dbg 1:6.13.0-2 xserver-xorg-video-vesa 1:2.3.0-3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
by Maciej Rutecki 19 May '11

19 May '11

Hi Last known good: 2.6.38 Failing kernel: 2.6.39-rc3 Subsystem: Intel graphics driver. Description: PC should work with 1440x900 resolution. But console (and after) X Window start work with 1024x768. I attach dmesg and Xorg.0.log with drm.debug=14 log_buf_len=16M options: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/kms/ seems that driver cannot detect resolution higher than 1024x768. Also I boot kernel replace "i915.modeset=1" with "nomodeset" option: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/nomodeset/ But then X Window fails to start and got message: "(EE) No devices detected." Config for 2.6.39-rc3: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/config-2.6.39-rc3 Best regards -- Maciej Rutecki http://www.maciek.unixy.pl

2 4

Embedded Linux memory management interest group list
by Jesse Barker 19 May '11

19 May '11

Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse

7 12

[RFC] drm: add overlays as first class KMS objects
by Jesse Barnes 17 May '11

17 May '11

Looking for comments on this. Obviously if we're going to add a new type of KMS object, we'd better get the ioctl more or less right to begin with, which means having all the attributes we'd like to track, plus some padding, available from the outset. So I'd like comments on this; the whole approach may be broken for things like OMAP; if so I'd like to hear about it now. Overall, overlays are treated a little like CRTCs, but without associated modes our encoder trees hanging off of them. That is, they can be enabled with a specific fb attached at a specific location, but they don't have to worry about mode setting, per se (though they do need to have an associated CRTC to actually pump their pixels out, post-blend). Flipping could be done either with the existing ioctl by updating the fb base pointer, or through a new flip ioctl similar to what we have already, but taking an overlay object instead of a CRTC. Overlays are a bit like half-CRTCs. They have a location and fb, but don't drive outputs directly. Add support for handling them to the core KMS code. Signed-off-by: Jesse Barnes <jbarnes(a)virtuousgeek.org> --- drivers/gpu/drm/drm_crtc.c | 219 ++++++++++++++++++++++++++++++++++++++++++++ include/drm/drm.h | 3 + include/drm/drm_crtc.h | 61 ++++++++++++ include/drm/drm_mode.h | 39 ++++++++ 4 files changed, 322 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 799e149..77ff9e0 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -533,6 +533,34 @@ void drm_encoder_cleanup(struct drm_encoder *encoder) } EXPORT_SYMBOL(drm_encoder_cleanup); +void drm_overlay_init(struct drm_device *dev, struct drm_overlay *overlay, + const struct drm_overlay_funcs *funcs) +{ + mutex_lock(&dev->mode_config.mutex); + + overlay->dev = dev; + drm_mode_object_get(dev, &overlay->base, DRM_MODE_OBJECT_OVERLAY); + overlay->funcs = funcs; + + list_add_tail(&overlay->head, &dev->mode_config.overlay_list); + dev->mode_config.num_overlay++; + + mutex_unlock(&dev->mode_config.mutex); +} +EXPORT_SYMBOL(drm_overlay_init); + +void drm_overlay_cleanup(struct drm_overlay *overlay) +{ + struct drm_device *dev = overlay->dev; + + mutex_lock(&dev->mode_config.mutex); + drm_mode_object_put(dev, &overlay->base); + list_del(&overlay->head); + dev->mode_config.num_overlay--; + mutex_unlock(&dev->mode_config.mutex); +} +EXPORT_SYMBOL(drm_overlay_cleanup); + /** * drm_mode_create - create a new display mode * @dev: DRM device @@ -864,6 +892,7 @@ void drm_mode_config_init(struct drm_device *dev) INIT_LIST_HEAD(&dev->mode_config.encoder_list); INIT_LIST_HEAD(&dev->mode_config.property_list); INIT_LIST_HEAD(&dev->mode_config.property_blob_list); + INIT_LIST_HEAD(&dev->mode_config.overlay_list); idr_init(&dev->mode_config.crtc_idr); mutex_lock(&dev->mode_config.mutex); @@ -1467,6 +1496,196 @@ out: } /** + * drm_mode_getoverlay_res - get overlay info + * @dev: DRM device + * @data: ioctl data + * @file_priv: DRM file info + * + * Return an overlay count and set of IDs. + */ +int drm_mode_getoverlay_res(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct drm_mode_get_overlay_res *overlay_resp = data; + struct drm_mode_config *config; + struct drm_overlay *overlay; + uint32_t __user *overlay_ptr; + int copied = 0, ret = 0; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + + mutex_lock(&dev->mode_config.mutex); + config = &dev->mode_config; + + /* + * This ioctl is called twice, once to determine how much space is + * needed, and the 2nd time to fill it. + */ + if (config->num_overlay && + (overlay_resp->count_overlays >= config->num_overlay)) { + overlay_ptr = (uint32_t *)(unsigned long)overlay_resp->overlay_id_ptr; + + list_for_each_entry(overlay, &config->overlay_list, head) { + if (put_user(overlay->base.id, overlay_ptr + copied)) { + ret = -EFAULT; + goto out; + } + copied++; + } + } + overlay_resp->count_overlays = config->num_overlay; + +out: + mutex_unlock(&dev->mode_config.mutex); + return ret; +} + +/** + * drm_mode_getoverlay - get overlay info + * @dev: DRM device + * @data: ioctl data + * @file_priv: DRM file info + * + * Return overlay info, including formats supported, gamma size, any + * current fb, etc. + */ +int drm_mode_getoverlay(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct drm_mode_get_overlay *overlay_resp = data; + struct drm_mode_object *obj; + struct drm_overlay *overlay; + uint32_t __user *format_ptr; + int ret = 0; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + + mutex_lock(&dev->mode_config.mutex); + obj = drm_mode_object_find(dev, overlay_resp->overlay_id, + DRM_MODE_OBJECT_OVERLAY); + if (!obj) { + ret = -EINVAL; + goto out; + } + overlay = obj_to_overlay(obj); + + if (overlay->crtc) + overlay_resp->crtc_id = overlay->crtc->base.id; + else + overlay_resp->crtc_id = 0; + + if (overlay->fb) + overlay_resp->fb_id = overlay->fb->base.id; + else + overlay_resp->fb_id = 0; + + overlay_resp->overlay_id = overlay->base.id; + overlay_resp->possible_crtcs = overlay->possible_crtcs; + overlay_resp->gamma_size = overlay->gamma_size; + overlay_resp->crtc_x = overlay->crtc_x; + overlay_resp->crtc_y = overlay->crtc_y; + overlay_resp->x = overlay->x; + overlay_resp->y = overlay->y; + + /* + * This ioctl is called twice, once to determine how much space is + * needed, and the 2nd time to fill it. + */ + if (overlay->format_count && + (overlay_resp->count_format_types >= overlay->format_count)) { + format_ptr = (uint32_t *)(unsigned long)overlay_resp->format_type_ptr; + if (copy_to_user(format_ptr, + overlay->format_types, + sizeof(uint32_t) * overlay->format_count)) { + ret = -EFAULT; + goto out; + } + } + overlay_resp->count_format_types = overlay->format_count; + +out: + mutex_unlock(&dev->mode_config.mutex); + return ret; +} + +/** + * drm_mode_setoverlay - set up or tear down an overlay + * @dev: DRM device + * @data: ioctl data* + * @file_prive: DRM file info + * + * Set overlay info, including placement, fb, scaling, and other factors. + * Or pass a NULL fb to disable. + */ +int drm_mode_setoverlay(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct drm_mode_set_overlay *overlay_req = data; + struct drm_mode_object *obj; + struct drm_overlay *overlay; + struct drm_crtc *crtc; + struct drm_framebuffer *fb; + int ret = 0; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + + mutex_lock(&dev->mode_config.mutex); + + /* + * First, find the overlay, crtc, and fb objects. If not available, + * we don't bother to call the driver. + */ + obj = drm_mode_object_find(dev, overlay_req->overlay_id, + DRM_MODE_OBJECT_OVERLAY); + if (!obj) { + DRM_DEBUG_KMS("Unknown overlay ID %d\n", + overlay_req->overlay_id); + ret = -EINVAL; + goto out; + } + overlay = obj_to_overlay(obj); + + /* No fb means shut it down */ + if (!overlay_req->fb_id) { + overlay->funcs->disable_overlay(overlay); + goto out; + } + + obj = drm_mode_object_find(dev, overlay_req->crtc_id, + DRM_MODE_OBJECT_CRTC); + if (!obj) { + DRM_DEBUG_KMS("Unknown crtc ID %d\n", + overlay_req->crtc_id); + ret = -EINVAL; + goto out; + } + crtc = obj_to_crtc(obj); + + obj = drm_mode_object_find(dev, overlay_req->fb_id, + DRM_MODE_OBJECT_FB); + if (!obj) { + DRM_DEBUG_KMS("Unknown framebuffer ID %d\n", + overlay_req->fb_id); + ret = -EINVAL; + goto out; + } + fb = obj_to_fb(obj); + + ret = overlay->funcs->update_overlay(overlay, crtc, fb, + overlay_req->crtc_x, + overlay_req->crtc_y, + overlay_req->x, overlay_req->y); + +out: + mutex_unlock(&dev->mode_config.mutex); + + return ret; +} + +/** * drm_mode_setcrtc - set CRTC configuration * @inode: inode from the ioctl * @filp: file * from the ioctl diff --git a/include/drm/drm.h b/include/drm/drm.h index 4be33b4..47909af 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -714,6 +714,9 @@ struct drm_get_cap { #define DRM_IOCTL_MODE_CREATE_DUMB DRM_IOWR(0xB2, struct drm_mode_create_dumb) #define DRM_IOCTL_MODE_MAP_DUMB DRM_IOWR(0xB3, struct drm_mode_map_dumb) #define DRM_IOCTL_MODE_DESTROY_DUMB DRM_IOWR(0xB4, struct drm_mode_destroy_dumb) +#define DRM_IOCTL_MODE_GETOVERLAYRESOURCES DRM_IOWR(0xB5, struct drm_mode_get_overlay_res) +#define DRM_IOCTL_MODE_GETOVERLAY DRM_IOWR(0xB6, struct drm_mode_get_overlay) +#define DRM_IOCTL_MODE_SETOVERLAY DRM_IOWR(0xB7, struct drm_mode_set_overlay) /** * Device specific ioctls should only be in their respective headers diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index b786a24..07a9025 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -44,6 +44,7 @@ struct drm_framebuffer; #define DRM_MODE_OBJECT_PROPERTY 0xb0b0b0b0 #define DRM_MODE_OBJECT_FB 0xfbfbfbfb #define DRM_MODE_OBJECT_BLOB 0xbbbbbbbb +#define DRM_MODE_OBJECT_OVERLAY 0xeeeeeeee struct drm_mode_object { uint32_t id; @@ -276,6 +277,7 @@ struct drm_crtc; struct drm_connector; struct drm_encoder; struct drm_pending_vblank_event; +struct drm_overlay; /** * drm_crtc_funcs - control CRTCs for a given device @@ -523,6 +525,57 @@ struct drm_connector { }; /** + * drm_overlay_funcs - driver overlay control functions + * @update_overlay: update the overlay configuration + */ +struct drm_overlay_funcs { + int (*update_overlay)(struct drm_overlay *overlay, + struct drm_crtc *crtc, struct drm_framebuffer *fb, + int crtc_x, int crtc_y, int x, int y); + void (*disable_overlay)(struct drm_overlay *overlay); +}; + +/** + * drm_overlay - central DRM overlay control structure + * @dev: DRM device this overlay belongs to + * @kdev: kernel device + * @attr: kdev attributes + * @head: for list management + * @base: base mode object + * @crtc_x: x position of overlay (relative to pipe base) + * @crtc_y: y position of overlay + * @x: x offset into fb + * @y: y offset into fb + * @crtc: CRTC this overlay is feeding + */ +struct drm_overlay { + struct drm_device *dev; + struct device kdev; + struct device_attribute *attr; + struct list_head head; + + struct drm_mode_object base; + + int crtc_x, crtc_y; + int x, y; + uint32_t possible_crtcs; + uint32_t *format_types; + uint32_t format_count; + + struct drm_crtc *crtc; + struct drm_framebuffer *fb; + + /* CRTC gamma size for reporting to userspace */ + uint32_t gamma_size; + uint16_t *gamma_store; + + bool enabled; + + const struct drm_overlay_funcs *funcs; + void *helper_private; +}; + +/** * struct drm_mode_set * * Represents a single crtc the connectors that it drives with what mode @@ -576,6 +629,8 @@ struct drm_mode_config { struct list_head connector_list; int num_encoder; struct list_head encoder_list; + int num_overlay; + struct list_head overlay_list; int num_crtc; struct list_head crtc_list; @@ -628,6 +683,7 @@ struct drm_mode_config { #define obj_to_fb(x) container_of(x, struct drm_framebuffer, base) #define obj_to_property(x) container_of(x, struct drm_property, base) #define obj_to_blob(x) container_of(x, struct drm_property_blob, base) +#define obj_to_overlay(x) container_of(x, struct drm_overlay, base) extern void drm_crtc_init(struct drm_device *dev, @@ -647,6 +703,11 @@ extern void drm_encoder_init(struct drm_device *dev, const struct drm_encoder_funcs *funcs, int encoder_type); +extern void drm_overlay_init(struct drm_device *dev, + struct drm_overlay *overlay, + const struct drm_overlay_funcs *funcs); +extern void drm_overlay_cleanup(struct drm_overlay *overlay); + extern void drm_encoder_cleanup(struct drm_encoder *encoder); extern char *drm_get_connector_name(struct drm_connector *connector); diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h index ae6b7a3..349052a 100644 --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -120,6 +120,45 @@ struct drm_mode_crtc { struct drm_mode_modeinfo mode; }; +#define DRM_MODE_OVERLAY_FORMAT_YUV422 1 /* YUV 4:2:2 packed */ +#define DRM_MODE_OVERLAY_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */ +#define DRM_MODE_OVERLAY_FORMAT_RGBX888 3 /* Standard x:8:8:8 RGB */ +#define DRM_MODE_OVERLAY_FORMAT_RGBX161616 4 /* x:16:16:16 float RGB */ + +/* Overlays blend with or override other bits on the CRTC */ +struct drm_mode_set_overlay { + __u32 overlay_id; + __u32 crtc_id; + __u32 fb_id; /* contains surface format type */ + + __u32 crtc_x, crtc_y; + __u32 x, y; + + /* FIXME: color key/mask, scaling, z-order, other? */ +}; + +struct drm_mode_get_overlay { + __u64 format_type_ptr; + __u32 overlay_id; + + __u32 crtc_id; + __u32 fb_id; + + __u32 crtc_x, crtc_y; + __u32 x, y; + + __u32 possible_crtcs; + __u32 gamma_size; + + __u32 count_format_types; +}; + + +struct drm_mode_get_overlay_res { + __u64 overlay_id_ptr; + __u32 count_overlays; +}; + #define DRM_MODE_ENCODER_NONE 0 #define DRM_MODE_ENCODER_DAC 1 #define DRM_MODE_ENCODER_TMDS 2 -- 1.7.4.1

14 36

← Newer
1
...
21
22
23
24
25
26
27
...
44
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2011