【问题标题】:Framebuffer Documentation帧缓冲文档
【发布时间】:2011-01-31 00:38:38
【问题描述】:

有没有关于如何在 Linux 中编写使用帧缓冲设备的软件的文档?我看过几个简单的例子,基本上是说:“打开它,映射它,将像素写入映射区域。”但是没有关于如何使用不同的 IOCTLS 的综合文档。我已经看到对“平移”和其他功能的引用,但“谷歌搜索”会提供太多无用信息。

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

【问题讨论】:

    标签: linux framebuffer


    【解决方案1】:

    任何启动画面的来源(即在启动期间)应该会给您一个良好的开端。

    【讨论】:

    • 这有点笼统,你能给我一个更具体的方向吗?
    【解决方案2】:

    您可以查看 fbi 的源代码,这是一个使用 linux 帧缓冲区的图像查看器。你可以在这里得到它:http://linux.bytesex.org/fbida/

    【讨论】:

      【解决方案3】:

      查看以下任何一个的源代码:fbxat、fbida、fbterm、fbtv、directFB 库、libxineliboutput-fbe、ppmtofb、xserver-fbdev 都是 debian 包应用程序。只需从 debian 库中获取源代码即可。还有很多...

      提示:使用您喜欢的包管理器在包描述中搜索帧缓冲区。

      好吧,即使阅读代码有时被称为“Guru 文档”,实际去做也可能有点过头了。

      【讨论】:

      • 对于这样的事情,每个人和那里的兄弟都在写自己的版本,如果没有文档来指导开发人员实现 API,问题是从一个到下一个的行为可能不一样。我正在查看 PS3 Linux 实现的源代码,您可以看到有些功能似乎被普遍实现但他们忽略了。
      • @NoMoreZealots:是的,带有最佳实践指南的真实文档将是一件非常好的事情。我真的不知道(所以我赞成你的问题),我的回答是一种玩笑 ;-) 你可能不得不写那个......
      【解决方案4】:

      -- 除了您提到的之外,似乎没有太多选项可以从桌面上的用户空间使用 fb 进行编程。这可能是某些文档如此陈旧的原因之一。查看 device driver writers 的这个 howto,它是从一些官方 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 进行双缓冲(在此device.. 虽然对于桌面,fb1 可能无法使用或者它可能访问不同的硬件),使用 volatile 关键字可能是合适的,我们应该注意 vsync。

      -- asm.sourceforge.net [斜线] 文章 [斜线] fb.html 汇编语言例程也出现(?)只是做基本的查询,打开,设置一些基础,mmap,绘制像素值到存储,并复制到 fb 内存(我想确保使用短的 stosb 循环,而不是更长的方法)。

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

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

      -- 注意 DirectFB 不是 fb。 DirectFB 最近比旧版 fb 获得了更多的喜爱,因为它更专注于更性感的 3d hw 加速。如果您想在不利用 3d 硬件加速(甚至 2d 硬件加速)的情况下尽可能快地渲染到桌面屏幕,那么 fb 可能会很好,但不会给您提供 X 没有给您的任何东西。 X 显然使用 fb,与您的程序可能具有的其他成本相比,开销可能可以忽略不计(不要在任何紧密循环中调用 X,而是在您为帧设置所有像素后在最后调用)。另一方面,如以下评论所述,与 fb 一起玩会很巧妙:Paint Pixels to Screen via Linux FrameBuffer

      【讨论】:

        【解决方案5】:

        检查MPlayer 来源。

        /libvo目录下有很多Mplayer用来显示多媒体的Video Output插件。在那里您可以找到使用 Linux 帧缓冲区的 fbdev(vo_fbdev* 源)插件。

        ioctl调用很多,代码如下:

        • FBIOGET_VSCREENINFO
        • FBIOPUT_VSCREENINFO
        • FBIOGET_FSCREENINFO
        • FBIOGETCMAP
        • FBIOPUTCMAP
        • FBIOPAN_DISPLAY

        它不像一个好的文档,但这肯定是一个很好的应用程序实现。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2023-03-07
          • 2014-06-26
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2023-04-04
          • 1970-01-01
          相关资源
          最近更新 更多