Про (не)лицензионные книги

>"Тебя посодют, а ты не воруй"

1) ПДФ-ка честно куплена

2) move != copy

ЗЫ А распечатывать лицензия позволяет? Дай студентам распечатки. Да и вообще пофиг на лицензии, у нас милиция выборочными продуктами интересуется. Есть список софта/контента который они ищут, на остальное внимания практически не обращают.

> А распечатывать лицензия позволяет?

В этом и вопрос.

> Да и вообще пофиг на лицензии, у нас милиция выборочными продуктами интересуется

Вопрос, безусловно, носит скорее теоретический характер.

Интересно, а есть ли у них право использовать слово UNIX, причем, без (R) ?

Да, книжка написана авторами юникса во времена работы в AT&T, а знак (r) -- вообще не обязательный, если есть сноска.

Я имею ввиду текст лицензии. Он к авторам книги не имеет ни какого отношения, мне так кааца.

> чес слово. с содержимым где-то на уровне 1го курса

Мечты, мечты... я про sudo apt-get update в пособии не написал, а в результате студенты копипастят дома из пособия команды apt-get install и жалуются, что не работает... а тут высокие споры о ELDD vs LDD(N) :(

Думаю, да, в силу ремарки № 2.

Читаю твой файлик...
Ну жди гостей в погонах :)

> http://www.intuit.ru/department/se/msfdev/

Курс создан при финансовой поддержке компании Microsoft Corp.

Сколько они вам заплатили?

> Сколько они вам заплатили?

Около 90тр чистыми на двоих в сумме, ЕМНИМ (2006-й год). В общем-то спорный (с точки зрения дохода) заработок. Это был открытый конкурс МС-грантов. Мероприятие было полезным. В ходе написания я и пристрастился к чтению лора, и у меня началось выздоровление от ФГМ.

"(с точки зрения *уровня* дохода)" в учёте на потраченное время.

> За отсутствием в продаже бумажного варианта

Что?!? Amazon закрыли?!? :-O

Подтверждаю - на doxygen не молятся, комментарии пишут паршиво (если пишут вообще), и вообще, полный разброд и шатание.

Боюсь, жесткой дисциплиной хороших разработчиков всё равно не выпестовать. Хорошие - они от природы хорошие, они сами всё поймут, а остальных учить смысла нет. Из остальных могут получиться паршивые разработчики и хорошие computer scientists (такого же, чтоб и хороший разработчик, и хороший ученый, со времён Дийкстры в природе ни разу не наблюдалось).

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

Может китайцы у кого-то в фантазиях говорят и даже пишут исключительно на английском но в реальности все с точностью до наоборот.
http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=writin...

> Из остальных могут получиться паршивые разработчики и хорошие computer scientists

