I3 on Raspberry Pi 4 with dual monitors

Hello! New forum user here, looking for a little guidance and hoping someone here might have some.

I have a 4GB Raspberry Pi 4 that I have installed Manjaro i3 20.08 on a standard SD card. Everything is working great but I am relatively new to the i3wm. I have two monitors I would like to use with the Pi (one is hooked up with a standard HDMI cable and the other is using a HDMI to DVI converter cable). They are different model monitors but both support a maximum resolution of 1080p.

Now on to my main question, with the Pi and i3 both monitors are working however the screen image is simply being mirrored. I would like to have the monitors be extended. I have tried using the “xrandr” utility to modify the displays but to me it seems that it is not detecting the monitors or displays correctly. It only outputs the following:

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080      0.00*

I have done my best to find a cause for this but nothing I have found really fits. I can provide any other configuration I have that might help troubleshoot this. My install is pretty much fresh out of the box. I feel like I am missing something simple.

1 Like

You can install a small tool such as arandr that allows you to create those configurations in a graphical way and save them for later use.

EDIT: also note that i3 and other Tiling window Managers usually extend the workspace to the different screens - noticeable by the different workspace numbers in the status bar. Each workspace can be filled with applications individually by switching to it (ALT+workspace no.) and run an application on it (ALT+d for application menu)

I stumbled across the arandr tool before creating this post. I am unable to get arandr or xrandr to modify the display setup on the Pi4. I could be using them incorrectly. From my internet searches it seems that arandr and xrandr should be reporting back the two HDMI (or DVI) devices that I have connected but they do not seem to do that. They only ever discover the “Screen 0” device and connect the “default” display to that. Am I to attempt to create the HDMI-0 and HDMI-1 devices using xrandr on my own?

The tvservice utility reports back both devices correctly, so from that perspective I know that they are there.

What you mention with the workspaces is what I want. The way it currently is working if I am actively using workspace “1” it displays on both monitors. What I would like to have happen is workspace “1” be on “monitor 1” and workspace “2” be on “monitor 2”. Or some type of configuration similar to that. For example all odd workspace numbers could be assigned to a specific monitor and all even workspace numbers to the other.

Hi. I wonder if someone can guide me here. I have the same problem. I can’t change the monitor resolution setting, so I have a hard time reading the screen, I need to change the resolution from 1920 x 1080, to 1280x720_60.00, but it is not available. Thank you very much in advance.

inxi -G

Graphics: Device-1: display-subsystem driver: rockchip_drm v: N/A
Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A
Device-3: rk3399-mali driver: panfrost v: kernel
Display: x11 server: X.Org 1.20.9 driver: fbturbo resolution: 1920x1080~N/A
OpenGL: renderer: llvmpipe (LLVM 10.0.1 128 bits) v: 3.3 Mesa 20.1.7

Hi, I’m having the same issue as the original post but I’m using Xfce on a Pi 400. It seems to be related to the fbturbo driver. Once removed, extended monitors return. I would still like to use the fbturbo driver. It seems much snappier then modsetting and YouTube videos play better. -Thanks

I am also running Manjaro i3 on a Rasperry Pi 4 and I am having the same issue. I get the exact same xrandr output (verbatim) as Mobius1. Sadly, I cannot shed any light on this issue, but I notice this thread is a few months old now. Perhaps someone else has solved the issue?

I also run Manjaro XFCE with an i3 session, and when I boot into XFCE it opens correctly into a dual display configuration (opens correctly in either the DE session or the i3 session) It is not an i3 issue, it seems to be a Manjaro i3 distro issue.

Anyway, I am no expert and probably should not even be posting this, but I do love the Manjaro i3 edition, and would love to use it with a dual display (i3 is perfect for multiple display setups). I have been forced back to XFCE until I can resolve this. Any help would be appreciated.

EDIT: I tried the arandr utility as suggested by appelgriebsch, but it seems to just be a graphical interface with xrandr. When I try do do anything with arandr it just dumps a stream of xrandr and randr errors into my terminal. I am running a Raspberry Pi 4, with Manjaro i3, 2 cheap Acer 21" LCD displays, and Kernel 5.10.17-1. Everything works perfectly in XFCE, where as I mentioned, I also run i3wm. I am flummoxed…

