Я занимаюсь разработкой встроенной системы с сенсорным экраном. Сенсорный экран работает как на входе, так и на выходе, а виртуальная клавиатура накладывается на графический вывод.
У меня есть работающий драйвер устройства, который считывает ввод с сенсорного датчика и правильно переводит его в нажатия клавиш, созданные с помощью этого руководства на kernel.org . Я хочу расширить этот драйвер, чтобы обрабатывать вывод изображения на экран.
Я хочу поддерживать как getty, так и X с минимальным дублированием. Я использую минимальный вариант Debian с выбранными вишневыми пакетами, например минимальный X. Обратите внимание, что я не собираюсь пытаться получить этот драйвер в конвейер хранилища, хотя я могу выгрузить его в общедоступный репозиторий GitHub.
Вывод изображений с экрана в настоящее время выполняется с помощью обходного обходного пути: опция загрузки для принудительного рендеринга на встроенное графическое оборудование ЦП, несмотря на то, что он не подключен к дисплею, и демон, который постоянно просматривает этот буфер, изменяет несколько предварительных настроек. определенные пиксели для создания визуальной клавиатуры, и выталкивает ее на реальный экран.
Это работает как подтверждение концепции, доказывая, что я правильно понимаю язык, который ожидает экранное устройство, но явно не оптимально.
kernel.org также есть руководство для драйверов устройств "DRM", но это кажется серьезным излишним для того, на что способно мое оборудование:
Уровень DRM в Linux содержит код, предназначенный для удовлетворения потребностей сложных графических устройств, обычно содержащий программируемые конвейеры, хорошо подходящие для ускорения 3D-графики.
Ни одно из моего оборудования не имеет ничего похожего на 3D-ускорение, поэтому я пришел к выводу, что это, вероятно, не то, что я хочу.
Какую подсистему / API я должен использовать? Я полагаю, что один из недостатков терминологии - это то, что сдерживает мои поиски, но любая дополнительная информация о том, как этого добиться, была бы оценена.
Детали аппаратного обеспечения (вероятно, неактуальные): ЦП и экран взаимодействуют через параллельный протокол 8080-esque, который ЦП не поддерживает изначально, поэтому я эмулирую его с помощью GPIO (манипулируя регистрами через mmap).
Отправка полного изображения экрана занимает около 20 мс, но получение полной копии из встроенного графического буфера занимает ~ 180 мс, поэтому пропуск этого шага является наиболее важной задачей. Аппаратное обеспечение экрана включает в себя достаточно памяти SGRAM для хранения данных всего кадра и поддерживает запись прямоугольной подобласти, поэтому было бы желательно использовать крючок для обновления только части экрана, которая изменилась.
Экран не особенно о времени поступления данных. Ввод датчика касания обрабатывается специальной интегральной микросхемой, которая обменивается данными с процессором через I²C , которую процессор поддерживает. Настоящий драйвер использует linux/input-polldev.hинтерфейс. Процессор - Broadcom BCM2835 , экран - TFT со встроенным контроллером Himax HX8357 , декодер сенсорного экрана - ST STMPE610 , и между HX8357 и BCM2835 находится переключатель уровней напряжения (Nexperia 74LVCH245A ). Более подробная информация доступна по запросу.
источник
Ответы:
Терминология, которую вы пропускаете, является устройством фреймбуфера . Вы можете найти документацию по kernel.org для этого здесь .
источник