summaryrefslogtreecommitdiffstats
path: root/drivers/video/fbcmap.c
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] framebuffer: cmap-setting return valuesAlan Curry2006-03-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | A set of 3 small bugfixes, all of which are related to bogus return values of fb colormap-setting functions. First, fb_alloc_cmap returns -1 if memory allocation fails. This is a hard condition to reproduce since you'd have to be really low on memory, but from studying the contexts in which it is called, I think this function should be returning a negative errno, and the -1 will be seen as an EPERM. Switching it to -ENOMEM makes sense. Second, the store_cmap function which is called for writes to /sys/class/graphics/fb0/color_map returns 0 for success, but it should be returning the count of bytes written since its return value ends up in userspace as the result of the write() syscall. Third, radeonfb returns 1 instead of a negative errno when FBIOPUTCMAP is called with an oversized colormap. This is seen in userspace as a return value of 1 from the ioctl() syscall with errno left unchanged. A more useful return value would be -EINVAL. Signed-off-by: Alan Curry <pacman@TheWorld.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fbdev: update info->cmap when setting cmap from user-/kernelspace.Michal Januszewski2005-07-271-60/+36
| | | | | | | | | | | | | | | | | | | | | | The fb_info struct, as defined in include/linux/fb.h, contains an element that is supposed to hold the current color map: struct fb_cmap cmap; /* Current cmap */ This cmap is currently never updated when either fb_set_cmap() or fb_set_user_cmap() are called. As a result, info->cmap contains the default cmap that was set by a device driver/fbcon and a userspace application using the FBIOGETCMAP ioctl will not always get the *currently* used color map. The patch fixes this by making sure the cmap is copied to info->cmap after it is set correctly. It moves most of the code that is responsible for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to avoid code-duplication. Signed-off-by: Michal Januszewski <spock@gentoo.org> Cc: <linux-fbdev-devel@lists.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fbdev: Batch cmap changes at driver levelBenjamin Herrenschmidt2005-05-011-2/+30
| | | | | | | | | | | This patch adds to the fbdev interface a set_cmap callback that allow the driver to "batch" palette changes. This is useful for drivers like radeonfb which might require lenghtly workarounds on palette accesses, thus allowing to factor out those workarounds efficiently. 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>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+337
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!
OpenPOWER on IntegriCloud