Import Upstream version 7.7+19ubuntu14
This commit is contained in:
openKylinBot
commit
9e88810c3a
|
|
@ -0,0 +1,19 @@
|
||||||
|
© 2010-2011 Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in
|
||||||
|
all copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
||||||
|
THE SOFTWARE.
|
||||||
|
|
@ -0,0 +1,64 @@
|
||||||
|
#!/usr/bin/make -f
|
||||||
|
|
||||||
|
txt_files = $(shell find -name '*.txt' -a ! -name '.*.txt')
|
||||||
|
|
||||||
|
html_files = $(patsubst %.txt,%.html,$(txt_files))
|
||||||
|
|
||||||
|
pdf_files = $(patsubst %.txt,%.pdf,$(txt_files))
|
||||||
|
|
||||||
|
TXT_TO_HTML = TZ=UTC asciidoc -a linkcss
|
||||||
|
HTML_TO_PDF = wkhtmltopdf
|
||||||
|
CSS_FILE = xsf.css
|
||||||
|
ADOC_CSS_FILE= asciidoc-xhtml11.css
|
||||||
|
ADOC_JS_FILE = asciidoc-xhtml11.js
|
||||||
|
SVG_LOGO = xsf.svg
|
||||||
|
PNG_LOGO = xsf.png
|
||||||
|
|
||||||
|
all_files = $(html_files) $(txt_files) $(CSS_FILE) $(ADOC_CSS_FILE) $(ADOC_JS_FILE) $(SVG_LOGO) $(PNG_LOGO)
|
||||||
|
|
||||||
|
all: html $(PNG_LOGO)
|
||||||
|
|
||||||
|
html: $(html_files)
|
||||||
|
|
||||||
|
pdf: $(pdf_files)
|
||||||
|
|
||||||
|
%.html: rel_path=$(shell echo $@|sed 's,[^/],,g;s,/,../,g')
|
||||||
|
%.html: link_home=$(shell echo "<a href=\"$(rel_path)index.html\">XSF</a> / ")
|
||||||
|
%.html: %.txt
|
||||||
|
@echo " HTML $@"
|
||||||
|
@$(TXT_TO_HTML) -o $@.tmp $<
|
||||||
|
@echo " HOME $@"
|
||||||
|
@if [ $< != index.txt ]; then sed -i 's,<h1>,<h1>$(link_home),' $@.tmp; fi
|
||||||
|
@echo " CSS $@"
|
||||||
|
@sed -i 's,\(rel="stylesheet" href="\)[^"]*,\1$(rel_path)$(CSS_FILE),' $@.tmp
|
||||||
|
@echo " JS $@"
|
||||||
|
@sed -i 's,\(type="text/javascript" src="\)[^"]*,\1$(rel_path)$(ADOC_JS_FILE),' $@.tmp
|
||||||
|
@mv $@.tmp $@
|
||||||
|
|
||||||
|
%.pdf: %.html $(CSS_FILE) $(ADOC_CSS_FILE) $(ADOC_JS_FILE) $(SVG_LOGO)
|
||||||
|
@echo " GEN $@"
|
||||||
|
@$(HTML_TO_PDF) $< $@
|
||||||
|
|
||||||
|
# We usually don't need to run this one, but it's easier to keep both
|
||||||
|
# SVN and PNG logos in sync:
|
||||||
|
$(PNG_LOGO): $(SVG_LOGO)
|
||||||
|
inkscape $< -e $@
|
||||||
|
|
||||||
|
install:
|
||||||
|
@if [ -z "$(DESTDIR)" ]; then \
|
||||||
|
echo 'E: DESTDIR is not set, not installing.'; exit 1; \
|
||||||
|
fi
|
||||||
|
mkdir -p $(DESTDIR)
|
||||||
|
# There are probably better ways:
|
||||||
|
set -e; for i in $(all_files); do \
|
||||||
|
d=$(DESTDIR)/`dirname $$i` && \
|
||||||
|
mkdir -p $$d && \
|
||||||
|
install $$i $$d; \
|
||||||
|
done
|
||||||
|
|
||||||
|
clean:
|
||||||
|
@echo "Removing all generated files"
|
||||||
|
rm -f $(html_files) $(pdf_files)
|
||||||
|
|
||||||
|
|
||||||
|
.PHONY: clean html pdf all
|
||||||
|
|
@ -0,0 +1,424 @@
|
||||||
|
/* Sans-serif font. */
|
||||||
|
h1, h2, h3, h4, h5, h6,
|
||||||
|
div.title, caption.title,
|
||||||
|
thead, p.table.header,
|
||||||
|
div#toctitle,
|
||||||
|
span#author, span#revnumber, span#revdate, span#revremark,
|
||||||
|
div#footer {
|
||||||
|
font-family: Arial,Helvetica,sans-serif;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Serif font. */
|
||||||
|
div.sectionbody {
|
||||||
|
font-family: Georgia,"Times New Roman",Times,serif;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Monospace font. */
|
||||||
|
tt {
|
||||||
|
font-size: inherit;
|
||||||
|
}
|
||||||
|
|
||||||
|
body {
|
||||||
|
margin: 1em 5% 1em 5%;
|
||||||
|
}
|
||||||
|
|
||||||
|
a {
|
||||||
|
color: blue;
|
||||||
|
text-decoration: underline;
|
||||||
|
}
|
||||||
|
a:visited {
|
||||||
|
color: fuchsia;
|
||||||
|
}
|
||||||
|
|
||||||
|
em {
|
||||||
|
font-style: italic;
|
||||||
|
color: navy;
|
||||||
|
}
|
||||||
|
|
||||||
|
strong {
|
||||||
|
font-weight: bold;
|
||||||
|
color: #083194;
|
||||||
|
}
|
||||||
|
|
||||||
|
tt {
|
||||||
|
font-size: inherit;
|
||||||
|
color: navy;
|
||||||
|
}
|
||||||
|
|
||||||
|
h1, h2, h3, h4, h5, h6 {
|
||||||
|
color: #527bbd;
|
||||||
|
margin-top: 1.2em;
|
||||||
|
margin-bottom: 0.5em;
|
||||||
|
line-height: 1.3;
|
||||||
|
}
|
||||||
|
|
||||||
|
h1, h2, h3 {
|
||||||
|
border-bottom: 2px solid silver;
|
||||||
|
}
|
||||||
|
h2 {
|
||||||
|
padding-top: 0.5em;
|
||||||
|
}
|
||||||
|
h3 {
|
||||||
|
float: left;
|
||||||
|
}
|
||||||
|
h3 + * {
|
||||||
|
clear: left;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.sectionbody {
|
||||||
|
margin-left: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
hr {
|
||||||
|
border: 1px solid silver;
|
||||||
|
}
|
||||||
|
|
||||||
|
p {
|
||||||
|
margin-top: 0.5em;
|
||||||
|
margin-bottom: 0.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
ul, ol, li > p {
|
||||||
|
margin-top: 0;
|
||||||
|
}
|
||||||
|
ul > li { color: #aaa; }
|
||||||
|
ul > li > * { color: black; }
|
||||||
|
|
||||||
|
pre {
|
||||||
|
padding: 0;
|
||||||
|
margin: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
span#author {
|
||||||
|
color: #527bbd;
|
||||||
|
font-weight: bold;
|
||||||
|
font-size: 1.1em;
|
||||||
|
}
|
||||||
|
span#email {
|
||||||
|
}
|
||||||
|
span#revnumber, span#revdate, span#revremark {
|
||||||
|
}
|
||||||
|
|
||||||
|
div#footer {
|
||||||
|
font-size: small;
|
||||||
|
border-top: 2px solid silver;
|
||||||
|
padding-top: 0.5em;
|
||||||
|
margin-top: 4.0em;
|
||||||
|
}
|
||||||
|
div#footer-text {
|
||||||
|
float: left;
|
||||||
|
padding-bottom: 0.5em;
|
||||||
|
}
|
||||||
|
div#footer-badges {
|
||||||
|
float: right;
|
||||||
|
padding-bottom: 0.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div#preamble {
|
||||||
|
margin-top: 1.5em;
|
||||||
|
margin-bottom: 1.5em;
|
||||||
|
}
|
||||||
|
div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
|
||||||
|
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
|
||||||
|
div.admonitionblock {
|
||||||
|
margin-top: 1.0em;
|
||||||
|
margin-bottom: 1.5em;
|
||||||
|
}
|
||||||
|
div.admonitionblock {
|
||||||
|
margin-top: 2.0em;
|
||||||
|
margin-bottom: 2.0em;
|
||||||
|
margin-right: 10%;
|
||||||
|
color: #606060;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.content { /* Block element content. */
|
||||||
|
padding: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Block element titles. */
|
||||||
|
div.title, caption.title {
|
||||||
|
color: #527bbd;
|
||||||
|
font-weight: bold;
|
||||||
|
text-align: left;
|
||||||
|
margin-top: 1.0em;
|
||||||
|
margin-bottom: 0.5em;
|
||||||
|
}
|
||||||
|
div.title + * {
|
||||||
|
margin-top: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
td div.title:first-child {
|
||||||
|
margin-top: 0.0em;
|
||||||
|
}
|
||||||
|
div.content div.title:first-child {
|
||||||
|
margin-top: 0.0em;
|
||||||
|
}
|
||||||
|
div.content + div.title {
|
||||||
|
margin-top: 0.0em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.sidebarblock > div.content {
|
||||||
|
background: #ffffee;
|
||||||
|
border: 1px solid #dddddd;
|
||||||
|
border-left: 4px solid #f0f0f0;
|
||||||
|
padding: 0.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.listingblock > div.content {
|
||||||
|
border: 1px solid #dddddd;
|
||||||
|
border-left: 5px solid #f0f0f0;
|
||||||
|
background: #f8f8f8;
|
||||||
|
padding: 0.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.quoteblock, div.verseblock {
|
||||||
|
padding-left: 1.0em;
|
||||||
|
margin-left: 1.0em;
|
||||||
|
margin-right: 10%;
|
||||||
|
border-left: 5px solid #f0f0f0;
|
||||||
|
color: #777777;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.quoteblock > div.attribution {
|
||||||
|
padding-top: 0.5em;
|
||||||
|
text-align: right;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.verseblock > pre.content {
|
||||||
|
font-family: inherit;
|
||||||
|
font-size: inherit;
|
||||||
|
}
|
||||||
|
div.verseblock > div.attribution {
|
||||||
|
padding-top: 0.75em;
|
||||||
|
text-align: left;
|
||||||
|
}
|
||||||
|
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
|
||||||
|
div.verseblock + div.attribution {
|
||||||
|
text-align: left;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.admonitionblock .icon {
|
||||||
|
vertical-align: top;
|
||||||
|
font-size: 1.1em;
|
||||||
|
font-weight: bold;
|
||||||
|
text-decoration: underline;
|
||||||
|
color: #527bbd;
|
||||||
|
padding-right: 0.5em;
|
||||||
|
}
|
||||||
|
div.admonitionblock td.content {
|
||||||
|
padding-left: 0.5em;
|
||||||
|
border-left: 3px solid #dddddd;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.exampleblock > div.content {
|
||||||
|
border-left: 3px solid #dddddd;
|
||||||
|
padding-left: 0.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.imageblock div.content { padding-left: 0; }
|
||||||
|
span.image img { border-style: none; }
|
||||||
|
a.image:visited { color: white; }
|
||||||
|
|
||||||
|
dl {
|
||||||
|
margin-top: 0.8em;
|
||||||
|
margin-bottom: 0.8em;
|
||||||
|
}
|
||||||
|
dt {
|
||||||
|
margin-top: 0.5em;
|
||||||
|
margin-bottom: 0;
|
||||||
|
font-style: normal;
|
||||||
|
color: navy;
|
||||||
|
}
|
||||||
|
dd > *:first-child {
|
||||||
|
margin-top: 0.1em;
|
||||||
|
}
|
||||||
|
|
||||||
|
ul, ol {
|
||||||
|
list-style-position: outside;
|
||||||
|
}
|
||||||
|
ol.arabic {
|
||||||
|
list-style-type: decimal;
|
||||||
|
}
|
||||||
|
ol.loweralpha {
|
||||||
|
list-style-type: lower-alpha;
|
||||||
|
}
|
||||||
|
ol.upperalpha {
|
||||||
|
list-style-type: upper-alpha;
|
||||||
|
}
|
||||||
|
ol.lowerroman {
|
||||||
|
list-style-type: lower-roman;
|
||||||
|
}
|
||||||
|
ol.upperroman {
|
||||||
|
list-style-type: upper-roman;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.compact ul, div.compact ol,
|
||||||
|
div.compact p, div.compact p,
|
||||||
|
div.compact div, div.compact div {
|
||||||
|
margin-top: 0.1em;
|
||||||
|
margin-bottom: 0.1em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.tableblock > table {
|
||||||
|
border: 3px solid #527bbd;
|
||||||
|
}
|
||||||
|
thead, p.table.header {
|
||||||
|
font-weight: bold;
|
||||||
|
color: #527bbd;
|
||||||
|
}
|
||||||
|
tfoot {
|
||||||
|
font-weight: bold;
|
||||||
|
}
|
||||||
|
td > div.verse {
|
||||||
|
white-space: pre;
|
||||||
|
}
|
||||||
|
p.table {
|
||||||
|
margin-top: 0;
|
||||||
|
}
|
||||||
|
/* Because the table frame attribute is overriden by CSS in most browsers. */
|
||||||
|
div.tableblock > table[frame="void"] {
|
||||||
|
border-style: none;
|
||||||
|
}
|
||||||
|
div.tableblock > table[frame="hsides"] {
|
||||||
|
border-left-style: none;
|
||||||
|
border-right-style: none;
|
||||||
|
}
|
||||||
|
div.tableblock > table[frame="vsides"] {
|
||||||
|
border-top-style: none;
|
||||||
|
border-bottom-style: none;
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
div.hdlist {
|
||||||
|
margin-top: 0.8em;
|
||||||
|
margin-bottom: 0.8em;
|
||||||
|
}
|
||||||
|
div.hdlist tr {
|
||||||
|
padding-bottom: 15px;
|
||||||
|
}
|
||||||
|
dt.hdlist1.strong, td.hdlist1.strong {
|
||||||
|
font-weight: bold;
|
||||||
|
}
|
||||||
|
td.hdlist1 {
|
||||||
|
vertical-align: top;
|
||||||
|
font-style: normal;
|
||||||
|
padding-right: 0.8em;
|
||||||
|
color: navy;
|
||||||
|
}
|
||||||
|
td.hdlist2 {
|
||||||
|
vertical-align: top;
|
||||||
|
}
|
||||||
|
div.hdlist.compact tr {
|
||||||
|
margin: 0;
|
||||||
|
padding-bottom: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
.comment {
|
||||||
|
background: yellow;
|
||||||
|
}
|
||||||
|
|
||||||
|
.footnote, .footnoteref {
|
||||||
|
font-size: 0.8em;
|
||||||
|
}
|
||||||
|
|
||||||
|
span.footnote, span.footnoteref {
|
||||||
|
vertical-align: super;
|
||||||
|
}
|
||||||
|
|
||||||
|
#footnotes {
|
||||||
|
margin: 20px 0 20px 0;
|
||||||
|
padding: 7px 0 0 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
#footnotes div.footnote {
|
||||||
|
margin: 0 0 5px 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
#footnotes hr {
|
||||||
|
border: none;
|
||||||
|
border-top: 1px solid silver;
|
||||||
|
height: 1px;
|
||||||
|
text-align: left;
|
||||||
|
margin-left: 0;
|
||||||
|
width: 20%;
|
||||||
|
min-width: 100px;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.colist td {
|
||||||
|
padding-right: 0.5em;
|
||||||
|
padding-bottom: 0.3em;
|
||||||
|
vertical-align: top;
|
||||||
|
}
|
||||||
|
div.colist td img {
|
||||||
|
margin-top: 0.3em;
|
||||||
|
}
|
||||||
|
|
||||||
|
@media print {
|
||||||
|
div#footer-badges { display: none; }
|
||||||
|
}
|
||||||
|
|
||||||
|
div#toc {
|
||||||
|
margin-bottom: 2.5em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div#toctitle {
|
||||||
|
color: #527bbd;
|
||||||
|
font-size: 1.1em;
|
||||||
|
font-weight: bold;
|
||||||
|
margin-top: 1.0em;
|
||||||
|
margin-bottom: 0.1em;
|
||||||
|
}
|
||||||
|
|
||||||
|
div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
|
||||||
|
margin-top: 0;
|
||||||
|
margin-bottom: 0;
|
||||||
|
}
|
||||||
|
div.toclevel2 {
|
||||||
|
margin-left: 2em;
|
||||||
|
font-size: 0.9em;
|
||||||
|
}
|
||||||
|
div.toclevel3 {
|
||||||
|
margin-left: 4em;
|
||||||
|
font-size: 0.9em;
|
||||||
|
}
|
||||||
|
div.toclevel4 {
|
||||||
|
margin-left: 6em;
|
||||||
|
font-size: 0.9em;
|
||||||
|
}
|
||||||
|
|
||||||
|
span.aqua { color: aqua; }
|
||||||
|
span.black { color: black; }
|
||||||
|
span.blue { color: blue; }
|
||||||
|
span.fuchsia { color: fuchsia; }
|
||||||
|
span.gray { color: gray; }
|
||||||
|
span.green { color: green; }
|
||||||
|
span.lime { color: lime; }
|
||||||
|
span.maroon { color: maroon; }
|
||||||
|
span.navy { color: navy; }
|
||||||
|
span.olive { color: olive; }
|
||||||
|
span.purple { color: purple; }
|
||||||
|
span.red { color: red; }
|
||||||
|
span.silver { color: silver; }
|
||||||
|
span.teal { color: teal; }
|
||||||
|
span.white { color: white; }
|
||||||
|
span.yellow { color: yellow; }
|
||||||
|
|
||||||
|
span.aqua-background { background: aqua; }
|
||||||
|
span.black-background { background: black; }
|
||||||
|
span.blue-background { background: blue; }
|
||||||
|
span.fuchsia-background { background: fuchsia; }
|
||||||
|
span.gray-background { background: gray; }
|
||||||
|
span.green-background { background: green; }
|
||||||
|
span.lime-background { background: lime; }
|
||||||
|
span.maroon-background { background: maroon; }
|
||||||
|
span.navy-background { background: navy; }
|
||||||
|
span.olive-background { background: olive; }
|
||||||
|
span.purple-background { background: purple; }
|
||||||
|
span.red-background { background: red; }
|
||||||
|
span.silver-background { background: silver; }
|
||||||
|
span.teal-background { background: teal; }
|
||||||
|
span.white-background { background: white; }
|
||||||
|
span.yellow-background { background: yellow; }
|
||||||
|
|
||||||
|
span.big { font-size: 2em; }
|
||||||
|
span.small { font-size: 0.6em; }
|
||||||
|
|
@ -0,0 +1,128 @@
|
||||||
|
var asciidoc = { // Namespace.
|
||||||
|
|
||||||
|
/////////////////////////////////////////////////////////////////////
|
||||||
|
// Table Of Contents generator
|
||||||
|
/////////////////////////////////////////////////////////////////////
|
||||||
|
|
||||||
|
/* Author: Mihai Bazon, September 2002
|
||||||
|
* http://students.infoiasi.ro/~mishoo
|
||||||
|
*
|
||||||
|
* Table Of Content generator
|
||||||
|
* Version: 0.4
|
||||||
|
*
|
||||||
|
* Feel free to use this script under the terms of the GNU General Public
|
||||||
|
* License, as long as you do not remove or alter this notice.
|
||||||
|
*/
|
||||||
|
|
||||||
|
/* modified by Troy D. Hanson, September 2006. License: GPL */
|
||||||
|
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
|
||||||
|
|
||||||
|
// toclevels = 1..4.
|
||||||
|
toc: function (toclevels) {
|
||||||
|
|
||||||
|
function getText(el) {
|
||||||
|
var text = "";
|
||||||
|
for (var i = el.firstChild; i != null; i = i.nextSibling) {
|
||||||
|
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
|
||||||
|
text += i.data;
|
||||||
|
else if (i.firstChild != null)
|
||||||
|
text += getText(i);
|
||||||
|
}
|
||||||
|
return text;
|
||||||
|
}
|
||||||
|
|
||||||
|
function TocEntry(el, text, toclevel) {
|
||||||
|
this.element = el;
|
||||||
|
this.text = text;
|
||||||
|
this.toclevel = toclevel;
|
||||||
|
}
|
||||||
|
|
||||||
|
function tocEntries(el, toclevels) {
|
||||||
|
var result = new Array;
|
||||||
|
var re = new RegExp('[hH]([2-'+(toclevels+1)+'])');
|
||||||
|
// Function that scans the DOM tree for header elements (the DOM2
|
||||||
|
// nodeIterator API would be a better technique but not supported by all
|
||||||
|
// browsers).
|
||||||
|
var iterate = function (el) {
|
||||||
|
for (var i = el.firstChild; i != null; i = i.nextSibling) {
|
||||||
|
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
|
||||||
|
var mo = re.exec(i.tagName);
|
||||||
|
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
|
||||||
|
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
|
||||||
|
}
|
||||||
|
iterate(i);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
iterate(el);
|
||||||
|
return result;
|
||||||
|
}
|
||||||
|
|
||||||
|
var toc = document.getElementById("toc");
|
||||||
|
var entries = tocEntries(document.getElementById("content"), toclevels);
|
||||||
|
for (var i = 0; i < entries.length; ++i) {
|
||||||
|
var entry = entries[i];
|
||||||
|
if (entry.element.id == "")
|
||||||
|
entry.element.id = "_toc_" + i;
|
||||||
|
var a = document.createElement("a");
|
||||||
|
a.href = "#" + entry.element.id;
|
||||||
|
a.appendChild(document.createTextNode(entry.text));
|
||||||
|
var div = document.createElement("div");
|
||||||
|
div.appendChild(a);
|
||||||
|
div.className = "toclevel" + entry.toclevel;
|
||||||
|
toc.appendChild(div);
|
||||||
|
}
|
||||||
|
if (entries.length == 0)
|
||||||
|
toc.parentNode.removeChild(toc);
|
||||||
|
},
|
||||||
|
|
||||||
|
|
||||||
|
/////////////////////////////////////////////////////////////////////
|
||||||
|
// Footnotes generator
|
||||||
|
/////////////////////////////////////////////////////////////////////
|
||||||
|
|
||||||
|
/* Based on footnote generation code from:
|
||||||
|
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
|
||||||
|
*/
|
||||||
|
|
||||||
|
footnotes: function () {
|
||||||
|
var cont = document.getElementById("content");
|
||||||
|
var noteholder = document.getElementById("footnotes");
|
||||||
|
var spans = cont.getElementsByTagName("span");
|
||||||
|
var refs = {};
|
||||||
|
var n = 0;
|
||||||
|
for (i=0; i<spans.length; i++) {
|
||||||
|
if (spans[i].className == "footnote") {
|
||||||
|
n++;
|
||||||
|
// Use [\s\S] in place of . so multi-line matches work.
|
||||||
|
// Because JavaScript has no s (dotall) regex flag.
|
||||||
|
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
|
||||||
|
noteholder.innerHTML +=
|
||||||
|
"<div class='footnote' id='_footnote_" + n + "'>" +
|
||||||
|
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
|
||||||
|
n + "</a>. " + note + "</div>";
|
||||||
|
spans[i].innerHTML =
|
||||||
|
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
|
||||||
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
||||||
|
var id =spans[i].getAttribute("id");
|
||||||
|
if (id != null) refs["#"+id] = n;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
if (n == 0)
|
||||||
|
noteholder.parentNode.removeChild(noteholder);
|
||||||
|
else {
|
||||||
|
// Process footnoterefs.
|
||||||
|
for (i=0; i<spans.length; i++) {
|
||||||
|
if (spans[i].className == "footnoteref") {
|
||||||
|
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
|
||||||
|
href = href.match(/#.*/)[0]; // Because IE return full URL.
|
||||||
|
n = refs[href];
|
||||||
|
spans[i].innerHTML =
|
||||||
|
"[<a href='#_footnote_" + n +
|
||||||
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,96 @@
|
||||||
|
General FAQ
|
||||||
|
===========
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Input drivers
|
||||||
|
-------------
|
||||||
|
|
||||||
|
* _How do I configure input for X?_ +
|
||||||
|
Look at the link:../howto/configure-input.html[how to configure input] documentation.
|
||||||
|
|
||||||
|
* _Why can’t I kill X through `Ctrl+Alt+Backspace`?_ +
|
||||||
|
That’s explained in the above-mentioned documentation.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Video drivers
|
||||||
|
-------------
|
||||||
|
|
||||||
|
All drivers
|
||||||
|
~~~~~~~~~~~
|
||||||
|
|
||||||
|
* _What’s wrong with the DPI setting?_ +
|
||||||
|
By the default, the X server uses 96 DPI, as seen on upstream bug
|
||||||
|
https://bugs.freedesktop.org/show_bug.cgi?id=23705[#23705] (in
|
||||||
|
particular
|
||||||
|
https://bugs.freedesktop.org/show_bug.cgi?id=23705#c6[Keith’s comment]). A
|
||||||
|
particular DPI setting can be set through desktop environment’s
|
||||||
|
preferences, through the `-dpi` X server command line option (see
|
||||||
|
++Xserver++’s manual page), or through ++xrandr++’s `--dpi` option.
|
||||||
|
|
||||||
|
* _How do I get some info about 3D support?_ +
|
||||||
|
Look at the link:../howto/build-mesa.html[instructions to build mesa],
|
||||||
|
there are a few commands to learn about 3D support, the current driver,
|
||||||
|
etc.
|
||||||
|
|
||||||
|
Ati driver
|
||||||
|
~~~~~~~~~~
|
||||||
|
|
||||||
|
* _Why is it I’m getting low performances, or even crashes?_ +
|
||||||
|
Make sure you have installed the
|
||||||
|
link:http://packages.debian.org/firmware-linux&exact=1[`firmware-linux`
|
||||||
|
package]. The driver might still be working without the firmware,
|
||||||
|
but using code paths which aren’t supported as well as the “normal”
|
||||||
|
ones.
|
||||||
|
|
||||||
|
Intel driver
|
||||||
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* _Why isn’t it working?_ +
|
||||||
|
KMS is mandatory, as documented in its `README.Debian` (view it
|
||||||
|
online:
|
||||||
|
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=blob;f=debian/README.Debian[git.debian.org]). You
|
||||||
|
probably disabled KMS or didn’t include it in your kernel
|
||||||
|
configuration if you’re using a custom kernel.
|
||||||
|
|
||||||
|
* _X is crashing all the time with my “old” Intel card. What can I do?_ +
|
||||||
|
Unfortunately, old cards are not very well supported, and you can’t
|
||||||
|
do much more than switching to a generic driver, like `fbdev` or
|
||||||
|
`vesa`, as documented in `README.Debian` (view it online:
|
||||||
|
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=blob;f=debian/README.Debian[git.debian.org]). Please
|
||||||
|
note that you need to disable `KMS` if you want to use the `vesa`
|
||||||
|
driver. A minimal `xorg.conf` would look like:
|
||||||
|
----
|
||||||
|
Section "Device"
|
||||||
|
Identifier "MyBuggyCard"
|
||||||
|
Driver "fbdev"
|
||||||
|
EndSection
|
||||||
|
----
|
||||||
|
|
||||||
|
Nouveau driver
|
||||||
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* _Why isn’t it working?_ +
|
||||||
|
Since it’s still considered experimental by its authors, the
|
||||||
|
interfaces aren’t stable yet, so the driver has particular
|
||||||
|
dependencies on the kernel, which are documented in `README.Debian`
|
||||||
|
(view it online:
|
||||||
|
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=blob;f=debian/README.Debian;h=27ced6b1bf5102a5b72525318439efdfb330745d;hb=6c2f12ca18f55b55d49e083d86d87d970ce53a07[for squeeze],
|
||||||
|
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=blob;f=debian/README.Debian[for sid]).
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Others
|
||||||
|
------
|
||||||
|
|
||||||
|
Session management
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* _How to start a bare X session (without Gnome, KDE, etc.)?_ +
|
||||||
|
Assuming there’s no X running on the `:1` display, run this from a
|
||||||
|
VT:
|
||||||
|
----
|
||||||
|
startx /usr/bin/xterm -- :1
|
||||||
|
----
|
||||||
|
|
@ -0,0 +1,201 @@
|
||||||
|
How to build mesa
|
||||||
|
=================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Foreword
|
||||||
|
--------
|
||||||
|
|
||||||
|
Mesa is a special package since many flavours are built, which means
|
||||||
|
it takes quite some time to get all packages ready, as well as some
|
||||||
|
disc space (over 2GB for the `build/` directory alone).
|
||||||
|
|
||||||
|
Also, trying to figure out whether latest `master` is also affected,
|
||||||
|
or backporting some bug fixes might lead to some painful I/O while
|
||||||
|
generating the `.deb` files, and then installing/unpacking them. This
|
||||||
|
is why this document was written: Helping users test other mesa
|
||||||
|
releases, branches, bug fixes without having to build full packages,
|
||||||
|
and without having to mess with their systems (_i.e._ no root access
|
||||||
|
is needed once the build dependencies are installed).
|
||||||
|
|
||||||
|
We’ll focus on the DRI (Direct Rendering Infrastructure) flavour
|
||||||
|
(`libgl1-mesa-dri`), which is the most common.
|
||||||
|
|
||||||
|
It might be possible to adapt the following steps to another flavour,
|
||||||
|
in which case the appropriate options to be passed to `./configure`
|
||||||
|
should be looked up in the `debian/rules` file of the Debian source
|
||||||
|
package.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Gathering information
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Get started by installing `mesa-utils`, which contains `glxinfo`.
|
||||||
|
|
||||||
|
* _Is direct rendering enabled?_
|
||||||
|
+
|
||||||
|
$ glxinfo | grep ^direct
|
||||||
|
direct rendering: Yes
|
||||||
|
+
|
||||||
|
↪ Yes.
|
||||||
|
|
||||||
|
* _Is this the classic or http://en.wikipedia.org/wiki/Gallium3D[Gallium] driver?_
|
||||||
|
+
|
||||||
|
$ glxinfo | grep 'renderer string'
|
||||||
|
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20100330 DEVELOPMENT
|
||||||
|
+
|
||||||
|
↪ No “Gallium” here, therefore: “classic”.
|
||||||
|
|
||||||
|
* _Which driver is this, and where is it located?_
|
||||||
|
+
|
||||||
|
$ LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null | grep so$
|
||||||
|
libGL: OpenDriver: trying /usr/lib/dri/tls/i915_dri.so
|
||||||
|
libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so
|
||||||
|
+
|
||||||
|
↪ `i915`, from the system directory: `/usr/lib/dri` (likely installed through a Debian package).
|
||||||
|
|
||||||
|
|
||||||
|
* _How can I get more debugging information?_
|
||||||
|
|
||||||
|
export LIBGL_DEBUG=verbose
|
||||||
|
export MESA_DEBUG=1
|
||||||
|
export EGL_LOG_LEVEL=debug
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Preparing mesa sources
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
To get started, installing all build dependencies of the `mesa` source
|
||||||
|
package should be sufficient, along with the essential build tools,
|
||||||
|
and `git`:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ sudo apt-get install build-essential git
|
||||||
|
$ sudo apt-get build-dep mesa
|
||||||
|
----
|
||||||
|
|
||||||
|
Make sure you have some disc space available, since the git repository
|
||||||
|
is over 120MB, and since the mesa directory is over 500MB after a
|
||||||
|
build. Once you’re ready, grab the upstream mesa sources:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ git clone git://anongit.freedesktop.org/mesa/mesa mesa.git
|
||||||
|
$ cd mesa.git
|
||||||
|
$ autoreconf -vfi
|
||||||
|
----
|
||||||
|
|
||||||
|
Here’s what the `./configure` call will look like:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ ./configure --prefix=/usr \
|
||||||
|
--enable-driglx-direct \
|
||||||
|
--enable-gles1 \
|
||||||
|
--enable-gles2 \
|
||||||
|
--enable-glx-tls \
|
||||||
|
--with-dri-driverdir=/usr/lib/dri \
|
||||||
|
--with-egl-platforms='drm x11' \
|
||||||
|
…
|
||||||
|
----
|
||||||
|
|
||||||
|
Now, what are the parameters to replace “++…++” with? Basically, if
|
||||||
|
you determined an Intel driver (`i915` or `i965`), you want to use the
|
||||||
|
classic drivers and to disable the Gallium drivers. Other drivers are
|
||||||
|
only available on Gallium (`r300`, `r600`, `radeonsi` and more).
|
||||||
|
Running `./configure --help` might be useful.
|
||||||
|
|
||||||
|
|
||||||
|
Examples for common drivers:
|
||||||
|
|
||||||
|
* For `i915`, you need:
|
||||||
|
|
||||||
|
--with-dri-drivers=i915
|
||||||
|
|
||||||
|
* For `i965`, you need:
|
||||||
|
|
||||||
|
--with-dri-drivers=i965
|
||||||
|
|
||||||
|
* For `nouveau`, you may want to try:
|
||||||
|
|
||||||
|
--with-dri-drivers=nouveau --with-gallium-drivers=nouveau
|
||||||
|
|
||||||
|
* For `r300`, you need:
|
||||||
|
|
||||||
|
--with-gallium-drivers=r300
|
||||||
|
|
||||||
|
* For `r600`, you need:
|
||||||
|
|
||||||
|
--with-gallium-drivers=r600
|
||||||
|
|
||||||
|
* For `radeonsi`, you need:
|
||||||
|
|
||||||
|
--with-gallium-drivers=radeonsi
|
||||||
|
|
||||||
|
Now, once you’ve run `./configure`, time for your favorite beverage:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ make
|
||||||
|
----
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Running the newly-built mesa libraries
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
Shared libraries end up in the `lib/` directory. It contains the
|
||||||
|
classic drivers, while Gallium drivers end up under `lib/gallium`. If
|
||||||
|
you’re not an Intel user, overwrite the classic drivers with the
|
||||||
|
Gallium ones:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ mv lib/gallium/* lib/
|
||||||
|
----
|
||||||
|
|
||||||
|
Now, 3 variables need to be set, so that the locally-built libraries
|
||||||
|
are used.
|
||||||
|
|
||||||
|
* To begin with, libGL itself and its drivers:
|
||||||
|
+
|
||||||
|
$ export LIBGL_DRIVERS_PATH=lib
|
||||||
|
+
|
||||||
|
_Did this work?_
|
||||||
|
+
|
||||||
|
$ LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null | grep so$
|
||||||
|
libGL: OpenDriver: trying lib/tls/i915_dri.so
|
||||||
|
libGL: OpenDriver: trying lib/i915_dri.so
|
||||||
|
+
|
||||||
|
↪ Yes: No system directory, paths are relative to `lib/`.
|
||||||
|
|
||||||
|
* Set `LD_LIBRARY_PATH` to make sure the locally-built libraries
|
||||||
|
(including those pulled through library dependencies) are used,
|
||||||
|
instead of system ones:
|
||||||
|
+
|
||||||
|
$ export LD_LIBRARY_PATH=lib
|
||||||
|
+
|
||||||
|
_Did this work?_
|
||||||
|
+
|
||||||
|
$ ldd lib/libGLESv2.so | grep glapi
|
||||||
|
libglapi.so.0 => lib/libglapi.so.0 (0x00007fee3192e000)
|
||||||
|
+
|
||||||
|
↪ Yes: Path is relative to `lib`.
|
||||||
|
|
||||||
|
* Set the EGL search path:
|
||||||
|
+
|
||||||
|
$ export EGL_DRIVERS_PATH=lib/egl
|
||||||
|
+
|
||||||
|
_Did this work?_
|
||||||
|
+
|
||||||
|
$ EGL_LOG_LEVEL=debug es2_info 2>&1 >/dev/null | grep '\.so'
|
||||||
|
libEGL debug: added lib/egl/egl_gallium.so to module array
|
||||||
|
libEGL debug: dlopen(lib/egl/egl_gallium.so)
|
||||||
|
libEGL debug: DRI2: dlopen(lib/i915_dri.so)
|
||||||
|
+
|
||||||
|
↪ Yes: No system directory, paths are relative to `lib/`.
|
||||||
|
|
||||||
|
|
||||||
|
[float]
|
||||||
|
The end.
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
Now you should be ready to test upstream’s suggestions!
|
||||||
|
|
@ -0,0 +1,193 @@
|
||||||
|
How to configure input
|
||||||
|
======================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
General considerations
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
Foreword
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
The Debian wiki also contains an
|
||||||
|
http://wiki.debian.org/XStrikeForce/InputHotplugGuide[input hotplug guide]
|
||||||
|
which contains some context around X’s input subsystem. The present
|
||||||
|
document is meant to be an executive summary, and might miss some
|
||||||
|
bits. (*FIXME:* Merge those bits.)
|
||||||
|
|
||||||
|
|
||||||
|
Rules of thumb
|
||||||
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
In this documentation, only the last part of the driver’s name will be
|
||||||
|
mentioned, all of them are under the `xserver-xorg-input-*` namespace.
|
||||||
|
|
||||||
|
* On Linux, `evdev` is used for both keyboard and mouse
|
||||||
|
input.
|
||||||
|
* On Linux as well, `synaptics` can be used to benefit from extra
|
||||||
|
features; it takes precedence over `evdev` automatically if both
|
||||||
|
are installed.
|
||||||
|
* On GNU/kFreeBSD and GNU/Hurd, `kbd` handles the keyboard and
|
||||||
|
`mouse` handles mice, unsurprisingly.
|
||||||
|
|
||||||
|
|
||||||
|
Configuration snippets
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
X can now be run without `xorg.conf`, but sometimes one has to
|
||||||
|
configure a few settings for this or that driver. Starting with
|
||||||
|
`squeeze`, that can be done by adding a file under
|
||||||
|
`/etc/X11/xorg.conf.d`, with a `.conf` suffix, as documented in the
|
||||||
|
`xorg.conf` manpage.
|
||||||
|
|
||||||
|
Some packages ship a default configuration file under
|
||||||
|
`/usr/share/X11/xorg.conf.d` with general rules to match appropriate
|
||||||
|
hardware. The files under `/etc/X11/xorg.conf.d` take precedence, as
|
||||||
|
documented in the `xorg.conf` manpage.
|
||||||
|
|
||||||
|
It’s probably mostly useful in the `synaptics` case, in case one wants
|
||||||
|
to change default settings on a system-wide fashion. See the _Pointer
|
||||||
|
configuration_ section below for an example.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Basic keyboard configuration
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
The `keyboard-configuration` package ships `/etc/default/keyboard`
|
||||||
|
which can be used to set the following `xkb` items: model, layout,
|
||||||
|
variant, and options. Here’s an example:
|
||||||
|
|
||||||
|
----
|
||||||
|
XKBMODEL="pc105"
|
||||||
|
XKBLAYOUT="fr"
|
||||||
|
XKBVARIANT="oss"
|
||||||
|
XKBOPTIONS="compose:menu,terminate:ctrl_alt_bksp"
|
||||||
|
----
|
||||||
|
|
||||||
|
Quick words about the options:
|
||||||
|
|
||||||
|
* They are comma-separated.
|
||||||
|
* The list of options and a short description for each can be found
|
||||||
|
in the `/usr/share/X11/xkb/rules/base.lst` file (shipped by the
|
||||||
|
`xkb-data` package).
|
||||||
|
* First option: `compose:menu`. This sets the `menu` key as the
|
||||||
|
Compose key. More information about it can be found in the
|
||||||
|
`Compose` manpage.
|
||||||
|
* Second option: `terminate:ctrl_alt_bksp`. By default, the X server
|
||||||
|
is no longer killed through `Ctrl+Alt+Backspace`. This option
|
||||||
|
restores the old behaviour.
|
||||||
|
|
||||||
|
Two ways to change the configuration:
|
||||||
|
|
||||||
|
* `dpkg-reconfigure keyboard-configuration` is going to ask questions
|
||||||
|
through debconf prompts.
|
||||||
|
* Manually editing `/etc/default/keyboard` also works.
|
||||||
|
|
||||||
|
How does it propagate to X?
|
||||||
|
|
||||||
|
* When HAL is used (that is: on GNU/kFreeBSD and GNU/Hurd), one has
|
||||||
|
to restart it: `invoke-rc.d hal restart`
|
||||||
|
* When udev is used (on GNU/Linux, starting with `squeeze`), one has
|
||||||
|
to tell udev to reload input-related configuration:
|
||||||
|
`udevadm trigger --subsystem-match=input --action=change`
|
||||||
|
(that can be found in ++keyboard-configuration++’s `README.Debian`
|
||||||
|
file). Properties attached to the input devices are then updated,
|
||||||
|
and X uses those properties when it starts, as can be seen by
|
||||||
|
searching for `xkb_` in the X log. Please note that trying
|
||||||
|
`invoke-rc.d udev restart` changes nothing, one has to use
|
||||||
|
`udevadm`. Properties can be inspected through:
|
||||||
|
`/sbin/udevadm info --export-db`
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Pointer configuration
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
evdev configuration
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Available options are documented in the `evdev` manpage. Let’s check
|
||||||
|
what a configuration snippet (mentioned in _General considerations_)
|
||||||
|
would look like. Here is a fictional `/etc/X11/xorg.conf.d/42-evdev.conf`:
|
||||||
|
|
||||||
|
----
|
||||||
|
Section "InputClass"
|
||||||
|
Identifier "evdev pointer tweaked catchall"
|
||||||
|
MatchIsPointer "on"
|
||||||
|
Driver "evdev"
|
||||||
|
Option "Emulate3Buttons" "True"
|
||||||
|
Option "SwapAxes" "True"
|
||||||
|
EndSection
|
||||||
|
----
|
||||||
|
|
||||||
|
Line by line walkthrough:
|
||||||
|
|
||||||
|
* To avoid specifying any device under `/dev/input` (`event$N` might
|
||||||
|
change, remember it’s about hotplug support!), we use an
|
||||||
|
`InputClass`.
|
||||||
|
* We need an identifier, the actual name doesn’t matter.
|
||||||
|
* We match everything that looks like a touchpad. Meaning no generic
|
||||||
|
pointer, keyboard, or tablet.
|
||||||
|
* We specify the driver we want to use for the matched device(s).
|
||||||
|
* Finally the options we want to set. Here we enable the 3rd button
|
||||||
|
emulation (clicking left and right buttons at the same time then no
|
||||||
|
longer acts as if the middle button was clicked). Then we swap x
|
||||||
|
and y axes, just for the fun of it.
|
||||||
|
|
||||||
|
|
||||||
|
synaptics configuration
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The `synaptics` driver comes with two tools. The more interesting one
|
||||||
|
is `synclient`, which can be used to list available options and
|
||||||
|
current settings: `synclient -l`. The documentation for each option
|
||||||
|
can be found in the `synaptics` manpage.
|
||||||
|
|
||||||
|
`synclient` can also be used to set options. A common example is
|
||||||
|
enabling tapping (upstream kept it disabled by default, Debian won’t
|
||||||
|
deviate, no need to file bugs): `synclient TapButton1=1`; one can also
|
||||||
|
disable the touchpad temporarily: `synclient TouchpadOff=1` to
|
||||||
|
disable it, `synclient TouchpadOff=0` to enable it again.
|
||||||
|
|
||||||
|
Let’s check what a configuration snippet (mentioned in _General
|
||||||
|
considerations_) would look like. Here is a fictional
|
||||||
|
`/etc/X11/xorg.conf.d/42-synaptics.conf`:
|
||||||
|
|
||||||
|
----
|
||||||
|
Section "InputClass"
|
||||||
|
Identifier "touchpad tweaked catchall"
|
||||||
|
MatchIsTouchpad "on"
|
||||||
|
Driver "synaptics"
|
||||||
|
Option "TapButton1" "1"
|
||||||
|
Option "HorizEdgeScroll" "1"
|
||||||
|
EndSection
|
||||||
|
----
|
||||||
|
|
||||||
|
Line by line walkthrough:
|
||||||
|
|
||||||
|
* To avoid specifying any device under `/dev/input` (`event$N` might
|
||||||
|
change, remember it’s about hotplug support!), we use an
|
||||||
|
`InputClass`.
|
||||||
|
* We need an identifier, the actual name doesn’t matter.
|
||||||
|
* We match everything that looks like a touchpad. Meaning no generic
|
||||||
|
pointer, keyboard, or tablet.
|
||||||
|
* We specify the driver we want to use for the matched device(s).
|
||||||
|
* Finally the options we want to set. We enable tapping for the first
|
||||||
|
button. And we enable horizontal scrolling (by default, only
|
||||||
|
vertical scrolling is enabled).
|
||||||
|
|
||||||
|
Settings can also be changed by various settings managers, like
|
||||||
|
Gnome’s or KDE’s. An example of a graphical user interface making it
|
||||||
|
possible to set options in a clicky way: `gpointing-device-settings`.
|
||||||
|
|
||||||
|
There’s a palm detection setting but that relies on hardware/firmware
|
||||||
|
support for the touchpad. The other tool shipped with the `synaptics`
|
||||||
|
driver is `syndaemon`, which makes it trivial to disable the touchpad
|
||||||
|
temporarily, when the keyboard is being used. Here’s an example:
|
||||||
|
`syndaemon -d -i 0.5` makes `syndaemon` start in background (`-d` for
|
||||||
|
daemon mode), waiting 0.5 second before enabling the touchpad again
|
||||||
|
after the last keypress. Warning: it becomes quite difficult to use
|
||||||
|
things like `Ctrl+click` in a browser, or `Alt+drag` to move
|
||||||
|
windows.
|
||||||
|
|
@ -0,0 +1,62 @@
|
||||||
|
How to report bugs
|
||||||
|
==================
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Report it upstream
|
||||||
|
------------------
|
||||||
|
|
||||||
|
In most cases, it is preferrable to report the bug upstream at
|
||||||
|
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
|
||||||
|
|
||||||
|
See https://01.org/linuxgraphics/documentation/how-report-bugs-0 for a good
|
||||||
|
introduction on how to write useful bug reports. While the document is targeted
|
||||||
|
at Intel graphics hardware, it is a good guideline for other vendor’s hardware
|
||||||
|
as well.
|
||||||
|
|
||||||
|
Simple as reportbug
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Initial report
|
||||||
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Unless you know which package to report the bug against, you can
|
||||||
|
report the bug against the `xorg` metapackage:
|
||||||
|
|
||||||
|
----
|
||||||
|
reportbug xorg
|
||||||
|
----
|
||||||
|
|
||||||
|
Like most packages related to the X server, reporting a bug against
|
||||||
|
this package triggers a bug script which is going to collect X-related
|
||||||
|
information, be it installed packages, running kernel, X
|
||||||
|
configuration, X log, and so on.
|
||||||
|
|
||||||
|
****
|
||||||
|
.Note
|
||||||
|
In case this metapackage wasn’t used to install your X stack,
|
||||||
|
report a bug against `xserver-xorg` instead. And if that one isn’t
|
||||||
|
installed either, go for `xserver-xorg-core`.
|
||||||
|
****
|
||||||
|
|
||||||
|
If a backtrace shows up in the X log, it’s much appreciated to try and
|
||||||
|
get a link:use-gdb.html[full backtrace using gdb].
|
||||||
|
|
||||||
|
|
||||||
|
Follow-up with more info
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
If you reported a bug against another package and if that bug was
|
||||||
|
reassigned to an X-related package, we might need more
|
||||||
|
information. You can run the bug script manually and attach its output
|
||||||
|
to your mail to the bug report:
|
||||||
|
|
||||||
|
----
|
||||||
|
/usr/share/bug/xserver-xorg-core/script 3>/tmp/script.log
|
||||||
|
----
|
||||||
|
|
||||||
|
****
|
||||||
|
.Note
|
||||||
|
Make sure there’s no space between `3` and `>`, that’s a shell
|
||||||
|
redirection.
|
||||||
|
****
|
||||||
|
|
@ -0,0 +1,104 @@
|
||||||
|
How to triage bugs
|
||||||
|
==================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Packaging bugs or upstream bugs?
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
It’d be nice to get all upstream bugs tagged as such (`upstream` tag),
|
||||||
|
forwarded upstream (which means the bugzilla instance on
|
||||||
|
http://bugs.freedesktop.org/ for most packages), and marked as such.
|
||||||
|
|
||||||
|
A mail to `control@bugs.debian.org` would look like:
|
||||||
|
|
||||||
|
----
|
||||||
|
tag X upstream
|
||||||
|
forwarded X https://bugs.freedesktop.org/show_bug.cgi?id=Y
|
||||||
|
thanks
|
||||||
|
----
|
||||||
|
|
||||||
|
Then http://bts-link.alioth.debian.org/[`bts-link`] comes into play
|
||||||
|
and helps us tracking upstream status, which is pretty nice to have.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Usertags
|
||||||
|
--------
|
||||||
|
|
||||||
|
Another feature of the BTS is usertagging. That lets people keep track
|
||||||
|
of additional tags, “attached” to a given mail address. For XSF,
|
||||||
|
that’s `debian-x@lists.debian.org`.
|
||||||
|
|
||||||
|
The list of all usertagged bugs can be seen on the following page; the
|
||||||
|
list of all used usertags is at the bottom, in the form. +
|
||||||
|
→ http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-x%40lists.debian.org
|
||||||
|
|
||||||
|
Let’s give some examples:
|
||||||
|
|
||||||
|
* `i810`, `i915`: helps triaging `-video-intel` bugs depending on the
|
||||||
|
chipset.
|
||||||
|
* `r200`, `r300`: ditto for `-video-ati`.
|
||||||
|
* `xset`, `xrandr`: helps triaging `x11-xserver-utils` bugs depending
|
||||||
|
on the affected tool (like other `x11-*` packages, that’s a bundle
|
||||||
|
of teeny tiny apps).
|
||||||
|
* `squeeze-candidate`: helps keeping a list of bugs we’d like to get
|
||||||
|
fixed in a point release (through a stable update).
|
||||||
|
* `needs-forwarding`: of course, it’d be nice to have all upstream
|
||||||
|
bugs reported upstream, but some might need special attention
|
||||||
|
(_e.g._ security bugs).
|
||||||
|
|
||||||
|
Here’s an example of URL, for the last tags: +
|
||||||
|
→ http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-x%40lists.debian.org&tag=squeeze-candidate +
|
||||||
|
→ http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-x%40lists.debian.org&tag=needs-forwarding
|
||||||
|
|
||||||
|
By the way one should keep an eye on the list of found/fixed
|
||||||
|
versions since those bugs are likely marked as resolved (in `unstable`
|
||||||
|
or `experimental`), but might still affect a stable release.
|
||||||
|
|
||||||
|
To list the bugs marked `squeeze-candidate` but not
|
||||||
|
`squeeze-accepted`: +
|
||||||
|
→ http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-x%40lists.debian.org&tag=squeeze-candidate&exclude=tag:squeeze-accepted
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Categories
|
||||||
|
----------
|
||||||
|
|
||||||
|
The BTS has yet another feature which can help, categories. That’s
|
||||||
|
based on usertags as well, but one has to use the package address
|
||||||
|
(`$package@packages.debian.org`), so that’s package-specific rather
|
||||||
|
than team-specific.
|
||||||
|
|
||||||
|
Categories are
|
||||||
|
http://wiki.debian.org/bugs.debian.org/usertags[documented on the wiki],
|
||||||
|
and they would probably be welcome in the `intel` and `ati` cases
|
||||||
|
above, as well as in the “multiple tools in a single bundle”
|
||||||
|
cases… An example of what we could achieve is the
|
||||||
|
http://bugs.debian.org/devscripts[devscripts bug page] (it takes
|
||||||
|
some time to load, plenty of bugs).
|
||||||
|
|
||||||
|
Needed steps for that to happen:
|
||||||
|
|
||||||
|
* create usercategories.
|
||||||
|
* move usertags from `debian-x@lists.debian.org` to
|
||||||
|
`$package@packages.debian.org`, probably using the `bts select`
|
||||||
|
command to get the list over which to iterate.
|
||||||
|
* profit!
|
||||||
|
|
||||||
|
To move the usertags, something like that should do the job:
|
||||||
|
----
|
||||||
|
# Adding usertags:
|
||||||
|
user $package1@packages.debian.org
|
||||||
|
usertag X xset
|
||||||
|
usertag Y xrandr
|
||||||
|
user $package2@packages.debian.org
|
||||||
|
usertag Z i810
|
||||||
|
|
||||||
|
# Removing tags which are no longer needed:
|
||||||
|
user debian-x@lists.debian.org
|
||||||
|
usertag X - xset
|
||||||
|
usertag Y - xrandr
|
||||||
|
usertag Z - i810
|
||||||
|
----
|
||||||
|
|
@ -0,0 +1,179 @@
|
||||||
|
How to use gdb
|
||||||
|
==============
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Foreword
|
||||||
|
--------
|
||||||
|
|
||||||
|
One should note that X is responsible for VT switching, meaning
|
||||||
|
switching between an X session and console terminals. In other words,
|
||||||
|
`Ctrl+Alt+Fn` is handled by X. If X is stopped, for example because
|
||||||
|
it’s running under `gdb`, one can no longer switch to another
|
||||||
|
VT. That’s why we’re recommending using a second machine to debug
|
||||||
|
X. Nevertheless, here are some instructions to attempt debugging X
|
||||||
|
with a single machine.
|
||||||
|
|
||||||
|
One-machine approach
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This is a _post-mortem_ approach. The idea is to run X with the
|
||||||
|
`-core` option. Once it dies, a core file (`/etc/X11/core`) is
|
||||||
|
generated, and can be loaded from `gdb`.
|
||||||
|
|
||||||
|
Follow these steps:
|
||||||
|
|
||||||
|
1. Getting a core file.
|
||||||
|
2. Loading a core file.
|
||||||
|
3. Displaying/saving a backtrace.
|
||||||
|
|
||||||
|
Two-machine approach
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
You pay the “need a second machine” price, but that buys you
|
||||||
|
interactivity. Just log into the first machine from the second one,
|
||||||
|
using `ssh`.
|
||||||
|
|
||||||
|
Follow these steps:
|
||||||
|
|
||||||
|
1. Attaching/Starting X from gdb.
|
||||||
|
2. Displaying/saving a backtrace.
|
||||||
|
|
||||||
|
Needed packages
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Obviously, `gdb` is needed; `xserver-xorg-core-dbg` contains the
|
||||||
|
debugging symbols for the server itself. Other needed packages can be
|
||||||
|
determined by looking at the backtrace. **FIXME: More info about
|
||||||
|
that.**
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Actual gdb work
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Getting a core file
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
* Using `gdm3` 3.4.1 and above: uncomment `Enable = true` in the
|
||||||
|
`[debug]` section of the `/etc/gdm3/daemon.conf` file.
|
||||||
|
|
||||||
|
* Using an older `gdm3` package: The idea is to tweak the daemon’s
|
||||||
|
`LocalXserverCommand` setting, adding the `-core` option. As of
|
||||||
|
`gdm3 2.30`, the defaults can be found in
|
||||||
|
`/usr/share/gdm/gdm.schemas`. Sample `/etc/gdm3/daemon.conf`
|
||||||
|
excerpt:
|
||||||
|
|
||||||
|
----
|
||||||
|
[daemon]
|
||||||
|
LocalXserverCommand=/usr/bin/Xorg -br -verbose -audit 0 -novtswitch -core
|
||||||
|
----
|
||||||
|
|
||||||
|
* Using `kdm`: One should look for the `ServerArgsLocal` variable in
|
||||||
|
the `/etc/kde4/kdm/kdmrc` file, and add `-core` there. Example:
|
||||||
|
|
||||||
|
----
|
||||||
|
ServerArgsLocal=-br -nolisten tcp -core
|
||||||
|
----
|
||||||
|
|
||||||
|
* Using `xdm`: It’s sufficient to add `-core` to the command
|
||||||
|
configured through `/etc/X11/xdm/Xservers`, for example:
|
||||||
|
|
||||||
|
----
|
||||||
|
:0 local /usr/bin/X :0 vt7 -nolisten tcp -core
|
||||||
|
----
|
||||||
|
|
||||||
|
Loading a core file
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
That’s trivial, one just needs to pass both the core file and the path
|
||||||
|
to the binary:
|
||||||
|
|
||||||
|
----
|
||||||
|
# gdb -c /etc/X11/core /usr/bin/Xorg
|
||||||
|
----
|
||||||
|
|
||||||
|
Now `gdb` is ready to display backtraces.
|
||||||
|
|
||||||
|
Attaching X from gdb
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The way of starting X doesn’t really matter, as `gdb` makes it
|
||||||
|
possible to attach a running process. If there’s a single X instance
|
||||||
|
running, that will do the job:
|
||||||
|
|
||||||
|
----
|
||||||
|
# gdb attach $(pidof X)
|
||||||
|
[---GDB starts---]
|
||||||
|
(gdb) handle SIGPIPE nostop
|
||||||
|
(gdb) cont
|
||||||
|
----
|
||||||
|
|
||||||
|
If there are several instances, one can use `ps aux` to determine the
|
||||||
|
PID of the appropriate instance (2nd column → `$pid`), and then attach
|
||||||
|
it:
|
||||||
|
|
||||||
|
----
|
||||||
|
# gdb attach $pid
|
||||||
|
[---GDB starts---]
|
||||||
|
(gdb) handle SIGPIPE nostop
|
||||||
|
(gdb) cont
|
||||||
|
----
|
||||||
|
|
||||||
|
Starting X from gdb
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
In case X crashes at start-up, one can start X from `gdb` in the
|
||||||
|
following way. In this example, the only parameter is the display, but
|
||||||
|
more parameters can be added.
|
||||||
|
|
||||||
|
----
|
||||||
|
# gdb --args Xorg :0
|
||||||
|
[---GDB starts---]
|
||||||
|
(gdb) handle SIGPIPE nostop
|
||||||
|
(gdb) run
|
||||||
|
----
|
||||||
|
|
||||||
|
What is SIGPIPE?
|
||||||
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
`SIGPIPE` is a signal that can reach the X server quite easily,
|
||||||
|
especially when performing a VT switch, or refreshing large parts of
|
||||||
|
the screen. That’s why we ask `gdb` not to stop when such a signal is
|
||||||
|
caught, thanks to the `handle SIGPIPE nostop` command.
|
||||||
|
|
||||||
|
How to display a backtrace?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Once X is crashed, for example because it received a `SIGSEGV`
|
||||||
|
(segmentation fault, usually because of a NULL pointer dereference),
|
||||||
|
or a `SIGBUS`, one gets back to the `gdb` prompt. One can then request
|
||||||
|
a backtrace (`bt`) or a full backtrace (`bt full`). The latter is what
|
||||||
|
developers are usually interested in, because variable values are also
|
||||||
|
available.
|
||||||
|
|
||||||
|
----
|
||||||
|
(gdb) bt
|
||||||
|
(gdb) bt full
|
||||||
|
----
|
||||||
|
|
||||||
|
How to save a backtrace?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
To save a recording of the gdb session to a file (`gdb.txt` by
|
||||||
|
default):
|
||||||
|
|
||||||
|
----
|
||||||
|
(gdb) set logging on
|
||||||
|
----
|
||||||
|
|
||||||
|
To save in a different file, use this instead:
|
||||||
|
|
||||||
|
----
|
||||||
|
(gdb) set logging file my-file.txt
|
||||||
|
(gdb) set logging on
|
||||||
|
----
|
||||||
|
|
||||||
|
Once logging is enabled, you can request a (full) backtrace using the
|
||||||
|
previous commands.
|
||||||
|
|
@ -0,0 +1,214 @@
|
||||||
|
How to use xrandr
|
||||||
|
=================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Getting started
|
||||||
|
---------------
|
||||||
|
|
||||||
|
What is xrandr?
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
`xrandr` is a command-line tool to interact with the X `RandR`
|
||||||
|
extension [see http://www.x.org/wiki/Projects/XRandR[x.org],
|
||||||
|
http://en.wikipedia.org/wiki/RandR[wikipedia]], which allows for
|
||||||
|
live (re)configuration of the X server (_i.e._ without restarting it):
|
||||||
|
It provides automatic discovery of modes (resolutions, refresh rates,
|
||||||
|
etc.) together with the ability to configure outputs dynamically
|
||||||
|
(resize, rotate, move, etc.).
|
||||||
|
|
||||||
|
*FIXME: Status across drivers?*
|
||||||
|
|
||||||
|
What consequences for xorg.conf?
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Starting with `squeeze`, removing the `xorg.conf` configuration file
|
||||||
|
entirely should work well enough, but in case that doesn’t work out,
|
||||||
|
let’s document what can be removed from it from a `RandR` point of
|
||||||
|
view.
|
||||||
|
|
||||||
|
With the driver detecting modes automatically, several configuration
|
||||||
|
options become useless most of the time in your configuration file
|
||||||
|
(xorg.conf). You might want to remove:
|
||||||
|
|
||||||
|
* `HorizSync` and `VertRefresh` from the `Monitor` section.
|
||||||
|
* Modes from `Display` subsection in `Screen` section.
|
||||||
|
* `ModeLine` from the `Monitor` section.
|
||||||
|
|
||||||
|
There’s also no need to keep static dual-head configuration. Some
|
||||||
|
suggestions to get a tiny `xorg.conf`:
|
||||||
|
|
||||||
|
* Drop dual `Device`/`Screen`/`Monitor` sections, a single one is
|
||||||
|
needed.
|
||||||
|
* Drop `MonitorLayout` option and `Screen` lines from the remaining
|
||||||
|
`Device` section.
|
||||||
|
* Drop the `ServerLayout` section(s).
|
||||||
|
* Drop `RightOf`/`LeftOf` indication of the remaining `Screen` line
|
||||||
|
in `ServerLayout` section.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Basic xrandr usage
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Once the configuration file (`xorg.conf`) is removed or updated,
|
||||||
|
starting the server should enable some outputs by default. Their
|
||||||
|
top-left corners will be at the same part of the image, but their
|
||||||
|
modes will probably be different.
|
||||||
|
|
||||||
|
All outputs may be configured through `xrandr`. To see the available
|
||||||
|
outputs, just run `xrandr`:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr
|
||||||
|
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
|
||||||
|
VGA1 disconnected (normal left inverted right x axis y axis)
|
||||||
|
LVDS1 connected 1280x800+0+0 inverted X and Y axis (normal left inverted right x axis y axis) 261mm x 163mm
|
||||||
|
1280x800 59.8*+
|
||||||
|
1024x768 60.0
|
||||||
|
800x600 60.3 56.2
|
||||||
|
640x480 59.9
|
||||||
|
DVI1 disconnected (normal left inverted right x axis y axis)
|
||||||
|
TV1 disconnected (normal left inverted right x axis y axis)
|
||||||
|
----
|
||||||
|
|
||||||
|
Comments:
|
||||||
|
|
||||||
|
* We see 4 outputs: `VGA1`, `LVDS1`, `DVI1`, `TV1`.
|
||||||
|
* Only the internal panel (`LVDS1`) is connected and it supports 4
|
||||||
|
modes at 60 Hz, 1 mode at 56 Hz.
|
||||||
|
* The mode marked with a star (`*`) is the current mode.
|
||||||
|
* The one marked with a plus (`+`) is the preferred one. Most
|
||||||
|
monitors report a preferred mode to the driver. And the
|
||||||
|
server/driver will generally choose it by default.
|
||||||
|
|
||||||
|
*FIXME: Mention output name conventions?*
|
||||||
|
|
||||||
|
When manipulating `VGA1` output properties, you should use:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output VGA1 <options>
|
||||||
|
----
|
||||||
|
|
||||||
|
Adding/removing heads dynamically
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The old days where you had to restart X when plugging a new monitor
|
||||||
|
are gone. With `RandR` 1.2, you can plug/unplug monitors whenever you
|
||||||
|
want. Running the following line will query all outputs and enable
|
||||||
|
them with their default mode:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --auto
|
||||||
|
----
|
||||||
|
|
||||||
|
You may also disable one output using:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output LVDS1 --off
|
||||||
|
----
|
||||||
|
|
||||||
|
This may be useful for some buggy application that don’t support
|
||||||
|
multiple outputs well. Also, due to CRTC limitations (see the Caveats
|
||||||
|
section below), it is often required to disable one output before
|
||||||
|
enabling another since most hardware only support 2 at the same time.
|
||||||
|
|
||||||
|
Changing the mode
|
||||||
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
With the above `xrandr` output, you may change the `LVDS1` mode to
|
||||||
|
`1024x768` using:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output LVDS1 --mode 1024x768
|
||||||
|
----
|
||||||
|
|
||||||
|
The refresh rate may also be changed, either at the same time or
|
||||||
|
independently:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output LVDS1 --mode 1024x768 --rate 75
|
||||||
|
$ xrandr --output LVDS1 --rate 75
|
||||||
|
----
|
||||||
|
|
||||||
|
To get back to the default mode:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output LVDS1 --auto
|
||||||
|
----
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Placing outputs in a virtual screen
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
A bit of configuration for non-KMS setups:
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Let’s have a look at the maximal virtual screen size, we see
|
||||||
|
`4096x4096` in this example:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr|head -1
|
||||||
|
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
|
||||||
|
----
|
||||||
|
|
||||||
|
With KMS (*FIXME: Link to a page which explains what KMS is*),
|
||||||
|
there's no need to specify any `Virtual` option. With DRI and without
|
||||||
|
KMS, that might be needed. Indeed, drivers will often create a default
|
||||||
|
virtual screen with small dimensions, for instance `1600x1200`, to
|
||||||
|
reduce memory consumption.
|
||||||
|
|
||||||
|
If you plan to use multiple outputs displaying different zones, you
|
||||||
|
should configure your `xorg.conf` by adding a `Virtual` line to the
|
||||||
|
`Display` subsection in the `Screen` section.
|
||||||
|
|
||||||
|
----
|
||||||
|
Section "Screen"
|
||||||
|
…
|
||||||
|
SubSection "Display"
|
||||||
|
Depth 24
|
||||||
|
Virtual 3000 2000
|
||||||
|
EndSubSection
|
||||||
|
EndSection
|
||||||
|
----
|
||||||
|
|
||||||
|
Place outputs
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Outputs are placed using the following options:
|
||||||
|
`--right-of`/`--left-of`/`--above`/`--below`. For instance, to place
|
||||||
|
the `VGA1` output virtually-right of the internal panel (`LVDS1`):
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --output VGA1 --right-of LVDS1
|
||||||
|
----
|
||||||
|
|
||||||
|
Note that hardware and memory limitations may severely restrict the
|
||||||
|
size of your virtual screen, see the Caveats section below.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Adding new modes
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Under some circumstances, some modes might be missing. For instance,
|
||||||
|
if the monitor does not report correct EDID information. Or if the
|
||||||
|
output didn't have a CRTC available at startup because another output
|
||||||
|
was using it and you disabled it in the meantime.
|
||||||
|
|
||||||
|
If a mode exist, you may add it to one output with:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --addmode VGA1 800x600
|
||||||
|
----
|
||||||
|
|
||||||
|
If the mode does not exist, you may first create it by passing a modeline:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ xrandr --newmode <ModeLine>
|
||||||
|
----
|
||||||
|
|
||||||
|
You may create a modeline using the `gtf` or `cvt` tools (shipped in
|
||||||
|
the `xserver-xorg-core` package).
|
||||||
|
|
@ -0,0 +1 @@
|
||||||
|
howto
|
||||||
|
|
@ -0,0 +1,51 @@
|
||||||
|
X Strike Force’s documentation
|
||||||
|
==============================
|
||||||
|
|
||||||
|
_The “X Strike Force” takes care of packaging X.Org for Debian._
|
||||||
|
|
||||||
|
{nbsp}
|
||||||
|
|
||||||
|
These documents are shipped in the
|
||||||
|
http://packages.debian.org/xserver-xorg&exact=1[xserver-xorg]
|
||||||
|
metapackage (under `/usr/share/doc/xorg`), starting with
|
||||||
|
`wheezy`. They are also available online at
|
||||||
|
http://x.debian.net/[x.debian.net], which is an alias for the
|
||||||
|
longer-to-type
|
||||||
|
http://pkg-xorg.alioth.debian.org/[pkg-xorg.alioth.debian.org].
|
||||||
|
|
||||||
|
Getting started
|
||||||
|
---------------
|
||||||
|
|
||||||
|
* link:faq/general.html[General FAQ]
|
||||||
|
|
||||||
|
How to…
|
||||||
|
-------
|
||||||
|
|
||||||
|
* link:howto/report-bugs.html[How to report bugs]
|
||||||
|
* link:howto/triage-bugs.html[How to triage bugs]
|
||||||
|
* link:howto/use-gdb.html[How to use GDB]
|
||||||
|
* link:howto/configure-input.html[How to configure input]
|
||||||
|
* link:howto/use-xrandr.html[How to configure outputs]
|
||||||
|
* link:howto/build-mesa.html[How to build mesa]
|
||||||
|
|
||||||
|
Reference documentation
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
* link:reference/git-usage.html[Using git for X repositories]
|
||||||
|
* link:reference/dependencies.html[Dependencies between server and drivers]
|
||||||
|
* link:reference/squeeze-backports.html[Backports of the whole X stack for squeeze]
|
||||||
|
* link:reference/upstream-contacts.html[Upstream contacts]
|
||||||
|
|
||||||
|
Other documentation
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
* link:upstream-features.html[Upstream features]
|
||||||
|
|
||||||
|
Feedback
|
||||||
|
--------
|
||||||
|
|
||||||
|
* Sources for these documents are available on
|
||||||
|
http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=shortlog;h=xsf-docs[git.debian.org].
|
||||||
|
|
||||||
|
* Patches, suggestions, flames, etc. are welcome, using the
|
||||||
|
http://lists.debian.org/debian-x/[debian-x] mailing list.
|
||||||
|
|
@ -0,0 +1,260 @@
|
||||||
|
Dependencies between server and drivers
|
||||||
|
=======================================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Upstream-side: ABI version numbers
|
||||||
|
----------------------------------
|
||||||
|
|
||||||
|
The X server defines several
|
||||||
|
http://en.wikipedia.org/wiki/Application_binary_interface[ABI] version numbers in the
|
||||||
|
`hw/xfree86/common/xf86Module.h` header, through the
|
||||||
|
`SET_ABI_VERSION(maj,min)` macro. In this document, the focus is on
|
||||||
|
`ABI_VIDEODRV_VERSION` and `ABI_XINPUT_VERSION`, which are
|
||||||
|
respectively about `video` drivers and `input` drivers.
|
||||||
|
|
||||||
|
An example of input ABI is `12.1`, `12` being the `major`, `1` being
|
||||||
|
the `minor`.
|
||||||
|
|
||||||
|
Like in usual shared libraries, the major is bumped when interfaces
|
||||||
|
are broken. There’s no compatibility at all in that case.
|
||||||
|
|
||||||
|
The minor gets bumped when interfaces are added. In other words, if a
|
||||||
|
driver is working with `x.y`, it should also work with higher minors:
|
||||||
|
`x.z`; `z>y`. The converse is not true, if a driver requires a given
|
||||||
|
minor (for example because it needs a new feature, like MultiTouch),
|
||||||
|
it won’t work with lower minors (which didn’t provide the needed
|
||||||
|
feature). Put another way: we have ascending compatibility with the
|
||||||
|
minors.
|
||||||
|
|
||||||
|
Conclusion: We need to keep track of both major and minor.
|
||||||
|
|
||||||
|
Thanks to `pkg-config` we can query them:
|
||||||
|
|
||||||
|
----
|
||||||
|
$ pkg-config --variable=abi_videodrv xorg-server
|
||||||
|
9.0
|
||||||
|
$ pkg-config --variable=abi_xinput xorg-server
|
||||||
|
12.1
|
||||||
|
----
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Debian-side: Using virtual packages
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
Server’s build system
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
When `xorg-server` gets built, we use ++pkg-config++’s output to
|
||||||
|
determine the current major. Through substitution variables, we add
|
||||||
|
two virtual packages in the `Provides` field of the server (for both
|
||||||
|
`xserver-xorg-core` and `xserver-xorg-core-udeb`): `xorg-input-abi-$x`
|
||||||
|
and `xorg-video-abi-$y`, where `$x` and `$y` are the major part of the
|
||||||
|
version queried through `pkg-config` variables.
|
||||||
|
|
||||||
|
To handle ascending compatibility for minors, we maintain in
|
||||||
|
`debian/serverminver` the minimal version of `xserver-xorg-core` which
|
||||||
|
is needed. When a minor is bumped, we store the server version in that
|
||||||
|
file. This way, drivers built afterwards will depend on a *minimal*
|
||||||
|
version of the driver, the last which saw a minor version bump. In
|
||||||
|
other words: they will “depend on the server version they were built
|
||||||
|
against, or a higher/compatible one”.
|
||||||
|
|
||||||
|
Both ABI and minimal server version are recorded in two files shipped
|
||||||
|
in `xserver-xorg-dev`, to be used while building drivers:
|
||||||
|
|
||||||
|
* `/usr/share/xserver-xorg/xinputdep`
|
||||||
|
* `/usr/share/xserver-xorg/videodrvdep`
|
||||||
|
|
||||||
|
Example for `xinputdep`:
|
||||||
|
|
||||||
|
----
|
||||||
|
xorg-input-abi-11, xserver-xorg-core (>= 2:1.8.99.904)
|
||||||
|
----
|
||||||
|
To make sure we bump the `debian/serverminver` when there’s a minor
|
||||||
|
ABI change, there’s a `abibumpcheck` target (on which `clean`
|
||||||
|
depends), which extracts input and video ABI from the upstream header,
|
||||||
|
and compares them to the previous ones stored in
|
||||||
|
`debian/serverminver`, failing and diffing is something changed.
|
||||||
|
|
||||||
|
|
||||||
|
Driver’s control file
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Drivers also use substitution variables in their control file,
|
||||||
|
replaced at build time.
|
||||||
|
|
||||||
|
----
|
||||||
|
# Input driver:
|
||||||
|
Depends: ${xinpdriver:Depends}, …
|
||||||
|
Provides: ${xinpdriver:Provides}
|
||||||
|
|
||||||
|
# Video driver:
|
||||||
|
Depends: ${xviddriver:Depends}, …
|
||||||
|
Provides: ${xviddriver:Provides}
|
||||||
|
----
|
||||||
|
|
||||||
|
For now, `${xinpdriver:Provides}` is always replaced with
|
||||||
|
`xorg-driver-input`, and `${xviddriver:Provides}` is always replaced
|
||||||
|
with `xorg-driver-video`. Hopefully provided packages will not change,
|
||||||
|
but using substitution variables is cheap, and makes it easy to add
|
||||||
|
tweaks afterwards if needed.
|
||||||
|
|
||||||
|
|
||||||
|
Driver’s build system
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
To set those variables, we ship a `dh_xsf_substvars` script in
|
||||||
|
`xserver-xorg-dev` starting with `2:1.9.4`, to be run before
|
||||||
|
`dh_gencontrol`. It iterates on the packages listed by
|
||||||
|
`dh_listpackages` (very old `debhelper` command) and does the
|
||||||
|
following work:
|
||||||
|
|
||||||
|
* It reads variables from the files mentioned above.
|
||||||
|
* If a package name ends with `-udeb`, it replaces
|
||||||
|
`xserver-xorg-core` with `xserver-xorg-core-udeb`.
|
||||||
|
* If a package name ends with `-dbg`, it does nothing for this
|
||||||
|
package. Debug packages usually depend strictly on the non-debug
|
||||||
|
packages, which in turn have appropriate dependencies.
|
||||||
|
* If a package name starts with `xserver-xorg-input-`, it appends
|
||||||
|
`xinpdriver:Depends=…` and `xinpdriver:Provides=…` to this
|
||||||
|
package’s substvars file.
|
||||||
|
* If a package name starts with `xserver-xorg-video-`, it appends
|
||||||
|
`xviddriver:Depends=…` and `xviddriver:Provides=…` to this
|
||||||
|
package’s substvars file.
|
||||||
|
|
||||||
|
Why such heuristics? The idea is to avoid getting “unused substitution
|
||||||
|
variable” warning messages while building. And since there’s a clear
|
||||||
|
`xserver-xorg-{input,video}-*` namespace, we can use that to specify
|
||||||
|
only input-related variables for input drivers, and only video-related
|
||||||
|
variables for video drivers.
|
||||||
|
|
||||||
|
To make it easy to compute substvars when using `dh`, a `dh` sequence
|
||||||
|
(`xsf.pm`) is shipped. As of `2:1.9.4-1`, it inserts
|
||||||
|
`dh_xsf_substvars` right before the `dh_gencontrol` call. Other
|
||||||
|
repetitive tasks could also be automated this way.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Sample driver packaging
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
The following assumes:
|
||||||
|
|
||||||
|
* The upstream build system is sane enough, which lets us run
|
||||||
|
`autoreconf` at build time.
|
||||||
|
* It is a `video` driver. For an `input` driver, replace both
|
||||||
|
`xviddriver` occurrences with `xinpdriver`.
|
||||||
|
|
||||||
|
Sample debian/control file
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
----
|
||||||
|
Build-Depends:
|
||||||
|
debhelper (>= 8),
|
||||||
|
dh-autoreconf,
|
||||||
|
quilt,
|
||||||
|
xserver-xorg-dev (>= 2:1.9.4),
|
||||||
|
----
|
||||||
|
|
||||||
|
----
|
||||||
|
Depends:
|
||||||
|
${shlibs:Depends},
|
||||||
|
${misc:Depends},
|
||||||
|
${xviddriver:Depends},
|
||||||
|
Provides:
|
||||||
|
${xviddriver:Provides}
|
||||||
|
----
|
||||||
|
|
||||||
|
Sample debian/rules file
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
----
|
||||||
|
#!/usr/bin/make -f
|
||||||
|
|
||||||
|
# Configuration:
|
||||||
|
#override_dh_auto_configure:
|
||||||
|
# dh_auto_configure -- --with-FOO --without-BAR
|
||||||
|
|
||||||
|
# Install in debian/tmp to retain control through dh_install:
|
||||||
|
override_dh_auto_install:
|
||||||
|
dh_auto_install --destdir=debian/tmp
|
||||||
|
|
||||||
|
# Kill *.la files, and forget no-one:
|
||||||
|
override_dh_install:
|
||||||
|
find debian/tmp -name '*.la' -delete
|
||||||
|
dh_install --fail-missing
|
||||||
|
|
||||||
|
## Debug package:
|
||||||
|
#override_dh_strip:
|
||||||
|
# dh_strip --dbg-package=xserver-xorg-video-DRIVER-dbg
|
||||||
|
|
||||||
|
# That's a plugin, use appropriate warning level:
|
||||||
|
override_dh_shlibdeps:
|
||||||
|
dh_shlibdeps -- --warnings=6
|
||||||
|
|
||||||
|
%:
|
||||||
|
dh $@ --with quilt,autoreconf,xsf --builddirectory=build/
|
||||||
|
----
|
||||||
|
|
||||||
|
Some comments:
|
||||||
|
|
||||||
|
* `dh_auto_configure`: Commented out since there’s usually no
|
||||||
|
specific option to pass when building drivers. Sometimes needed to
|
||||||
|
get a related utility built.
|
||||||
|
* `dh_auto_install`: It behaves differently when operating on a
|
||||||
|
single package (it installs under `debian/PACKAGE` instead of
|
||||||
|
`debian/tmp`), so make it use `debian/tmp` in all cases. This way,
|
||||||
|
`dh_install` has to be used (see below). That also means that a
|
||||||
|
binary package (_e.g._ a debug package) can be added without
|
||||||
|
changing this part.
|
||||||
|
* `dh_install`: No point in keeping the `.la` files. Also, using
|
||||||
|
`--fail-missing` makes sure every file installed by upstream is
|
||||||
|
installed in some package, or explicitly ignored.
|
||||||
|
* `dh_strip`: Commented out, there’s only a few drivers shipping a
|
||||||
|
debug package.
|
||||||
|
* `dh_shlibdeps`: The comment really says it all.
|
||||||
|
* `dh`: The order is important! We want patching to happen before
|
||||||
|
autoreconfiguring (both `quilt` and `autoreconf` insert commands
|
||||||
|
before `dh_auto_configure`, and after `dh_clean`). Also, we build
|
||||||
|
out-of-tree. The `xsf` sequence is explained in the previous part.
|
||||||
|
|
||||||
|
If one needs to build several flavours,
|
||||||
|
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-fbdev.git;a=blob;f=debian/rules[++fbdev++’s rules file]
|
||||||
|
can be used as an example.
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Handling a transition
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
When a new major version of the server comes up, it can be updated
|
||||||
|
following its `README.source`. Usually, drivers can be rebuilt using
|
||||||
|
binNMUs. Be sure `xorg-server` is marked as `Installed` on all
|
||||||
|
buildds, or set a `dep-wait`.
|
||||||
|
|
||||||
|
On the release team side, a transition page can be asked for, to track
|
||||||
|
fully rebuilt drivers. For the input 12→13 and video 10→11
|
||||||
|
transitions, the settings are:
|
||||||
|
|
||||||
|
* Affected: `.build-depends ~ /xserver-xorg-dev/`
|
||||||
|
* Good: `.depends ~ /xorg-input-abi-13/ | .depends ~ /xorg-video-abi-11/`
|
||||||
|
* Bad: `.depends ~ /xorg-input-abi-12/ | .depends ~ /xorg-video-abi-10/`
|
||||||
|
|
||||||
|
|
||||||
|
<<<
|
||||||
|
Staying tuned
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Staying informed of driver-related changes can be a bit difficult in
|
||||||
|
the following cases:
|
||||||
|
|
||||||
|
* If one maintains a single driver within the X Strike Force, one
|
||||||
|
might not notice the few mails about drivers in the heavy mail flow
|
||||||
|
on `debian-x@`.
|
||||||
|
* If one maintains a driver outside the X Strike Force, one is
|
||||||
|
probably not subscribed to the mailing list at all.
|
||||||
|
|
||||||
|
For those reasons, a mail alias is being set up to gather all
|
||||||
|
maintainers interested in receiving driver-related mails.
|
||||||
|
|
@ -0,0 +1,98 @@
|
||||||
|
Handling multiple server versions thanks to experimental
|
||||||
|
========================================================
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Context
|
||||||
|
-------
|
||||||
|
|
||||||
|
A quick overview of how things work upstream for the server:
|
||||||
|
|
||||||
|
* Patches get reviewed and merged into the `master` branch.
|
||||||
|
* After a few release candidates, `master` gets tagged (say: `1.10`
|
||||||
|
or `1.10.0`), and a stable branch (`server-1.10-branch` in this
|
||||||
|
case) is created to receive bug fixes.
|
||||||
|
* Those bug fixes usually are cherry-picks from commits in the
|
||||||
|
`master` branch.
|
||||||
|
* This leads to stable bugfix releases: `1.10.1`, `1.10.2`, and
|
||||||
|
so on.
|
||||||
|
|
||||||
|
It doesn’t make much sense to try and package `master` on a continuous
|
||||||
|
fashion, since the ABI can be broken multiple times, without a bump
|
||||||
|
for the ABI version numbers every time. It’s usually done once a bunch
|
||||||
|
of major changes landed, and when things are supposed to be stable
|
||||||
|
for a while. On the packaging side, as explained on the
|
||||||
|
link:dependencies.html[dependencies between server and drivers] page,
|
||||||
|
a bump means the need for a rebuild of the relevant drivers (input
|
||||||
|
and/or video).
|
||||||
|
|
||||||
|
That’s why the idea is to concentrate on upstream release candidates
|
||||||
|
and official releases. Depending on available developer time (both
|
||||||
|
upstream and in Debian), several branches can be developed/maintained
|
||||||
|
in parallel, so it can be worth having several versions available in
|
||||||
|
parallel, which is where `experimental` is handy.
|
||||||
|
|
||||||
|
Keeping on with this example, with `1.9` in `unstable`, release
|
||||||
|
candidates for `1.10` can be uploaded to `experimental`, along with a
|
||||||
|
few drivers so that it’s actually useful.
|
||||||
|
|
||||||
|
|
||||||
|
Selecting drivers
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
To avoid repetitive and sometimes pointless work, it’s probably a good
|
||||||
|
idea to upload (to `experimental` as well) only a few drivers built
|
||||||
|
against the server in `experimental`. ABI might be bumped between
|
||||||
|
release candidates (that happened between `1.10rc3` and `1.10` for
|
||||||
|
example), so drivers would need to be rebuilt (even though binNMUs
|
||||||
|
might help).
|
||||||
|
|
||||||
|
The proposed drivers can be seen on the
|
||||||
|
link:squeeze-backports.html[backports policy for squeeze] page, along
|
||||||
|
with a tiny description for each.
|
||||||
|
|
||||||
|
|
||||||
|
Building drivers in experimental
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
Having a driver in `experimental` doesn’t change much: It is sufficient
|
||||||
|
to declare a build-dependency against `xserver-xorg-dev (>=
|
||||||
|
$serverminver)`, where `$serverminver` can be seen in:
|
||||||
|
|
||||||
|
* `debian/serverminver` in the `xorg-server` source package: see its
|
||||||
|
first line.
|
||||||
|
* `/usr/share/xserver-xorg/inputdrvdep`: see the needed version of
|
||||||
|
`xserver-xorg-core`.
|
||||||
|
* `/usr/share/xserver-xorg/videodrvdep`: ditto.
|
||||||
|
|
||||||
|
So, for a given version of a driver in `unstable`, bumping the
|
||||||
|
build-dep version and uploading to `experimental` should be enough,
|
||||||
|
providing it doesn’t require further changes (source code changes are
|
||||||
|
sometimes needed to support building against a newer server). When
|
||||||
|
that happens, the revision number can be constructed by appending
|
||||||
|
`+exp1`. The idea here is to avoid things like:
|
||||||
|
|
||||||
|
* `1.42-1` to `unstable`.
|
||||||
|
* `1.42-2` to `experimental`: bump the build-dep.
|
||||||
|
* `1.42-3` to `unstable`: revert the build-dep bump, add a bugfix.
|
||||||
|
* `1.42-4` to `experimental`: build the build-dep again, keep the bugfix.
|
||||||
|
* etc.
|
||||||
|
|
||||||
|
Instead, that seems more natural:
|
||||||
|
|
||||||
|
* `1.42-1` to `unstable`.
|
||||||
|
* `1.42-1+exp1` to `experimental`: bump the build-dep.
|
||||||
|
* `1.42-2` to `unstable`: add a bugfix to ++unstable++’s version.
|
||||||
|
* `1.42-2+exp1` to `experimental`: rebuild against experimental
|
||||||
|
(merging or rebasing the build-dep bump).
|
||||||
|
|
||||||
|
****
|
||||||
|
.Note
|
||||||
|
|
||||||
|
Remember `experimental` is special. With the above sequence of
|
||||||
|
uploads, if the `1.42-2+exp1` version isn’t uploaded, the
|
||||||
|
`1.42-1+exp1` upload might disappear from `experimental` after some
|
||||||
|
time, since the version in `unstable` is more recent: the “obsolete”
|
||||||
|
package goes away. That’s why it’s important to remember uploading to
|
||||||
|
`experimental` as well when uploading a new driver to `unstable`.
|
||||||
|
****
|
||||||
|
|
@ -0,0 +1,200 @@
|
||||||
|
Git usage
|
||||||
|
=========
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
[NOTE]
|
||||||
|
The old documentation is still available on the wiki:
|
||||||
|
http://wiki.debian.org/XStrikeForce/git-usage[wiki.debian.org/XSF/git-usage];
|
||||||
|
this documentation is just a draft for now.
|
||||||
|
|
||||||
|
|
||||||
|
Getting started
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Upstream repositories are hosted on
|
||||||
|
http://cgit.freedesktop.org/[git.freedesktop.org]
|
||||||
|
|
||||||
|
Debian repositories are hosted on
|
||||||
|
http://git.debian.org/[git.debian.org] under the `pkg-xorg/*`
|
||||||
|
namespace. Each repository is about a single Debian source package.
|
||||||
|
|
||||||
|
We have two types of repositories:
|
||||||
|
|
||||||
|
* *regular* packages: 1 upstream repository → 1 Debian repository → 1
|
||||||
|
Debian source package (non-native).
|
||||||
|
* *bundle* packages: multiple upstream repositories → 1 Debian
|
||||||
|
repository → 1 Debian source package (native).
|
||||||
|
|
||||||
|
A local git repository can have several remotes. In the context of
|
||||||
|
Debian packaging, one usually starts by cloning the Debian repository,
|
||||||
|
so `origin` will likely point to `git.debian.org`. One can use
|
||||||
|
`upstream` to point to `anongit.freedesktop.org`. The following
|
||||||
|
documentation assumes this convention.
|
||||||
|
|
||||||
|
The following bits in `~/.gitconfig` will make it possible to fetch
|
||||||
|
updates using the `git` protocol (anonymously), and to push updates
|
||||||
|
through `ssh` without having to fiddle with the remote’s URL (in other
|
||||||
|
words: using `git://git.debian.org` everywhere):
|
||||||
|
|
||||||
|
----
|
||||||
|
[url "ssh://git.debian.org"]
|
||||||
|
pushInsteadOf = "git://git.debian.org"
|
||||||
|
----
|
||||||
|
|
||||||
|
To get the repository from `git.debian.org` one can run `debcheckout
|
||||||
|
$package` (or `debcheckout $package $package.git`), which will use the
|
||||||
|
`Vcs-Git` fields in the APT cache to pick the appropriate git
|
||||||
|
location. To add the `upstream` remote (using the info stored in
|
||||||
|
`debian/watch`), one can use `xsf-remote-add-upstream` script from the
|
||||||
|
http://git.debian.org/?p=pkg-xorg/debian/xsf-tools.git[pkg-xorg/debian/xsf-tools.git]
|
||||||
|
repository.
|
||||||
|
|
||||||
|
**TODO:** There will be more information about how to deal with the
|
||||||
|
many repositories maintained by the X Strike Force in a later chapter.
|
||||||
|
|
||||||
|
The usual workflow is to keep the target suite in `debian/changelog`
|
||||||
|
to `UNRELEASED` until the upload happens, the last commit before a
|
||||||
|
commit being only `dch -r`. To achieve that, and to avoid noise since
|
||||||
|
those packages are comaintained, it’s advised to set the following
|
||||||
|
variable in `~/.devscripts`:
|
||||||
|
|
||||||
|
----
|
||||||
|
DEBCHANGE_RELEASE_HEURISTIC=changelog
|
||||||
|
----
|
||||||
|
|
||||||
|
|
||||||
|
Regular packages
|
||||||
|
----------------
|
||||||
|
|
||||||
|
For most packages (exceptions include `xorg-server`), development is
|
||||||
|
linear, and happens in a `master` branch. That `master` branch is
|
||||||
|
pushed in the Debian repository as `upstream-$suite`
|
||||||
|
(e.g. `upstream-unstable`), depending on the target suite. Usually,
|
||||||
|
`upstream-unstable` tracks `upstream/master`.
|
||||||
|
|
||||||
|
The packaging is kept in `debian-$suite` branches, branched from
|
||||||
|
`upstream-$suite`. When cloning a Debian repository, the default
|
||||||
|
branch is `debian-unstable`.
|
||||||
|
|
||||||
|
To create the initial packaging from the `upstream-unstable` branch,
|
||||||
|
just run `git checkout -b debian-unstable`, add packaging files
|
||||||
|
(`changelog`, `control`, `copyright`, `rules` etc. under `debian/`),
|
||||||
|
and that’s it.
|
||||||
|
|
||||||
|
Here’s how to merge from upstream (`$foo` being a tag or
|
||||||
|
`upstream/master`):
|
||||||
|
|
||||||
|
----
|
||||||
|
git checkout upstream-unstable
|
||||||
|
git merge $foo
|
||||||
|
git log $foo > ChangeLog
|
||||||
|
dch -v $debianrevision
|
||||||
|
git commit -am 'Bump changelogs.'
|
||||||
|
----
|
||||||
|
|
||||||
|
`$debianrevision` is usually `$foo` with `-1` appended (first upload),
|
||||||
|
and sometimes prepended with a epoch (for example `2:`). Passing
|
||||||
|
`$foo-1` is usually a good rule of thumb, since `dch` will complain if
|
||||||
|
the epoch is missing (given the specified version string wouldn’t be
|
||||||
|
newer than the current one).
|
||||||
|
|
||||||
|
When development isn’t linear
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
For packages like `xorg-server` and `libx11`, there are stable
|
||||||
|
branches which receive updates for a while. Trying to switch from
|
||||||
|
`1.10.2` to `1.11.0` might trigger a lot of conflicts. But in the end
|
||||||
|
what matters is the changes between `upstream-$suite` and
|
||||||
|
`debian-$suite`. Here’s an example, supposing `upstream-unstable` and
|
||||||
|
`debian-unstable` are pointing to the “old” branches, and supposing
|
||||||
|
the new branch is `upstream/master`:
|
||||||
|
|
||||||
|
----
|
||||||
|
git checkout -b debian-unstable-new upstream/master
|
||||||
|
git merge -s ours upstream-unstable
|
||||||
|
git merge debian-unstable
|
||||||
|
git branch -d debian-unstable
|
||||||
|
git branch -m debian-unstable
|
||||||
|
----
|
||||||
|
|
||||||
|
Subtitles:
|
||||||
|
|
||||||
|
* Create a `debian-unstable-new` branch starting with the upstream
|
||||||
|
`master` branch, and switch to it.
|
||||||
|
* “Merge” the old `upstream-unstable` branch, actually keeping only
|
||||||
|
the new upstream branch.
|
||||||
|
* Merge the old packaging on top of it.
|
||||||
|
* Remove the old branch (so that the name can be reused).
|
||||||
|
* Rename the current `debian-unstable-new` branch into
|
||||||
|
`debian-unstable`.
|
||||||
|
|
||||||
|
Since the tip of the new `debian-unstable` branch is a descendant of
|
||||||
|
the tip of the old `debian-unstable` one, it can be pushed normally.
|
||||||
|
|
||||||
|
Since old `upstream-unstable` and new `upstream-unstable` diverged,
|
||||||
|
this branch has to be pushed with a `-f` to force the update (it’s not
|
||||||
|
a fast-forward).
|
||||||
|
|
||||||
|
|
||||||
|
Bundle packages
|
||||||
|
---------------
|
||||||
|
|
||||||
|
One bundle package is a Debian native package, with just a (Debian)
|
||||||
|
tarball, instead of an upstream tarball plus a Debian diff.
|
||||||
|
|
||||||
|
There is no upstream branches here, only `debian-$suite`.
|
||||||
|
|
||||||
|
The repository contains a `debian/` directory for the packaging, and
|
||||||
|
one directory per upstream source. Merging a new upstream release
|
||||||
|
means updating the contents of the relevant directory with the
|
||||||
|
contents of the new upstream tarball. Fetching new tarballs is
|
||||||
|
automated through a specific target: `make -f debian/rules
|
||||||
|
get-tarballs`
|
||||||
|
|
||||||
|
To perform an update, first run `dch -i` to create a new changelog
|
||||||
|
entry if the previous commit was an upload (the new entry targets the
|
||||||
|
`UNRELEASED` suite, see “Foreword”).
|
||||||
|
|
||||||
|
Assuming `get-tarballs` made `foo-bar.tar.gz` appear in the top-level
|
||||||
|
directory, here’s how to update (trailing slashes are not needed, just
|
||||||
|
there to clarify we’re working on directories):
|
||||||
|
|
||||||
|
----
|
||||||
|
git rm -r foo/
|
||||||
|
tar xf foo-bar.tar.gz
|
||||||
|
mv foo-bar/ foo/
|
||||||
|
git add foo/
|
||||||
|
dch "foo bar"
|
||||||
|
debcommit -a
|
||||||
|
----
|
||||||
|
|
||||||
|
Using the `xsf-remote-add-upstream` script will create several
|
||||||
|
`upstream-$foo` remotes, using info stored in `debian/watch*`. This
|
||||||
|
helps browsing the history of a given repository (rather than having
|
||||||
|
to look at a big fat diff with autogenerated files in the middle).
|
||||||
|
|
||||||
|
|
||||||
|
Upgrade checklist
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
[NOTE]
|
||||||
|
Since it’s likely for a reader of this page to be on her way to update
|
||||||
|
a package, here’s a tiny upgrade checklist.
|
||||||
|
|
||||||
|
Basic checks include looking into what happened to those files since
|
||||||
|
the last packaging update:
|
||||||
|
|
||||||
|
* `COPYING`: Update `debian/copyright` accordingly.
|
||||||
|
* `configure.ac` (or `configure.in`): Update (build-)dependencies
|
||||||
|
accordingly.
|
||||||
|
|
||||||
|
About xorg macros (they show up very often in the diff), they’re
|
||||||
|
shipped in the `xutils-dev` package, which contains a file to help map
|
||||||
|
macro versions and package versions:
|
||||||
|
`/usr/share/doc/xutils-dev/versions`
|
||||||
|
|
||||||
|
Some packages might have more specific instructions. That’s the case
|
||||||
|
for at least `xorg-server`. See its `debian/README.source`, below the
|
||||||
|
generic “how to use quilt” blurb.
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
Backports for squeeze
|
||||||
|
=====================
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Bird’s-eye view
|
||||||
|
---------------
|
||||||
|
|
||||||
|
If one forgets about libraries and clients, a whole X stack boils down
|
||||||
|
to: the server itself, input and video drivers, libdrm, and mesa.
|
||||||
|
|
||||||
|
To keep things simple, the idea is to backport all of those to
|
||||||
|
`squeeze` through `squeeze-backports`, along with some of the
|
||||||
|
additional packages which might be involved (like `libxfont` or
|
||||||
|
`x11proto-fixes-dev`).
|
||||||
|
|
||||||
|
The backports were prepared so that it’s possible to upgrade the
|
||||||
|
`input-all` and `video-all` meta packages on `amd64` and `i386`. If
|
||||||
|
specific drivers (maintained by the X Strike Force) are wanted,
|
||||||
|
requesting them on the `debian-backports@` / `debian-x@` mailing lists
|
||||||
|
should do the trick. For other drivers, please contact the relevant
|
||||||
|
package maintainers.
|
||||||
|
|
||||||
|
|
||||||
|
Instructions
|
||||||
|
------------
|
||||||
|
|
||||||
|
The usual link:http://backports-master.debian.org/[backports instructions]
|
||||||
|
apply. But let’s gather everything in a single place.
|
||||||
|
|
||||||
|
Add that to your `sources.list`:
|
||||||
|
----
|
||||||
|
deb http://backports.debian.org/debian-backports squeeze-backports main
|
||||||
|
----
|
||||||
|
|
||||||
|
Update your cache:
|
||||||
|
----
|
||||||
|
apt-get update
|
||||||
|
----
|
||||||
|
|
||||||
|
If you’re interested in just upgrading the usual `mesa` packages:
|
||||||
|
----
|
||||||
|
apt-get install -t squeeze-backports libgl1-mesa-dri libgl1-mesa-glx
|
||||||
|
----
|
||||||
|
|
||||||
|
If you want the whole stack, we should distinguish between two
|
||||||
|
cases.
|
||||||
|
|
||||||
|
In the usual case, both the `xserver-xorg-input-all` and
|
||||||
|
`xserver-xorg-video-all` meta packages were installed, and pulled a
|
||||||
|
lot of packages, which should work for most users.
|
||||||
|
Specifying a few packages to upgrade should pull
|
||||||
|
everything from `squeeze-backports`.
|
||||||
|
|
||||||
|
----
|
||||||
|
apt-get install -t squeeze-backports xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-all
|
||||||
|
apt-get install -t squeeze-backports libgl1-mesa-dri libgl1-mesa-glx
|
||||||
|
----
|
||||||
|
|
||||||
|
In case only the needed packages were installed, like the `synaptics`
|
||||||
|
input driver and the `intel` video driver, the following should be
|
||||||
|
sufficient:
|
||||||
|
----
|
||||||
|
apt-get install -t squeeze-backports xorg xserver-xorg xserver-xorg-core xserver-xorg-input-synaptics xserver-xorg-video-intel
|
||||||
|
apt-get install -t squeeze-backports libgl1-mesa-dri libgl1-mesa-glx
|
||||||
|
----
|
||||||
|
|
||||||
|
It is probably a very good idea to install the Linux kernel from
|
||||||
|
`squeeze-backports` as well. It is even required for the `nouveau`
|
||||||
|
video driver.
|
||||||
|
|
@ -0,0 +1,46 @@
|
||||||
|
Upstream contacts
|
||||||
|
=================
|
||||||
|
:toc:
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Getting announcements
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
* Almost everything: `xorg-announce@lists.freedesktop.org`
|
||||||
|
* Mesa: `mesa-announce@lists.freedesktop.org`
|
||||||
|
|
||||||
|
_(Source: http://wiki.x.org/wiki/XorgMailingLists[XorgMailingLists])_
|
||||||
|
|
||||||
|
|
||||||
|
Developer lists
|
||||||
|
---------------
|
||||||
|
|
||||||
|
|
||||||
|
Almost everything:
|
||||||
|
|
||||||
|
* `xorg-devel@lists.freedesktop.org` — doc:
|
||||||
|
http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches[SubmittingPatches]
|
||||||
|
— module maintainers:
|
||||||
|
http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS[MAINTAINERS]
|
||||||
|
|
||||||
|
Driver-specific:
|
||||||
|
|
||||||
|
* ATI: `xorg-driver-ati@lists.x.org`
|
||||||
|
* Intel: `intel-gfx@lists.freedesktop.org` — doc:
|
||||||
|
http://intellinuxgraphics.org/how_to_report_bug.html[How to file a good bug report]
|
||||||
|
* Nouveau: `nouveau@lists.freedesktop.org`
|
||||||
|
* VMMouse & VMWare: `thellstrom@vmware.com` — source:
|
||||||
|
http://wiki.x.org/wiki/vmware[vmware wikipage]
|
||||||
|
|
||||||
|
Other:
|
||||||
|
|
||||||
|
* DRM: `dri-devel@lists.freedesktop.org`
|
||||||
|
* Mesa: `mesa-dev@lists.freedesktop.org`
|
||||||
|
* Pixman: `pixman@lists.freedesktop.org`
|
||||||
|
* Wayland: `wayland-devel@lists.freedesktop.org`
|
||||||
|
* XCB: `xcb@lists.freedesktop.org`
|
||||||
|
* XKeyboardConfig/xkb-data: `xkb@listserv.bat.ru` — source:
|
||||||
|
http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development[XKeyboardConfig]
|
||||||
|
|
||||||
|
_(Source: http://wiki.x.org/wiki/XorgMailingLists[XorgMailingLists])_
|
||||||
|
|
@ -0,0 +1,17 @@
|
||||||
|
Upstream features
|
||||||
|
=================
|
||||||
|
Cyril Brulebois <kibi@debian.org>
|
||||||
|
|
||||||
|
|
||||||
|
Let’s collect links where one can learn more about features. It might
|
||||||
|
make sense to ask permission to (re)use those and merge them into this
|
||||||
|
package, in case the hosting sites go offline.
|
||||||
|
|
||||||
|
Multitouch/touchpads
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
Touchpad features, by Peter Hutterer: +
|
||||||
|
→ http://who-t.blogspot.com/2010/06/incomplete-roundup-of-touchpad-features.html
|
||||||
|
|
||||||
|
What multitouch really is about, by Peter Hutterer: +
|
||||||
|
→ http://who-t.blogspot.com/2010/10/thoughts-on-linux-multitouch.html
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
@import url("asciidoc-xhtml11.css");
|
||||||
|
|
||||||
|
h1 {
|
||||||
|
background-image: url("xsf.svg");
|
||||||
|
background-repeat: no-repeat;
|
||||||
|
background-position: center right;
|
||||||
|
background-size: auto 95%;
|
||||||
|
}
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 3.8 KiB |
|
|
@ -0,0 +1,234 @@
|
||||||
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||||
|
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||||
|
|
||||||
|
<svg
|
||||||
|
xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
|
||||||
|
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||||
|
xmlns:cc="http://creativecommons.org/ns#"
|
||||||
|
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||||
|
xmlns:svg="http://www.w3.org/2000/svg"
|
||||||
|
xmlns="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
|
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||||
|
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||||
|
width="80"
|
||||||
|
height="80"
|
||||||
|
id="svg2958"
|
||||||
|
version="1.1"
|
||||||
|
inkscape:version="0.47 r22583"
|
||||||
|
sodipodi:docname="attempt3.svg">
|
||||||
|
<defs
|
||||||
|
id="defs2960">
|
||||||
|
<inkscape:perspective
|
||||||
|
sodipodi:type="inkscape:persp3d"
|
||||||
|
inkscape:vp_x="0 : 526.18109 : 1"
|
||||||
|
inkscape:vp_y="0 : 1000 : 0"
|
||||||
|
inkscape:vp_z="744.09448 : 526.18109 : 1"
|
||||||
|
inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
|
||||||
|
id="perspective2966" />
|
||||||
|
<inkscape:perspective
|
||||||
|
id="perspective2940"
|
||||||
|
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
|
||||||
|
inkscape:vp_z="1 : 0.5 : 1"
|
||||||
|
inkscape:vp_y="0 : 1000 : 0"
|
||||||
|
inkscape:vp_x="0 : 0.5 : 1"
|
||||||
|
sodipodi:type="inkscape:persp3d" />
|
||||||
|
<inkscape:perspective
|
||||||
|
id="perspective3239"
|
||||||
|
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
|
||||||
|
inkscape:vp_z="1 : 0.5 : 1"
|
||||||
|
inkscape:vp_y="0 : 1000 : 0"
|
||||||
|
inkscape:vp_x="0 : 0.5 : 1"
|
||||||
|
sodipodi:type="inkscape:persp3d" />
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3224"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396" />
|
||||||
|
<linearGradient
|
||||||
|
id="LO"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396">
|
||||||
|
<stop
|
||||||
|
style="stop-color:#e54c18"
|
||||||
|
offset="0"
|
||||||
|
id="stop3094" />
|
||||||
|
<stop
|
||||||
|
style="stop-color:#fec350"
|
||||||
|
offset="1"
|
||||||
|
id="stop3096" />
|
||||||
|
</linearGradient>
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3284"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396" />
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3291"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396" />
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3300"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396" />
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3306"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396" />
|
||||||
|
<linearGradient
|
||||||
|
inkscape:collect="always"
|
||||||
|
xlink:href="#LO"
|
||||||
|
id="linearGradient3309"
|
||||||
|
gradientUnits="userSpaceOnUse"
|
||||||
|
x1="319.20822"
|
||||||
|
y1="235.14877"
|
||||||
|
x2="657.65295"
|
||||||
|
y2="269.49396"
|
||||||
|
gradientTransform="matrix(0.33444317,0,0,0.33444317,160.14506,391.84518)" />
|
||||||
|
</defs>
|
||||||
|
<sodipodi:namedview
|
||||||
|
id="base"
|
||||||
|
pagecolor="#ffffff"
|
||||||
|
bordercolor="#666666"
|
||||||
|
borderopacity="1.0"
|
||||||
|
inkscape:pageopacity="0.0"
|
||||||
|
inkscape:pageshadow="2"
|
||||||
|
inkscape:zoom="1.4"
|
||||||
|
inkscape:cx="57.251616"
|
||||||
|
inkscape:cy="2.651303"
|
||||||
|
inkscape:document-units="px"
|
||||||
|
inkscape:current-layer="layer1"
|
||||||
|
showgrid="false"
|
||||||
|
inkscape:window-width="666"
|
||||||
|
inkscape:window-height="756"
|
||||||
|
inkscape:window-x="0"
|
||||||
|
inkscape:window-y="0"
|
||||||
|
inkscape:window-maximized="0" />
|
||||||
|
<metadata
|
||||||
|
id="metadata2963">
|
||||||
|
<rdf:RDF>
|
||||||
|
<cc:Work
|
||||||
|
rdf:about="">
|
||||||
|
<dc:format>image/svg+xml</dc:format>
|
||||||
|
<dc:type
|
||||||
|
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||||
|
</cc:Work>
|
||||||
|
</rdf:RDF>
|
||||||
|
</metadata>
|
||||||
|
<g
|
||||||
|
inkscape:label="Layer 1"
|
||||||
|
inkscape:groupmode="layer"
|
||||||
|
id="layer1"
|
||||||
|
transform="translate(-288.5803,-423.06919)">
|
||||||
|
<rect
|
||||||
|
id="rect3105"
|
||||||
|
height="0"
|
||||||
|
width="0.16891931"
|
||||||
|
y="465.94339"
|
||||||
|
x="406.15314"
|
||||||
|
style="opacity:0.40740739;fill:#000cff" />
|
||||||
|
<g
|
||||||
|
id="g3375"
|
||||||
|
transform="matrix(0.61835866,0,0,0.61835866,129.38048,171.50702)">
|
||||||
|
<path
|
||||||
|
id="path3102"
|
||||||
|
d="m 274.54934,522.51286 37.15573,-48.57995 -38.25252,-53.41491 24.58638,0.0204 30.48048,42.00033 -45.57461,59.9741 -8.39546,0 z m 72.72393,0.0343 -30.27005,-42.07244 45.95411,-60.00228 8.18775,0 -37.30736,48.80915 38.02231,53.26557 -24.58676,0 z" />
|
||||||
|
<g
|
||||||
|
i:rgbTrio="#4F008000FFFF"
|
||||||
|
i:dimmedPercent="50"
|
||||||
|
i:layer="yes"
|
||||||
|
id="Layer_1"
|
||||||
|
transform="matrix(1.2459517,0,0,0.63116303,267.96832,440.28054)">
|
||||||
|
<g
|
||||||
|
id="g2900">
|
||||||
|
<path
|
||||||
|
id="path2902"
|
||||||
|
d="m 51.986,57.297 c -1.797,0.025 0.34,0.926 2.686,1.287 0.648,-0.506 1.236,-1.018 1.76,-1.516 -1.461,0.358 -2.948,0.366 -4.446,0.229"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2904"
|
||||||
|
d="m 61.631,54.893 c 1.07,-1.477 1.85,-3.094 2.125,-4.766 -0.24,1.192 -0.887,2.221 -1.496,3.307 -3.359,2.115 -0.316,-1.256 -0.002,-2.537 -3.612,4.546 -0.496,2.726 -0.627,3.996"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2906"
|
||||||
|
d="m 65.191,45.629 c 0.217,-3.236 -0.637,-2.213 -0.924,-0.978 0.335,0.174 0.6,2.281 0.924,0.978"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2908"
|
||||||
|
d="m 45.172,1.399 c 0.959,0.172 2.072,0.304 1.916,0.533 1.049,-0.23 1.287,-0.442 -1.916,-0.533"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2910"
|
||||||
|
d="M 47.088,1.932 46.41,2.072 47.041,2.016 47.088,1.932"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2912"
|
||||||
|
d="m 76.992,46.856 c 0.107,2.906 -0.85,4.316 -1.713,6.812 l -1.553,0.776 c -1.271,2.468 0.123,1.567 -0.787,3.53 -1.984,1.764 -6.021,5.52 -7.313,5.863 -0.943,-0.021 0.639,-1.113 0.846,-1.541 -2.656,1.824 -2.131,2.738 -6.193,3.846 L 60.16,65.878 C 50.142,70.591 36.226,61.251 36.409,48.507 c -0.107,0.809 -0.304,0.607 -0.526,0.934 -0.517,-6.557 3.028,-13.143 9.007,-15.832 5.848,-2.895 12.704,-1.707 16.893,2.197 -2.301,-3.014 -6.881,-6.209 -12.309,-5.91 -5.317,0.084 -10.291,3.463 -11.951,7.131 -2.724,1.715 -3.04,6.611 -4.227,7.507 -1.597,11.737 3.004,16.808 10.787,22.773 1.225,0.826 0.345,0.951 0.511,1.58 -2.586,-1.211 -4.954,-3.039 -6.901,-5.277 1.033,1.512 2.148,2.982 3.589,4.137 -2.438,-0.826 -5.695,-5.908 -6.646,-6.115 4.203,7.525 17.052,13.197 23.78,10.383 -3.113,0.115 -7.068,0.064 -10.566,-1.229 -1.469,-0.756 -3.467,-2.322 -3.11,-2.615 9.182,3.43 18.667,2.598 26.612,-3.771 2.021,-1.574 4.229,-4.252 4.867,-4.289 -0.961,1.445 0.164,0.695 -0.574,1.971 2.014,-3.248 -0.875,-1.322 2.082,-5.609 l 1.092,1.504 c -0.406,-2.696 3.348,-5.97 2.967,-10.234 0.861,-1.304 0.961,1.403 0.047,4.403 1.268,-3.328 0.334,-3.863 0.66,-6.609 0.352,0.923 0.814,1.904 1.051,2.878 -0.826,-3.216 0.848,-5.416 1.262,-7.285 -0.408,-0.181 -1.275,1.422 -1.473,-2.377 0.029,-1.65 0.459,-0.865 0.625,-1.271 -0.324,-0.186 -1.174,-1.451 -1.691,-3.877 0.375,-0.57 1.002,1.478 1.512,1.562 -0.328,-1.929 -0.893,-3.4 -0.916,-4.88 -1.49,-3.114 -0.527,0.415 -1.736,-1.337 -1.586,-4.947 1.316,-1.148 1.512,-3.396 2.404,3.483 3.775,8.881 4.404,11.117 -0.48,-2.726 -1.256,-5.367 -2.203,-7.922 0.73,0.307 -1.176,-5.609 0.949,-1.691 C 83.519,18.706 76.074,10.902 69.225,7.24 70.063,8.007 71.121,8.97 70.741,9.121 67.335,7.093 67.934,6.935 67.446,6.078 64.671,4.949 64.489,6.169 62.651,6.08 57.421,3.306 56.413,3.601 51.6,1.863 l 0.219,1.023 c -3.465,-1.154 -4.037,0.438 -7.782,0.004 -0.228,-0.178 1.2,-0.644 2.375,-0.815 -3.35,0.442 -3.193,-0.66 -6.471,0.122 0.808,-0.567 1.662,-0.942 2.524,-1.424 -2.732,0.166 -6.522,1.59 -5.352,0.295 -4.456,1.988 -12.37,4.779 -16.811,8.943 l -0.14,-0.933 c -2.035,2.443 -8.874,7.296 -9.419,10.46 l -0.544,0.127 c -1.059,1.793 -1.744,3.825 -2.584,5.67 -1.385,2.36 -2.03,0.908 -1.833,1.278 -2.724,5.523 -4.077,10.164 -5.246,13.97 0.833,1.245 0.02,7.495 0.335,12.497 -1.368,24.704 17.338,48.69 37.785,54.228 2.997,1.072 7.454,1.031 11.245,1.141 -4.473,-1.279 -5.051,-0.678 -9.408,-2.197 -3.143,-1.48 -3.832,-3.17 -6.058,-5.102 l 0.881,1.557 c -4.366,-1.545 -2.539,-1.912 -6.091,-3.037 l 0.941,-1.229 C 28.751,98.334 26.418,96.056 25.78,94.795 l -1.548,0.061 c -1.86,-2.295 -2.851,-3.949 -2.779,-5.23 l -0.5,0.891 c -0.567,-0.973 -6.843,-8.607 -3.587,-6.83 -0.605,-0.553 -1.409,-0.9 -2.281,-2.484 l 0.663,-0.758 c -1.567,-2.016 -2.884,-4.6 -2.784,-5.461 0.836,1.129 1.416,1.34 1.99,1.533 -3.957,-9.818 -4.179,-0.541 -7.176,-9.994 L 8.412,66.472 C 7.926,65.74 7.631,64.945 7.24,64.165 l 0.276,-2.75 C 4.667,58.121 6.719,47.409 7.13,41.534 7.415,39.145 9.508,36.602 11.1,32.614 l -0.97,-0.167 c 1.854,-3.234 10.586,-12.988 14.63,-12.486 1.959,-2.461 -0.389,-0.009 -0.772,-0.629 4.303,-4.453 5.656,-3.146 8.56,-3.947 3.132,-1.859 -2.688,0.725 -1.203,-0.709 5.414,-1.383 3.837,-3.144 10.9,-3.846 0.745,0.424 -1.729,0.655 -2.35,1.205 4.511,-2.207 14.275,-1.705 20.617,1.225 7.359,3.439 15.627,13.605 15.953,23.17 l 0.371,0.1 c -0.188,3.802 0.582,8.199 -0.752,12.238 l 0.908,-1.912"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2914"
|
||||||
|
d="m 32.372,59.764 -0.252,1.26 c 1.181,1.604 2.118,3.342 3.626,4.596 -1.085,-2.118 -1.891,-2.993 -3.374,-5.856"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2916"
|
||||||
|
d="m 35.164,59.654 c -0.625,-0.691 -0.995,-1.523 -1.409,-2.352 0.396,1.457 1.207,2.709 1.962,3.982 l -0.553,-1.63"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2918"
|
||||||
|
d="m 84.568,48.916 -0.264,0.662 c -0.484,3.438 -1.529,6.84 -3.131,9.994 1.77,-3.328 2.915,-6.968 3.395,-10.656"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2920"
|
||||||
|
d="M 45.527,0.537 C 46.742,0.092 48.514,0.293 49.803,0 48.123,0.141 46.451,0.225 44.8,0.438 l 0.727,0.099"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2922"
|
||||||
|
d="m 2.872,23.219 c 0.28,2.592 -1.95,3.598 0.494,1.889 1.31,-2.951 -0.512,-0.815 -0.494,-1.889"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
<path
|
||||||
|
id="path2924"
|
||||||
|
d="M 0,35.215 C 0.563,33.487 0.665,32.449 0.88,31.449 -0.676,33.438 0.164,33.862 0,35.215"
|
||||||
|
i:knockout="Off"
|
||||||
|
style="fill:#d70751" />
|
||||||
|
</g>
|
||||||
|
</g>
|
||||||
|
</g>
|
||||||
|
</g>
|
||||||
|
</svg>
|
||||||
|
After Width: | Height: | Size: 11 KiB |
Loading…
Reference in New Issue