config.txt display_default_lcd adafruit 2.8 tft lcd display price

Going further I plugged a HDMI display and Voila! there is my Desktop, but no mirror at all. Even the touchscreen is working and I can move de cursor over the Desktop (HDMI) with my finger on the 2.8" display.

Going further again, with the HDMI plugged and choosing console I can startx and the desktop goes to HDMI, then I can see running Xorg using top from SSH. Restart again the script and I choose mirror, no HDMI connected and black screen over the TFT, but I also can see Xorg running.

I just finished two solid days of work trying to get an HDMI LCD panel working with one of the inexpensive older model TFT LCD displays in a "Dual mode" configuration. There was a tremendous amount of help from this post, which got me most of the way there, but the infamous "last mile" still took me a while. I"m leaving some breadcrumbs here, as well as asking the group if anyone knows of a better way.

I am working on a device that uses a Raspberry Pi 4 as an embedded controller. For output, I need an 2K DSI LCD w/ its own HDMI adapter (Sharp LS055R1SX04, about $65 USD), as well as an inexpensive TFT LCD used for a basic touch user interface. The TFT LCD, which uses an ILI9341 LCD controller and an ads7846 touchscreen controller, can be had for about $10 USD. The Pi was flashed with the latest Raspberry Pi OS 32 bit then updated, so everything is current as of this writing (March 2021).

Initial configuration of the display worked with little issue. The HDMI adapter for the Sharp LCD works at 50 Hz only, so it requires custom timings. The TFT LCD uses the same controller chips as the original 3.5" Raspberry Pi LCD, so I was able to activate it with the rpi-display dtoverlay.

Booting with the above correctly revealed two framebuffer devices listed with ls -l /dev/fb*. The display initially showed as all white, then went all black, indicating correct initialization. However, when starting the desktop GUI, only the Sharp LCD showed any contents, and only it was listed as a device by xrandr.

The above configuration seems to work well. Both displays showed data. VNC showed a single combined desktop. Moving a window from left to right moved to the appropriate display as expected by the Option "Xinerama" "true" option of the server layout.

Based on claims of the above not being "ideal", I experimented with various settings. If the above file is deleted entirely, xrandr reports the Sharp LCD as the sole display. If you put the above file in place, and remove all references to the Sharp LCD (including the Device, Monitor, Screen, and ServerLayouts), xrandr correctly reports the TFT LCD, but not the Sharp LCD. I left JUST the Device sections in, but xrandr failed to correctly report one of the other.

No matter what combinations I tried, I was unable to get xrandr to list both the HDMI display and the SPI display at the same time. If all parts above ARE explicitly listed in the configuration, running xrandr reports an error that the RandR extension is not loaded. Thus I was unable to use the more advanced built in layout management of X11 using the RandR extension.

Since xrandr was INOP in this configuration, I could not use xinput --map-to-output to limit touchscreen coordinates to the TFT LCD. Instead, I settled on using a combination of touch screen rotation, and input coordinate translation:

Note that the TransformationMatrix is very specific to a 1440x2560 in portrait mode with 320x240 in landscape mode to the right of the Sharp LCD. The numbers are basically:

You may be tempted to try to hack a dtoverlay that uses the ads7846 driver and specifies the x-min, x-max, etc. parameters. Don"t. I wasted a huge amount of time on this. While you can specify min/max, they apparently do NOT affect the output of that driver. The raw numbers are still reported when watching X11 input events via sudo DISPLAY=:0.0 evtest /dev/input/event0 no matter what the min/max parameters to that driver are.

The reference post noted that you can"t change the background color or image of the small display with this configuration. While that is true using the GUI, those configuration options are stored in the following files:

My question to the group, if anyone knows, is simple: is it possible to configure a Pi4 so an SPI connected LCD can co-exist without disabling the RandR extension in X11?

My question to the group, if anyone knows, is simple: is it possible to configure a Pi4 so an SPI connected LCD can co-exist without disabling the RandR extension in X11?

Xserver wants to talk to either DRM/KMS for all rendering, or goes to /dev/fbX nodes if there is no DRM/KMS available (and then Xinerama is required to support multiple displays).

With DRM/KMS X will render one "super desktop" covering all displays in their correct positions, and then tell each DRM/KMS device to display the correct bit of it. That"s how it works with dual HDMI on Pi4.

