А я не говорю, что вы должны мониторить себя ежесекундно во время чтения.
Достаточно мысленно опросить организм во время неизбежных перерывов: на туалет, на «заварить чайку» и т.п.
Даже позы вы как правило меняете не в моменты прочтения захватывающих событий, а между ними — в эти моменты тоже можно тормознуть на секунду и прислушаться к ощущениям. Хотя и не обязательно — других перерывов как правило достаточно.
В любом случае это ваш организм, ваше зрение, ваше здоровье. Филонить или нет — решать каждому за себя. Сам я тоже не святоша в этом плане )))
Ну вот собственно вы в своей статье по ссылке как раз указываете зависимость удобства к весу девайса и позе.
Даже когда вы сидите и держите относительно тяжелый девайс в руках — из-за его веса вы напрягаете мышцы рук и мышцы рядом с верхней частью позвоночника, чтобы зафиксировать осанку. Вместе с этим напрягаются мышцы шеи, ограничивая кровоток к голове. В результате и глаза устают быстрее, кроме того вы их дополнительно как бы «травите» недостатком давления крови, кислорода и других веществ. Даже мышцы глаз(фокусировка и отклонение) начинают терять в скорости реакции и отработки «маневров». Кратковременные такие помехи зрению не повредят, но если зачитываться интересными книжками по нескольку часов — оно неизбежно скажется в итоге и на зрении. У кого-то быстрее, у кого-то медленнее, тут все индивидуально и тоже зависит от множества факторов. К примеру у людей, занимающихся спортом, как правило гораздо меньшая предрасположенность к такой потере зрения.
При условии нормальной позы и комфортной картинки — исключительно ваше самочувствие является индикатором. Вы сами в состоянии следить за усталостью глаз. Их усталость — есть главный индикатор, не зависимо от количества «нехороших» факторов.
Главное ложно не убеждать себя, что все нормально, если книжка интересная ))))
В статье довольно грубая ошибка. Зрение садится от факторов усталости глаз, а не яркости.
К пониженной, но относительно комфортной яркости глаза адаптируются сами. Гораздо более влияющий фактор на зрение — это неудобная поза. Точнее — ограничения кровотока к голове(к глазам в частности), нарушения кровообращения.
Рекомендации к расстоянию до текста в первую очередь несут попытки отрегулировать нарастание усталости глазных мышц. То есть на зрение это влияет косвенно, а не непосредственно.
Другой фактор — блики и тряска. Это заставляет глаза напрягаться и непрерывно ловить картинку. При чем если в транспорте книжка в ваших руках, ловить картинку гораздо проще, чем в чужих. Кстати о транспорте. Неравномерность освещения(постоянно изменяющуюся яркость) можно отнести к той же категории, что и блики — и то и другое заставляет глаза непрерывно подстраиваться под уровень освещения.
В общем я о чем: вреден не столько сам факт чтения при неподходящих условиях, сколько отношение «тяжести» этих условий к продолжительности чтения в них. Иначе говоря, даже при идеальных условиях полсуток-сутки почти непрерывного чтения будут вредны для зрения. При плохих условиях лучше себя ограничивать принудительно.
)))
да я не об этом.
про буффер BIOS кстати было интересно.
все-же подозреваю, что и это зависит от конкретного BIOS'а и даже не только от производителя, но возможно и от конкретной прошивки(если аппаратно есть куда увеличить буффер).
Что и требовалось доказать.
По-прежнему ни одного намека на аппаратные ограничения интерфейса PS/2.
Либо контроллер клавы, либо хост, как вы сейчас написали.
>> PS/2 обрабатывает не более 4-х нажатых клавиш одновременно (аппаратное ограничение)
С чего вы взяли? Пруф есть? Я не исключаю такой вероятности, но чесгря впервые слышу о таком аппаратном ограничении именно интерфейса PS/2. PS/2 протокол похож на MIDI — он тупо передает хосту события нажатий, отпусканий и повторов удерживаемых клавиш(с событиями мыши в общем-то та же фигня). Не вижу ни одной причины ограничивать количество одновременно нажатых. Так что если таковое и имеется, то это косяки контроллера клавиатуры с наибольшей вероятностью(с наименьшей — косяки драйвера со стороны хоста). То есть тупо сэкономил производитель клавы.
В протоколе есть два узких места:
1. мало кто реализует покторные запрос/отправку данных при ошибках в канале(чтобы исключить зацикливание мусора). Из-за этого некоторые события могут теряться.
2. Клавиши-модификаторы не генерируют повторы нажатий. Только нажатие/отпускание. В результате чего при потере события нажатия оно не восстановимо, как у обычной алфавитно-цифровой клавиши.
>> Вычисленный вами блок это и есть зависимость матрицы клавиатуры.
своими словами "(особенности внутренней кухни клавиатур)" я не стал лезть в дебри.
а вы меня неявно нубом обозвали )))))
Хм…
Кстати, во многих клавиатурах их собственный чип не обрабатывает более какого-то количества одновременных нажатий. Возможно у вас и там и там подобные. В смысле я ваш глюк встречал раньше и сам.
Попытайтесь повторить этот глюк, попробовав переключить раскладку в то время, когда нажата любая алфавитно-цифровая клавиша, либо две таких клавиши. При чем сначала попробуйте клавиши рядом, например Z и X, а потом разнесенные, типа Z и U.
Не смотря на то что контроллер так или иначе должен такие нажатия отработать последовательно, некоторые контроллеры бывает «залипают» в таких ситуациях.
Ну соответственно и глюк проявляется из-за этого только во время быстрого набора текста(нажал следующую клавишу, а предыдущую еще не отпустил). При чем не во всеми произвольно выбранными клавишами срабатывает. У контроллера как правило кнопки поделены группами(особенности внутренней кухни клавиатур), каждая группа опрашивается «своими» ногами контроллера.
Часто по 9 клавиш в группе. Например квадратный блок кнопок QWEASDZXC вполне может быть такой группой. В таком случае контроллер может «терять» одновременные нажатия в пределах одной группы, но свободно всегда обрабатывать нажатия между разными группами.
В любом случае я вас понимаю. Такие глюки бесят, это да…
В вашем случае к сожалению затруднительно даже назвать виновных. Именно потому, что событие клавы не доставляется вообще.
Это может быть Майкрософт, это может быть производитель клавиатуры, это может быть производитель чипсета или драйвера, обрабатывающих USB или PS/2 подключение клавиатуры. Чип самой клавиатуры, грязь на контактах, драйвер совершенно третьей стороны, мешающий доставке событий клавиатуры, всякие программы типа пунтосвитчера(не обязательно он, любая программа, реализующая глобальный перехват клавиатуры на предмет своих глобальных хоткеев).
В маке с этим проще — событие хоткея доставляется, но позже, не вовремя. То есть глюк в самой операционке, а не в железе уже налицо.
Возможно и так. Но…
А вы только в своей программе это проверяли, или в системных событиях тоже?
Я не зря намекнул на асинхронность только при разноуровневых объектах. Внутри одной программы системе нет смысла диспетчеризировать сообщения непоследовательно. В разных потоках вы тоже не поймете что к чему, поскольку потоки и не должны быть синхронными при любом раскладе.
Однако, думаю в чем-то вы правы. Ок, может быть я поспешил с сообщениями. Проблема может быть не в самой системе сообщений, а только в некоторых нюансах. Возможно даже просто в архитектуре конкретного(маковского) GUI слоя.
Ща приведу пример(я правда не оратор, могу сумбурно описать, смешав людей с конями вместе, но надеюсь мою основную мысль вы поймете):
Вам знакома такая конструкция?: [delegate performSelectorOnMainThread:selector withObject:object waitUntilDone:YES];
Обращаю ваше внимание на waitUntilDone:YES.
В принципе такое дело есть везде, и в виндовз тоже.
Но! Когда читаешь документацию по WinAPI, в принципе понимаешь что система внутри построена совсем не на объектах — там сплошные функции и структуры, что в общем-то и правильно — ООП в общем представлении как таковое есть удобство для программиста, но для системы совершенно пофиг — все-равно поднаготная ничем не отличается от обычных функций со структурами, кроме большего жора памяти на объектную обвязку и более длинных цепочек вызовов. И даже для программиста при вроде бы большей простоте написания кода объекты могут затруднять «визуальную» отладку(без спецсредств) из-за большего «наслоения» этого самого кода.
Как все построено в маке, я к сожалению еще не очень хорошо понимаю, не профи я, только начинаю учить )
Однако я довольно внимательно изучал историю развития Apple, и хорошо помню, что текущие макоси построены на наработках NeXT, а об этой конторе во всех историях описывается, как сильно они(Стив и Ko) загонялись на объектной ориентированности всей системы. Что по сути в общем-то замечательно, но зная увлеченность этих людей идеей(да что уж там, зная себя в моменты увлеченности )))), можно предположить, что они могли местами и переборщить.
Так вот, вернемся к waitUntilDone:YES. По сути это не что иное, как обмен информацией между разными потоками(или «нитями»), и конкретно waitUntilDone:YES рулит синхронностью/асинхронностью вызова. И если предположить, что сканкоды клавиатуры от драйвера входят в обработчик GUI, который отправляет обычные нажатия в один поток(объект?), но просекая «горячую клавишу», отправляет ее обработку в другой поток(объект?), установив waitUntilDone:NO, вполне может получиться такая хрень, что она будет обрабатываться дольше, чем предполагается. В результате имеем ситуацию, при которой в момент переключения языка ГУЯми чудесным образом уже успели проскочить в конечную программу и обработаться еще несколько нажатий «обычных» кнопок.
Как-то так. Я по-прежнему ничего не утверждаю. Я не знаю наверняка. Просто теоретизирую.
Я делал серверные демоны, эмулирующие многопоточность, работая фактически в одном потоке. И много раз видел, как ответы на комманды приходят асинхронно совершенно не в той последовательности, в которой отправлялись. Именно из-за разного количества времени, потраченного на их обработку. Вот только в моем случае это не могло породить никаких глюков — в этой асинхронности и была цель той системы. А здесь(в МакОСи) могли просто что-то не продумать в архитектуре.
Какая мышь-то у вас? У меня Logitech VX Nano, радиомышь не блютуз.
Я не утверждаю, что эффекта «кисельной мыши» не существует в принципе.
Более того, я даже практически уверен в том, что это вполне вероятно, и даже имею гипотезу на этот счет(ясен пень я не уверен в ее абсолютной правдивости).
Мне кажется, что проблемы не в драйверах, и вообще не в низкоуровневых слоях системы, а как раз таки на высоких уровнях близко к UI.
Как знают разработчики под Apple, в документации к Objective-C очень настаивается, что информация между объектами передается не с помощью методов, а сообщениями. При чем при вроде бы общей их похожести разница есть не только в синтаксисе, но и во внутренней кухне. Я сильно подозреваю, что одно из основных отличий сообщений от методов — асинхронность доставки(если объекты лежат не на одном уровне/слое). Что в принципе может объяснить оба обсуждаемых нами глюка — и непоследовательность обработки разноуровневых сообщений клавиатуры, и задержки в обработке «мышиных» движений.
Или, что еще более вероятно, проблема скорее всего составная, то есть описанная мною гипотеза — не единственная причина всех этих «странностей», а только часть более комплексной причины.
Точно те же причины могут быть у пользователя diamant в комменте чуть выше с браузером Firefox. Только тут уже не система, а сам браузер может как-то по особенному работать с мышью: стекировать внутри себя ее события, чрезмерно следить за движениями и обрабатывать их с повышенным «вниманием»(например пытаться непрерывно ловить «жесты»), ну и т.п. Я думаю, есть смысл открыть параллельно с Firefox еще и менеджер задач и последить за тем, как он жрет процессор, активно двигая мышью в это время над активным окном Firefox. Если он слишком неоптимизированно следит за мышью — будет видно сразу — процент загрузки проца будет сремиться вверх.
И еще вспомнил одну изредка проскакивающую странность. Жесты трекпада. При «подзагруженной» системе иногда бывает, что перестает обрабатываться какой-нибудь один жест. Или два.
Например тремя пальцами влево/вправо работает переход между пространствами(экранами), а те же три пальца вверх для вызова Mission Control — не работают. При этом Mission Control без проблем вызывается «горячей клавишей» либо «замапленной» кнопкой мыши. И переход между экранами «хоткеями» работает. Что интересно, данный глюк не зависит от количества пальцев. Может не работать один из трехпальцевых жестов, либо например прокрутка двумя пальцами не пашет, а трехпальцевые жесты все работают, и прокрутка колесом мыши тоже ОК.
Обычно это ненадолго, на полминуты-минуту, потом все восстанавливается как ни в чем не бывало.
Чесгря «мышь как в киселе» я замечал только на блютузных мышах(не только в маке, под виндой тоже), либо когда игрался в винде под параллелсами(там-то понятно что лаги от виртуалки).
В случае с блютузом решается многими способами, в зависимости от причины — вайфай на другие каналы перевесить чтоб не мешал, дрова поменять если есть альтернативы, и т.п. ну и радикальный вариант сменить мышь на неблютузную.
В маке больше иногда подбешивает другой лаг с клавиатурой: когда машина чем-то фоновым загружена, например перепаковкой видео, часто наблюдается такой интересный эффект: печатаешь например новый коммент на хабре, тыкаешь мышью в поле ввода, жмакаешь Cmd+пробел для переключения на русский, и сходу начинаешь писать текст. В результате потом видишь текст, в котором первые несколько символов(7-15) на англицкой раскладке, остальное на русском.
Такое ощущение, что комбинация Cmd+пробел при наборе падает не в тот же стек, что остальные одиночные нажатия клавиш, либо обрабатывается системой асинхронно, в результате чего срабатывает с запозданием. В винде такого не наблюдал ни разу.
Но это весьма нечастый эффект. На незагруженной машине не заметно. Однако на старом маке(late 2006) под леопардом было и без нагрузки одно время. После очередной заплатки там исчезло.
>> Стоп, а как же рекомендации производителей тех же сотовых с подобными аккумами произвести несколько циклов полной разрядки/заряди телефона?
На счет нескольких циклов, что-то не припомню таких инструкций, кроме как для устаревших никелевых аккумов.
А вот первичная зарядка на несколько часов — в принципе для лития не обязательна, но для «фирмового»(ноуты, сотовые) желательна. Это знаете, когда рекомендуют в первый раз поставить батареи на зарядку на 8 часов, не смотря на то, что через час-два зарядник уже загорится зеленым и на экране будет 100%.
Когда контроллер заряжает батарею полностью(4.2 вольта на каждой банке), обычно умные контроллеры не отрубают зарядку совсем полностью, а переходят в режим «поддерживающих токов»(этот термин может называться по-разному). То есть продолжает давать на банку мизерные токи, продолжая эту банку мониторить, чтоб не перезарядить.
Таким образом происходит первичная «раскачка» аккумуляторной химии и считается, что батарея после этого больше циклов отработает без существенных потерь емкости.
Ежемесячный полный цикл — это калибровка контроллера. Если его регулярно калибровать(но без фанатизма, раз в месяц достаточно), он лучше рассчитывает режимы зарядки/разрядки банок и точнее показывает вам на экране процент заряда и оставшееся время.
И для лития полный цикл не значит разряд до нуля. Ноль — это нижний порог разряда для лития, а не 0 вольт. То есть когда вам в айфоне показывает ноль — это значит на аккумуляторе текущее напряжение около трех вольт. Про это более можете найти мой комментарий ниже в этом же топике.
А для никелевых да — там до нуля вольт разряжается и циклы нужны, чтобы избавиться от «эффекта памяти».
То есть рекомендации вроде внешне и похожи(прогнать полный цикл), но относятся к совершенно разным сущностям.
Это если вы используете длинный шнур со стороны розетки.
А так у Эппла обе части шнура длинные, со стороны розетки шнур можно отстегнуть и непосредственно к блоку вместо него пристегнуть вилку, чтоб он прямо на розетке и висел.
Плюс часть шнура от блока к ноуту очень удобно наматывается на сам блок в «походном» положении, да и магнитный MagSafe коннектор к ноуту — удобнейшая штука. Правда с последним другие производители к сожалению не могут повторить — запатентован он и блюдется Эпплом сильно.
Я об обычных аккумуляторах, не тесловских и даже не ноутбучных многобаночных )
Которые например в фонариках используются. Сорри, что не указал, чтоб без фанатизма.
Не передергивайте, если переразрядившаяся банка жива, ничего она не напартачит. Тем более вы не КЗ делаете, и даже напряжение в данной цепи будет только разностью, а не полным. Банки будут стремиться уравняться.
Если есть подозрения, либо это полимерка с высокой токоотдачей и т.п. — там конечно лучше перестраховываться резисторами.
А остальные простые литий-ионные имеют собственное токоограничение — большинство китая вообще не способно больше полутора ампер выдать, даже без контроллера, у брендовых контроллер ограничит токи сам.
По-хорошему конечно вы правы — можно просчитать максимальный выходной ток и сравнить с емкостью банок. Если даем ток заряда до 2C, то при кратковременной подаче ничего с ней не случится.
А так-то конечно, трехамперчасной 18650 AW с пятиамперным выходом я бы не рискнул пытаться поднимать какую-нибудь мелкую 10180 на 90 mAh емкости. Ее ж разорвать может )))
Нюансов слишком много к сожалению, их все коротко не опишешь.
Собственно это и доказывает мою правоту в поддержке производителей и отрубания контроллеров при переразрядах. Проще отрубить батарею и заставить пользователя обратиться в сервис, чем писать многотомный талмуд с подробнейшими инструкциями и прописывать везде границы ответственности и т.п.
То есть по сути обсуждать здесь отказ контроллера — не очень логично. Более логично обсуждать политику компании Тесла и цену в 40 тонн зелени за обращение в сервис. Впрочем, возможно в эти «сорок тонн» заложена цена новой батареи на замену… я по ссылкам не ходил и вопрос глубоко не изучал — потому не знаю.
Проблема не в питании контроллера. У контроллера может быть даже своя Backup Battery. Проблема в том, что разряд аккумулятора ниже определенного предела считается нештатной ситуацией, опасной для последующей зарядки с некоторой вероятностью. Речь ведь о литии, а не о свинцовых аккумуляторах, как в обычных автомобилях.
Поэтому при такой ситуации у контроллера четкая задача: блокировка как минимум до сервиса, как максимум — до замены. Все логично.
>> А вот чтоб сами внутрь не лазили и не чинили акумы.
Вы углядели в этом что-то неправильное?
Будь вы производителем, вы бы конечно не блокировали возможности самопального ремонта, да? И вероятно отвечали бы за все случаи взрыва батарей например?
>> Банка умерла — покупай новый аккумулятор от производителя
что мешает купить новый не от производителя, а на прядок дешевле аналог от более-менее зарекомендовавшего себя бренда(пусть даже китайского)?
У лития считается полный разряд около 0.75-0.85 номинала на каждую банку. Число плавающее, т.к. разные производители разные уровни отсечки выставляют.
В общем при разрядах ниже этого предела считается, что литиевая банка начинает деградировать либо ей уже пипец. Это с точки зрения контроллера — они так программируются.
Таким образом имеем, что для литиевых банок номиналом 3.7 вольта показываемый вам в интерфейсе гаджета/ноута уровень заряда соответствует нулю при фактическом напряжении банки 2.7-3.1 вольта(зависит от производителя), и соответствует 100% заряда при напряжении на банке 4.2 вольта.
Одна из задач защитных контроллеров батарей — отрубить банку нафиг в случае такого разряда, т.к. при попытке ее заряда повышается вероятность нестандартного поведения включая перегрев и бигбарабум. Кроме того, напряжение на банке ниже предела для контроллера может означать не только ее переразряд, но и физическое повреждение, что делает процесс заряда просевших банок еще более опасным.
Так что описанное вами поведение самсунговских батарей — вовсе не брак и не глюк — а самое что ни на есть штатное поведение.
Ровно такое же поведение вы можете обнаружить у обычных зарядников для литиевых батарей. При напряжении банки ниже вышеописанных пределов большинство зарядников с хоть какими-то «мозгами» просто откажутся ее заряжать.
Однако во многих случаях удается реанимировать банку даже при глубоком разряде. После чего в общем-то не редкий случай, что банка теряет немного в емкости, но тем не менее отрабатывает еще немалое количество циклов с нормальными токами.
Лечится такое дело как правило просто — берем два проводка/скрепки/ножа с кухни, и подключаем эту просевшую банку к такой же, но заряженной параллельно. Если просевшая банка у вас еще не совсем в нуле, как правило достаточно буквально несколько секунд(2-10), чтобы заряженная банка подняла напряжение просешей выше предела отсечки зарядника. После чего вставляем псевдодохлую банку в зарядник и вуаля. Заряд пошел.
Вот вам и описание того, почему ваш контроллер отрубил батарею, и что ваши удачные действия по реанимации в общем-то ничьей вины не доказывают. Кроме того, не забывайте, что у ноутбуков обычно(да практически всегда) батареи многобаночные, и контроллер может отрубить всю батарею, даже если просела ниже предела всего одна банка.
Достаточно мысленно опросить организм во время неизбежных перерывов: на туалет, на «заварить чайку» и т.п.
Даже позы вы как правило меняете не в моменты прочтения захватывающих событий, а между ними — в эти моменты тоже можно тормознуть на секунду и прислушаться к ощущениям. Хотя и не обязательно — других перерывов как правило достаточно.
В любом случае это ваш организм, ваше зрение, ваше здоровье. Филонить или нет — решать каждому за себя. Сам я тоже не святоша в этом плане )))
Даже когда вы сидите и держите относительно тяжелый девайс в руках — из-за его веса вы напрягаете мышцы рук и мышцы рядом с верхней частью позвоночника, чтобы зафиксировать осанку. Вместе с этим напрягаются мышцы шеи, ограничивая кровоток к голове. В результате и глаза устают быстрее, кроме того вы их дополнительно как бы «травите» недостатком давления крови, кислорода и других веществ. Даже мышцы глаз(фокусировка и отклонение) начинают терять в скорости реакции и отработки «маневров». Кратковременные такие помехи зрению не повредят, но если зачитываться интересными книжками по нескольку часов — оно неизбежно скажется в итоге и на зрении. У кого-то быстрее, у кого-то медленнее, тут все индивидуально и тоже зависит от множества факторов. К примеру у людей, занимающихся спортом, как правило гораздо меньшая предрасположенность к такой потере зрения.
Главное ложно не убеждать себя, что все нормально, если книжка интересная ))))
К пониженной, но относительно комфортной яркости глаза адаптируются сами. Гораздо более влияющий фактор на зрение — это неудобная поза. Точнее — ограничения кровотока к голове(к глазам в частности), нарушения кровообращения.
Рекомендации к расстоянию до текста в первую очередь несут попытки отрегулировать нарастание усталости глазных мышц. То есть на зрение это влияет косвенно, а не непосредственно.
Другой фактор — блики и тряска. Это заставляет глаза напрягаться и непрерывно ловить картинку. При чем если в транспорте книжка в ваших руках, ловить картинку гораздо проще, чем в чужих. Кстати о транспорте. Неравномерность освещения(постоянно изменяющуюся яркость) можно отнести к той же категории, что и блики — и то и другое заставляет глаза непрерывно подстраиваться под уровень освещения.
В общем я о чем: вреден не столько сам факт чтения при неподходящих условиях, сколько отношение «тяжести» этих условий к продолжительности чтения в них. Иначе говоря, даже при идеальных условиях полсуток-сутки почти непрерывного чтения будут вредны для зрения. При плохих условиях лучше себя ограничивать принудительно.
да я не об этом.
про буффер BIOS кстати было интересно.
все-же подозреваю, что и это зависит от конкретного BIOS'а и даже не только от производителя, но возможно и от конкретной прошивки(если аппаратно есть куда увеличить буффер).
По-прежнему ни одного намека на аппаратные ограничения интерфейса PS/2.
Либо контроллер клавы, либо хост, как вы сейчас написали.
С чего вы взяли? Пруф есть? Я не исключаю такой вероятности, но чесгря впервые слышу о таком аппаратном ограничении именно интерфейса PS/2. PS/2 протокол похож на MIDI — он тупо передает хосту события нажатий, отпусканий и повторов удерживаемых клавиш(с событиями мыши в общем-то та же фигня). Не вижу ни одной причины ограничивать количество одновременно нажатых. Так что если таковое и имеется, то это косяки контроллера клавиатуры с наибольшей вероятностью(с наименьшей — косяки драйвера со стороны хоста). То есть тупо сэкономил производитель клавы.
В протоколе есть два узких места:
1. мало кто реализует покторные запрос/отправку данных при ошибках в канале(чтобы исключить зацикливание мусора). Из-за этого некоторые события могут теряться.
2. Клавиши-модификаторы не генерируют повторы нажатий. Только нажатие/отпускание. В результате чего при потере события нажатия оно не восстановимо, как у обычной алфавитно-цифровой клавиши.
>> Вычисленный вами блок это и есть зависимость матрицы клавиатуры.
своими словами "(особенности внутренней кухни клавиатур)" я не стал лезть в дебри.
а вы меня неявно нубом обозвали )))))
Кстати, во многих клавиатурах их собственный чип не обрабатывает более какого-то количества одновременных нажатий. Возможно у вас и там и там подобные. В смысле я ваш глюк встречал раньше и сам.
Попытайтесь повторить этот глюк, попробовав переключить раскладку в то время, когда нажата любая алфавитно-цифровая клавиша, либо две таких клавиши. При чем сначала попробуйте клавиши рядом, например Z и X, а потом разнесенные, типа Z и U.
Не смотря на то что контроллер так или иначе должен такие нажатия отработать последовательно, некоторые контроллеры бывает «залипают» в таких ситуациях.
Ну соответственно и глюк проявляется из-за этого только во время быстрого набора текста(нажал следующую клавишу, а предыдущую еще не отпустил). При чем не во всеми произвольно выбранными клавишами срабатывает. У контроллера как правило кнопки поделены группами(особенности внутренней кухни клавиатур), каждая группа опрашивается «своими» ногами контроллера.
Часто по 9 клавиш в группе. Например квадратный блок кнопок QWEASDZXC вполне может быть такой группой. В таком случае контроллер может «терять» одновременные нажатия в пределах одной группы, но свободно всегда обрабатывать нажатия между разными группами.
В любом случае я вас понимаю. Такие глюки бесят, это да…
Это может быть Майкрософт, это может быть производитель клавиатуры, это может быть производитель чипсета или драйвера, обрабатывающих USB или PS/2 подключение клавиатуры. Чип самой клавиатуры, грязь на контактах, драйвер совершенно третьей стороны, мешающий доставке событий клавиатуры, всякие программы типа пунтосвитчера(не обязательно он, любая программа, реализующая глобальный перехват клавиатуры на предмет своих глобальных хоткеев).
В маке с этим проще — событие хоткея доставляется, но позже, не вовремя. То есть глюк в самой операционке, а не в железе уже налицо.
Понимаю, бесят оба глюка, но тем не менее разница между ними принципиальна.
А вы только в своей программе это проверяли, или в системных событиях тоже?
Я не зря намекнул на асинхронность только при разноуровневых объектах. Внутри одной программы системе нет смысла диспетчеризировать сообщения непоследовательно. В разных потоках вы тоже не поймете что к чему, поскольку потоки и не должны быть синхронными при любом раскладе.
Однако, думаю в чем-то вы правы. Ок, может быть я поспешил с сообщениями. Проблема может быть не в самой системе сообщений, а только в некоторых нюансах. Возможно даже просто в архитектуре конкретного(маковского) GUI слоя.
Ща приведу пример(я правда не оратор, могу сумбурно описать, смешав людей с конями вместе, но надеюсь мою основную мысль вы поймете):
Вам знакома такая конструкция?:
[delegate performSelectorOnMainThread:selector withObject:object waitUntilDone:YES];Обращаю ваше внимание на waitUntilDone:YES.
В принципе такое дело есть везде, и в виндовз тоже.
Но! Когда читаешь документацию по WinAPI, в принципе понимаешь что система внутри построена совсем не на объектах — там сплошные функции и структуры, что в общем-то и правильно — ООП в общем представлении как таковое есть удобство для программиста, но для системы совершенно пофиг — все-равно поднаготная ничем не отличается от обычных функций со структурами, кроме большего жора памяти на объектную обвязку и более длинных цепочек вызовов. И даже для программиста при вроде бы большей простоте написания кода объекты могут затруднять «визуальную» отладку(без спецсредств) из-за большего «наслоения» этого самого кода.
Как все построено в маке, я к сожалению еще не очень хорошо понимаю, не профи я, только начинаю учить )
Однако я довольно внимательно изучал историю развития Apple, и хорошо помню, что текущие макоси построены на наработках NeXT, а об этой конторе во всех историях описывается, как сильно они(Стив и Ko) загонялись на объектной ориентированности всей системы. Что по сути в общем-то замечательно, но зная увлеченность этих людей идеей(да что уж там, зная себя в моменты увлеченности )))), можно предположить, что они могли местами и переборщить.
Так вот, вернемся к waitUntilDone:YES. По сути это не что иное, как обмен информацией между разными потоками(или «нитями»), и конкретно waitUntilDone:YES рулит синхронностью/асинхронностью вызова. И если предположить, что сканкоды клавиатуры от драйвера входят в обработчик GUI, который отправляет обычные нажатия в один поток(объект?), но просекая «горячую клавишу», отправляет ее обработку в другой поток(объект?), установив waitUntilDone:NO, вполне может получиться такая хрень, что она будет обрабатываться дольше, чем предполагается. В результате имеем ситуацию, при которой в момент переключения языка ГУЯми чудесным образом уже успели проскочить в конечную программу и обработаться еще несколько нажатий «обычных» кнопок.
Как-то так. Я по-прежнему ничего не утверждаю. Я не знаю наверняка. Просто теоретизирую.
Я делал серверные демоны, эмулирующие многопоточность, работая фактически в одном потоке. И много раз видел, как ответы на комманды приходят асинхронно совершенно не в той последовательности, в которой отправлялись. Именно из-за разного количества времени, потраченного на их обработку. Вот только в моем случае это не могло породить никаких глюков — в этой асинхронности и была цель той системы. А здесь(в МакОСи) могли просто что-то не продумать в архитектуре.
Я не утверждаю, что эффекта «кисельной мыши» не существует в принципе.
Более того, я даже практически уверен в том, что это вполне вероятно, и даже имею гипотезу на этот счет(ясен пень я не уверен в ее абсолютной правдивости).
Мне кажется, что проблемы не в драйверах, и вообще не в низкоуровневых слоях системы, а как раз таки на высоких уровнях близко к UI.
Как знают разработчики под Apple, в документации к Objective-C очень настаивается, что информация между объектами передается не с помощью методов, а сообщениями. При чем при вроде бы общей их похожести разница есть не только в синтаксисе, но и во внутренней кухне. Я сильно подозреваю, что одно из основных отличий сообщений от методов — асинхронность доставки(если объекты лежат не на одном уровне/слое). Что в принципе может объяснить оба обсуждаемых нами глюка — и непоследовательность обработки разноуровневых сообщений клавиатуры, и задержки в обработке «мышиных» движений.
Или, что еще более вероятно, проблема скорее всего составная, то есть описанная мною гипотеза — не единственная причина всех этих «странностей», а только часть более комплексной причины.
Точно те же причины могут быть у пользователя diamant в комменте чуть выше с браузером Firefox. Только тут уже не система, а сам браузер может как-то по особенному работать с мышью: стекировать внутри себя ее события, чрезмерно следить за движениями и обрабатывать их с повышенным «вниманием»(например пытаться непрерывно ловить «жесты»), ну и т.п. Я думаю, есть смысл открыть параллельно с Firefox еще и менеджер задач и последить за тем, как он жрет процессор, активно двигая мышью в это время над активным окном Firefox. Если он слишком неоптимизированно следит за мышью — будет видно сразу — процент загрузки проца будет сремиться вверх.
И еще вспомнил одну изредка проскакивающую странность. Жесты трекпада. При «подзагруженной» системе иногда бывает, что перестает обрабатываться какой-нибудь один жест. Или два.
Например тремя пальцами влево/вправо работает переход между пространствами(экранами), а те же три пальца вверх для вызова Mission Control — не работают. При этом Mission Control без проблем вызывается «горячей клавишей» либо «замапленной» кнопкой мыши. И переход между экранами «хоткеями» работает. Что интересно, данный глюк не зависит от количества пальцев. Может не работать один из трехпальцевых жестов, либо например прокрутка двумя пальцами не пашет, а трехпальцевые жесты все работают, и прокрутка колесом мыши тоже ОК.
Обычно это ненадолго, на полминуты-минуту, потом все восстанавливается как ни в чем не бывало.
В случае с блютузом решается многими способами, в зависимости от причины — вайфай на другие каналы перевесить чтоб не мешал, дрова поменять если есть альтернативы, и т.п. ну и радикальный вариант сменить мышь на неблютузную.
В маке больше иногда подбешивает другой лаг с клавиатурой: когда машина чем-то фоновым загружена, например перепаковкой видео, часто наблюдается такой интересный эффект: печатаешь например новый коммент на хабре, тыкаешь мышью в поле ввода, жмакаешь Cmd+пробел для переключения на русский, и сходу начинаешь писать текст. В результате потом видишь текст, в котором первые несколько символов(7-15) на англицкой раскладке, остальное на русском.
Такое ощущение, что комбинация Cmd+пробел при наборе падает не в тот же стек, что остальные одиночные нажатия клавиш, либо обрабатывается системой асинхронно, в результате чего срабатывает с запозданием. В винде такого не наблюдал ни разу.
Но это весьма нечастый эффект. На незагруженной машине не заметно. Однако на старом маке(late 2006) под леопардом было и без нагрузки одно время. После очередной заплатки там исчезло.
На счет нескольких циклов, что-то не припомню таких инструкций, кроме как для устаревших никелевых аккумов.
А вот первичная зарядка на несколько часов — в принципе для лития не обязательна, но для «фирмового»(ноуты, сотовые) желательна. Это знаете, когда рекомендуют в первый раз поставить батареи на зарядку на 8 часов, не смотря на то, что через час-два зарядник уже загорится зеленым и на экране будет 100%.
Когда контроллер заряжает батарею полностью(4.2 вольта на каждой банке), обычно умные контроллеры не отрубают зарядку совсем полностью, а переходят в режим «поддерживающих токов»(этот термин может называться по-разному). То есть продолжает давать на банку мизерные токи, продолжая эту банку мониторить, чтоб не перезарядить.
Таким образом происходит первичная «раскачка» аккумуляторной химии и считается, что батарея после этого больше циклов отработает без существенных потерь емкости.
И для лития полный цикл не значит разряд до нуля. Ноль — это нижний порог разряда для лития, а не 0 вольт. То есть когда вам в айфоне показывает ноль — это значит на аккумуляторе текущее напряжение около трех вольт. Про это более можете найти мой комментарий ниже в этом же топике.
А для никелевых да — там до нуля вольт разряжается и циклы нужны, чтобы избавиться от «эффекта памяти».
То есть рекомендации вроде внешне и похожи(прогнать полный цикл), но относятся к совершенно разным сущностям.
А так у Эппла обе части шнура длинные, со стороны розетки шнур можно отстегнуть и непосредственно к блоку вместо него пристегнуть вилку, чтоб он прямо на розетке и висел.
Плюс часть шнура от блока к ноуту очень удобно наматывается на сам блок в «походном» положении, да и магнитный MagSafe коннектор к ноуту — удобнейшая штука. Правда с последним другие производители к сожалению не могут повторить — запатентован он и блюдется Эпплом сильно.
Которые например в фонариках используются. Сорри, что не указал, чтоб без фанатизма.
Не передергивайте, если переразрядившаяся банка жива, ничего она не напартачит. Тем более вы не КЗ делаете, и даже напряжение в данной цепи будет только разностью, а не полным. Банки будут стремиться уравняться.
Если есть подозрения, либо это полимерка с высокой токоотдачей и т.п. — там конечно лучше перестраховываться резисторами.
А остальные простые литий-ионные имеют собственное токоограничение — большинство китая вообще не способно больше полутора ампер выдать, даже без контроллера, у брендовых контроллер ограничит токи сам.
По-хорошему конечно вы правы — можно просчитать максимальный выходной ток и сравнить с емкостью банок. Если даем ток заряда до 2C, то при кратковременной подаче ничего с ней не случится.
А так-то конечно, трехамперчасной 18650 AW с пятиамперным выходом я бы не рискнул пытаться поднимать какую-нибудь мелкую 10180 на 90 mAh емкости. Ее ж разорвать может )))
Нюансов слишком много к сожалению, их все коротко не опишешь.
Собственно это и доказывает мою правоту в поддержке производителей и отрубания контроллеров при переразрядах. Проще отрубить батарею и заставить пользователя обратиться в сервис, чем писать многотомный талмуд с подробнейшими инструкциями и прописывать везде границы ответственности и т.п.
То есть по сути обсуждать здесь отказ контроллера — не очень логично. Более логично обсуждать политику компании Тесла и цену в 40 тонн зелени за обращение в сервис. Впрочем, возможно в эти «сорок тонн» заложена цена новой батареи на замену… я по ссылкам не ходил и вопрос глубоко не изучал — потому не знаю.
Поэтому при такой ситуации у контроллера четкая задача: блокировка как минимум до сервиса, как максимум — до замены. Все логично.
Вы углядели в этом что-то неправильное?
Будь вы производителем, вы бы конечно не блокировали возможности самопального ремонта, да? И вероятно отвечали бы за все случаи взрыва батарей например?
>> Банка умерла — покупай новый аккумулятор от производителя
что мешает купить новый не от производителя, а на прядок дешевле аналог от более-менее зарекомендовавшего себя бренда(пусть даже китайского)?
В общем при разрядах ниже этого предела считается, что литиевая банка начинает деградировать либо ей уже пипец. Это с точки зрения контроллера — они так программируются.
Таким образом имеем, что для литиевых банок номиналом 3.7 вольта показываемый вам в интерфейсе гаджета/ноута уровень заряда соответствует нулю при фактическом напряжении банки 2.7-3.1 вольта(зависит от производителя), и соответствует 100% заряда при напряжении на банке 4.2 вольта.
Одна из задач защитных контроллеров батарей — отрубить банку нафиг в случае такого разряда, т.к. при попытке ее заряда повышается вероятность нестандартного поведения включая перегрев и бигбарабум. Кроме того, напряжение на банке ниже предела для контроллера может означать не только ее переразряд, но и физическое повреждение, что делает процесс заряда просевших банок еще более опасным.
Так что описанное вами поведение самсунговских батарей — вовсе не брак и не глюк — а самое что ни на есть штатное поведение.
Ровно такое же поведение вы можете обнаружить у обычных зарядников для литиевых батарей. При напряжении банки ниже вышеописанных пределов большинство зарядников с хоть какими-то «мозгами» просто откажутся ее заряжать.
Однако во многих случаях удается реанимировать банку даже при глубоком разряде. После чего в общем-то не редкий случай, что банка теряет немного в емкости, но тем не менее отрабатывает еще немалое количество циклов с нормальными токами.
Лечится такое дело как правило просто — берем два проводка/скрепки/ножа с кухни, и подключаем эту просевшую банку к такой же, но заряженной параллельно. Если просевшая банка у вас еще не совсем в нуле, как правило достаточно буквально несколько секунд(2-10), чтобы заряженная банка подняла напряжение просешей выше предела отсечки зарядника. После чего вставляем псевдодохлую банку в зарядник и вуаля. Заряд пошел.
Вот вам и описание того, почему ваш контроллер отрубил батарею, и что ваши удачные действия по реанимации в общем-то ничьей вины не доказывают. Кроме того, не забывайте, что у ноутбуков обычно(да практически всегда) батареи многобаночные, и контроллер может отрубить всю батарею, даже если просела ниже предела всего одна банка.