<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/video/uvesafb.h, branch linux-3.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2013-05-31T03:37:36Z</updated>
<entry>
<title>uvesafb: Clean up MTRR code</title>
<updated>2013-05-31T03:37:36Z</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@amacapital.net</email>
</author>
<published>2013-05-13T23:58:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75'/>
<id>urn:sha1:63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75</id>
<content type='text'>
The old code allowed very strange memory types.  Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).

UC, WB, and WT support is gone.  If there are MTRR conflicts that prevent
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.

As an added bonus, any MTRR added is freed on unload.

Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>UAPI: (Scripted) Disintegrate include/video</title>
<updated>2012-12-20T17:14:26Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2012-12-20T17:14:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b889fcf63cb62e7fdb7816565e28f44dbe4a76a5'/>
<id>urn:sha1:b889fcf63cb62e7fdb7816565e28f44dbe4a76a5</id>
<content type='text'>
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Michael Kerrisk &lt;mtk.manpages@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Acked-by: Dave Jones &lt;davej@redhat.com&gt;
</content>
</entry>
<entry>
<title>headers_check fix: video/uvesafb.h</title>
<updated>2009-01-30T18:44:52Z</updated>
<author>
<name>Jaswinder Singh Rajput</name>
<email>jaswinderrajput@gmail.com</email>
</author>
<published>2009-01-30T17:05:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=de4d3795527b06c67e1333c5662f146b59c97e21'/>
<id>urn:sha1:de4d3795527b06c67e1333c5662f146b59c97e21</id>
<content type='text'>
fix the following 'make headers_check' warning:

  usr/include/video/uvesafb.h:5: found __[us]{8,16,32,64} type without #include &lt;linux/types.h&gt;

Signed-off-by: Jaswinder Singh Rajput &lt;jaswinderrajput@gmail.com&gt;
</content>
</entry>
<entry>
<title>uvesafb: the driver core</title>
<updated>2007-10-16T16:43:13Z</updated>
<author>
<name>Michal Januszewski</name>
<email>spock@gentoo.org</email>
</author>
<published>2007-10-16T08:28:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8bdb3a2d7df48b861972c4bfb58490853a228f51'/>
<id>urn:sha1:8bdb3a2d7df48b861972c4bfb58490853a228f51</id>
<content type='text'>
uvesafb is an enhanced version of vesafb.  It uses a userspace helper (v86d)
to execute calls to the x86 Video BIOS functions.  The driver is not limited
to any specific arch and whether it works on a given arch or not depends on
that arch being supported by the userspace daemon.  It has been tested on
x86_32 and x86_64.

A single BIOS call is represented by an instance of the uvesafb_ktask
structure.  This structure contains a buffer, a completion struct and a
uvesafb_task substructure, containing the values of the x86 registers, a flags
field and a field indicating the length of the buffer.  Whenever a BIOS call
is made in the driver, uvesafb_exec() builds a message using the uvesafb_task
substructure and the contents of the buffer.  This message is then assigned a
random ack number and sent to the userspace daemon using the connector
interface.

The message's sequence number is used as an index for the uvfb_tasks array,
which provides a mapping from the messages coming from userspace to the
in-kernel uvesafb_ktask structs.

The userspace daemon performs the requested operation and sends a reply in the
form of a uvesafb_task struct and, optionally, a buffer.  The seq and ack
numbers in the reply should be exactly the same as those in the request.

Each message from userspace is processed by uvesafb_cn_callback() and after
passing a few sanity checks leads to the completion of a BIOS call request.

Signed-off-by: Michal Januszewski &lt;spock@gentoo.org&gt;
Signed-off-by: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: Paul Mundt &lt;lethal@linux-sh.org&gt;
Cc: Paulo Marques &lt;pmarques@grupopie.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
