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.

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.
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