summaryrefslogtreecommitdiff
path: root/drivers/video/edid.h
AgeCommit message (Collapse)Author
2014-04-17video: move fbdev to drivers/video/fbdevTomi Valkeinen
The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-03-22video: Fix EDID macros H_SYNC_WIDTH and H_SYNC_OFFSETMartin Decky
The macros for getting the values for horizontal sync width and offset do not respect the EDID specification. Both these values are 10 bit values according to [1], not 6 bit values. The lower 8 bits are stored in byte 8 and byte 9 of the DTD respectively, while two additional bits for each value are stored in byte 11. The original macros just slammed the bits together. Although the original macros usually worked fine because the higher two bits are rarely used, it can cause severe problems on plasma panels running at 1920x1080 @ 50 Hz with drivers that rely on the correct parsing of the EDID data by fbmon.c (e.g. udlfb). The patch should apply cleanly to both the fbdev-2.6.git branch and linux-next.git branch. [1] VESA Enhanced Extended Display Identification Data Standard, Release A, Revision 2, page 34, notes 7 & 8, VESA, Sep 2006 Signed-off-by: Martin Decky <martin@decky.cz> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!