1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
xf86-video-unichrome:
---------------------
xf86-video-unichrome is a free software graphics driver for VIA Technologies
Integrated graphics of the CastleRock, Unichrome and Chrome9 denominations.
It currently supports the following chipsets:
VT3122: CLE266 (CastleRock).
VT7205: KM400, KM400A, KN400, P4M800 (Unichrome).
VT3108: K8M800, K8N800, K8N800A (Unichrome Pro, aka Pro B).
VT3118: CN400, PM800, PM880, PN800 (Unichrome Pro A).
VT3344: VN800, P4M800Pro, CN700, P4M800CE (Unichrome Pro).
VT3157: CX700, CX700M, VX700, CX700-M2 (Unichrome Pro).
VT3230: K8M890 (Chrome9 IGP).
VT3343: P4M890, VN890 (Unichrome Pro).
VT3371: P4M900, VN896, CN896 (Chrome 9 HC IGP).
VT1122: VX800, VX820 (Chrome 9 HC3 IGP).
The level of support for these chipsets varies.
The canonical source for this driver is:
http://cgit.freedesktop.org/~libv/xf86-video-unichrome/
You can get a copy of this repository by running:
git clone git://anongit.freedesktop.org/~libv/xf86-video-unichrome
Its main project website is:
http://unichrome.sf.net
If you run into any difficulties, please contact the unichrome-users
mailinglist at unichrome-devel@lists.sourceforge.net . Subscribe at
http://lists.sourceforge.net/mailman/listinfo/unichrome-devel first.
1) Building this driver manually:
---------------------------------
WARNING: This section is about building and installing this driver yourself.
This will not make your package manager happy, and you might want to check
the next section instead. You might also want to back up via_drv.o/so and the
manpage first.
This driver is suited for Xorg 7.0 through 7.5. While it used to support
older X versions, such support has now been removed, but can be re-added upon
popular request. Such wide range of support is unique in today's X world.
1.1) Requirements:
- An X version more recent than 7.0 RC2 (there was a macro difference before
that).
- A full X install or the xorg DDK installed. Here is a list of package
names for the common distributions:
* Debian and derivates: xserver-xorg-dev
* Redhat/SuSE: xorg-x11-server-sdk
Contact me if you would like to add to this list.
1.2) Building:
Building against modular is a breeze. All it takes is:
# ./autogen.sh
or
# ./autogen.sh --prefix=<...>
and then
# make
and
# make install
1.3) Common problems:
1.3.1) aclocal is unable to find X macros.
You will see configure complain with:
./configure: line xxxxx: XORG_MANPAGE_SECTIONS: command not found
./configure: line xxxxx: XORG_RELEASE_VERSION: command not found
What happens is that aclocal is unable to find your xorgversion.m4 and
xorg-macros.m4. These are usually found in <prefix>/share/aclocal
This can be solved by doing the following before running autogen.sh:
- permanent solution: add a file named dirlist to your
/usr/share/aclocal/ directory, and add a line with the path for X
macros.
- temporary solution: run
# export ACLOCAL_LOCALDIR="<prefix>/share/aclocal/"
1.3.2) XORG_DRIVER_CHECK_EXT missing from macros.
Configure fails with following message:
./configure: line xxxxx: syntax error near unexpected token `RANDR,'
./configure: line xxxxx: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'
The cause of this is that xorg-server.m4 isn't available. This was only
added a few days before 7.0RC2 was tagged, but it is quite incompatible
with earlier versions.
Make sure you have at least RC2.
If anyone with a lot of autoconf experience knows how to properly check
for the existence of individual macros at the autoheader stage, please
don't hesitate to contact me.
1.3.3) Automake too old.
autogen.sh fails with:
configure.ac: xxx: required file `./[config.h].in' not found
src/Makefile.am:xx: via_drv_la_SOURCES defined both conditionally
Make sure that you have at least automake version 1.7
2) Building this driver as a package:
-------------------------------------
This driver comes with some support for being built as a package directly.
This is, once again, a rather unique feature of this driver.
2.1) Debian based systems:
This driver comes with built in debian package scripts in the debian/
directory. It is suited for at least debian and ubuntu, and even handles
the early ubuntu days where they used completely different package names
from debian.
All you have to do is run dpkg-buildpackage in the drivers top level
directory. dpkg-buildpackage is a part of the dpkg-dev package.
2.2) RPM based systems:
No spec file is provided at this time, i should poke sndirsch (SUSE Xorg
package/bugmaster) to see whether i am allowed to just steal his. It works
for most rpm based distributions directly.
3) Using XvMC with this driver.
-------------------------------
This driver provides Slice decoder support for xine and MythTV, even
though there are some things that you should be aware of.
2.1) Xine issues:
The Xine "XXMC" video output driver has a rather appalling amount of
issues.
2.1.1) video_out_xxmc requires subpicture support.
This for no reason whatsoever, the xxmc video out module depends on
subpictures. When running this driver, you can notice the following when
xine dies:
abort: video_out_xxmc.c:622: create_ximage: Aborting.
To alleviate this, add the following to your device section in your
xorg.conf:
Option "XvMCBrokenXine" "True"
This fools xine in that the server advertises subpictures, while not
actually implementing them. You will notice these messages:
XvMCCreateSubpicture is not implemented.
XvMCBlendSubpicture2 is not implemented.
These are rather harmless. The first will have the xxmc code fall back to
software drawing just fine. And the second is actually just a horrible
example of abusing an API for other purposes.
2.1.2) Xine splash is not always showing correctly.
This is an issue with the xxmc code as well: it tends to feed the
dimensions of the mpeg2 stream as the dimensions of the xine splash, which
the standard Xv interface then feeds to the driver. You can notice a
strangely squated splash, with some green edges with sometimes flickering
areas. This is not a problem, as it is just showing random (empty) FB
content.
Luc Verhaegen, <libv@skynet.be>
|
