- Похоже, что при программировании с помощью fb из пользовательского пространства на рабочем столе может быть не так уж много вариантов помимо того, что вы упомянули. Это может быть одной из причин того, почему некоторые документы такие старые. Посмотрите это руководство для разработчиков драйверов устройств , на которое ссылаются некоторые официальные документы Linux: www.linux-fbdev.org [slash] HOWTO [slash] index.html. Он не ссылается на слишком много интерфейсов ... хотя, глядя на исходное дерево linux, можно привести примеры большего кода.
- opentom.org [slash] Hardware_Framebuffer не для среды рабочего стола. Он усиливает основную методологию, но, похоже, избегает объяснения всех компонентов, необходимых для «быстрого» двойного переключения буфера, о котором он упоминает. Еще один пример для другого устройства, который не учитывает некоторые подробности буферизации ключа, - это wiki.gp2x.org [slash] wiki [slash] Writing_to_the_framebuffer_device, хотя он, по крайней мере, предполагает, что вы можете использовать fb1 и fb0 для включения двойной буферизации (на этом устройство ... хотя для настольного компьютера fb1 может быть невозможен или может иметь доступ к другому оборудованию), что может быть целесообразно использовать ключевое слово volatile, и что мы должны обратить внимание на vsync.
- asm.sourceforge.net [slash] article [slash] fb.html Подпрограммы на ассемблере, которые также появляются (?), Чтобы просто выполнять основы запросов, открытия, установки нескольких основ, mmap, рисования значений пикселей в хранение и копирование в память fb (я полагаю, что я использовал короткий цикл stosb, а не какой-то более длинный подход).
- Остерегайтесь 16 bpp комментариев при поиске кадрового буфера Linux: я использовал fbgrab и fb2png во время сеанса X, но безрезультатно. Каждый из них представлял изображение, которое предлагало снимок экрана моего рабочего стола, как если бы изображение рабочего стола было сделано с очень плохой камерой, под водой, а затем передержано в темной комнате. Изображение было полностью разбито по цвету, размеру и пропускало много деталей (все было усеяно пиксельными цветами, которые не принадлежали). Кажется, что / proc / sys на компьютере, который я использовал (новое ядро с не более чем незначительными модификациями .. от производной от PCLOS), утверждает, что fb0 использует 16 бит / с, и большинство вещей, которые я гуглил, указывало что-то подобное, но эксперименты привели меня к совсем другой вывод. Помимо результатов этих двух сбоев из стандартных утилит захвата кадрового буфера (для версий, хранящихся в этом дистрибутиве), которые могли принимать 16 бит, у меня был другой успешный результат теста, в котором данные пикселей буфера кадра обрабатывались как 32 бита. Я создал файл из данных, извлеченных через cat / dev / fb0. Размер файла в итоге составил 1920000. Затем я написал небольшую программу на C, чтобы попытаться манипулировать этими данными (в предположении, что это были пиксельные данные в той или иной кодировке). В конце концов я прибил его, и формат пикселя точно соответствовал тому, что я получил от X при запросе (TrueColor RGB 8 бит, без альфа-канала, но с добавлением 32 бит). Обратите внимание на другую подсказку: мое разрешение экрана 800x600 раз 4 байта дает 1920000 точно. Все 16-битные подходы, которые я пробовал вначале, приводили к схожему поврежденному изображению с fbgrap, так что это не так, как если бы я не смотрел правильные данные. [Дайте мне знать, если вы хотите код, который я использовал для проверки данных. По сути, я просто читаю весь дамп fb0, а затем выкладываю его обратно в файл, после добавления заголовка «P6 \ n800 600 \ n255 \ n», который создает подходящий файл ppm, и пока зацикливаюсь на всех пикселях, манипулируя их порядком или расширяя их, ... с конечным успешным результатом для меня было отбрасывать каждый 4-й байт и переключать первый и третий в каждом 4-байтовом блоке. Короче говоря, я превратил очевидный дамп BGRA fb0 в RGB-файл ppm. ppm можно просматривать с помощью многих программ просмотра изображений в Linux.]
- Возможно, вы захотите пересмотреть причины желания программировать с использованием fb0 (это также может объяснить, почему существует несколько примеров). Возможно, вы не добьетесь сколько-нибудь значительного прироста производительности по сравнению с X (это был мой, хотя и ограниченный) опыт, хотя вы отказались от преимуществ использования X. Эта причина может также объяснять, почему существует немного примеров кода.
- Обратите внимание, что DirectFB не является fb. DirectFB в последнее время получил больше любви, чем старый fb, так как он больше сосредоточен на более привлекательном 3D hw Accele. Если вы хотите рендерить на экран рабочего стола как можно быстрее без использования аппаратного ускорения 3d (или даже ускорения 2d hw), то fb может подойти, но не даст вам ничего такого, что X не дает вам. X, очевидно, использует fb, и издержки, вероятно, незначительны по сравнению с другими затратами, которые, вероятно, будет иметь ваша программа (не вызывайте X в каком-либо жестком цикле, а вместо этого в конце, когда вы настроите все пиксели для кадра). С другой стороны, можно поиграть с fb, как описано в этом комментарии: Рисование пикселей на экране через Linux FrameBuffer