search

notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.85k stars 493 forks source link

need for help: framebuffer number assigned differently #518

Closed khalifima closed 3 years ago

khalifima commented 6 years ago

I am using fbtft to display on five ili9340 compatible displays simultaneously using raspberry pi zero w i created the dt overlays and so far everything is working i could display on each of the displays. but the framebuffer numbering is somehow not deterministic sometimes it assigns dev/fb1 to the display attached to spi0.1 other times to another display e.g spi1.0 . could someone tell whether it is possible to fix the framebuffer assignement to a specified spi bus number??

notro commented 6 years ago

Since you use the same driver for all displays, it's the device order that decides framebuffer numbering. Are the displays on the same spi bus with five chip selects, or on multiple busses?

notro commented 6 years ago

I saw you're email:

what i want is something like: /dev/fb1 >> spi0.0 /dev/fb2 >> spi0.1 /dev/fb3 >> spi1.0 /dev/fb4 >> spi1.1 /dev/fb5 >> spi1.2

i have tried reordering dtoverlay call in /boot/config.txt and it does not help

Reordering dtoverlay statements doesn't effect ordering, since the resulting Device Tree is what the kernel parses. When the spi controller driver loads, it parses it's DT node for spi devices and converts them to real spi devices in of_register_spi_devices.

So I guess what can change in your setup is the load order of the spi controller drivers. spi0 is spi_bcm2835 and spi1/2 is spi_bcm2835_aux or something. udev autoloads modules for devices if it can, which probaly is what is happening for you. Try loading the modules "manually" like described here: https://github.com/notro/fbtft/wiki#make-it-permanent-debian-jessie-arch-linux-systemd

Be aware that spi0 is much faster than spi1/2 because it can do dma transfers which is a significant speedup on full display updates. On spi1/2 the cpu has to fill the fifo itself using interrupts.

tabarnakos commented 5 years ago

Hey @khalifima,

I know this thread is 1 year old, but I can't for the life of me figure out how to map a single display from spi1.0 to fb0

Any chance you can share your code?

I just want to use the tft as some kind of debug console, but somehow every library I find will not work on fb1

notro commented 5 years ago

The fbdev numbering (fbN) is controlled by the order in which the drivers are registered. On the Pi, the firmware sets up a framebuffer that the early simplefb driver hooks into and it gets fb0:

[    1.043103] simple-framebuffer 1e887000.framebuffer: fb0: simplefb registered!

fb0 is what the console is attached to by default. See here for how to change that: https://github.com/notro/fbtft/wiki/Boot-console You can also change it at runtime by using con2fbmap.

In the case of the Pi, later in the boot process the simplefb driver is unbound and either the Pi fbdev driver is bound and gets fb0 (or the vc4 driver, depending on config).

So if you really need fb0 for your tft display, you need to block the other drivers from loading until the tft driver has loaded so it gets fb0.

tabarnakos commented 5 years ago

So far even though the tft is properly set up as /dev/fb1, (using modprobe) I have been unsuccessful with both "startx" methods and "con2fbmap". (startx crashes, con2fbmap does nothing)

Since my device is purely accessed via ssh, I have needs for neither hdmi nor composite output, I should find a way to disable those drivers.

My next step was to look into the device tree method to see if it works better.

notro commented 5 years ago

This should put the console on the tft: con2fbmap 1 1. As for X windows, in this file: /usr/share/X11/xorg.conf.d/99-fbturbo.conf Change this line: Option "fbdev" "/dev/fb0"

Using Device Tree doesn't help with this problem. It doesn't affect the driver probing order. Unless you remove devices ofc.

tabarnakos commented 5 years ago

Thanks for your help. I was able to successfully enable the display on /dev/fb1, and use it for both console of x session. I assigned it as boot console as well, and I would like to compile it into the kernel to display entire boot process now, but I will start a new thread for that.

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.