kernel/git/stable/linux-stable.git/drivers/video, branch linux-2.6.15.y

[PATCH] gbefb: IP32 gbefb depth change fix

2006-03-01T22:36:36+00:00

The gbefb driver does not update the framebuffer layers visual setting when depth is changed with fbset, resulting in strange colors (very dark blue in 16-bit, almost black in 24-bit). Signed-off-by: Kaj-Michael Lang Signed-off-by: Martin Michlmayr Signed-off-by: Antonino Daplas Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] gbefb: Set default of FB_GBE_MEM to 4 MB

2006-03-01T22:36:36+00:00

Allocating more than 4 MB memory for the GBE (SGI O2) framebuffer completely breakfs gbefb support at the moment. According to comments on #mipslinux, more than 4 MB has never worked correctly in Linux. Therefore, the default should be 4 MB. Signed-off-by: Martin Michlmayr Signed-off-by: Antonino Daplas Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] vgacon: fix doublescan mode

2006-01-15T06:15:28+00:00

When doublescan mode is in use, scanlines must be doubled. Thanks to Jason Dravet for reporting and testing. Signed-off-by: Samuel Thibault Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] Fix onboard video on SPARC Blade 100 for 2.6.{13,14,15}

2006-01-15T06:15:27+00:00

I have recently been switching from using 2.4.32 on my trusty old Sparc Blade 100 to using 2.6.15 . Some of the problems I ran into were distorted video when the console was active (missing first character, skipped dots) and when running X windows (colored snow, stripes, missing pixels). A quick examination of the 2.6 versus 2.4 source for the ATY driver revealed alot of changes. A closer look at the code/data for the 64GR/XL chip revealed two minor "typos" that the rewriter(s) of the code made. The first is a incorrect clock value (230 .vs. 235) and the second is a missing flag (M64F_SDRAM_MAGIC_PLL). Making both these changes seems to have fixed my problem. I tend to think the 235 value is the correct one, as there is a 29.4 Mhz clock crystal close to the video chip and 235.2 (29.4*8) is too close to 235 to make it a coincidence. The flag for M64F_SDRAM_MAGIC_PLL was dropped during the changes made by adaplas in file revision 1.72 on the old bitkeeper repository. The change relating to the clock rate has been there forever, at least in the 2.6 tree. I'm not sure where to look for the old 2.5 tree or if anyone cares when it happened. On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the clock crystal frequency is 235.2 Mhz, not 230 Mhz. The chipset also requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL properly for the DRAM. Signed-off-by: Luis F. Ortiz Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[VIDEO] sbuslib: Disallow private mmaps.

2005-12-24T20:06:10+00:00

The COW semantics just do not make any sense especially with the physically discontiguous I/O mappings possible here. Signed-off-by: David S. Miller

[SPARC]: introduce a SPARC Kconfig symbol

2005-12-23T07:09:54+00:00

Introduce a Kconfig symbol SPARC that is defined on both the sparc and sparc64 architectures. This symbol makes some dependencies more readable. Signed-off-by: Adrian Bunk Signed-off-by: David S. Miller

[PATCH] Fix framebuffer console upside-down ywrap scrolling

2005-12-20T17:44:20+00:00

Whenever ywrap scrolling is selected together with 180 degree screen rotation, 2.6.15-rc6 and earlier versions are broken. fb_pan_display() expects non-negative yoffsets, but ud_update_start() calls it with yoffsets down to -(yres - font height). This patch transforms yoffset to the correct range 0 ... vyres-1. Some obviously unneeded parentheses are removed, too. Verified with cyblafb, should be applied before 2.6.15-final because it does fix the framebuffer rotation code introduced early in the 2.6.15 release cycle. Signed-off-by: Knut Petersen Acked-by: Antonino Daplas Signed-off-by: Linus Torvalds

[PATCH] intelfb: Fix oops when changing video mode

2005-12-20T17:27:15+00:00

Reported by: janis huang (Bugzilla Bug 5747) Fix on oops in intelfb. Not sure what's happening, looks like dinfo->name pointer is invalidated after initialization. Remove intelfb_get_fix, it's not needed and move the majority of the code to the initialization routine. Signed-off-by: Antonino Daplas Signed-off-by: Linus Torvalds

[PATCH] intelfb: Fix freeing of nonexistent resource

2005-12-20T17:27:15+00:00

Fix intelfb trying to free a non-existent resource in its error path. Signed-off-by: Antonino Daplas Signed-off-by: Linus Torvalds

[PATCH] arcfb __user annotations

2005-12-15T18:04:30+00:00

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds