jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Thu Mar 11, 2021 3:09 am

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

Here are the issues and solutions I've selected thus far:

1. Dual displays, one of which is an SPI connected LCD panel
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.

Here are my additions to /boot/config.txt:

Code: Select all

max_framebuffers=2

## For Sharp LS055R1SX04 LCD display------------
hdmi_ignore_edid=0xa5000080
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_drive=1
disable_overscan=1
framebuffer_width=1440
framebuffer_height=2560
max_framebuffer_width=1440
max_framebuffer_height=2560
hvs_priority=0x32ff
hdmi_pixel_freq_limit=400000000
hdmi_timings=1440 0 112 160 272 2560 0 4 4 3 0 0 0 48 0 244940000 3


## TFT screen configuration--------
dtoverlay=rpi-display

## Framebuffer color depth must match for X11 to run without error
framebuffer_depth=16

gpu_mem=256
The TFT LCD was wired as so:

Code: Select all

LCD label    GPIO/Header Pin
T_IRQ     ->  25/11
T_DO     ->   9(MISO)/21
T_DIN    ->   10(MOSI)/19
T_CS     ->    7(CE1)/13
T_CLK   ->    11(SCLK)/23
SDO(MISO) ->  9(MISO)/21
LED        ->    18/12   (or 3.3v for "always on")
SCK       ->     11(SCLK)/23
SDI(MOSI)   ->  10(MOSI)/19
DC         ->    24/18
RESET   ->   23/16
CS         ->   8(CE0)/24
GND      ->   Gnd/25
VCC      ->   3.3v/17
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.

I then moved on to the customized X11 configuration file mentioned in the reference post.

The relevant X11 configuration files are located in /usr/share/X11/xorg.conf.d. The reference forum post mentioned replacing the contents of the file 99-fbturbo.conf. My first problem that took way to long to discover: 99-fbturbo.conf gets automatically deleted if the vc4-fkms-v3d overlay is activated (which is the default for a RasPi4). So, the configuration would work fine, but would suddenly stop working if the Pi is rebooted! :shock: :x As it turns out, you can name this file whatever you want. ALL files with the .conf extension in this directory are parsed and processed in alphabetical order, so I just renamed it something else. I also cut down the original posts' config to the "bare essential" entries that had an actual effect. Here is the contents of the now named 99-multihead.conf:

/usr/share/X11/xorg.conf.d/99-multihead.conf

Code: Select all

Section "Device"
        Identifier      "fbturbo0"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb0"
        Option          "SwapbuffersWait" "true"   
EndSection

Section "Device"
        Identifier      "fbturbo1"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"
        Option          "SwapbuffersWait" "true"
EndSection

Section "Monitor"
    Identifier "HDMI0"
    Option "Primary" "False"
EndSection

Section "Monitor"
    Identifier "TFT-SPI"
    Option "RightOf" "HDMI0"
    Option "Primary" "False"
EndSection

Section "Screen"
    Identifier "ScreenHDMI"
    Monitor "HDMI0"
    Device "fbturbo0"
    Subsection "Display"
    EndSubSection
EndSection

Section "Screen"
    Identifier "ScreenTFT"
    Monitor "TFT-SPI"
    Device "fbturbo1"
    Subsection "Display"
    EndSubSection
EndSection

Section "ServerLayout"
    Identifier "Multihead"
    Screen  0 "ScreenHDMI"
    Screen  1 "ScreenTFT" rightof "ScreenHDMI"
    Option  "Xinerama" "true"
EndSection

Section "ServerLayout"
    Identifier "Singlehead0"
    Screen  0 "ScreenHDMI"
EndSection

Section "ServerLayout"
    Identifier "Singlehead1"
    Screen  0 "ScreenTFT"
EndSection

Section "InputClass"
        Identifier "Touchscreen Calibration"
        MatchProduct "ADS7846 Touchscreen"
        Driver "libinput"
        Option "TransformationMatrix" "0.1818 0 0.8181 0 -0.09375 0.09625 0 0 1"
EndSection


Section "ServerFlags"
    Option "BlankTime"  "0"
    Option "StandbyTime"  "0"
    Option "SuspendTime"  "0"
    Option "OffTime"  "0"
    Option "DefaultServerLayout" "Multihead"
EndSection
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.

2. Booting to Desktop GUI in Dual Mode
Simply using raspi-config's System Options to boot to the Desktop works as expected, as my X11 configuration changed the last option in the "ServerFlags" section to:

Code: Select all

Option "DefaultServerLayout" "Multihead"
3. Getting touch screen to tap in the correct area
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:

a. Modified /boot/config.txt
dtoverlay=rpi-display,rotate=90,swapxy=1

b. Added to /usr/share/X11/xorg.conf.d/99-multihead.conf

Code: Select all