Solution found!! My brother is a high level IT Professional who has been using Linux since early days. He also runs Manjaro i3 on the Raspberry Pi 4. While he does NOT run a dual monitor setup when he ran xrandr he was getting the same output as Mobius1 and I. He was unable to change his screen resolution or rotate his screen because xrandr was not recognizing his display correctly.

He knew it worked on XFCE so he compared the Xorg start logs for i3 and XFCE. While XFCE probed the monitor and got modes back, i3 did not. After comparing the X configs, he found the problem. There is a config file for a non-Pi graphics driver that somehow ended up in i3’s X config. This is at best useless, at worst dangerous. Anyway, if you delete this file, the Pi will use a generic probe on boot and set up your displays correctly. It will also fix xrandr so it will see your displays and allow you to configure your screen resolutions, rotations, etc.

One final ancillary benefit of this fix is that it significantly increases Picom’s efficiancy. Before implementing this solution Picom was using 12 - 15% of my CPU at rest. Enough that I always had to disable Picom. After implementing the fix outlined here, Picom is using a fraction of 1% CPU.

I suggest you try this solution. It is easy, and works immediately:

  • Boot into Manjaro i3

  • Open a terminal and become root

  • Navigate to /etc/X11/xorg.conf.d

  • In xorg.conf.d you will find the file 99-fbturbo.conf.d Remove this file by running the command:
    rm 99- fbturbo.conf.d

  • Reboot

  • Enjoy your new dual display, or new ability to adjust your display settings with xrandr!!

I consider this SOLVED (at least for me), thanks to my brilliant brother…

One final thing, there is a config file in xorg.conf.d for a touchpad that is called something like ‘30-touchpad’? You can remove that as well, unless you are running a keyboard with a touchpad, which is unlikely if you are using the Pi 4."

Makes sense. We do not install that by default on any of our rpi images. We do not maintain the i3 image.

1 Like

Hi Darksky,

Nothing is ever perfect, but the Manjaro i3 distro for the RPi 4 is awesome!! It is a pleasure to use, and even if this issue could not have been fixed I would have likely continued to use it.

Thanks for your response and all your hard work.

With fbturbo installed you will always loose having dual monitors on the pi4 but you also gain V3D gpu acceleration along with dual monitors with it not installed. I just do not know anything about the i3 and non of the other devs here use it either.

I guess it is a tradeoff.

For me, I want the dual display and am not really doing anything graphically intensive on the Pi (it is a single processor and not a high performance unit). I would say that if anyone wants to try the solution, iterated above they should make a copy of the fbturbo file so they can restore it if they miss the benefits it provides.

I miss spoke above and edited it. You have best scenario for the pi4 with fbturbo not installed in most cases.

Hi Darksky,

Indeed, I have noticed significantly enhanced performance since I removed it this morning. It serendipitously solved some other issues I was having as well. I agree with you that one is better served without it on the Pi 4, if you are running the distro on other hardware you may want to keep fbturbo installed.

Thanks for responding.

My final word on this:
Here is the section of the log file from my brother’s boot with fbturbo enabled. There are a lot of lines, but the main gist is that it precipitated a cascade of error messages and did NOT load properly. I think it is obvious from this output that this file has no business being there, at least not on this chip architecture. You can make up your own minds, but for me at least, much better performance without it. Log file:

