帧缓冲区文档

发布于 2024-08-26 06:51:35 字数 191 浏览 4 评论 0原文

有没有关于如何在 Linux 中编写使用帧缓冲区设备的软件的文档？我见过几个简单的例子，基本上说：“打开它，映射它，将像素写入映射区域。”但没有关于如何使用不同 IOCTLS 的综合文档。我见过对“平移”和其他功能的引用，但“谷歌搜索”给出了太多无用信息的点击。

编辑：从编程角度来看，唯一的文档是代码文档，而不是“用户如何配置系统以使用 fb”吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

靖瑶 2024-09-02 06:51:35

您可以查看 FBI 的源代码，这是一个使用 Linux 帧缓冲区的图像查看器。您可以在这里获取它：http://linux.bytesex.org/fbida/

回复收藏 0 原文

千仐 2024-09-02 06:51:35

-- 除了您提到的之外，似乎没有太多选项可以从桌面上的用户空间使用 fb 进行编程。这可能是某些文档如此陈旧的原因之一。查看设备驱动程序编写者的指南，它是从一些官方 Linux 文档中引用的： www.linux-fbdev.org [slash] HOWTO [slash] index.html 。它没有引用太多接口。尽管查看 Linux 源代码树确实提供了更大的代码示例。

-- opentom.org [斜杠] Hardware_Framebuffer 不适用于桌面环境。它强化了主要方法，但它似乎确实避免解释执行它提到的“快速”双缓冲区切换所需的所有要素。另一种针对不同设备的方法是 wiki.gp2x.org [slash] wiki [slash]writing_to_the_framebuffer_device ，它留下了一些关键的缓冲细节，尽管它至少表明您可以使用 fb1 和 fb0 来进行双缓冲（在此设备..虽然对于桌面，fb1可能不可能或者它可能访问不同的硬件），使用 volatile 关键字可能是合适的，并且我们应该注意垂直同步。

-- asm.sourceforge.net [slash] 文章 [slash] fb.html 汇编语言例程也出现（？），用于执行查询、打开、设置一些基础知识、mmap、将像素值绘制到存储等基础知识，以及复制到 fb 内存（我想，确保使用短的 stosb 循环，而不是一些较长的方法）。

-- 在谷歌搜索 Linux 帧缓冲区时要注意 16 bpp 注释：我在 X 会话期间使用了 fbgrab 和 fb2png，但没有效果。它们各自渲染了一张图像，该图像暗示了我的桌面屏幕的快照，就好像桌面的照片是使用非常糟糕的相机在水下拍摄的，然后在黑暗的房间中过度曝光。图像的颜色、大小完全损坏，并且丢失了很多细节（到处都是不属于的像素颜色）。似乎我使用的计算机上的 /proc /sys （新内核，最多进行了较小的修改......来自 PCLOS 衍生品）声称 fb0 使用 16 bpp，并且我在 google 上搜索的大多数内容都说明了类似的内容，但实验引导我一个非常不同的结论。除了标准帧缓冲区抓取实用程序（对于该发行版持有的版本）可能假设为 16 位的这两次失败的结果之外，我还有一个不同的成功测试结果，将帧缓冲区像素数据视为 32 位。我根据通过 cat /dev/fb0 拉入的数据创建了一个文件。该文件的大小最终为 1920000。然后我编写了一个小型 C 程序来尝试操作该数据（假设它是某种编码或其他编码的像素数据）。我最终成功了，像素格式与我在查询时从 X 获得的格式完全匹配（TrueColor RGB 8 位，没有 alpha，但填充到 32 位）。请注意另一条线索：我的屏幕分辨率为 800x600 乘以 4 字节，结果正好是 1920000。我最初尝试的 16 位方法都产生了与 fbgrap 类似的损坏图像，所以这不像我可能没有查看正确的数据。 [如果您想要我用来测试数据的代码，请告诉我。基本上，我只是读取整个 fb0 转储，然后将其吐回文件，添加标题“P6\n800 600\n255\n”创建合适的 ppm 文件，并循环遍历所有像素操作其顺序或扩展它们，..最终成功的结果是我删除每 4 个字节并在每 4 个字节单元中交换第一个和第三个字节。简而言之，我将明显的 BGRA fb0 转储转换为 ppm RGB 文件。 ppm 可以在 Linux 上使用许多图片查看器来查看。]

-- 您可能需要重新考虑使用 fb0 进行编程的原因（这也可能解释了为什么存在很少的示例）。在放弃使用 X 的好处的同时，您可能无法获得比 X 更有价值的性能提升（这是我的经验，如果有限的话）。这个原因也可能解释了为什么存在很少的代码示例。

