Система - nForce 410, ALC655, ядро собирал как gcc 4.4.0 так и gcc 4.3.3 по PKGBUILD'у из тестинга ArchLinux.
У кого-то подобная проблема была?
Смотрел XAutoRepeatOff, но увы этот способ отключает автоповтор нажатия клавиш вообще и для конкретного экрана.
Обновил библиотеку к версии 1.0(система - ArchLinux), и мобильный(LG KG200) перестал дозваниваться, заваливаясь вот так:
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"IP","internet"
AT+CGDCONT=1,"IP","internet"
OK
--> Modem initialized.
--> Sending: ATM1L3DT*99***1#
--> Waiting for carrier.
ATM1L3DT*99***1#
CONNECT
~[7f]}#@!}!} } }2}"}&} } } } }#}$@#}'}"}(}"R[04]~
--> Carrier detected. Waiting for prompt.
~[7f]}#@!}!}!} }2}"}&} } } } }#}$@#}'}"}(}"][14]~
--> PPP negotiation detected.
--> Starting pppd at Sun Jun 7 00:43:56 2009
--> Pid of pppd: 14478
--> Disconnecting at Sun Jun 7 00:43:56 2009
--> The PPP daemon has died. (exit code = 127)
ЗЫ: ошибка 127 это вообще что-то из астрала О_о
Система: ArchLinux, проц Athlon X2 3800+. У одного меня такое счастье, или все-же повезло с SVN-версией? :)
все, выдохнул :)
PS: выдохнул и жую кактус в ожидании чуда(то ли от NVIDIA, то ли от разработчиков compiz'а) PPS: всех ЧЯДНТ'акающих прошу не беспокоить. PPPS: лопнул от троллиного ожирения, пошел писать диплом... осталось 5 дней...
Ъ: Коротенькая манга примечательная тем, что посвящена… Ubuntu, дистрибутиву Linux. Как и Линукс, изначально распостраняется согласно свободной лицензии, на территории любой страны (в отличии от большинства другой любительской манги, продающейся в японии за деньги). Манга при переводе была отзеркалена, то есть читать слева направо.
Т.к. с недавних пор снова начал заниматься геймд^W фигней, решил привести в более вменяемый вид одну свою pascal'евскую библиотеку(да-да, Pascal). Но ввиду того, что новых проектов нет, взялся подкрутить старый. Если не сложно, может кто погонять/протестировать эту гамезу(двухмерная танковая аркада, 1.9Мб) ?. В архиве лежат бинарники для x86 и x86_64, включая сборку для альтернативной ОС. Для арчеводов есть PKGBUILD. Из зависимостей - OpenAL и libmodplug, ну и про наличие хардварного OpenGL не стоит забывать :)
ЗЫ: На всякий случай - описание управления и бонусов искать в меню Help.
Тему с багом касательно рендеринга ass-субтитров я поднял еще 21 февраля(хотя думаю сам баг существует дольше). В тот же день запостил в bugzill'у... в которую разработчики видимо даже не заглядывают. Спустя несколько дней баг исправили в той же libass, только в проекте Aegisub. Все делалось банальным присвоением font_scale_x единицы(есть там один параметр :)). Я даже об этом решил отписаться во все той-же багзилле, но реакции абсолютный ноль. Сегодня обновляясь из svn дождался таки исправления проблемы... которую исправили так же как и в Aegisub, то бишь абсолютно не разобравшись что к чему :) Просто упомянутый параметр висит в коде как нечто пришедшее из астрала, т.к. участвует в одной операции - умножение. Общий scale_x теперь умножается на единицу, смысла в этом? О_о
В общем к чему веду. Вам попадались подобные случаи скорого отклика разработчиков? :)
ЗЫ: Собственно после такого как-то «впадлы» становится сообщать об ошибках... вот так и живем, жалуясь на баги только в пределах ЛОРа :)
Тема начиналась тут: www.linux.org.ru/view-message.jsp?msgid=3520055
Полностью разобравшись что к чему, пришел к выводу, что таки font_scale_x остался излишеством в коде. Далее по коду в модуле ass_render.c видно единственное упоминание этого параметра:
ass_font_set_transform(render_context.font,
render_context.scale_x * frame_context.font_scale_x,
render_context.scale_y,
&shift );
Но в render_context.scale_x уже хранится правильное значение для рендера субтитров, соответственно font_scale_x только сбивает все. В общем собрал патч. Но т.к. увлекся занятием, решил кое-чего добавить. Довольно часто приходится смотреть широкоформатное видео, а т.к. монитор у меня с соотношением сторон 5/4(1280х1024), то охота сместить субтитры на черные полосы. Не всегда конечно, но когда субтитры довольно велики, или просто плохо контрастируют с видеорядом, это будет не лишним. В SMPlayer'е есть подобие нужного мне функционала, но там все делается обычным expand'ом, а с ним сбиваются координаты субтитров, для которых указан \pos. В самом mplayer'е есть -ass-top/bottom-marign, но для каждого видео вычислять нужные отступы - та еще морока :) Патч же добавляет опцию -ass-auto-margins, и при его использовании с -ass-use-margins, mplayer будет автоматически вычислять размер черных полос, которые следует добавить в соответствии с соотношением сторон вашего монитора. Что интересно - при -vo gl, черные полосы будут задействованы только в полноэкранном режиме(если конечно не использовать -vf-add ass). Правда пока так и не разобрался, почему эта неплохая особенность не действует в случаи с SMPlayer'ом... поэтому приходится в его настройках указывать «Сохранять субтитры на снимках экрана».
В общем, думаю кому-то будет полезно :)
ЗЫ: реакция разработчиков на баг пока не последовала... то ли суток мало, то ли выходные.
У mplayer'а отличная рендерилка сабов, но время от времени мне попадались сабы, где указанные PlayResX/PlayResY отличаются от размеров самого видеоряда. Как в итоге определил, это вызывало проблемы с позиционированием субтитров на экране(используя \pos в ass). До того как «прозрел», постоянно матерился сквозь зубы на фансаберов за коряво составленные сабы. И ничего не оставалось, как сидеть и переправлять координаты 8) Последней каплей стало «Nodame Cantbile», в котором количество «ляпов» просто зашкаливало... просмотрев сериал, и подправив координаты всеравно оставались огрехи и корявое позиционирование. Но вчера подвернулась машина с вендой, где была установлена рендерилка DirectVobSub... в общем, счастливы те, кто живет в неведении :) Начал ковыряться в исходниках mplayer'а, и чего только там не накуралесил с коррекцией аспекта, чтобы сабы созданные для 640x480 корректно ложились на видеоряд в 1280х720 или еще куда. В итоге оказалось все проще. В libass/ass_render.c в функции ass_start_frame есть строчки:
if (frame_context.orig_width * track->PlayResY == frame_context.orig_height * track->PlayResX)
frame_context.font_scale_x = 1.;
else
frame_context.font_scale_x = ((double)(frame_context.orig_width * track->PlayResY)) / (frame_context.orig_height * track->PlayResX);
frame_context.font_scale_x = 1.;
добился желаемого результата :) Для сравнения привожу скрины «до» и «после»(хотя тут не самые кошмарные ситуации):
до: http://s59.radikal.ru/i164/0902/4d/7d669ea37465.jpg
после: http://i056.radikal.ru/0902/87/790cc4e27dcd.jpg
до: http://s59.radikal.ru/i165/0902/68/3b562add6367.jpg
после: http://s41.radikal.ru/i093/0902/fd/d38ef1201180.jpg
Сейчас у меня нет постоянного выхода в сеть, да и с разговорным английским не так все гладко. Может ли кто в багзиллу mplayer'а запостить?
ЗЫ: эх... теперь надо бы перебрать свои DVD, и глянуть где вернуть сабы в обратное состояние... ЗЫЫ: кстати, таже трабла и в AegiSub
ЗЫ: в рубли/доллары переводить лень, цены назвал так - чисто для показа процентного соотношения.
Есть у кого "петсы", и с какими оригинальными случаями/поведением? :)
| ← назад | следующие → |
