4,441
社区成员
发帖
与我相关
我的任务
分享请问framebuffer设备驱动是不是仅用于console下面的显示驱动？
这几天越看越糊涂了。
我要使用真正的图形界面，还是要真正的显卡驱动？而framebuffer只是在console下面，用图形模式仿真文本模式来达到更好的显示效果？
我要使用真正的图形界面，还是要真正的显卡驱动？而framebuffer只是在console下面，用图形模式仿真文本模式来达到更好的显示效果？
...全文
请发表友善的回复…
发表回复
getit911 2005-03-07
- 打赏
- 举报
vesafb是个通用的驱动，性能很差的除了显示图片没什么大用。
如果你想在控制台下(不启动X)全屏高品质回放DVD，网络视频流，就应该使用内核带的或厂家提供FB支持，这样某些加速特性就会被发挥出来。
简单点说，mplayer在vesa模式下播放DVD，即使你的座机是P4流畅度也会很差，如果安装了相应显卡的FB驱动，效果就会非常好，因为没有XWindows，所以会发挥出系统的最大潜力，效果好坏与驱动程序的品质也有很大关系，可以参考via官方提供的FB驱动viafb.ko，目前2.6.10内核新增加对Intel的FB设备支持，在intel集成主板上也可以玩FB了。
如果你想在控制台下(不启动X)全屏高品质回放DVD，网络视频流，就应该使用内核带的或厂家提供FB支持，这样某些加速特性就会被发挥出来。
简单点说，mplayer在vesa模式下播放DVD，即使你的座机是P4流畅度也会很差，如果安装了相应显卡的FB驱动，效果就会非常好，因为没有XWindows，所以会发挥出系统的最大潜力，效果好坏与驱动程序的品质也有很大关系，可以参考via官方提供的FB驱动viafb.ko，目前2.6.10内核新增加对Intel的FB设备支持，在intel集成主板上也可以玩FB了。
power77 2005-03-07
- 打赏
- 举报
看看/drivers/video/vesafb.c
就会有启发的。
就会有启发的。
power77 2005-03-07
- 打赏
- 举报
可以直接使用BIOS服务的，当然可能只是部分。
在VBE3.0的文档中说了，现在vesa标准已经提供了保护模式下的接口。
另外，在v86模式下好像可以通过dos虚拟机直接访问硬件的
在VBE3.0的文档中说了，现在vesa标准已经提供了保护模式下的接口。
另外，在v86模式下好像可以通过dos虚拟机直接访问硬件的
Wolf0403 2005-03-07
- 打赏
- 举报
传说 X 的显卡驱动是 user space 的。。。
fb 的操作是通过对 /dev/fb/0 这个文件操作，当然就是 read/write 这些接口了
至于『直接使用BIOS服务或I/O』。。。不说野蛮，能不能行得通？怀疑ing
fb 的操作是通过对 /dev/fb/0 这个文件操作，当然就是 read/write 这些接口了
至于『直接使用BIOS服务或I/O』。。。不说野蛮，能不能行得通？怀疑ing
wolke 2005-03-07
- 打赏
- 举报
呵呵，俺在windows下分析代码，当然是'\'.
************
这种东西是通过在内核启动时在未进入保护模式之前在bios的帮助下将显卡工作模式置于FB模式下，当然以后我们也不可能再切换回来了，因为大家知道在80x86的保护模式中我们无法使用底层bios功能***********
如果进入v86模式改成fb模式（graphic)，这个显示的效果是啥样子呢？
************
这种东西是通过在内核启动时在未进入保护模式之前在bios的帮助下将显卡工作模式置于FB模式下，当然以后我们也不可能再切换回来了，因为大家知道在80x86的保护模式中我们无法使用底层bios功能***********
如果进入v86模式改成fb模式（graphic)，这个显示的效果是啥样子呢？
power77 2005-03-07
- 打赏
- 举报
先谢楼上几位。
昨天看了linux device driver一书关于fb的部分，只讲了一点点，但是让我清楚了不少。
原文如下：
drivers/video
Here you find all the frame buffer video devices. The directory is concerned with video output, not video input. Like /drivers/sound, the whole directory implements a single char device driver; a core frame buffer system dispatches actual access to the various frame buffers available on the computer.
The entry point to /dev/fb devices is in fbmem.c. The file registers the major number and maintains an internal list of which frame buffer device is in charge of each minor number. A hardware driver registers itself by calling register_framebuffer, passing a pointer to struct fb_info. The data structure includes everything that’s needed for specific device management. It includes the open and release methods, but no read, write, or mmap; these methods are implemented in a generalized way in fbmem.c itself.
In addition to frame buffer memory, this directory is in charge of frame buffer consoles. Because the layout of pixels in frame buffer memory is standardized to some extent, kernel developers have been able to implement generic console support for the various layouts of display memory. Once a hardware driver registers its own struct fb_info, it automatically gets a text console attached to it, according to its declared layout of video memory.
Unfortunately, there is no real standardization in this area, so the kernel currently supports 17 different screen layouts; they range from the fairly standard 16-bit and 32-bit color displays to the hairy VGA and Mac pixel placements. The files concerned with placing text on frame buffers are called fbcon-name.c.
When the first frame buffer device is registered, the function register_framebuffer calls take_over_console (exported by drivers/char/console.c) in order to actually set up the current frame buffer as the system console. At boot time, before frame buffer initialization, the console is either the native text screen or, if none is there, the first serial port. The command line starting the kernel, of course, can override the default by selecting a specific console device. Kernel developers created take_over_console to add support for frame buffer consoles without complicating the boot code. (Usually frame buffer drivers depend on PCI or equivalent support, so they can’t be active too early during the boot process.) The take_over_console feature, however, is not limited to frame buffers; it’s available to any code involving any hardware. If you want to transmit kernel messages using a Morse beeper or UDP network packets, you can do that by calling take_over_console from your kernel module.
因此我现在的理解就是，linux首先实现了fb设备的抽象和基本管理，基本功能（如read，write，ioctl等等），同时它在内核源代码中已经提供了部分针对特定显卡的fb驱动（如vesafb，在/drivers/video中）。
但是，如果我们要写自己的显卡驱动，有两种方法。一是按照老的写法，不利用fb设备，直接使用BIOS服务或I/O。二是在fb设备之上，利用内核已经提供的对fb设备的访问，同时增加针对自己特定显卡的加速功能子函数，通过注册驱动的方式添加上这些子函数。
vesafb是为了支持通用的vesa显卡，只实现了最简单的功能，没有加速，但是兼容性很好。
大家还有没有什么想法，都讨论一下
昨天看了linux device driver一书关于fb的部分，只讲了一点点，但是让我清楚了不少。
原文如下：
drivers/video
Here you find all the frame buffer video devices. The directory is concerned with video output, not video input. Like /drivers/sound, the whole directory implements a single char device driver; a core frame buffer system dispatches actual access to the various frame buffers available on the computer.
The entry point to /dev/fb devices is in fbmem.c. The file registers the major number and maintains an internal list of which frame buffer device is in charge of each minor number. A hardware driver registers itself by calling register_framebuffer, passing a pointer to struct fb_info. The data structure includes everything that’s needed for specific device management. It includes the open and release methods, but no read, write, or mmap; these methods are implemented in a generalized way in fbmem.c itself.
In addition to frame buffer memory, this directory is in charge of frame buffer consoles. Because the layout of pixels in frame buffer memory is standardized to some extent, kernel developers have been able to implement generic console support for the various layouts of display memory. Once a hardware driver registers its own struct fb_info, it automatically gets a text console attached to it, according to its declared layout of video memory.
Unfortunately, there is no real standardization in this area, so the kernel currently supports 17 different screen layouts; they range from the fairly standard 16-bit and 32-bit color displays to the hairy VGA and Mac pixel placements. The files concerned with placing text on frame buffers are called fbcon-name.c.
When the first frame buffer device is registered, the function register_framebuffer calls take_over_console (exported by drivers/char/console.c) in order to actually set up the current frame buffer as the system console. At boot time, before frame buffer initialization, the console is either the native text screen or, if none is there, the first serial port. The command line starting the kernel, of course, can override the default by selecting a specific console device. Kernel developers created take_over_console to add support for frame buffer consoles without complicating the boot code. (Usually frame buffer drivers depend on PCI or equivalent support, so they can’t be active too early during the boot process.) The take_over_console feature, however, is not limited to frame buffers; it’s available to any code involving any hardware. If you want to transmit kernel messages using a Morse beeper or UDP network packets, you can do that by calling take_over_console from your kernel module.
因此我现在的理解就是，linux首先实现了fb设备的抽象和基本管理，基本功能（如read，write，ioctl等等），同时它在内核源代码中已经提供了部分针对特定显卡的fb驱动（如vesafb，在/drivers/video中）。
但是，如果我们要写自己的显卡驱动，有两种方法。一是按照老的写法，不利用fb设备，直接使用BIOS服务或I/O。二是在fb设备之上，利用内核已经提供的对fb设备的访问，同时增加针对自己特定显卡的加速功能子函数，通过注册驱动的方式添加上这些子函数。
vesafb是为了支持通用的vesa显卡，只实现了最简单的功能，没有加速，但是兼容性很好。
大家还有没有什么想法，都讨论一下
nodummy 2005-03-06
- 打赏
- 举报
你用什么Linux啊？路径居然是\而不是/？？？？？？
那个东西是X的vesa驱动……
那个东西是X的vesa驱动……
DanXer 2005-03-06
- 打赏
- 举报
fb设备提供了一个图形硬件的抽象层，代表某些视频硬件的帧缓冲，帧缓冲可以直接通过规范定义的接口供软件访问(/dev/fb*)。我们熟知的Xwindows有一个非加速X服务器，XF86_FBDev就是使用帧缓冲驱动，该驱动最早出现于XFree86 3.2版本中，现在已很成熟。
帧缓冲在各种显卡硬件各有不同，如ATI Rage128提供了自己的帧缓冲，Cirrus Logic，Matrox，PowerVR 2，都有自己的帧缓冲，TGA，VESA，是两种帧缓冲设备标准，VESA由于被大多数现代显卡所具有，所以使用的较为广泛。不同的帧缓冲设备需要在内核编译时使用不同的驱动。所以欲使用帧缓冲必须要拥有具有帧缓冲能力的显示卡。并且不同显卡对帧缓冲的支持能力也不同，如可以使用的分辨率模式(1024*768或800*600)及其下的色深。
fb在linux的出现目的最初是为了在linux内核启动开始后，显示linux的logo图标(小企鹅)，才增加入内核(是不是觉得有点无聊)，这种东西是通过在内核启动时在未进入保护模式之前在bios的帮助下将显卡工作模式置于FB模式下，当然以后我们也不可能再切换回来了，因为大家知道在80x86的保护模式中我们无法使用底层bios功能。
后来当然就开始使用它为linux文本控制台提供更大的字体和显示分辨率(如1024*768 32位真彩色)，并且可以使用很cool的字体，以区别于80x25列的令人枯燥的文本字体。例如你可以让linux的文本界面像黑客帝国里的尼奥的电脑。Linux2.0之后的内核，你都可以通过在内核启动参数(一般在grub或lilo的配置文件中内核镜像文件名之后)中加一条vga=<linux内核模式号>让linux在启动时进入帧缓冲控制台模式，linux内核模式号如下：
linux内核模式号 = VESA模式号+ 0x200
所以linux内核模式号如下表
| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x301 0x303 0x305 0x307
32k | 0x310 0x313 0x316 0x319
64k | 0x311 0x314 0x317 0x31A
16M | 0x312 0x315 0x318 0x31B
如果启动时出现问题，大多数情况下是显卡的问题。
后来有人使用它为其它的国家语言提供语言平台，如我们的中文平台zhcon就是使用fb来显示中文字体。
当然还有就是前面提到过的X Server：XF86_FBDev
再多说两句，对于/dev/fb*可以像访问普通文件一样访问帧缓冲存储区。希望大家利用好帧缓冲，体会Linux给我们提供的乐趣。
帧缓冲在各种显卡硬件各有不同，如ATI Rage128提供了自己的帧缓冲，Cirrus Logic，Matrox，PowerVR 2，都有自己的帧缓冲，TGA，VESA，是两种帧缓冲设备标准，VESA由于被大多数现代显卡所具有，所以使用的较为广泛。不同的帧缓冲设备需要在内核编译时使用不同的驱动。所以欲使用帧缓冲必须要拥有具有帧缓冲能力的显示卡。并且不同显卡对帧缓冲的支持能力也不同，如可以使用的分辨率模式(1024*768或800*600)及其下的色深。
fb在linux的出现目的最初是为了在linux内核启动开始后，显示linux的logo图标(小企鹅)，才增加入内核(是不是觉得有点无聊)，这种东西是通过在内核启动时在未进入保护模式之前在bios的帮助下将显卡工作模式置于FB模式下，当然以后我们也不可能再切换回来了，因为大家知道在80x86的保护模式中我们无法使用底层bios功能。
后来当然就开始使用它为linux文本控制台提供更大的字体和显示分辨率(如1024*768 32位真彩色)，并且可以使用很cool的字体，以区别于80x25列的令人枯燥的文本字体。例如你可以让linux的文本界面像黑客帝国里的尼奥的电脑。Linux2.0之后的内核，你都可以通过在内核启动参数(一般在grub或lilo的配置文件中内核镜像文件名之后)中加一条vga=<linux内核模式号>让linux在启动时进入帧缓冲控制台模式，linux内核模式号如下：
linux内核模式号 = VESA模式号+ 0x200
所以linux内核模式号如下表
| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x301 0x303 0x305 0x307
32k | 0x310 0x313 0x316 0x319
64k | 0x311 0x314 0x317 0x31A
16M | 0x312 0x315 0x318 0x31B
如果启动时出现问题，大多数情况下是显卡的问题。
后来有人使用它为其它的国家语言提供语言平台，如我们的中文平台zhcon就是使用fb来显示中文字体。
当然还有就是前面提到过的X Server：XF86_FBDev
再多说两句，对于/dev/fb*可以像访问普通文件一样访问帧缓冲存储区。希望大家利用好帧缓冲，体会Linux给我们提供的乐趣。
getit911 2005-03-05
- 打赏
- 举报
FB设备可以直接操作显存,并可以最大限度的获得硬件加速性能,驱动很小,一般是一个.ko文件,通常用于嵌入式设备的图形化界面和回放(比如机顶盒),某些软件比如mplay也可以使用fb设备在控制台下播放视频。
nodummy 2005-03-05
- 打赏
- 举报
目前似乎没有什么人用fb来编写一个X的底层……
wolke 2005-03-05
- 打赏
- 举报
长见识了。
请问所谓的vesafb是不是应该在kernel的代码树里面？
那么XFree86里面的代码分支 xc\programs\Xserver\hw\kdrive\vesa 这个又是什么呢？
能不能详细说说各种driver对应的代码位置呢？
俺只知道所谓加速的代码位于 \xc\programs\Xserver\hw\xfree86\drivers
请问所谓的vesafb是不是应该在kernel的代码树里面？
那么XFree86里面的代码分支 xc\programs\Xserver\hw\kdrive\vesa 这个又是什么呢？
能不能详细说说各种driver对应的代码位置呢？
俺只知道所谓加速的代码位于 \xc\programs\Xserver\hw\xfree86\drivers
Wolf0403 2005-03-05
- 打赏
- 举报
Framebuffer 可以理解成是打开了一个直接写屏幕的接口，可以认为没有硬件加速。是核心的一部分。vesafb 驱动必须编译在核心中，而且必须在启动时候挂载，否则无法使用。
DirectFB 是一个基于 Framebuffer 的库，支持部分加速。
真正的硬件加速还是靠 X11 的驱动吧。
DirectFB 是一个基于 Framebuffer 的库，支持部分加速。
真正的硬件加速还是靠 X11 的驱动吧。
wolke 2005-03-05
- 打赏
- 举报
fb driver 好像没有加速功能。只是充分利用显卡的内存。（这是俺的理解）
真正的显卡加速，只能由厂商做。
真正的显卡加速，只能由厂商做。
Great_Bug 2005-03-05
- 打赏
- 举报
mark