Now these SPI displays used to be driven by a driver that only exposed them as /dev/fbX nodes. They now appear to be under the tinydrm driver, so I would have expected them to show up as DRM/KMS devices. The output from modetest would be interesting to see (X can not be running when you run modetest). "xrandr --verbose" may tell you if you have vc4-(f)kms-v3d enabled. (Sorry, I don"t have one of these displays to test with)

That is how I believe things work if you were to drop 2 different graphics cards into an x86 PC - one does all the rendering through OpenGL, and then they each get told which bits of the resultant image to display.

As I mentioned in my initial post, what "works" for me is the "rpi-display" overlay. If I execute fdtdump /boot/overlays/rpi-display.dtbo on my current configuration, I see this fragement:

I"m not real familiar with this stuff (I stumbled across it while I was stuck in the mud), but I assume by these results that there are two different drivers possible: fb_ili9341 which is the framebuffer version, and ili9341 which I assume is the DRM version. If I understand how this all fits together, it appears that when I select the "rpi-display" overlay, its picking the framebuffer version due to the last line in modules.alias?

Adding "tinydrm" to my google searches revealed this Github issue: https://github.com/notro/tinydrm/issues/14, and it mentions in passing "here is an example overlay source file", pointing to the rpi-display overlay. However, when I look at the referenced source, https://github.com/notro/tinydrm/blob/m ... verlay.dts, it contains this:

Is it fair to say that there is more to a board than just saying it"s controlled by a an ILS9341? That seems to be the case with these multiple initialization sequences. I believe my board to be one from HiLetgo. Is it possible to create a DRM driver that functions EXACTLY like the fb_ili9341? Another possibility: for $10 USD, I could just get another board. That certainly might be easier. I"d just like to know the best way to match a board to a driver. The "brand name" ADAfruit board is $27 - almost 3 x the cost of the Hiletgo. Not super significant for a one-off, but a significant increase in unit cost.

Switching to the "multi-inno,mi0283qt" compatible and I get nothing. Reading the DT bindings, the backlight has been moved from being a GPIO property of the display to being a link to the backlight device driver, so it"s understandable that the backlight stays off.

On my CM4 xrandr didn"t even list the extra SPI display, whereas on x86 it is listing all the connected and disconnected displays (7 of them total!). On both systems they show up under /sys/class/drm, so it may be the way that X enumerates the displays.

So, I tried the dtoverlay you posted, and sure enough - I was also able to get a test pattern using modetest! So, that explains part 1 - the pinout is different on some of these displays.

Next, I removed my previous 99-multihead-conf file from my "/usr/share/X11/xorg.conf.d/" and restarted the desktop manager. I opened a terminal window, entered "xrandr", and both displays listed! I thought it was solved, but at that point, my poor little Pi completely locked up. I had this same problem in the past when I was trying the various DRM driver overlays. The desktop just became very unstable.

Strange that the SPI display showed up for you but not me, even if it did then crash. I"ve tried an upgrade of my RaspiOS 32bit install (although with latest kernel) and it still doesn"t want to acknowledge the SPI display through xrandr. Could you post the output from xrandr when it sees both displays?

is needed for xrandr to see the display (listed as Unknown19-1 for me, presumably as X hasn"t been built with any knowledge of DRM_MODE_CONNECTOR_SPI being 19. https://elixir.bootlin.com/linux/latest ... ode.h#L390

However it is as I suspected - we have no mouse pointer on the TFT screen, presumably as X can"t cope with one display having a cursor plane and the other not. I don"t know the best way to overcome that.

*edit*: Minor correction there. If the two displays overlap, then the mouse cursor disappears on the SPI screen. If you set them to be independent (eg "xrandr --output Unknown19-1 --right-of HDMI-1"), then X switches mode and renders the mouse cursor.

Which sounds like yours (i.e the "Unknown19-1). I got the "lock up" again, but it turns out that lock-up was actually VNC (I"ve been using that to develop, as the text on a Sharp LCD is VERY tiny to look at in desktop mode). My console was still alive, so I hooked up an actual keyboard and mouse to the Pi, and the desktop on my Sharp LCD came alive. With the above two commands you"ve discovered, I now have two desktops. Sort of...

It appears as if the upper left hand corner of my Sharp LCD desktop is mirrored on the small LCD. It"s not two independent desktops. Instead, it"s the same desktop duplicated. I suspect that is probably more X configuration than driver stuff, however.

It appears as if the upper left hand corner of my Sharp LCD desktop is mirrored on the small LCD. It"s not two independent desktops. Instead, it"s the same desktop duplicated. I suspect that is probably more X configuration than driver stuff, however.

4) After the image has finished writing, open the config.txt file in the root directory of the TF card, add the following code at the end of config.txt, then save and quit the TF card safely.

5) Insert the TF card into the Raspberry Pi, power on the Raspberry Pi, and wait for more than 10 seconds to display normally. But the touch is abnormal at that time, and the touch needs to be calibrated as the following steps.

You can perform touch calibration by clicking the Raspberry Pi icon on the taskbar, selecting Preferences -> Calibrate Touchscreen, and following the displayed prompts.

4. After calibration, the following data will be displayed. If you want to save these touch values, you can replace the data in the red circle with the data in the corresponding position in 99-calibration.conf.