w23, posts by tag: linux - LiveJournal

я обещал: да вот так.

Отчет за прошедшие полгода: вместо того, чтобы постить вам сюда ежедневных котов, или, там, пропивать зарплату, я подсуетился и научился sizecoding'у для линукса.

Вот что получается, например:

[linux, 1k] urotsuki by Ye Olde Laptops Posse

Эта няшка была написана на ноуте, шейдеры видеокарты которого представляют странную помесь из GLSL 1.10 и 1.20, и, например, напрочь не умеют ветвиться. Поэтому никакого fancy raymarching, только простые функции от (x, y, t). И звук. Да, это первая 1к-интра для линукса со звуком.

(pouet || youtube-dl -t http://www.youtube.com/watch?v=EwU… || bin)

[linux, 256b] Blin Elfom by Ye Olde Laptops Posse

Эта няшка была написана на том же самом ноуте, но уже никакого OpenGL там нет, ибо хер его впихнешь туда. Запустить её "немного сложновато", но у ребят на Alternative Party 2011 это в итоге получилось, и эта интрочка заняла там почетное восьмое место из 12. Несмотря на то, что это первая интра в 256байт для линукса со звуком, и вторая — вообще.

(pouet || youtube-dl -t http://www.youtube.com/watch?v=c0V… || bin)

Я планирую в течение ближайшей недели накатать пару статей на тему, как такое делается из бетона и стекла, так что stay tuned.

Если вам когда-нибудь доведется быть в Гонконгском аэропорту с линукс-ноутбуком и иметь желание подключиться к зашифрованной сети PCCW1x (то же самое, что и просто PCCW, только WPA, сами понимаете, зачем нужно), то вот вам секция для конфига wpa_supplicant:

network={
#ssid="#HKAirport Free WiFi1x"
 ssid="PCCW1x"
 key_mgmt=WPA-EAP
 eap=PEAP
 identity="pccw"
 password="pccw"
 ca_cert="/etc/ssl/certs/Thawte_Premium_Server_CA.pem"
 phase1="peapver=0"
 phase2="auth=MSCHAPV2"
}

Файл /etc/ssl/certs/Thawte_Premium_Server_CA.pem может лежать у вас в другом месте (сделайте ему locate). Если он вообще у вас отсутствует, то его можно взять с сайта Thawte. А можно и не брать, а пойти в горы есть ягоды.

Нокия изобрела gnupoc: http://labs.qt.nokia.com/2010/12/1…

Это давно известное страдание, что карточки ATI/AMD при включеном composition говнят на операциях создания и изменения размера окон. Весь интернет страдает, и мало кто знает, почему так, и что с этим делать. Я тоже страдал, но не очень, потому что композицию использовал нечасто и давно. Однако поставив четвертые кеды, в котором оно включено по-умолчанию и вполне к месту, это начало меня бесить, и надо было срочно искать решение проблемы.
Оказалось, что косяк этот очень старый, но все от него отмахиваются — авторы fglrx говорят, что всё остальное же работает, работает (более-менее, лол) нормально, и вообще по-другому сделать нельзя, авторы xorg говорят "човаще, на других карточках всё работает прекрасно, так что это fglrx говяный", а ребята, делающие уже конкретные композиционные менеджеры, вообще считают, что пацаны уже взрослые и пусть сами разбираются, да и вообще не их это дело — подмазываться под карточки и производителей, когда последние должны уметь стандарты правильно и эффективно.
Техническая сторона проблемы на пальцах (чуть сложнее можно в два-три клика найти в гугле — старайтесь, коли интересно; здесь, например, есть чуть-чуть подробностей) выглядит примерно так: при каждой операции создания или растягивания окна надо пересоздавать текстуру из pixmap и перерисовывать содержимое окна в неё. Это создание выделяет память под текстуру, но, судя по всему, не чистит её. На современных серьёзных карточках эта память выделяется в памяти видеокарты, не доступной напрямую процессору. И беда в том, что процедура очистки на карточках АТИ, в силу каких-то непонятных причин, скачивает эту текстуру в общую память, что адски медленно. Вероятно, беда эта носит системно-архитектурный характер, оттого и решить её в одном месте нельзя — надо менять либо всё, либо железо, либо программистов ати (хотя это спорно — говорят, что опенсорсные дрова этим тоже страдают, если у карточки есть своя отдельная память) например, уходить в лес и жить собирательством.
Поэтому предлагаемое решение простое: убрать к свиньям очистку текстуры. Так, в общем-то, и поступали в некоторых дистрибутивах, патча xorg-server. Но потом ребята, судя по всему это были люди из Intel, заорали, что это security threat, т.к. на экран выводится непроинициализированная память, а там может быть что угодно, отчего дистры этот патч в массе своей свернули. И опять наступило всеобщее страдание.

Но от страдания можно легко избавиться, если у вы — задрот, как я, и используете gentoo (и не работаете на оборонку или крупную корпорацию с секретами дороже жизни вас и ваших родственников). Самый простой способ — подсунуть патч в /usr/portage/x11-base/xorg-server/files/ и в /usr/portage/x11-base/xorg-server/xorg-server-${VERSION}.ebuild (в моем случае это /usr/portage/x11-base/xorg-server/xorg-server-1.6.3.901-r2.ebuild: найти строку GENTOO_PATCHES=( и добавить после неё строку "${FILESDIR}/pixmap-bg-fglrx-compiz-slow-resize.patch". далее в том же каталоге (/usr/portage/x11-base/xorg-server/) сделать ebuild xorg-server-1.6.3.901-r2.ebuild manifest и пересобрать emerge -1 xorg-server. Перезапустить иксы (лучше полной перезагрузкой — fglrx иначе болеет) и радоваться.
Чтобы эти изменения не терялись при emerge --sync и пересборке иксов, лучше засунуть их в оверлей. Но это вы сами разберитесь, как сделать, мне лень писать.

Осталось дождаться XSync для Qt.

PS: KDE4 (4.3.2) — такая няшка! Решил просто попробовать, и больше в kde3.5.10 и не перезагружался — незачем. Тут всё есть, все работает неожиданно для линукса хорошо, приятно и в меру стабильно. Рекомендую.

upd: PPS: Еще есть косяк со Starcraft, который мне пока не удается вылечить — прозреваю корявые ARB-шейдеры на fglrx. Известно, что SC, будучи старой игрушечкой, требует восьмибитного графического режима, поддержка которого, особенно в случае композиции, сейчас не особо везде есть. wine может решать эту проблему двумя способами: 1) через x11; 2) через opengl. Первый способ заключается в том, что создается обычный 24/32-битный режим, изображение в который битблочится иксами из палитрованного восьмибитного процессором, что медленно адски (требует перехода каждого вызова через кучу говна, типа переключения прав доступа, процессора в режим ядра и назад пару раз и вообще), но работает стабильно и давно. Но тормозит и говно. Это по-умолчанию. Можно также включить экспериментальный режим через opengl — либо через расширение GL_EXT_paletted_texture (мало кем поддерживается, например некоторыми картами nVidia), либо через две текстуры — одна 2D под 8-битное изображение, в которое рисует приложение, другая 1D — под палитру, а затем это всё коротким фрагмент-шейдером выводится на экран. Всё быстро и на видеокарте. Казалось бы. У меня с wine 1.1.30 это почему-то не хочет работать: тупо не применяется правильная палитра, вся игра выглядит как блевота немытого пса с червями. Интернет молчит, надо разбираться, почему так.

Пока вы там спали, glxgears перестал вешать иксы при использовании опенсорсных дров на карточках ati radeon xpress 200m (в моем случае это RS482/485 — lspci говорит одно, cat /var/log/Xorg.0.log — другое).

Что-либо более тяжелое, правда, всё так же взрывается.

upd: квачок 3 нормально идет, а вот sauerbraten уже нет. душа моя болит.

С ума можно сойти, что я вам хочу сказать-то:
Намедни столкнулся с неприятным ядерным багом #11585, суть которого сводится к тому, что в ядрах после 2.6.26.3 USB->serial конверторы на базе mos7840 стали вести себя, как говно. А именно: слать всякий мусор, вместо того, что надо, и сегфолтить ядро при отключении модуля/устройства. Происходит это из-за жидов долбоебовновой строчки "serial->minor = SERIAL_TTY_NO_MINOR;" в функции create_serial() файла drivers/usb/serial/usb-serial.c. Эта строчка решает другой баг, который мне видеть не приходилось, но если я понимаю его суть, то связан он с тем, что при каком-нибудь провале на стадии инициализации конвертора, до того, как ему выдадут minor, существующий невыданный minor (равный на этой стадии 0) будет высвобожден. Когда он не занят. Лол. Поэтому они решили пометить не выданный minor как SERIAL_TTY_NO_MINOR. И всё бы хорошо, но модуль mos7840 этот самый minor использует в функции attach() (функция mos7840_startup() в файле drivers/usb/serial/mos7840.c), а вызов attach() происходит еще до того, как minor будет выдан. БАБАХ! Баг не проявлял себя раньше из-за того, что все ленивые долбоебы и нихуя не тестируют при наличии только одного конвертора ему как раз и выдается minor = 0. А теперь получается, что во время attach() minor == SERIAL_TTY_NO_MINOR, а после инициализации он уже другой. Драйверу это, разумеется, не нравится, ему плохеет и всё взрывается к чертям.
Патч для этой ситуации очень простой — выдать minor до вызова attach(). Ну или можно покопаться в ужаснейшем коде mos7840 (который изобилует комментариями вида ".................." и " !!!") и понять, зачем же ему там minor нужен. Что более правильно, но мне было лень.

Простой патч выглядит так:

--- linux.orig/drivers/usb/serial/usb-serial.c	2009-02-24 14:26:15.000000000 +0600
+++ linux/drivers/usb/serial/usb-serial.c	2009-03-03 15:05:41.000000000 +0600
@@ -908,6 +908,12 @@
 	} else if (num_interrupt_out) {
 		dbg("the device claims to support interrupt out transfers, but write_int_callback is not defined");
 	}
+
+	if (get_free_serial (serial, num_ports, &minor) == NULL) {
+		dev_err(&interface->dev, "No more free serial devices\n");
+		goto probe_error;
+	}
+	serial->minor = minor; 	
 	/* if this device type has an attach function, call it */
 	if (type->attach) {
@@ -926,12 +932,6 @@
 		}
 	} 