Последнее --- не наш случай :(

> http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=writin.. .

из полусотни ссылок от силы десяток на CJK. это с учётом того, что одних только китайцев больше, чем белых вместе взятых а сравнивать уровень развития микроэлектроники в Китае/Тайване с РФ просто бессмысленно. не так уж и плохо.

// wbr

>из полусотни ссылок от силы десяток на CJK.

Приведи если не сложно хоть одну ссылку _по теме_ в запросе не на китайском или не куцый перевод с китайского. Просто для меня это сейчас актуально - буду очень признателен.

> Приведи если не сложно хоть одну ссылку _по теме_ в запросе не на китайском или не куцый перевод с китайского. Просто для меня это сейчас актуально - буду очень признателен.

по поводу "writting linux LCD drivers" ? а что конкретно под этим подразумевается? различных LCD контроллеров как грязи и подходы/интерфейсы могут быть самыми разными от VGA по отображения окна куда-нить на шину или общение командами через последовательный интерфейс.

// wbr

Интерфейс не важен - интересует именно написание framebuffer драйвера c виртуальным буфером в системной памяти, собственно на встраиваемых системах обычно его и реализуют, если так надо конкретики - то иннтерфейс spi.

В моем случае видеопамять есть на контроллере LCD но есть два момента - интерфейс у контроллера однонаправленный (3-wire и не SISO а просто на прием данных) и к тому же у него нестандартный режим RGB 12 бит, есть 8 бит - но на самом деле это тот же 12 бит только нужно задать карту отображения 8 бит на 12 бит, а 16 бит - соответственно тот же 12 бит только с потерей полутонов.

> В моем случае видеопамять есть на контроллере LCD но есть два момента - интерфейс у контроллера однонаправленный (3-wire и не SISO а просто на прием данных) и к тому же у него нестандартный режим RGB 12 бит, есть 8 бит - но на самом деле это тот же 12 бит только нужно задать карту отображения 8 бит на 12 бит, а 16 бит - соответственно тот же 12 бит только с потерей полутонов.

ну если я правильно понимаю, то вывод на дисплей осуществляется посредством интегрированного на нём контроллера, который по последовательному интерфейсу принимает определённый набор команд. дисплеи бывают разные, контроллеры и протоколы то-же, но в общем и целом идея более-менее стандартная.

правда, зачем тут framebuffer? в отличие от "обычной" видеокарты, которая предоставляет окно в физической памяти и к которому AFAIU лезет устройство посредством mmap на /dev/fbX, подобные железки оного по понятным причинам не предоставляют. нет, желание писать в "память" дисплея как обычной карточки вполне понятно, но в этом случае придётся фактически эмулировать видеопамять и как это сделать эффективно по крайней мере мне не совсем понятно.

помечать замапленные странички как отсутствующие и каждый раз ловить попытку записи и транслировать её в соотв. команды дисплея? боюсь, это будет жутко неэффективно.

// wbr

>правда, зачем тут framebuffer?

Это тот уровень абстракциии который позволяет использовать это утсройство как в консоли через fbcon так и и с графикой (любой тулкит с поддержкой fb да и тот же xorg - kdrive).

>помечать замапленные странички как отсутствующие и каждый раз ловить попытку записи и транслировать её в соотв. команды дисплея?

я сам не совсем понимаю как это делается - поэтому и ищу информацию, возможно можно будет отрисовывать весь экран через какие-то промежутки времени, например 10 раз в секунду ? Там разрешение небольшое и на 6 МГц spi clk теоретически за секунду можно не меньше 40 раз в секунду экран отрисовывать (разрешение 132х132@8) а если учесть что на контроллере с arm ядром spi аппапаратный с поддержкой дма то процессор вообще тут практически участвовать не будет.

> я сам не совсем понимаю как это делается - поэтому и ищу информацию, возможно можно будет отрисовывать весь экран через какие-то промежутки времени, например 10 раз в секунду ? Там разрешение небольшое и на 6 МГц spi clk теоретически за секунду можно не меньше 40 раз в секунду экран отрисовывать (разрешение 132х132@8) а если учесть что на контроллере с arm ядром spi аппапаратный с поддержкой дма то процессор вообще тут практически участвовать не будет.

drivers/video/skeletonfb.c

для начала там должно быть вполне достаточно информации. и далее по примерам.

// wbr

>drivers/video/skeletonfb.c

для начала там должно быть вполне достаточно информации. и далее по примерам.

Я собственно другого ответа и не надеялся получить. Была правда небольшая надежда :)

> тот же xorg - kdrive

Тот же kdrive наверняка имеет драйверный интерфейс, подходящий и для не-fb.

> Я собственно другого ответа и не надеялся получить. Была правда небольшая надежда :)

ну а какой собственно ещё ответ? AFAIU фактически нужно лишь эффективно реализовать imageblit. можно тупо оттранслировать в соотв. команды LCD контроллера. можно подумать о ручном кешировании грязных областей и их сбросе по таймеру или ещё как. в общем, в первую очередь зависит от конкретного протокола и что он позволяет делать.

// wbr

>Тот же kdrive наверняка имеет драйверный интерфейс, подходящий и для не-fb.

Мне кажется намного удобней иметь один драйвер уровня ядра для всего. Насколько мне известно обычно так и поступают, хотя если есть конкретные предложения - с радостью схожу по любезно предоставленным ссылкам :)

>в первую очередь зависит от конкретного протокола и что он позволяет делать.

http://www.sparkfun.com/tutorial/Nokia%206100%20LCD%20Display%20Driver.pdf

На ютубе видел ролики с работающми иксами и консолью на нем, но исходники драйвера почемуто не спешать выкладывать.

> На ютубе видел ролики с работающми иксами и консолью на нем, но исходники драйвера почемуто не спешать выкладывать.

блин, я думал человеку для дела нужно, а тут запускать Xы на пипиське размером меньше квадратного дюйма :-/

// wbr

>блин, я думал человеку для дела нужно, а тут запускать Xы на пипиське размером меньше квадратного дюйма :-/

Задумано было для дела - на подобной платке правда с arm9 я хотел сделать что-то типа шлюза для опроса электросчетчиков на удаленных объектах через gsm модем, но потом стало ясно что для таких целей 8-битного микроконтроллера выше крыше хватит и нет смысла тратить лишние деньги. Никогда не знаешь что тебе пригодится и когда - платка осталась вот и решил всеже довести дело до какого-то логического конца.

В общем я зря боялся - посмотрел скелет - там действительно все очень просто, даже не думал что может быть так легко написать драйвер для framebuffer, фактически все что нужно реализовать - это отрисовывать прямоугольник с определенными координатами на экране из системной памяти где лежит фрэйм, в памяти все отрисовывается готовыми процедурами (тех что необходимы всегда всего 3 и они уже есть в ядре), после просмотра исходника arcfb.c вообще все понятно стало. Спасибо за дельные советы. Желаю творческих успехов :)