8.752] (II) FBTURBO: driver for framebuffer: fbturbo
[ 8.776] (WW) Falling back to old probe method for fbturbo
[ 8.776] (II) Loading sub module “fbdevhw”
[ 8.776] (II) LoadModule: “fbdevhw”
[ 8.777] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 8.780] (II) Module fbdevhw: vendor=“X.Org Foundation”
[ 8.780] compiled for 1.20.10, module version = 0.0.2
[ 8.780] ABI class: X.Org Video Driver, version 24.1
[ 8.780] (II) FBTURBO(0): using /dev/fb0
[ 8.780] (II) FBTURBO(0): Creating default Display subsection in Screen section
“Default Screen Section” for depth/fbbpp 16/16
[ 8.780] (==) FBTURBO(0): Depth 16, (==) framebuffer bpp 16
[ 8.781] (==) FBTURBO(0): RGB weight 565
[ 8.781] (==) FBTURBO(0): Default visual is TrueColor
[ 8.781] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0)
[ 8.781] (II) FBTURBO(0): hardware: vc4drmfb (video memory: 5400kB)
[ 8.781] (DB) xf86MergeOutputClassOptions unsupported bus type 0
[ 8.781] () FBTURBO(0): Option “fbdev” “/dev/fb0”
[ 8.781] (
) FBTURBO(0): Option “SwapbuffersWait” “true”
[ 8.781] (II) FBTURBO(0): processor: Unknown
[ 8.781] (II) FBTURBO(0): checking modes against framebuffer device…
[ 8.781] (II) FBTURBO(0): checking modes against monitor…
[ 8.781] (II) FBTURBO(0): Virtual size is 2560x1080 (pitch 2560)
[ 8.781] () FBTURBO(0): Built-in mode “current”
[ 8.781] (==) FBTURBO(0): DPI set to (96, 96)
[ 8.781] (II) Loading sub module “fb”
[ 8.781] (II) LoadModule: “fb”
[ 8.782] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 8.787] (II) Module fb: vendor=“X.Org Foundation”
[ 8.787] compiled for 1.20.10, module version = 1.0.0
[ 8.787] ABI class: X.Org ANSI C Emulation, version 0.4
[ 8.787] (
) FBTURBO(0): using shadow framebuffer
[ 8.787] (II) Loading sub module “shadow”
[ 8.787] (II) LoadModule: “shadow”
[ 8.787] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 8.791] (II) Module shadow: vendor=“X.Org Foundation”
[ 8.791] compiled for 1.20.10, module version = 1.1.0
[ 8.791] ABI class: X.Org ANSI C Emulation, version 0.4
[ 8.821] (II) FBTURBO(0): can’t load ‘g2d_23’ kernel module
[ 8.822] (II) FBTURBO(0): failed to enable the use of sunxi display controller
[ 8.822] (II) FBTURBO(0): No sunxi-g2d hardware detected (check /dev/disp and /dev/g2d)
[ 8.822] (II) FBTURBO(0): G2D hardware acceleration can’t be enabled
[ 8.822] (==) FBTURBO(0): Backing store enabled
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.822] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.823] (EE) FBTURBO(0): FBIOPUTCMAP: Invalid argument
[ 8.824] (==) FBTURBO(0): DPMS enabled
[ 8.824] (II) FBTURBO(0): failed to enable hardware cursor
[ 8.824] (II) FBTURBO(0): no 3D acceleration because the driver has been compiled without libUMP
[ 8.824] (II) FBTURBO(0): if this is wrong and needs to be fixed, please check

For the most part that is normal in that mode. What is not normal is “FBTURBO(0): FBIOPUTCMAP: Invalid argument” which I have seen quite a bit over the years and it is caused by a setting with in the DE. Usually turning off compositing and or animations will get rid of it. Years past when it first started showing in the logs searches on the internet would say it was safe to ignore. There have been times that mesa and the DE do not mesh right and seems to be an on going problem also from time to time.

Having fbturbo installed does have it’s place though in certain circumstances and will still be around.

1 Like

What? Say it is not true… I was going to try to get this to work. I am sure I used dual monitors with Ubuntu when they used fbturbo. But then, maybe they patched it to get it to work.

I have just the use case, some software can run better with a framebuffer than with v3d.

It has been over a year since I messed with it. Seems like I could get mirrored screens but not extended. I could not change the screen resolution either. From what I remember others was having the same issue. I have always had issues using a tv for a monitor on the pi4 as proper edid info is not being provided. I never had 2 regular computer monitors to test with.

I have fbturbo installed but disabled as I switch back and forth regularly.