openezx

Пока я чесал пятки с 2.6.30, в 2.6.32-rc1 звук доломали окончательно. Мало того, что BP там нету вообще, так оно еще и виснет при попытке что-то проиграть. Сейчас будет бессмысленный и беспощадный git bisect с Jun 17 по Oct 10, чтобы найти, когда оно поломалось.

Сложный результат интерференции нескольких багов

Когда телефон лежит в кармане, а я с него слушаю музыку - он моргает подсветкой при смене треков в плеере. Во-первых, мне это не нравится, во-вторый - это совершенно лишний раз жрет батарейку.

Первое и самое интересное - почему подсветка вообще дергается при смене трека? Потомучто есть такая штука, как power constraints, которая регулирует, насколько далеко устройству можно уходить в сберегающих режимах. Вполне естественно, что телефон не может играть музыку, когда он находится в слипе.

Исходя из этого здравого рассуждения, медиасервер запрещает уходить в слип, когда проигрывает что-то. Когда проигрываение останавливается, плеер снимает разрешение.

И тут закрадываются внеземная логика работников тролльтех: при смене power constraint, нужно включить подсветку. При чем это делает кто-то аж изнутри QtGui, а код там загадочен.

Делаю ход конем: режим меняется не тогда, когда меняется состояние плеера "играю-неиграю", а через две секунды. Проверяю: не работает. То есть работает, но подсветка все равно мигает на смене трека. Для проверки, убираю из медиасервера управление питанием - моргает. Магия... Стоп, магии же не бывает.

Смотрю код медиадвижка, благо багов там обычно есть: он питание вообще не трогает. Смотрю код плеера и вижу чудеса: плеер запрещает выключать подсветку, когда проигрывает видео. Это меня не касается - видео я не смотрю. Для проверки, убираю из плеера код управление питанием - не моргает. Оппа, "связистор опять выловил что-то за хвост из болота", как сказал тридемоделятор azcapone.

Судя по коду, в плеере есть некий "медиавиджет", который создается при наличии видео. Если виджет есть - питание трогаем, если нету - не трогаем. Но виджета же нету, почему тогда мограет? Нахожу замечательный факт:

notifier = new QMediaControlNotifier( QMediaVideoControl::name(), this );

connect( notifier, SIGNAL(valid()), this, SLOT(activateVideo()) );
connect( notifier, SIGNAL(invalid()), this, SLOT(deactivateVideo()) );

при чем в deactivateVideo() дергается управление питанием без проверки виджета.

Опять патч в одну строку, а началось все с того, что я хотел замерить, сколько телефон живет от одного заряда батареи.

Закрытый флип и входящий вызов

Сделал небольшой хак для входящего вызова. Кроме поднятия частоты процессора, во время входящего вызова, теперь прячется виджет флипа и можно увидеть, кто звонит.

Включено в автобилд 200903171449.

В автобилде 200903171534 включены конфиги из прошивки tmp_do и немного поломан виджет набора номера: картинки остались старые, а масштаб новый.

Убил очередного таракана в движке звука

Убил того, который валил медиасервер при проигрывании мелодии вызова и будильника.

Конечно же работа с памятью - после удаление объекта к нему успевало произойти обращение. Еще и потоки. Продолжаю ненавидеть этот объектно-ориентированый ассемблер.

Если на билдхосте опять ничего не сломается - забирайте автобилд с номером 200903060113.

Остается разобраться с еще одним тараканом в gsm и будет красота.

Нездоровые фокусы с дескрипторами в gprsv

Есть у нас такой баг с gprs: если его включить, закрыть настройки и попробовать выключить - он не выключается.

Чтобы понять, откуда она берется и как ее чинить, нужно знать, как работает включение/выключение gprs на наших телефонах.

На обычной хосте с линуксом gprs работает так же, как и другие ppp соединения: pppd открывает линию, шлет в нее AT-команды дозвона, после чего через эту же линию гоняет ppp трафик в обе стороны. Тут следует заметить две вещи: pppd именно читает и пишет в эту линию все передаваемые данные, а под линией может подразумеваться все что угодно от банального ttyS0, напрямую подключенного к другой машине, до программы в пайпе, гоняющей трафик через xmpp.

На ezx все не так. Для работы с gprs у нас есть как минимум два канала мультиплексора: для команд и для данных. Для начала, мы открываем управляющий канал и пишем в него волшебные AT-команды, а потом сразу читаем оттуда свой ip и dns адреса провайдера, при чем в человекочитаемом виде, а не куском ppp-трафика. Потом мы открываем канал данных и устанавливаем ему line displine N_GPRS и ассоциируем его с сетевым интерфейсом gprsv0. Потом используем полученный в первом пункте адрес и настраиваем сетевой интерфейс, пишем dns в resolv.conf.

А где ppp трафик? Нету. Весь на BP остался.

Чтобы выключить gprs - просто закрываем канал с данными.

Все эти фокусы отрабатывают в qpe, но управляются из netsetup (Settings -> Internet). Раньше баг состоял в том, что дескриптор канала данных был полем класса, объект которого управлял ppp соединениями и жил в qpe. Проблема была в том, что объект существовал только во время работаы netsetup, хотя и находился в пространстве qpe. При этом сам файловый дескриптор никуда не пропадал, но его номер терялся и закрыть его было нельзя. Сейчас все наоборот: gprsv - глобальная переменная и никакие объекты ее не теряют, но после закрытия дескриптора в qpe, он продолжает оставаться открытым в новом процессе netsetup. После закрытия netsetup все приходит в норму.

Тут непонятен один момент: почему после запуска netsetup у него остаются все дескрипторы qpe.