<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/video/macfb.c, branch linux-2.6.18.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.18.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.18.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2006-07-10T20:24:16+00:00</updated>
<entry>
<title>[PATCH] vt: Remove VT-specific declarations and definitions from tty.h</title>
<updated>2006-07-10T20:24:16+00:00</updated>
<author>
<name>Jon Smirl</name>
<email>jonsmir@gmail.com</email>
</author>
<published>2006-07-10T11:44:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a8f340e394ff30b79ab5b03c67ab4c94b2ac3646'/>
<id>urn:sha1:a8f340e394ff30b79ab5b03c67ab4c94b2ac3646</id>
<content type='text'>
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 &lt;jonsmir@gmail.com&gt;
Signed-off-by: Antonino Daplas &lt;adaplas@pol.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] m68k: fix macfb init</title>
<updated>2006-01-12T17:09:05+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2006-01-12T09:06:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed1705afb93409a3e345d653be9d263984aa5c1b'/>
<id>urn:sha1:ed1705afb93409a3e345d653be9d263984aa5c1b</id>
<content type='text'>
To be used by module_init() function should return int; same for functions
that have "return -ENODEV;" in them, actually ;-)

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon</title>
<updated>2005-11-07T15:53:50+00:00</updated>
<author>
<name>Antonino A. Daplas</name>
<email>adaplas@gmail.com</email>
</author>
<published>2005-11-07T09:00:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c465e05a03209651078b95686158648fd7ed84c5'/>
<id>urn:sha1:c465e05a03209651078b95686158648fd7ed84c5</id>
<content type='text'>
According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant.  The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit.  And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.

Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank.  For drivers that do, they can fill up this field with their own
version.

The end result is a smaller code size.  And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.

Signed-off-by: Antonino Daplas &lt;adaplas@pol.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
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!
</content>
</entry>
</feed>