Section "InputClass"
        Identifier "Touchscreen Calibration"
        MatchProduct "ADS7846 Touchscreen"
        Driver "libinput"
        Option "TransformationMatrix" "0.1818 0 0.8181 0 -0.09375 0.09625 0 0 1"
EndSection
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:

Code: Select all

max-x-res-tft / (max-x-res-sharp + max-x-res-tft)
0
1 - <first number>
0
max-y-res-tft / max-y-res-sharp * -1
above *-1 plus some fudge to calibrate
0
0
1
I found this link helpful to play with the transformation numbers: https://codepen.io/GottZ/full/pWpNgK/

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

4. Changing background image or color on both displays
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:

<user_home>/.config/pcmanfm/LXDE-pi/desktop-items-0.conf
<user_home>/.config/pcmanfm/LXDE-pi/desktop-items-1.conf

where "<user_home>" is either /home/pi or /root or whatever user you are logged in as.

The "0" and "1" in the file names correspond to display numbers. Entries such as this in each file will make both match:

Code: Select all

wallpaper_mode=color
desktop_bg=#151515
desktop_fg=#ffffff
Well, that is it for my contribution to the excellent work @aBugsWorstNightmare did to get the ball rolling.

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?
Last edited by 6by9 on Mon Oct 18, 2021 5:10 pm, edited 3 times in total.
Reason: Fix forum URL

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Thu Mar 11, 2021 10:46 am

jkoz wrote:
Thu Mar 11, 2021 3:09 am
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?
Not to the best of my knowledge, although with possibly one caveat.

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)

If it is a DRM device, then I would expect X to be able to render to that as an alternate output device, providing it supports a suitable pixel format.
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.

It's not just that it's disabled by default? Again "xrandr --verbose" may give more information.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Thu Mar 11, 2021 6:19 pm

Thanks for the response @6by9!

So, "TinyDRM" is new to me. Of all the extensive google searches I did, I never came across this. Adding "tinydrm" to my previous searches has revealed a lot of new information to explore. So far, this is what I have uncovered:

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:

