0

When using a freshly imaged uSD card with Raspbian in my Raspberry Pi 4, after initial splash screens for setup/autoconfigure, I'm left with a black screen, with the text cursor blinking in the top left.

I can access and view/use TTYs fine (e.g. ctrl+alt+F2). If I restart the display manager, sudo service lightdm restart, it takes me back to the aforementioned black screen.

Setup

  • Raspberry Pi 4b (2GB RAM)
  • running Raspbian (Debian Bullseye)
  • with a DisplayLink monitor (either UM1000 Mimo Magic Monster, or the newer UM-1080C-G-NB Mimo Vue Touch Monitor) (USB port on the Pi does not seem to matter)

Some of the testing done

On another SD card, I was able to load and try various flavors of Ubuntu. These "just work", albeit are extremely slow and not really usable on this 2GB model. So I know the hardware is good/compatible. I've also used both of these screen models extensively for years on "regular" computers running Ubuntu 14 and 20.

In addition to restarting lightdm, I also tried running startx from the TTY. No change there.

This round of testing... is a repeat of similar testing I did about 6 months ago with an RPi 3b+ and had the same issues, which prompted my ordering the RPi 4. So this issue probably also applies to Raspbian on the 3b+.

1 Answer 1

0

In my case, the credit goes to this blog post for putting me on the right path. It seems that Raspbian is missing something (that must exist in Ubuntu-likes) to auto-define to X11 to use (and how) the screen.

That led to me creating the file /etc/X11/xorg.conf with the contents below. I believe this should work for just about any DisplayLink screen + Raspbian, verbatim. The only thing that might need to be tweaked is the /dev/fb0 path. If it's a second screen, it might be /dev/fb1, for example. Just check the output of ls /dev/fb* before/after unplugging to figure out.

Section "Files"
  ModulePath "/usr/lib/xorg/modules"
  ModulePath "/usr/local/lib/xorg/modules"
  ModulePath "/usr/local/lib/xorg/modules/drivers"
EndSection

Section "Device"
  Identifier "DisplayLinkDevice"
  Driver "fbdev"
  Option "fbdev" "/dev/fb0"
EndSection

Section "Monitor"
  Identifier "DisplayLinkMonitor"
EndSection

Section "Screen"
  Identifier "DisplayLinkScreen"
  Device "DisplayLinkDevice"
  Monitor "DisplayLinkMonitor"
EndSection

Section "ServerLayout"
  Identifier "Server Layout"
  Screen 0 "DisplayLinkScreen" 0 0
EndSection

Upon rebooting, voila, I was at the login screen, and able to log in.

Miscellany

Contrary to the introudction in the blog post I linked above, my impression is that DisplayLink support has been baked into Linux for years, so the only thing needed, fortunately, is this xorg.conf file. No extra drivers need to be installed/enabled.

One thing I noted along the way: I tried enabling Wayland in raspi-config to see if that would help. I still had that enabled when I added the above solution. This led to the following symptom: I got to the login greeter, but logging would quickly fail and return me to login, repeatedly. Disabling Wayland fixed this.

Side note: While I've been aware of the concept of making a xorg.conf file manually, I thought it was an outdated approach from the past, and resisted learning to do it. In this case, it ended up being pretty trivial, thankfully. I've been spoiled by Linux displays mostly just working for the past several years.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.