aboutsummaryrefslogtreecommitdiff
path: root/drivers/video
AgeCommit message (Collapse)Author
2005-04-30[PATCH] ARM: IntegratorCP: 16bpp is RGB565 not RGB555Russell King
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-04-30[PATCH] ARM: AMBA CLCD: program palette for pseudocolor visualsRussell King
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-04-28[PATCH] ARM: Fix AMBA CLCD fb driver for 32bppRussell King
We were supporting 24bpp. However, the pixel organisation in memory was 0RGB, so it was 24bpp in 32bit words. This means we're actually supporting 32bpp and not 24bpp. Also, add a check to ensure that we don't exceed the available framebuffer when changing display resolutions. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-04-28[PATCH] ARM: Fix AMBA CLCD fb driver for 1bpp/STN mono panelsRussell King
Fix the AMBA CLCD framebuffer driver for 1bpp modes and STN monochrome LCD panels. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-04-26[PATCH] imsttfb missing iomem annotationsAl Viro
write_reg_le32() and read_reg_le32() expect iomem pointers... Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-26[PATCH] savagefb iomem annotationsAl Viro
trivial iomem annotations + memset() replaced with memset_io() in a place that deals with ioremapped area. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-24[SPARC]: Enable sun logo on sparc32Bob Breuer
This enables the sun linux logo to be selected on sparc32. Signed-off-by: Bob Breuer <breuerr@mc.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-24[SPARC]: TCX Framebuffer fixesTom 'spot' Callaway
Using the same logic as the other framebuffer fixes committed in 2.6.11, this is a set of fixes to make TCX functional on the console again. Adds the tcx_pan_display function, sets the all->info.var.{red,green,blue}.length values to 8, and runs fb_set_cmap. Also looks for the correct SUNW,tcx prom value. This patch just slipped through the cracks. Originally by: Georg Chini <georg.chini@triaton-webhosting.com> Signed-off-by: Tom 'spot' Callaway <tcallawa@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-21[PATCH] Fix tgafb.c compile failureAdrian Bunk
The untested patch below should fix this compile error. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] fix u32 vs. pm_message_t in driver/videoPavel Machek
This fixes u32 vs. pm_message_t confusion in drivers/video. Should change no code. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] ppc32: Fix AGP and sleep againBenjamin Herrenschmidt
My previous patch that added sleep support for uninorth-agp and some AGP "off" stuff in radeonfb and aty128fb is breaking some configs. More specifically, it has problems with rage128 setups since the DRI code for these in X doesn't properly re-enable AGP on wakeup or console switch (unlike the radeon DRM). This patch fixes the problem for pmac once for all by using a different approach. The AGP driver "registers" special suspend/resume callbacks with some arch code that the fbdev's can later on call to suspend and resume AGP, making sure it's resumed back in the same state it was when suspended. This is platform specific for now. It would be too complicated to try to do a generic implementation of this at this point due to all sort of weird things going on with AGP on other architectures. We'll re-work that whole problem cleanly once we finally merge fbdev's and DRI. In the meantime, please apply this patch which brings back some r128 based laptops into working condition as far as system sleep is concerned. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.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!