linux/drivers/video, branch v3.14.4

tgafb: fix data copying

2014-05-13T11:32:54Z

commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream. The functions for data copying copyarea_foreward_8bpp and copyarea_backward_8bpp are buggy, they produce screen corruption. This patch fixes the functions and moves the logic to one function "copyarea_8bpp". For simplicity, the function only handles copying that is aligned on 8 pixes. If we copy an unaligned area, generic function cfb_copyarea is used. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

tgafb: fix mode setting with fbset

2014-05-13T11:32:54Z

commit 624966589041deb32a2626ee2e176e8274581101 upstream. Mode setting in the TGA driver is broken for these reasons: - info->fix.line_length is set just once in tgafb_init_fix function. If we change videomode, info->fix.line_length is not recalculated - so the video mode is changed but the screen is corrupted because of wrong info->fix.line_length. - info->fix.smem_len is set in tgafb_init_fix to the size of the default video mode (640x480). If we set a higher resolution, info->fix.smem_len is smaller than the current screen size, preventing the userspace program from mapping the framebuffer. This patch fixes it: - info->fix.line_length initialization is moved to tgafb_set_par so that it is recalculated with each mode change. - info->fix.smem_len is set to a fixed value representing the real amount of video ram (the values are taken from xfree86 driver). - add a check to tgafb_check_var to prevent us from setting a videomode that doesn't fit into videoram. - in tgafb_register, tgafb_init_fix is moved upwards, to be called before fb_find_mode (because fb_find_mode already needs the videoram size set in tgafb_init_fix). Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

mach64: fix cursor when character width is not a multiple of 8 pixels

2014-05-13T11:32:50Z

commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream. This patch fixes the hardware cursor on mach64 when font width is not a multiple of 8 pixels. If you load such a font, the cursor is expanded to the next 8-byte boundary and a part of the next character after the cursor is not visible. For example, when you load a font with 12-pixel width, the cursor width is 16 pixels and when the cursor is displayed, 4 pixels of the next character are not visible. The reason is this: atyfb_cursor is called with proper parameters to load an image that is 12-pixel wide. However, the number is aligned on the next 8-pixel boundary on the line "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole function acts as it is was loading a 16-pixel image. This patch fixes it so that the value written to the framebuffer is padded with 0xaaaa (the transparent pattern) when the image size it not a multiple of 8 pixels. The transparent pattern causes that the cursor will not interfere with the next character. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

mach64: use unaligned access

2014-05-13T11:32:50Z

commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream. This patch fixes mach64 to use unaligned access to the font bitmap. This fixes unaligned access warning on sparc64 when 14x8 font is loaded. On x86(64), unaligned access is handled in hardware, so both functions le32_to_cpup and get_unaligned_le32 perform the same operation. On RISC machines, unaligned access is not handled in hardware, so we better use get_unaligned_le32 to avoid the unaligned trap and warning. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

matroxfb: restore the registers M_ACCESS and M_PITCH

2014-05-13T11:32:50Z

commit a772d4736641ec1b421ad965e13457c17379fc86 upstream. When X11 is running and the user switches back to console, the card modifies the content of registers M_MACCESS and M_PITCH in periodic intervals. This patch fixes it by restoring the content of these registers before issuing any accelerator command. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

framebuffer: fix cfb_copyarea

2014-05-13T11:32:50Z

commit 00a9d699bc85052d2d3ed56251cd928024ce06a3 upstream. The function cfb_copyarea is buggy when the copy operation is not aligned on long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines). How to reproduce: - use x86-64 machine - use a framebuffer driver without acceleration (for example uvesafb) - set the framebuffer to 8-bit depth (for example fbset -a 1024x768-60 -depth 8) - load a font with character width that is not a multiple of 8 pixels note: the console-tools package cannot load a font that has width different from 8 pixels. You need to install the packages "kbd" and "console-terminus" and use the program "setfont" to set font width (for example: setfont Uni2-Terminus20x10) - move some text left and right on the bash command line and you get a screen corruption To expose more bugs, put this line to the end of uvesafb_init_info: info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST; - Now framebuffer console will use cfb_copyarea for console scrolling. You get a screen corruption when console is scrolled. This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this patch, console scrolling in 8-bit depth with a font width that is not a multiple of 8 pixels works fine. The cfb_copyarea code was very buggy and it looks like it was written and never tried with non-8-pixel font. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

video: atmel_lcdfb: ensure the hardware is initialized with the correct mode

2014-05-06T14:59:31Z

commit 7d3477d801808a5037a511cf5a5aae5718e7ecce upstream. If no driver takeover the atmel_lcdfb, the lcd won't be in a working state since atmel_lcdfb_set_par() will never be called. Enabling a driver which does, like fbcon, will call the function and put atmel_lcdfb in a working state. Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport) Signed-off-by: Antoine Ténart Reported-by: Alexandre Belloni Acked-by: Alexandre Belloni Acked-by: Nicolas Ferre Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.

2014-02-14T08:44:52Z

Without that patch, a user can't select the imxfb driver when the i.MX25 and/or the i.MX27 device tree board are selected and that no boards that selects IMX_HAVE_PLATFORM_IMX_FB are compiled in. Cc: Eric Bénard Cc: Jean-Christophe Plagniol-Villard Cc: Sascha Hauer Cc: Tomi Valkeinen Cc: linux-arm-kernel@lists.infradead.org Cc: linux-fbdev@vger.kernel.org Signed-off-by: Denis Carikli Acked-by: Shawn Guo Acked-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Sascha Hauer Signed-off-by: Tomi Valkeinen

video: exynos: Fix S6E8AX0 LCD driver build error

2014-02-14T08:44:51Z

Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver. Else we get the following errors due to missing symbols: drivers/built-in.o: In function `s6e8ax0_probe': :(.text+0x51aec): undefined reference to `lcd_device_register' :(.text+0x51c44): undefined reference to `lcd_device_unregister' Signed-off-by: Sachin Kamat Signed-off-by: Tomi Valkeinen

OMAPDSS: fix fck field types

2014-02-11T14:19:46Z

'fck' field in dpi and sdi clock calculation struct is 'unsigned long long', even though it should be 'unsigned long'. This hasn't caused any issues so far. Fix the field's type. Signed-off-by: Tomi Valkeinen