Code: Select all

    fragment@4 {
...
            rpi-display@0 {
                compatible = "ilitek,ili9341";
If I then issue cat /lib/modules/5.10.17+/modules.alias | grep 9341 I see these results:

Code: Select all

alias of:N*T*Cadafruit,yx240qv29C* ili9341
alias of:N*T*Cadafruit,yx240qv29 ili9341
alias spi:yx240qv29 ili9341
alias platform:ili9341 fb_ili9341
alias spi:ili9341 fb_ili9341
alias platform:fb_ili9341 fb_ili9341
alias spi:fb_ili9341 fb_ili9341
alias of:N*T*Cilitek,ili9341C* fb_ili9341
alias of:N*T*Cilitek,ili9341 fb_ili9341
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:

Code: Select all

			rpidisplay: rpi-display@0{
				compatible = "mi,mi0283qt";
which is of course a different driver. I already had a customized overlay source, so I changed it to use the mentioned "mi0283qt" driver. It did not work (my screen remains blank white). I also tried the straight ili9341 driver (with no "fb_" prefix). Both showed results from modetest, but the screen remained white.

I suspect that perhaps my pins may not be set up correctly for those drivers? The overlay sources seemed to indicate they were the same, but I don't know if that is true.

I'm not sure if I uncovered an inconsistency in what is supposed to be in the distribution, or if in order to get this to work, I need to download and compile the drivers? I'll keep experimenting, but I wanted to report what I found thus far.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Thu Mar 11, 2021 7:14 pm

Yes, it looks like it has actually been merged to mainline as just tiny - https://github.com/raspberrypi/linux/tr ... u/drm/tiny
I'd only skim read the code and thought that the DRM driver was being loaded, but it looks like it's not.

https://github.com/raspberrypi/linux/bl ... _ili9481.c is the fb version. fbtft is being deprecated and converted to DRM drivers, as in the TODO

If it's not working then it should be possible to do a comparison of the register settings between the two.

I've ordered up one of these displays to have a play with, so I'll see what it ends up doing.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Thu Mar 11, 2021 10:44 pm

So I just looked at the source code you referenced. I assume by this:

Code: Select all

static const struct of_device_id ili9341_of_match[] = {
	{ .compatible = "adafruit,yx240qv29" },
	{ }
};
That I should be able to reference that driver in dtoverlay with:

Code: Select all

        fragment@4 {
...
                        rpidisplay: rpi-display@0{
                                compatible = "adafruit,yx240qv29";
So, I tried that, and I get what looks like something connected:

Code: Select all

pi@pcb2:~ $ modetest -M ili9341 
Encoders:
id	crtc	type	possible crtcs	possible clones	
35	34	none	0x00000001	0x00000001

Connectors:
id	encoder	status		name		size (mm)	modes	encoders
31	35	connected	(null)-1       	37x49		1	35
  modes:
	index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 240x320 0.01 240 240 240 240 320 320 320 320 1 flags: ; type: preferred, driver
  props:
	1 EDID:
		flags: immutable blob
		blobs:

		value:
	2 DPMS:
		flags: enum
		enums: On=0 Standby=1 Suspend=2 Off=3
		value: 0
	5 link-status:
		flags: enum
		enums: Good=0 Bad=1
		value: 0
	6 non-desktop:
		flags: immutable range
		values: 0 1
		value: 0
	4 TILE:
		flags: immutable blob
		blobs:

		value:

CRTCs:
id	fb	pos	size
34	36	(0,0)	(240x320)
  #0 240x320 0.01 240 240 240 240 320 320 320 320 1 flags: ; type: preferred, driver
  props:
	24 VRR_ENABLED:
		flags: range
		values: 0 1
		value: 0

Planes:
id	crtc	fb	CRTC x,y	x,y	gamma size	possible crtcs
32	34	36	0,0		0,0	0       	0x00000001
  formats: RG16 XR24
  props:
	8 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 1
	30 IN_FORMATS:
		flags: immutable blob
		blobs:

		value:
			01000000000000000200000018000000
			01000000200000005247313658523234
			03000000000000000000000000000000
			0000000000000000
		in_formats blob decoded:
			 RG16:  LINEAR
			 XR24:  LINEAR

Frame buffers:
id	size	pitch
But when I try this:

Code: Select all

modetest -M ili9341 -s 31:240x320
setting mode 240x320-0.01Hz on connectors 31, crtc 34
failed to set gamma: Function not implemented
The screen remains white, and the terminal hangs. I need to ctrl-C to break out.

Assuming I did this right, I'm interested to see if the screen you ordered behaves the same.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 12, 2021 10:32 am

That all looks positive, but obviously not right.

I do note that the mi0283qt driver also appears to be a 320x240 ILI934 based panel from looking at the source. That's also the compatible ("multi-inno,mi0283qt") referenced by notro in https://github.com/notro/tinydrm/issues/14 (different vendor prefix though). It'd be nice to know the differences.

Looking at the gamma command it looks like a better match though
https://github.com/raspberrypi/linux/bl ... 9341.c#L26 vs https://github.com/raspberrypi/linux/bl ... 83qt.c#L96
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 12, 2021 4:03 pm

6by9 wrote:
Fri Mar 12, 2021 10:32 am
That's also the compatible ("multi-inno,mi0283qt") referenced by notro
So I just tried that also for grins, but same result - still no image:

Code: Select all

modetest -M mi0283qt -s 31:320x240
setting mode 320x240-0.01Hz on connectors 31, crtc 34
failed to set gamma: Function not implemented
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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 12, 2021 4:32 pm

Well my display works with the if you ignore Waveshare's wiring and base it on the DT overlay.

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.

A small amount of overlay rework to address that.

Then I made a guess that the reset GPIO may be taking the opposite sense. Make that change and modetest will write to it!

Code: Select all

/*
 * Device Tree overlay for rpi-display by Watterott
 *
 */

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&spi0>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target = <&spidev0>;
		__overlay__ {
			status = "disabled";
		};
	};

	fragment@2 {
		target = <&spidev1>;
		__overlay__ {
			status = "disabled";
		};
	};

	fragment@3 {
		target = <&gpio>;
		__overlay__ {
			rpi_display_pins: rpi_display_pins {
				brcm,pins = <18 23 24 25>;
				brcm,function = <1 1 1 0>; /* out out out in */
				brcm,pull = <0 0 0 2>; /* - - - up */
			};
		};
	};

	fragment@4 {
		target = <&spi0>;
		__overlay__ {
			/* needed to avoid dtc warning */
			#address-cells = <1>;
			#size-cells = <0>;

			rpidisplay: rpi-display@0{
				compatible = "multi-inno,mi0283qt";
				reg = <0>;
				pinctrl-names = "default";
				pinctrl-0 = <&rpi_display_pins>;

				spi-max-frequency = <32000000>;
				rotation = <270>;
				bgr;
				fps = <30>;
				buswidth = <8>;
				reset-gpios = <&gpio 23 0>;
				dc-gpios = <&gpio 24 0>;
				debug = <0>;
				backlight = <&backlight>;
			};

			rpidisplay_ts: rpi-display-ts@1 {
				compatible = "ti,ads7846";
				reg = <1>;

				spi-max-frequency = <2000000>;
				interrupts = <25 2>; /* high-to-low edge triggered */
				interrupt-parent = <&gpio>;
				pendown-gpio = <&gpio 25 1>;
				ti,x-plate-ohms = /bits/ 16 <60>;
				ti,pressure-max = /bits/ 16 <255>;
			};
		};
	};

	fragment@5 {
		target-path = "/";
		__overlay__ {
			backlight: backlight {
				compatible = "gpio-backlight";
				gpios = <&gpio 18 0>;
			};
		};
	};

	__overrides__ {
		speed =     <&rpidisplay>,"spi-max-frequency:0";
		rotate =    <&rpidisplay>,"rotate:0";
		fps =       <&rpidisplay>,"fps:0";
		debug =     <&rpidisplay>,"debug:0";
		xohms =     <&rpidisplay_ts>,"ti,x-plate-ohms;0";
		swapxy =    <&rpidisplay_ts>,"ti,swap-xy?";
		backlight = <&rpidisplay>,"led-gpios:4",
		            <&rpi_display_pins>,"brcm,pins:0";
	};
};
I don't have the touchscreen on my display, so that is totally untested.

Unfortunately my hope that X would then choose to render to both DRM devices.
I'll have to break out my x86 box and see what it is doing if I stick two different graphics cards in it (here's hoping it has multiple PCIe slots).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 12, 2021 5:44 pm

Hmm, my x86 system (Ubuntu 20.10 with 5.8 kernel) seems quite happy to share the desktop between two graphics cards (one Radeon 6450 (XFX 6450 HD-645-ZQ 1GB), and one Nvidia Geforce GT710).
(Performance is another matter, but they are old or low-end cards)

This is where my knowledge of X configuration runs out.
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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Mon Mar 15, 2021 8:43 pm

@6by9

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.

So, at this point, I'm wondering if the driver has some bugs in it, or if it's in some interaction between X and the driver.

At this point, I'm going to just fall back to the configuration I posted at the beginning of this first thread. It seems to work fine. And while it may in theory not be ideal, it works for my purposes (I'm creating a very basic touch UI on the touchscreen. I'm not trying to stream video to it or anything crazy).

I'll keep the "the legacy driver is being deprecated" in the back of my head for future purposes. Maybe by the time that happens, if this configuration is still needed, someone will have taken the information in this thread and figured out the problem.

Thanks for all your help!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Tue Mar 16, 2021 7:57 pm

Thanks for coming back to me.

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?

I do wonder if X gets confused as one display supports a cursor plane whilst the other doesn't, so does it render that through GL or not?

Ah, xrandr --listproviders shows me the SPI display

Code: Select all

pi@raspberrypi:~ $ DISPLAY=:0 xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7a cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x41 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 1 outputs: 1 associated providers: 0 name:modesetting
Now to work out how to enable it....
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Wed Mar 17, 2021 11:45 am

Next small step is that

Code: Select all

xrandr  --setprovideroutputsource 1 0
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

Code: Select all

xrandr --output Unknown19-1 --auto
then wakes that display up and displays the desktop and is usable!!!

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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Wed Mar 17, 2021 12:32 pm

Ah, further note, I'm running vc4-kms-v3d (not fkms). It shouldn't make any real difference though.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 19, 2021 9:35 pm

6by9 wrote:
Wed Mar 17, 2021 11:45 am
Next small step is that

Code: Select all

xrandr  --setprovideroutputsource 1 0
is needed for xrandr to see the display
...

Code: Select all

xrandr --output Unknown19-1 --auto
then wakes that display up and displays the desktop and is usable!!!
Well hows about that!!

So, I repeated the steps again. My output from xrandr is

Code: Select all

 xrandr
Screen 0: minimum 320 x 200, current 1440 x 2560, maximum 7680 x 7680
HDMI-1 connected primary 1440x2560+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   FIXED_MODE    48.02*+
Unknown19-1 connected (normal left inverted right x axis y axis)
   240x320        0.01 +
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 looks like this configuration indeed can be made to work, but there are still some settings that need to be tweaked somewhere.

jkoz
Posts: 8
Joined: Thu Mar 11, 2021 12:17 am

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 19, 2021 9:36 pm

6by9 wrote:
Wed Mar 17, 2021 12:32 pm
Ah, further note, I'm running vc4-kms-v3d (not fkms). It shouldn't make any real difference though.
I was using the default fkms in my above tests, so I think it "sort of" works with either configuration.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12155
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Dual display support with legacy driver (HDMI + SPI-LCD on RPi4)

Fri Mar 19, 2021 9:53 pm

jkoz wrote:
Fri Mar 19, 2021 9:35 pm
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 looks like this configuration indeed can be made to work, but there are still some settings that need to be tweaked somewhere.
Having the same origin but different sizes is the default. That's the situation where I lost my mouse cursor on the SPI screen.

Code: Select all

xrandr --output Unknown19-1 --right-of HDMI-1
Replace --right-of with --left-of, --above, or --below as required, or use the Screen Configuration app (arandr) to graphically drag things around.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “General discussion”