-- 请注意，DirectFB 不是 fb。 DirectFB 最近比旧版 Facebook 受到更多喜爱，因为它更专注于更性感的 3d hw accel。如果您想在不利用 3d 硬件加速（甚至 2d 硬件加速）的情况下尽可能快地渲染到桌面屏幕，那么 fb 可能没问题，但不会给您提供 X 无法提供的任何东西。 X 显然使用了 fb，与程序可能具有的其他成本相比，开销可能可以忽略不计（不要在任何紧密循环中调用 X，而是在设置了帧的所有像素后在最后调用 X）。另一方面，如以下评论所述，使用 fb 会很方便：通过 Linux FrameBuffer 将像素绘制到屏幕

-- It appears there might not be too many options possible to programming with the fb from user space on a desktop beyond what you mentioned. This might be one reason why some of the docs are so old. Look at this howto for device driver writers and which is referenced from some official linux docs: www.linux-fbdev.org [slash] HOWTO [slash] index.html . It does not reference too many interfaces.. although looking at the linux source tree does offer larger code examples.

-- opentom.org [slash] Hardware_Framebuffer is not for a desktop environment. It reinforces the main methodology, but it does seem to avoid explaining all the ingredients necessary to doing the "fast" double buffer switching it mentions. Another one for a different device and which leaves some key buffering details out is wiki.gp2x.org [slash] wiki [slash] Writing_to_the_framebuffer_device , although it does at least suggest you might be able use fb1 and fb0 to engage double buffering (on this device.. though for desktop, fb1 may not be possible or it may access different hardware), that using volatile keyword might be appropriate, and that we should pay attention to the vsync.

-- asm.sourceforge.net [slash] articles [slash] fb.html assembly language routines that also appear (?) to just do the basics of querying, opening, setting a few basics, mmap, drawing pixel values to storage, and copying over to the fb memory (making sure to use a short stosb loop, I suppose, rather than some longer approach).

-- Beware of 16 bpp comments when googling Linux frame buffer: I used fbgrab and fb2png during an X session to no avail. These each rendered an image that suggested a snapshot of my desktop screen as if the picture of the desktop had been taken using a very bad camera, underwater, and then overexposed in a dark room. The image was completely broken in color, size, and missing much detail (dotted all over with pixel colors that didn't belong). It seems that /proc /sys on the computer I used (new kernel with at most minor modifications.. from a PCLOS derivative) claim that fb0 uses 16 bpp, and most things I googled stated something along those lines, but experiments lead me to a very different conclusion. Besides the results of these two failures from standard frame buffer grab utilities (for the versions held by this distro) that may have assumed 16 bits, I had a different successful test result treating frame buffer pixel data as 32 bits. I created a file from data pulled in via cat /dev/fb0. The file's size ended up being 1920000. I then wrote a small C program to try and manipulate that data (under the assumption it was pixel data in some encoding or other). I nailed it eventually, and the pixel format matched exactly what I had gotten from X when queried (TrueColor RGB 8 bits, no alpha but padded to 32 bits). Notice another clue: my screen resolution of 800x600 times 4 bytes gives 1920000 exactly. The 16 bit approaches I tried initially all produced a similar broken image to fbgrap, so it's not like if I may not have been looking at the right data. [Let me know if you want the code I used to test the data. Basically I just read in the entire fb0 dump and then spit it back out to file, after adding a header "P6\n800 600\n255\n" that creates the suitable ppm file, and while looping over all the pixels manipulating their order or expanding them,.. with the end successful result for me being to drop every 4th byte and switch the first and third in every 4 byte unit. In short, I turned the apparent BGRA fb0 dump into a ppm RGB file. ppm can be viewed with many pic viewers on Linux.]

-- You may want to reconsider the reasons for wanting to program using fb0 (this might also account for why few examples exist). You may not achieve any worthwhile performance gains over X (this was my, if limited, experience) while giving up benefits of using X. This reason might also account for why few code examples exist.

-- Note that DirectFB is not fb. DirectFB has of late gotten more love than the older fb, as it is more focused on the sexier 3d hw accel. If you want to render to a desktop screen as fast as possible without leveraging 3d hardware accel (or even 2d hw accel), then fb might be fine but won't give you anything much that X doesn't give you. X apparently uses fb, and the overhead is likely negligible compared to other costs your program will likely have (don't call X in any tight loop, but instead at the end once you have set up all the pixels for the frame). On the other hand, it can be neat to play around with fb as covered in this comment: Paint Pixels to Screen via Linux FrameBuffer

回复收藏 0 原文