Friday, 23 August 2013

An introduction and the frame buffer theory

My adventure with Raspberry Pi was started by chance. Some time ago my friend Maciek showed me Raspberry Pi and say that I can lend it for some time.I wondered about Raspberry application. First thought was a radio device with some 802.15.04 transceiver connected via SPI with the board. But then I found one LCD COG display with st7565r controller that I have used for some old project. I resigned from transsiver project and I decide to make some experiments with LCD and spi driver.

I began with little knowledge about Linux driver development. I had experience only with simple character device driver. Linux drivers seemed to be complicated to me. Therefore I decided to overcome my fear of Linux driver and create own from a scratch. I was starting read about Linux and device drivers.

I have read Essential Linux DeviceDrivers by Sreekrishnan Venkateswaran – is was a great introduction to my adventure with Linux drivers, there is a very good chapter about video driver with suitable information about frame buffer.

My LCD has a graphical display with 132x64 resolution. St7565r controller can be connected by SPI or parallel port. Here is a very nice page about it.

If I had a character LCD display it would be the best option to create a simple character device driver with supported file operations eg. open(), close(), write() and maybe ioctl for device specific operations like contrast setup. 

Yeah - but I wondered about something more and I have found information about frame buffer. 

Most device drivers are not directly implemented as character devices or block devices. They are implemented under a framework , specic to a device type (frame buffer, V4L, serial, etc.). The framework allows to factorize the common parts of drivers for the same type of devices. From userspace, they are still seen as normal character devices. The framework allows to provide a coherent userspace interface (ioctl numbering and semantic, etc.) for every type of device, regardless of the driver. 

The frame buffer is intermediate layer between higher kernel layers and video drivers. To present something on display with frame buffer support we need to implement specific programing interface. I think that frame buffer can consider as a proxy design pattern. The frame buffer provider general abstraction to handle all forms of video device.

User's applications can interface with the frame buffer by file operations or in other way (using mmap for example). The frame buffer has own ioctl method to set up video devices. All of structures are defined in include/linux/fb.h, fb_ioctl is defined in drivers/video/fbmem.c.
Fb_info is the main structure with all information about frame buffer. I prepare simplified diagram of it.

Now we have enough information to move forward. In the next post I will describe driver implementation details.

No comments:

Post a comment