Commit Graph

6 Commits

Author SHA1 Message Date
Helge Deller
adf6b20654 [PATCH] fbcmap.c: mark structs const or __read_mostly
- Mark the default colormaps read-only, as nobody should be allowed to
  modify them

- Additionally mark color values as __read_mostly since they will only be
  modified (very seldom) by fb_invert_cmaps()

- Add named C99-initializers in fb_cmap structs and use the ARRAY_SIZE()
  macro

Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08 08:29:05 -08:00
Jon Smirl
a8f340e394 [PATCH] vt: Remove VT-specific declarations and definitions from tty.h
MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one.  Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.

[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 13:24:16 -07:00
Alan Curry
db77ec270d [PATCH] framebuffer: cmap-setting return values
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>
2006-03-27 08:44:56 -08:00
Michal Januszewski
03e259a9cd [PATCH] fbdev: update info->cmap when setting cmap from user-/kernelspace.
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>
2005-07-27 16:26:19 -07:00
Benjamin Herrenschmidt
7149437669 [PATCH] fbdev: Batch cmap changes at driver level
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>
2005-05-01 08:59:22 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00