Заваял постец о написание дров под линь

[dlinyj]

Решил таки показать народу, что дрова писать ОооОооОочень просто


Дисплей, управляемый дровами

Даже есть в динамике:

Всё это разумеется тут: http://habrahabr.ru/post/206148/ читаем, плюсуем, комментируем, ругаем :))))

Comments

[eddy-em.livejournal.com]

Ну ты намудрил! Оно же в юзерспейсе проще решается!

[dlinyj.livejournal.com]

А ты внимательно статью читал? Там есть пример работы и для юзерспейса и для ядра. Это раз.
Второе, цель была именно показать как пишется драйвер.
В третьих, тут полноценная консоль, со всеми вытекающими. Стандартный вывод можно туда перенаправлять.

[minimumlaw.livejournal.com]

Эээххх... Молодежь... Ну драйвер, ну под Linux... Ну да, просто - за то его (пингвина) и любим... Чего орать-то?

Примеров навалом. От допотопного auxdisplay (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/auxdisplay) на KS01008 c LPT до Sharp LQ035 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/video/bf537-lq035.c) с полноцветкой на SPI. Бери любой за основу и пиши под свой контроллер.

Я тут с пол года назад пробовал Sharp Memory LCD LS027B7DH01 (типа жрет почти как E-INC, но вез его закидонов) - так шел именно этим путем. Сначала SPI драйвер, потом написал фирмварьку для USB (под рукой тогда Atmel'овская X Pro была) и перенес код под Linux с SPI на USB (благо не сложно).

Но если вдруг кому интересно... Схемы здесь не выставляю - они или типовые, или элементарные. А код весь здесь (https://github.com/MinimumLaw/memlcdfb). Консоль работала. Midnight Commander бегал шустро, картинки выводились... А вот с видео беда - не нашел плейера, который бы в реально монохромный фреймбуфер выводить смог.

[dlinyj.livejournal.com]

>>Чего орать-то?

А мы не орём, мы учим. Люди не рождаются умеющими писать дрова.

А что было сделано, нихрена не понял...

[minimumlaw.livejournal.com]

Ну прости, конечно познавательный элемент в тексте присутствует в приличном количестве.
Только вот тогда до конца бы - параметры и шрифты через ioctl (самый идеалогически правильный путь), а не навороченной функцией handleInput(). В качестве бонуса - код станет проще и понятнее. Ну, и в многозадачной системе с такими read и write не ах до чего кошерно. Это про разделение ресурсов и игнорирование семафоров/мьютексов, очередей задач. Кстати, последние (http://www.ibm.com/developerworks/linux/library/l-tasklets/index.html#work_queues) классное средство борьбы с задержками. Только о нем мало где написано.

Мое мнение - таких учебников по сети вагон и малая телега. Реальная ценность только в том, что на родном языке написано (чаще всего приходится на международном читать). За это, конечно, честь и хвала. Хотя... Хороший разраб обязан владеть международным (хотя бы на уровне понять написанное).

Ну да. Я ретроград. И до сих пор считаю, что документация либо русская, либо правильная. Увы. Это, видимо, не лечится.

А свое я положил только за тем, чтоб показать что все действительно очень просто. Там все еще веселее - есть чисто графический Memory LCD LS027B7DH01 (http://www.sharpmemorylcd.com/resources/LS027B7DH01_Spec.pdf) от Sharp, единственным достоинством которого является крайне низкое потребление (сравнимое с e-Inc) и при этом отсутствие гадостей типа медленного рефреша или высоких напряжений. Надо было попробовать на чем-то. Вот и зацепил по SPI за свою отладку. Быстренько набрасал драйвер. Получил самую настоящую монохромную фреймбуферную консоль с загружаемым шрифтом всех размеров. Народу понравилось. Попросили подключить к реальной x86'ой системе - а там SPI те еще заморочки (если, конечно, ножками на LPT не дрыгать, а использовать системное API). Пришлось написать кусок кода для Atmel XPro чтоб с одной стороны USB (vendor specific device), а с другой SPI c дисплеем и "подшаманить" драйвер. Все это (FrameBuffer на SPI, FrameBuffer на USB и прошивка X Pro) и лежит в git hub'e. Привычка бросать весь код в github, sourceforge, bitbucket - она полезна. Эпизодически сильно пригождается...

Реальная ценность этого кода - показать связку двух классов устройств (SPI device - Framebuffer Device и USB device - Framebuffer Device). Тут и deferred io толком не работает (все не дописать).

А по проекту в целом - ну каша получилась. Кому нужен низкопотребляющий дисплей, когда XPro жрет больше? Но народ прется имея такую маленькую переключаемую консоль для серверов. А мне и не жалко. В своих изделиях если где и будет применяться, то только в виде SPI.

[dlinyj.livejournal.com]

Можете ещё раз перечитать статью, чтобы понять что ioctl там лишнее, это реализация консоли. Реализовать его - добавить одну функцию. Можно ещё и poll сделать было, и много всяких всячин. Но зачем? Это УЧЕБНЫЙ драйвер. Он априори БЕСПОЛЕЗЕН!!!

Работу с моим экраном можно и НУЖНО делать из юзерспейса

А вот вашу заморочку давайте отдельной статьёй с фотками в общий доступ. Это ж круто.

[minimumlaw.livejournal.com]

> Это УЧЕБНЫЙ драйвер. Он априори БЕСПОЛЕЗЕН!!!

Эх... Вот проблема в том, что отношение к "учебному" драйверу как к чему-то априори бесполезному. А по мне так именно на таких драйверах и учишься концепциям системы и правильной работе с ней.

И, если уж на то пошло, то и pool() далеко не бесполезен (хотя, конкретно здесь...). А вот, скажем seek() был бы в тему (чтобы при каждом write'е указатель на ноль не сбрасывать и читать с произвольного места). С кратким пояснением того, что есть seek() и с чем его едят. А уж тот же ioctl() - просто обязателен к реализации.

Увы, но вынужден признать что в коде достаточно именитых контор (можно я не буду их называть? может это они конкретно нашу контору так не любят?) регулярно встречаются такие вот куски "учебных недодрайверов" с аналогами функции handleInput(). Спорим причина именно в том, что большинство руководств обрывается именно на этой точке?

Кстати, Вы с handleInput() ушли чуть дальше, чем обычно. Но это скорее вредный совет. На этом уровне даже ESC-последовательности отрабатывать не стоит (ибо записанное в таких устройствах всегда должно быть эквивалентно прочитанному). А уж если очень хочется, то должен быть и ioctl, переводящий запись в RAW режим.

> Работу с моим экраном можно и НУЖНО делать из юзерспейса

ммм... Честно говоря, я противник того, чтоб все делать из юзерспейса (ну, разве что через libusb или FUSE - но только на попробовать, чтоб потом сделать по людски). Вывод в порт - привелигированная инструкция (как, впрочем, и произвольный доступ к памяти на альтернативных платформах). Как-то так...

> А вот вашу заморочку давайте отдельной статьёй с фотками в общий доступ. Это ж круто.

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

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