Upon rebooting, voila, I was at the login screen, and able to log in. ModulePath "/usr/local/lib/xorg/modules/drivers" Just check the output of ls /dev/fb* before/after unplugging to figure out. If it's a second screen, it might be /dev/fb1, for example. The only thing that might need to be tweaked is the /dev/fb0 path. I believe this should work for just about any DisplayLink screen + Raspbian, verbatim. That led to me creating the file /etc/X11/nf with the contents below. It seems that Raspbian is missing something (that must exist in Ubuntu-likes) to auto-define to X11 to use (and how) the screen. In my case, the credit goes to this blog post for putting me on the right path. So this issue probably also applies to Raspbian on the 3b+. 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. In addition to restarting lightdm, I also tried running startx from the TTY. I've also used both of these screen models extensively for years on "regular" computers running Ubuntu 14 and 20. So I know the hardware is good/compatible. These "just work", albeit are extremely slow and not really usable on this 2GB model. On another SD card, I was able to load and try various flavors of Ubuntu. 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).If I restart the display manager, sudo service lightdm restart, it takes me back to the aforementioned black screen. I can access and view/use TTYs fine (e.g. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |