dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[Bug 66871] New: Radeon multi-screen intermittent display failure
by bugzilla-daemon＠bugzilla.kernel.org 02 Jun '14

02 Jun '14

https://bugzilla.kernel.org/show_bug.cgi?id=66871 Bug ID: 66871 Summary: Radeon multi-screen intermittent display failure Product: Drivers Version: 2.5 Kernel Version: 3.13.0-rc3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erik(a)emedwards.info Regression: No In this kernel the 3rd display only comes on for a few partial frames every 20 to 40 seconds. Three displays attached to motherboard. Under kernel 3.11.10, Radeon driver operates correctly. Using: ASRock FM2A85X-ITX MB AMD A10-6800k (Not overclocked) 8 GB DDR3 VGA montitor - Dell flat screen - 19" HDMI0 montitor - (via DVI connector) - Acer 23" flat. HDMI1 montitor - (via HDMI connector) - Acer 22" flat VGA is 1 - on an the left. HDMI1 is 2 - in the center. HDMI0 is 3 - on the right. -- You are receiving this mail because: You are watching the assignee of the bug.

1 9

[PATCH 0/5] drm: Allow vblank interrupts during modeset and make the code less racy
by ville.syrjala＠linux.intel.com 30 May '14

30 May '14

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> I'm going to require vblank interrupts during modeset in i915 soon, however the drm vblank code won't currently allow it. It simply refuses to re-enable the vblank interrupts whenever they were disable and the refcount is already elevated. That means anyone holding a vblank reference across a modeset/dpms cycle can prevent the driver from operating correctly. The same problem can also cause wait for vblank ioctls issued soon after a modeset to fail. I've cooked up a few i-g-t/kms_flip subtests to excercise this. I don't want to be responsible for potentially breaking every other drm driver, so I've made the new behaviour opt in. If the driver uses the new way of doing things, vblank interrupts (and ioctls) are allowed everywhere except between drm_vblank_off() and drm_vblanl_on(). Any wait for vblank ioctl currently pending will get completed when drm_vblank_off() is called, including blocking waits which previously could have just sat there until the timeout expired. I also fixed the vblank disable timer to act predictably when multiple crtcs are involved , and I hoovered up an old patch from Peter Hurley to skip the double irqsave in drm_vblank_get(). Peter Hurley (1): drm: Use correct spinlock flavor in drm_vblank_get() Ville Syrjälä (4): drm: Make the vblank disable timer per-crtc drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled drm: Allow reenabling of vblank interrupts even if refcount>0 drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/drm_irq.c | 78 ++++++++++++++++++++++---------- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/gma500/gma_display.c | 2 +- drivers/gpu/drm/i915/i915_dma.c | 6 +++ drivers/gpu/drm/i915/intel_display.c | 23 ++++++---- drivers/gpu/drm/tegra/dc.c | 2 +- include/drm/drmP.h | 14 +++++- 8 files changed, 91 insertions(+), 38 deletions(-) -- 1.8.3.2

5 26

[Bug 72621] New: X crash while video playback in Chrome (with enabled hardware acceleration)
by bugzilla-daemon＠freedesktop.org 29 May '14

29 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=72621 Priority: medium Bug ID: 72621 Assignee: dri-devel(a)lists.freedesktop.org Summary: X crash while video playback in Chrome (with enabled hardware acceleration) Severity: normal Classification: Unclassified OS: All Reporter: russianneuromancer(a)ya.ru Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 90632 --> https://bugs.freedesktop.org/attachment.cgi?id=90632&action=edit Xorg log This crash happen while video playback in Google Chrome with enabled hardware acceleration (enabled on page chrome://flags/#ignore-gpu-blacklist so in result all items on chrome://gpu/ page is "Hardware accelerated"). When that happen image on screen just freeze, but audio playback is continue. (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x7f5022fb002d] (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x7f5022e796d2] (EE) 2: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f50183c2000+0x566f) [0x7f50183c766f] (EE) 3: /usr/bin/X (0x7f5022e0e000+0x91af8) [0x7f5022e9faf8] (EE) 4: /usr/bin/X (0x7f5022e0e000+0xba520) [0x7f5022ec8520] (EE) 5: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5021f0e000+0xfbb0) [0x7f5021f1dbb0] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7f5020c1a2f7] (EE) 7: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x34) [0x7f5021d053a4] (EE) 8: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmCommandWrite+0x1e) [0x7f5021d076be] (EE) 9: /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x7f501c85a000+0x1f39) [0x7f501c85bf39] (EE) 10: /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x7f501c85a000+0x213c) [0x7f501c85c13c] (EE) 11: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f501ca67000+0x33491) [0x7f501ca9a491] (EE) 12: /usr/lib/xorg/modules/libexa.so (0x7f501be26000+0xadc8) [0x7f501be30dc8] (EE) 13: /usr/bin/X (0x7f5022e0e000+0x192f13) [0x7f5022fa0f13] (EE) 14: /usr/bin/X (0x7f5022e0e000+0xdf675) [0x7f5022eed675] (EE) 15: /usr/bin/X (0x7f5022e0e000+0x52516) [0x7f5022e60516] (EE) 16: /usr/bin/X (0x7f5022e0e000+0x5500e) [0x7f5022e6300e] (EE) 17: /usr/bin/X (0x7f5022e0e000+0x4456a) [0x7f5022e5256a] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f5020b49de5] (EE) 19: /usr/bin/X (0x7f5022e0e000+0x448af) [0x7f5022e528af] Radeon HD 6620G Linux 3.13-rc3 libdrm 2.4.50+git1312040908.4c5de7 Mesa 10.1~git1312090928.992a2d xserver-xorg-video-radeon 7.2.0+git1311151746.d571d6 Xserver 1.14.3-3ubuntu2 Kubuntu 13.10 x86_64 updated from Oibaf PPA. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 70411] New: 7970M PRIME: lockup with Distance game, recovery doesn't work
by bugzilla-daemon＠bugzilla.kernel.org 26 May '14

26 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=70411 Bug ID: 70411 Summary: 7970M PRIME: lockup with Distance game, recovery doesn't work Product: Drivers Version: 2.5 Kernel Version: 3.13-3.14-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: haagch.christoph(a)googlemail.com Regression: Yes Created attachment 125651 --> https://bugzilla.kernel.org/attachment.cgi?id=125651&action=edit dmesg of radeon getting stuck 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] Using PRIME to render on the gpu etc. This has been going on for a while and I sadly don't really know since when, maybe later I'll test older kernels. It has worked some time ago (again, no specifics, but I think it was 3.12 (without dpm, maybe it's relevant). I report this because this is specifically happening with the Distance game in the Alpha version only available to kickstarter backers (I believe). http://survivethedistance.com/ (Surely there is a way to get this into the hands of driver developers if it is useful for finding out if more GPUs and configurations are affected and fixing bugs!) Well, it's alpha so it's maybe buggy, but it shouldn't bring the radeon driver down to an unrecoverable status... (I believe restarting X doesn't help and rmmod radeon doesn't really work currently) I don't really see lockups with other 3D programs so this is specifically for Distance. It's reproducible every time so I can later get more detail. For now there's the dmesg: Starting the game and showing some intro works, but shortly before displaying the menu X freezes for a few seconds and after it is usable again, I see the stuff starting at 82688.801309 in dmesg. The game window is still there, but frozen and killable with -9. Unfortunately the gpu has not recovered and e.g. trying to run DRI_PRIME=1 glxgears results in the message: radeon: The kernel rejected CS, see dmesg for more information. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 31565] New: [r300] radeon_texture.c:136: radeon_teximage_map: Assertion `!image->base.Data' failed.
by bugzilla-daemon＠freedesktop.org 24 May '14

24 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=31565 Summary: [r300] radeon_texture.c:136: radeon_teximage_map: Assertion `!image->base.Data' failed. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: vlee(a)vmware.com mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master) chipset: RV530 71C5 (ATI Radeon X1600) system architecture: i686 libdrm-dev: 2.4.21-1ubuntu2.1 kernel version: 2.6.35-22-generic Linux distribution: Ubuntu 10.10 i386 Machine model: iMac4,1 Run piglit fbo-blit. $ ./bin/fbo-blit ... radeonSetSpanFunctions: bad format: 0x0002 radeonSetSpanFunctions: bad format: 0x0002 fbo-blit: radeon_texture.c:136: radeon_teximage_map: Assertion `!image->base.Data' failed. (gdb) bt #0 0x0020c416 in __kernel_vsyscall () #1 0x00354941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00357e42 in abort () at abort.c:92 #3 0x0034d8e8 in __assert_fail (assertion=0x1123ce5 "!image->base.Data", file=0x1123cb6 "radeon_texture.c", line=136, function=0x1123f06 "radeon_teximage_map") at assert.c:81 #4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001') at radeon_texture.c:136 #5 0x00f22fb0 in radeon_map_unmap_framebuffer (ctx=<value optimized out>, fb=0x9884350, map=1 '\001') at radeon_span.c:1047 #6 0x00f2ebc4 in radeonSpanRenderStart (ctx=0x9526458) at radeon_span.c:1085 #7 0x01027253 in swrast_render_start (ctx=0x9526458, x=10, y=10, width=10, height=10, format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at swrast/s_context.h:268 #8 _swrast_ReadPixels (ctx=0x9526458, x=10, y=10, width=10, height=10, format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at swrast/s_readpix.c:473 #9 0x00f2176d in radeonReadPixels (ctx=0x9526458, x=10, y=10, width=10, height=10, format=6407, type=5126, pack=0x9535108, pixels=0x98b7508) at radeon_pixel_read.c:221 #10 0x00f9a58b in _mesa_ReadPixels (x=10, y=10, width=10, height=10, format=6407, type=5126, pixels=0x98b7508) at main/readpix.c:232 #11 0x0804b53e in piglit_probe_rect_rgb (x=10, y=10, w=10, h=10, expected=0xbfde7a00) at piglit/tests/util/piglit-util.c:278 #12 0x0804a890 in verify_color_rect (start_x=10, start_y=10, w=20, h=20) at /piglit/tests/fbo/fbo-blit.c:110 #13 0x0804ae31 in run_test () at piglit/tests/fbo/fbo-blit.c:193 #14 0x0804aeb6 in piglit_display () at /piglit/tests/fbo/fbo-blit.c:206 #15 0x0804ce7b in display () at piglit/tests/util/piglit-framework.c:52 #16 0x00d79820 in fghRedrawWindow (window=0x9509050, enumerator=0xbfde7b68) at freeglut_main.c:210 #17 fghcbDisplayWindow (window=0x9509050, enumerator=0xbfde7b68) at freeglut_main.c:227 #18 0x00d7d660 in fgEnumWindows (enumCallback=0xd79790 <fghcbDisplayWindow>, enumerator=0xbfde7b68) at freeglut_structure.c:394 #19 0x00d79cdb in fghDisplayAll () at freeglut_main.c:249 #20 glutMainLoopEvent () at freeglut_main.c:1450 #21 0x00d7a605 in glutMainLoop () at freeglut_main.c:1498 #22 0x0804d024 in main (argc=1, argv=0xbfde7df4) at piglit/tests/util/piglit-framework.c:118 (gdb) frame 4 #4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001') at radeon_texture.c:136 136 assert(!image->base.Data); (gdb) l 131 radeon_print(RADEON_TEXTURE, RADEON_VERBOSE, 132 "%s(img %p), write_enable %s.\n", 133 __func__, image, 134 write_enable ? "true": "false"); 135 if (image->mt) { 136 assert(!image->base.Data); 137 138 radeon_bo_map(image->mt->bo, write_enable); 139 teximage_set_map_data(image); 140 } (gdb) print image->base $1 = {InternalFormat = 6408, _BaseFormat = 6408, TexFormat = 2, Border = 0, Width = 64, Height = 64, Depth = 1, Width2 = 64, Height2 = 64, Depth2 = 1, WidthLog2 = 6, HeightLog2 = 6, DepthLog2 = 0, MaxLog2 = 6, WidthScale = 64, HeightScale = 64, DepthScale = 1, IsClientData = 0 '\000', _IsPowerOfTwo = 1 '\001', TexObject = 0x9884690, FetchTexelc = 0x10cfc60 <fetch_texel_float_to_chan>, FetchTexelf = 0x10c9dc0 <fetch_texel_2d_f_rgba8888_rev>, RowStride = 64, ImageOffsets = 0x9884278, Data = 0xb77cb000, DriverData = 0x0} (gdb) print image->base.Data $2 = (GLvoid *) 0xb77cb000 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 36934] New: screen corruption after running a game through wine
by bugzilla-daemon＠freedesktop.org 24 May '14

24 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=36934 Summary: screen corruption after running a game through wine Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: aaalmosss(a)gmail.com After running a game through wine, some graphic elements of other applications get garbled. These include window decorations, window shadows, images in already opened tabs of firefox, parts of the taskbar etc. They usually return to normal if refreshed (e.g. window shadows on resizing the window). The problem seems to occur only through wine, but I don't think its wine's fault. I use 32bit debian unstable (kde 4.4.5, compiz 8.4, xserver 7.6 (xserver-xorg-core 1.9.5)) with vanilla kernel 2.6.37.6 and wine 1.3.15 from sources. The issue appears with both the installed mesa 7.10.2 and 7.11-dev from git. I'm not sure about the product and component, just guessing... #35452 might be related, but there Michel Dänzer said that's related to page flipping, which is not in 2.6.37, and this one also happens with non-fullscreen games. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 22

