From framebuffer to SPI via ioctl in Linux
-
This is a Linux question, hope it is OK to ask here. I am asking here since I am getting no response from original article author nor Linux forum. I am "discovering" variety of Linux ways to interface with the world. I do not particularly want to call these ways "modules". I am into using "ioctl" and having some success coding "dev" individually. Each "dev" has decent Linux documentation which I am using. The real question - how does "dev" framebuffer gets to output to "dev" SPI? I need some general comments , not particularity code samples. Appreciate any help, but if Linux questions are not appropriate here , just ignore me. Cheers.
I think the answer is in the way Linux "outputs" to memory instead to the physical device. I may get the terminology wrong - but if I direct framebuffer "memory" to SPI "memory" it should work. Assuming each "dev" has its own "memory". Time to hit the books again.
-
You can use
ioctl(). But if you have a framebuffer device for an SPI display it is much easier to use that instead of communicating directly with the display using SPI.That is the issue. I do not know - all I am using now is what this call returns system("ls -l /dev/fb*"); which is only fb0. I think I need to go back to Raspberry OS to make sure where is "fb0" connected. That part is still not clear - to what device fb0 outputs. I have only one monitor I can physically connect at a time. I suspect this fb0 is sending the output to HDMI port on RPi. Thanks for your inputs, appreciate that.
-
That is the issue. I do not know - all I am using now is what this call returns system("ls -l /dev/fb*"); which is only fb0. I think I need to go back to Raspberry OS to make sure where is "fb0" connected. That part is still not clear - to what device fb0 outputs. I have only one monitor I can physically connect at a time. I suspect this fb0 is sending the output to HDMI port on RPi. Thanks for your inputs, appreciate that.
fb0 is the HDMI port on RaspberryPi. If there is no fb1 you have to check your setup for the SPI display. It should be part of the documentation for your display. Start by loading the modules for SPI and the display manually. Once that works use the device tree to load the modules. The above applies to displays using fbtft module. Otherwise you have to use a compiled module supplied by the display manufacturer (which is always for a specific kernel / Raspbian version) or build it for your kernel.
-
fb0 is the HDMI port on RaspberryPi. If there is no fb1 you have to check your setup for the SPI display. It should be part of the documentation for your display. Start by loading the modules for SPI and the display manually. Once that works use the device tree to load the modules. The above applies to displays using fbtft module. Otherwise you have to use a compiled module supplied by the display manufacturer (which is always for a specific kernel / Raspbian version) or build it for your kernel.
Been thinking same way, so far do not see much of configuring RPi for fb1. Will keep looking for "how to " add more fbx to RPi. Just found an interesting tidbit - there is a real driver (fb?) called fbtft. However after more reading I also found that this "driver" is part of the latest Linux and is no longer actively developed. It does "reroute" framebuffer from fb0 to fb1. That is NOT what I am after - I want to use fbx and SPI on selected fbx. Back to research.
-
Been thinking same way, so far do not see much of configuring RPi for fb1. Will keep looking for "how to " add more fbx to RPi. Just found an interesting tidbit - there is a real driver (fb?) called fbtft. However after more reading I also found that this "driver" is part of the latest Linux and is no longer actively developed. It does "reroute" framebuffer from fb0 to fb1. That is NOT what I am after - I want to use fbx and SPI on selected fbx. Back to research.
That is what I told you in my first post: There is the fbtft driver that supports most of the SPI displays. It is part of the kernel tree since 2015 and included with recent Rasbian versions. It is still maintained but now as part of the kernel. I provided the original GitHub link because it does not only contain the sources (the actual sources can be found in the kernel sources) but also some documentation. It does not reroute any fb. It creates /dev/fb1 when properly configured for an attached display. But there are options to make it the default display when booting. So you have the RPi display. The name RPi was initially used by Watterott. If you have that display, see RPi-Display | Watterott electronic[^] and select FBTFT Installation in the menu on the left side. Use the provided script method or do it manually with a recent Raspbian version. For manual install see the sections FBTFT compiled into Kernel (BRANCH=builtin) (when using such a kernel) and FBTFT Device Tree enabled Kernel (works always with recent Raspbian versions).
-
That is what I told you in my first post: There is the fbtft driver that supports most of the SPI displays. It is part of the kernel tree since 2015 and included with recent Rasbian versions. It is still maintained but now as part of the kernel. I provided the original GitHub link because it does not only contain the sources (the actual sources can be found in the kernel sources) but also some documentation. It does not reroute any fb. It creates /dev/fb1 when properly configured for an attached display. But there are options to make it the default display when booting. So you have the RPi display. The name RPi was initially used by Watterott. If you have that display, see RPi-Display | Watterott electronic[^] and select FBTFT Installation in the menu on the left side. Use the provided script method or do it manually with a recent Raspbian version. For manual install see the sections FBTFT compiled into Kernel (BRANCH=builtin) (when using such a kernel) and FBTFT Device Tree enabled Kernel (works always with recent Raspbian versions).
Thanks, I finally have fdftf documentation to study. Here is the "introduction": The fbtft kernel module is a layer between the driver and the framebuffer subsystem. I'll give in a go. Still little confused with terminology Linux has a driver and fdftf is the interface between driver and framebuilder? Why is it called "subsystem" while fdftf "knows" about actuall ( hardware ) device such as SPI? Let me read the doc and hope it will make more sense after.
-
Thanks, I finally have fdftf documentation to study. Here is the "introduction": The fbtft kernel module is a layer between the driver and the framebuffer subsystem. I'll give in a go. Still little confused with terminology Linux has a driver and fdftf is the interface between driver and framebuilder? Why is it called "subsystem" while fdftf "knows" about actuall ( hardware ) device such as SPI? Let me read the doc and hope it will make more sense after.
Think more general. Drivers provide a standardised interface for a specific kind of hardware. With Linux, drivers may be built into the kernel or provided as loadable modules. In your case the standardised interface is the framebuffer and the name of the driver / module is fbtft. The driver will create the (virtual) /dev/fbx framebuffer device. So you don't have to care about the physical used interface and how to access that. It is done by the driver. Because the fbtft driver supports multiple kinds of SPI connected displays, you have to pass the name of your display and optional parameters like rotation and SPI bus speed. These can be found in the driver documentation and the documentation provided by the display manufacturer.
-
Think more general. Drivers provide a standardised interface for a specific kind of hardware. With Linux, drivers may be built into the kernel or provided as loadable modules. In your case the standardised interface is the framebuffer and the name of the driver / module is fbtft. The driver will create the (virtual) /dev/fbx framebuffer device. So you don't have to care about the physical used interface and how to access that. It is done by the driver. Because the fbtft driver supports multiple kinds of SPI connected displays, you have to pass the name of your display and optional parameters like rotation and SPI bus speed. These can be found in the driver documentation and the documentation provided by the display manufacturer.
Now it makes sense, and some folks thinks I am too hang-up on terminology. Here is part of my "test code" so far. It's fun. I am having some small issues- cannot "create" custom device... Thanks for all your comments and help. Cheers Vaclav
system("ls -l /dev/fb*"); sleep(2);
system("sudo modprobe fbtft_device custom name=SPI_TEST buswidth=8 gpios=reset:25,dc:24");
//sleep(1);
system("sudo modprobe fbtft_device custom name=_ANOTHER_SPI_TEST buswidth=8 gpios=reset:25,dc:24");
system("sudo modprobe fbtft_device name=adafruit22A");
system("sudo modprobe fbtft_device name=adafruit28");
system("sudo modprobe fbtft_device custom name=adafruit22A buswidth=8 gpios=reset:25,dc:24");
system("sudo modprobe fbtft_device custom name=adafruit28 buswidth=8 gpios=reset:25,dc:24");
cout << "// \n is it there ? \n "<< endl;
sleep(2); // print the tail of dmesg - some
system("sudo modprobe fbtft_device name=list; dmesg | tail -250");
system("ls -l /dev/fb*"); -
Now it makes sense, and some folks thinks I am too hang-up on terminology. Here is part of my "test code" so far. It's fun. I am having some small issues- cannot "create" custom device... Thanks for all your comments and help. Cheers Vaclav
system("ls -l /dev/fb*"); sleep(2);
system("sudo modprobe fbtft_device custom name=SPI_TEST buswidth=8 gpios=reset:25,dc:24");
//sleep(1);
system("sudo modprobe fbtft_device custom name=_ANOTHER_SPI_TEST buswidth=8 gpios=reset:25,dc:24");
system("sudo modprobe fbtft_device name=adafruit22A");
system("sudo modprobe fbtft_device name=adafruit28");
system("sudo modprobe fbtft_device custom name=adafruit22A buswidth=8 gpios=reset:25,dc:24");
system("sudo modprobe fbtft_device custom name=adafruit28 buswidth=8 gpios=reset:25,dc:24");
cout << "// \n is it there ? \n "<< endl;
sleep(2); // print the tail of dmesg - some
system("sudo modprobe fbtft_device name=list; dmesg | tail -250");
system("ls -l /dev/fb*");Read the documentation at fbtft_device · notro/fbtft Wiki · GitHub[^]:
Quote:
Use the speed= argument to make it a SPI device, or else it becomes a platform_device
You have an SPI device and omitting the
speedargument will not find it. Also, why did you not usedsudo modprobe fbtft_device name=rpi-display speed=32000000
when having a Watterott RPi display?
-
Read the documentation at fbtft_device · notro/fbtft Wiki · GitHub[^]:
Quote:
Use the speed= argument to make it a SPI device, or else it becomes a platform_device
You have an SPI device and omitting the
speedargument will not find it. Also, why did you not usedsudo modprobe fbtft_device name=rpi-display speed=32000000
when having a Watterott RPi display?
Yes, that is a doc I have been using. I seems to have to run the app twice before the new device shows up as replacement for the SPI 0. Also system("ls -l /dev/fb*") does not show the fb1 on first try. Maybe I need to do some kind of "update". Just a note - perhaps fbtft is good only for fb0 / fb1. But taht doe snot matter now. It's good to know about the "speed" . It just shows to pay attention to every detail.
-
Read the documentation at fbtft_device · notro/fbtft Wiki · GitHub[^]:
Quote:
Use the speed= argument to make it a SPI device, or else it becomes a platform_device
You have an SPI device and omitting the
speedargument will not find it. Also, why did you not usedsudo modprobe fbtft_device name=rpi-display speed=32000000
when having a Watterott RPi display?
Yes, that is a doc I have been using. I seems to have to run the app twice before the new device shows up as replacement for the SPI 0. Also system("ls -l /dev/fb*") does not show the fb1 on first try. Maybe I need to do some kind of "update". Just a note - perhaps fbtft is good only for fb0 / fb1. But taht doe snot matter now. It's good to know about the "speed" . It just shows to pay attention to every detail.