-	if (get_free_serial (serial, num_ports, &minor) == NULL) {
-		dev_err(&interface->dev, "No more free serial devices\n");
-		goto probe_error;
-	}
-	serial->minor = minor;
-
 	/* register all of the individual ports with the driver core */
 	for (i = 0; i < num_ports; ++i) {
 		port = serial->port[i];

Тут встает тот же вопрос, который должен был встать у авторов патча, закоммиченного в 2.6.26.3: не сломает ли это что-нибудь еще? Протестируйте, пожалуйста, если есть на чём.

я вот вам, ребята, что скажу.

самая лучшая игра на планете (после, разве что, homeworld, или там command & conquer: tiberian dawn): sauerbraten.

почему:

• Опенсорс, бесплатная и мультиплатформенная
• Свой написанный с нуля движок
  
• Графика сравнима с hl2 или doom3/q4
  
• Крайне быстрая (моментально грузится, меняет карты за две секунды, огромнейший фпс (под 200, против 30..20 у hl2))
• и самое главное: уровни можно редактировать прямо внутри игры. в том числе по сети. в том числе кучей человек. лучше развлечение сложно придумать.

архив с игрой весит чуть больше 200Мб. виндовую версию не смотрел, но вместе с линуксовой идёт не только x86-бинарник, но исходники, которые прекрасно собираются и работают на x86_64, как под линуксом, так и под freebsd.

я тут смеха ради написал сборщик статистики по логам psi.

официальная страница проекта, лол.