[Bug 51604] New: and yet it moves: colored sparkling
by bugzilla-daemon＠freedesktop.org 24 May '14

24 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=51604 Bug #: 51604 Summary: and yet it moves: colored sparkling Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: aaalmosss(a)gmail.com They are on some rocks in episode 1, on all level exits, but most apparent on the tree joints in episode 2. Upon startup this is printed: Mesa: User error: GL_INVALID_OPERATION in glUniform(program not linked) BTW is it normal that it almost always segfaults on startup? The backtrace is different each time (64 bit). -- 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 58839] New: errors about too many fences printed while playing neverball
by bugzilla-daemon＠freedesktop.org 24 May '14

24 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=58839 Priority: medium Bug ID: 58839 Assignee: dri-devel(a)lists.freedesktop.org Summary: errors about too many fences printed while playing neverball Severity: normal Classification: Unclassified OS: All Reporter: aaalmosss(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa This is printed in mass quantities: EE r600_pipe.c:80 r600_create_fence - r600: too many concurrent fences They don't cause any visible rendering error though. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 58840] New: rendering error with MSAA on HD6850
by bugzilla-daemon＠freedesktop.org 24 May '14

24 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=58840 Priority: medium Bug ID: 58840 Assignee: dri-devel(a)lists.freedesktop.org Summary: rendering error with MSAA on HD6850 Severity: normal Classification: Unclassified OS: All Reporter: aaalmosss(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa There are weird rendering errors when OpenGL applications use MSAA framebuffer. The output is mostly noise. KDE 4.8 with OpenGL compositing is totally unusable this way. It is also interesting, that MS visuals are only advertised in glxinfo, if I have the msaa-capable r600_dri.so installed on the system. If I only enable it via LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH, they are not advertised, but still selectable. At least with __GL_FSAA_MODE=4 the applications are broken in the same way. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[PATCH] drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs
by Daniel Thompson 23 May '14

23 May '14

The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the existing users of the established timing bits forcing a rework of the ESTABLISHED_TIMINGS_BITS macro. Tested new EDID on an aged (and misbehaving) industrial LCD panel; existing EDIDs still pass edid-decode's checksum checks. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Documentation/EDID/1024x768.S | 2 +- Documentation/EDID/1280x1024.S | 2 +- Documentation/EDID/1600x1200.S | 2 +- Documentation/EDID/1680x1050.S | 2 +- Documentation/EDID/1920x1080.S | 2 +- Documentation/EDID/800x600.S | 41 +++++++++++++++++++++++++++++++++++++++++ Documentation/EDID/HOWTO.txt | 2 +- Documentation/EDID/edid.S | 17 ++++++++++++++--- drivers/gpu/drm/drm_edid_load.c | 21 ++++++++++++++++++++- 9 files changed, 81 insertions(+), 10 deletions(-) create mode 100644 Documentation/EDID/800x600.S diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S index 4b486fe..6f3e4b7 100644 --- a/Documentation/EDID/1024x768.S +++ b/Documentation/EDID/1024x768.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux XGA" -#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ +#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ #define HSYNC_POL 0 #define VSYNC_POL 0 #define CRC 0x55 diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S index a2799fe..bd9bef2 100644 --- a/Documentation/EDID/1280x1024.S +++ b/Documentation/EDID/1280x1024.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux SXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0xa0 diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S index 0ded64c..a45101c 100644 --- a/Documentation/EDID/1600x1200.S +++ b/Documentation/EDID/1600x1200.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux UXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x9d diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S index 96f67ca..b0d7c69 100644 --- a/Documentation/EDID/1680x1050.S +++ b/Documentation/EDID/1680x1050.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux WSXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x26 diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S index 36ed5d5..3084355e 100644 --- a/Documentation/EDID/1920x1080.S +++ b/Documentation/EDID/1920x1080.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux FHD" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x05 diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S new file mode 100644 index 0000000..6644e26 --- /dev/null +++ b/Documentation/EDID/800x600.S @@ -0,0 +1,41 @@ +/* + 800x600.S: EDID data set for standard 800x600 60 Hz monitor + + Copyright (C) 2011 Carsten Emde <C.Emde(a)osadl.org> + Copyright (C) 2014 Linaro Limited + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 40000 /* kHz */ +#define XPIX 800 +#define YPIX 600 +#define XY_RATIO XY_RATIO_4_3 +#define XBLANK 256 +#define YBLANK 28 +#define XOFFSET 40 +#define XPULSE 128 +#define YOFFSET (63+1) +#define YPULSE (63+4) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux SVGA" +#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0xc2 + +#include "edid.S" diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 7146db1..835db33 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt @@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an individually prepared or corrected EDID data set in the /lib/firmware directory from where it is loaded via the firmware interface. The code (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for -commonly used screen resolutions (1024x768, 1280x1024, 1600x1200, +commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200, 1680x1050, 1920x1080) as binary blobs, but the kernel source tree does not contain code to create these data. In order to elucidate the origin of the built-in binary EDID blobs and to facilitate the creation of diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S index ea97ae2..7ac0327 100644 --- a/Documentation/EDID/edid.S +++ b/Documentation/EDID/edid.S @@ -33,6 +33,17 @@ #define XY_RATIO_5_4 0b10 #define XY_RATIO_16_9 0b11 +/* Provide defaults for the timing bits */ +#ifndef ESTABLISHED_TIMING1_BITS +#define ESTABLISHED_TIMING1_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING2_BITS +#define ESTABLISHED_TIMING2_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING3_BITS +#define ESTABLISHED_TIMING3_BITS 0x00 +#endif + #define mfgname2id(v1,v2,v3) \ ((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f)) #define swap16(v1) ((v1>>8)+((v1&0xff)<<8)) @@ -139,7 +150,7 @@ white_x_y_msb: .byte 0x50,0x54 Bit 2 640x480 @ 75 Hz Bit 1 800x600 @ 56 Hz Bit 0 800x600 @ 60 Hz */ -estbl_timing1: .byte 0x00 +estbl_timing1: .byte ESTABLISHED_TIMING1_BITS /* Bit 7 800x600 @ 72 Hz Bit 6 800x600 @ 75 Hz @@ -149,11 +160,11 @@ estbl_timing1: .byte 0x00 Bit 2 1024x768 @ 72 Hz Bit 1 1024x768 @ 75 Hz Bit 0 1280x1024 @ 75 Hz */ -estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS +estbl_timing2: .byte ESTABLISHED_TIMING2_BITS /* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II) Bits 6-0 Other manufacturer-specific display mod */ -estbl_timing3: .byte 0x00 +estbl_timing3: .byte ESTABLISHED_TIMING3_BITS /* Standard timing */ /* X resolution, less 31, divided by 8 (256-2288 pixels) */ diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c index 1b4c7a5..6e09f61 100644 --- a/drivers/gpu/drm/drm_edid_load.c +++ b/drivers/gpu/drm/drm_edid_load.c @@ -31,8 +31,9 @@ module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware), 0644); MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob " "from built-in data or /lib/firmware instead. "); -#define GENERIC_EDIDS 5 +#define GENERIC_EDIDS 6 static const char *generic_edid_name[GENERIC_EDIDS] = { + "edid/800x600.bin", "edid/1024x768.bin", "edid/1280x1024.bin", "edid/1600x1200.bin", @@ -44,6 +45,24 @@ static const u8 generic_edid[GENERIC_EDIDS][128] = { { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x05, 0x16, 0x01, 0x03, 0x6d, 0x1b, 0x14, 0x78, + 0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25, + 0x20, 0x50, 0x54, 0x01, 0x00, 0x00, 0x45, 0x40, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xa0, 0x0f, + 0x20, 0x00, 0x31, 0x58, 0x1c, 0x20, 0x28, 0x80, + 0x14, 0x00, 0x15, 0xd0, 0x10, 0x00, 0x00, 0x1e, + 0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e, + 0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20, + 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b, + 0x3d, 0x24, 0x26, 0x05, 0x00, 0x0a, 0x20, 0x20, + 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfc, + 0x00, 0x4c, 0x69, 0x6e, 0x75, 0x78, 0x20, 0x53, + 0x56, 0x47, 0x41, 0x0a, 0x20, 0x20, 0x00, 0xc2, + }, + { + 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, + 0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x16, 0x01, 0x03, 0x6d, 0x23, 0x1a, 0x78, 0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25, 0x20, 0x50, 0x54, 0x00, 0x08, 0x00, 0x61, 0x40, -- 1.9.0

2 3

← Newer
1
...
55
56
57
58
59
60
61
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014