RPi 5 and custom resolution

[m0vse]

Hi.

I am trying to use tty2rpi on a PI5 with a 1680x342 resolution screen using an HDMI to DisplayPort adapter.

I have had some success by forcing the frame buffer device, but wanted to try setting the resolution via Xorg. I have added a modeline to 10-monitor.conf, but get following in Xorg.0.log:

[ 20.014] (II) FBDEV(0): checking modes against framebuffer device...
[ 20.014] (II) FBDEV(0): mode "1680x352" not found
[ 20.014] (II) FBDEV(0): mode "720x400" ok
[ 20.014] (II) FBDEV(0): mode "800x600" ok
[ 20.014] (II) FBDEV(0): mode "640x480" ok

Any ideas how I can resolve this?

Thanks

Phil

[ojaksch]

Difficult to analyze w/o having that monitor ;) But at first glance it looks like your display isn't reporting/confirming the resolution of 1680x342 (EDID). But to get closer to that issue please try some commands and report their output, maybe we're getting any hint then.

On console or by ssh: fbset -i also dmesg | grep -i v3d and dmesg | grep -i vc4
On console: xrandr or by ssh: DISPLAY=:0 xrandr

I'm using a "marquee like" HDMI monitor which identifies as 1280x720 but is in fact a 1280x390 display. You see in which direction I am thinking right now...

[ojaksch]

What I'm wondering about (but I'm having no RPi5 at hand) is that your xorg.log is showing FBDEV. With all my RPi's (Zero, 2 and 3) Xorg is using modeset as display driver.

[m0vse]

I got a bit further and have enabled vc4-kms-v3d, however nothing but an occasional flicker on the screen!

It is currently connected via a KVM, but the Windows PC on the other port works fine, so I know it is able to control the screen.

$ fbset -i
mode "1680x342"
geometry 1680 342 1680 342 16
timings 0 0 0 0 0 0 0
rgba 5/11,6/5,5/0,0/0
endmode

Frame buffer device information:
Name : vc4drmfb
Address : 0
Size : 1149120
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 1
YPanStep : 1
YWrapStep : 0
LineLength : 3360
Accelerator : No

$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 342, maximum 8192 x 8192
HDMI-1 disconnected primary 1680x342+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
HDMI-2 disconnected (normal left inverted right x axis y axis)
1680x342 (0x45) 45.300MHz +HSync -VSync
h: width 1680 start 1728 end 1888 total 2100 skew 0 clock 21.57KHz
v: height 342 start 345 end 355 total 360 clock 59.92Hz

[ojaksch]

I got a bit further and have enabled vc4-kms-v3d, however nothing but an occasional flicker on the screen!

Shouldn't that be vc4-kms-v3d-pi5 ?
And have a look at my 1st post, I've added two more things I'd like to know...

[m0vse]

Shouldn't that be vc4-kms-v3d-pi5 ?

Not sure, I just un-commented the line that was there already!

Sorry missed the extra commands:

$ dmesg | grep -i v3d
[ 3.258994] [drm] Initialized v3d 1.0.0 20180419 for 1002000000.v3d on minor

$ dmesg | grep -i vc4
[ 4.310588] vc4-drm axi:gpu: bcm2712_iommu_of_xlate: MMU 1000005200.iommu
[ 4.321445] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops [vc4])
[ 4.322878] rc rc0: vc4-hdmi-0 as /devices/platform/soc/107c701400.hdmi/rc/rc0
[ 4.322933] input: vc4-hdmi-0 as /devices/platform/soc/107c701400.hdmi/rc/rc0/input1
[ 4.324379] input: vc4-hdmi-0 HDMI Jack as /devices/platform/soc/107c701400.hdmi/sound/card0/input2
[ 4.324594] vc4-drm axi:gpu: bound 107c701400.hdmi (ops vc4_hdmi_ops [vc4])
[ 4.328799] rc rc1: vc4-hdmi-1 as /devices/platform/soc/107c706400.hdmi/rc/rc1
[ 4.328892] input: vc4-hdmi-1 as /devices/platform/soc/107c706400.hdmi/rc/rc1/input3
[ 4.331518] input: vc4-hdmi-1 HDMI Jack as /devices/platform/soc/107c706400.hdmi/sound/card1/input4
[ 4.333676] vc4-drm axi:gpu: bound 107c706400.hdmi (ops vc4_hdmi_ops [vc4])
[ 4.333850] vc4-drm axi:gpu: bound 107c500000.mop (ops vc4_txp_ops [vc4])
[ 4.333963] vc4-drm axi:gpu: bound 107c501000.moplet (ops vc4_txp_ops [vc4])
[ 4.334154] vc4-drm axi:gpu: bound 107c410000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 4.334297] vc4-drm axi:gpu: bound 107c411000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 4.382786] [drm] Initialized vc4 0.0.0 20140616 for axi:gpu on minor 1
[ 4.478632] vc4-drm axi:gpu: [drm] fb0: vc4drmfb frame buffer device

[ojaksch]

Looks similar (but not equal) to my Pi3 and is showing that display driver and HDMI should be working. But please try vc4-kms-v3d-pi5 in your config.txt
Also maybe that your HDMI to DisplayPort adapter is preventing the correct EDID setup/detection, because xrandr is reporting that both of your HDMI ports are disconnected.

[m0vse]

Weirdly, I was able to get the screen to work originally with the following in cmdline.txt:
`
video=HDMI-A-1:1920x400@60D vc4.force_hotplug=1 drm.edid_firmware=myedid.dat console=serial0,115200 console=tty1 root=PARTUUID=8f7d3603-02 rootfstype=ext4 fsck.repair=yes rootwait quiet

`And adding this to tty2rpi.user:

FBUFDEV="yes"                                    # Set to "yes" when using such a display
FBDEVICE="/dev/fb0"                             # If FBUFDEV set to "yes" then defince the used framebuffer device here
USEFBCP="yes"                                    # Set to "yes" when fbcp-ili9341 is needed

I realize that resolution is a bit screwy, but it didn't work at all without it. However, this only worked connected directly and it didn't work through my KVM, which is why I am trying again!

[m0vse]

Looks similar (but not equal) to my Pi3 and is showing that display driver and HDMI should be working. But please try vc4-kms-v3d-pi5 in your config.txt Also maybe that your HDMI to DisplayPort adapter is preventing the correct EDID setup/detection, because xrandr is reporting that both of your HDMI ports are disconnected.

Yes I suspect there is an EDID issue, I am not sure what the KVM does with regard to EDID? I know that some will store the EDID to report to the inactive computer, maybe it doesn't like something (although Windows works ok?)

[ojaksch]

Using FBDEV and FBCP with a HDMI setup should work but is the wrong way. The framebuffer setup is for meant for non HDMI/DSI setups and is lacking of hardware video acceleration then.
The quirk at your side is imho either a not-working video setup (missing or wrong module(s) in config.txt) or the HDMI->DP adapter (or a combination of both).

I'm going to order a RPi5 (I always wanted to have one), but it's a holiday today here in Germany and the country is sunk in a holiday mood 'til sunday, I'm afraid ;)

[m0vse]

I am also using the Pi5 with a Pimoroni NVMe base and running RetroNAS on it, and I thought it would be best to use that for tty2rpi as well... At worse, I can see if I can get it working with a 3b.

[ojaksch]

Funny, I'm also running a RPi Zero2W with a Pimoroni HyperPixel 4" (DSI, not HDMI) for tty2rpi and even this "poor mans setup" is working very reliably.
Let's postpone the topic for a few days until my Pi5 has arrived. I'm sure that this will need only some small modifications to get a blasting experience :)

[m0vse]

Sorry I was remote when I ran that command, I am now in front of the machine and realised that the monitor was switched-off at the mains!

$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 342, maximum 8192 x 8192
HDMI-1 connected primary 1680x342+0+0 (normal left inverted right x axis y axis) 480mm x 300mm
1680x342 59.92*+
1920x1080 60.00 59.94
1280x720 60.00 59.94
800x600 60.32
720x480 60.00 59.94
640x480 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

[m0vse]

If you are interested, this is the screen:

https://www.ebay.co.uk/itm/305814035748?itmmeta=01J99JZPFNNNPQ4T7PF3BAG0KY&hash=item4733efdd24:g:lRIAAOSwvZVjLu11

[ojaksch]

If you are interested, this is the screen:

Very well and very similar to mine 👍

Sorry I was remote when I ran that command, I am now in front of the machine and realised that the monitor was switched-off at the mains!

Ha-ha! The curse of a remote worker, which I am, too.
Then replace vc4-kms-v3d with vc4-kms-v3d-pi5 in your config.txt, set FBUFDEV to "no" in tty2rpi.user, then reboot.
After rebooting check Xorg.0.log to see which display driver is used, which should be modeset
Check with xrandr which resolutions are detected and which one is the default and should be used (the line containing "*+")
Run source ~/tty2rpi.ini ; source ~/tty2rpi-user.ini ; source ~/tty2rpi-screens.ini ; echo "${WIDTH}x${HEIGHT}" (on console or by ssh) which will output the really used display resolution in xorg.

If modeset is used all is saying 1680x342 you should be fine. If not, we'll be going to set a fixed resolution in ~/.xinitrc-extra.example in the next step:
Edit ~/.xinitrc-extra.example and write to a new line xrandr --size 1680x342. Reboot and re-check.

[m0vse]

Good morning, here is the relevant bit from Xorg.0.log:

[ 21.456] (WW) modeset(0): Output HDMI-1: Strange aspect ratio (480/80), consider adding a quirk
[ 21.456] (WW) modeset(0): Output HDMI-1: Strange aspect ratio (480/80), consider adding a quirk
[ 21.456] (--) modeset(0): HDMI max TMDS frequency 300000KHz
[ 21.456] (II) modeset(0): Printing probed modes for output HDMI-1
[ 21.456] (II) modeset(0): Modeline "1680x342"x59.9 45.30 1680 1728 1888 2100 342 345 355 360 +hsync -vsync (21.6 kHz eP)
[ 21.456] (II) modeset(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[ 21.456] (II) modeset(0): Modeline "1920x1080"x59.9 148.35 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.4 kHz e)
[ 21.456] (II) modeset(0): Modeline "1280x720"x60.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e)
[ 21.456] (II) modeset(0): Modeline "1280x720"x59.9 74.18 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e)
[ 21.456] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 21.456] (II) modeset(0): Modeline "720x480"x60.0 27.03 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e)
[ 21.456] (II) modeset(0): Modeline "720x480"x59.9 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e)
[ 21.456] (II) modeset(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 21.456] (II) modeset(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 21.456] (II) modeset(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 21.458] (II) modeset(0): EDID for output HDMI-2
[ 21.458] (II) modeset(0): Output HDMI-1 connected
[ 21.458] (II) modeset(0): Output HDMI-2 disconnected
[ 21.458] (II) modeset(0): Using exact sizes for initial modes
[ 21.458] (II) modeset(0): Output HDMI-1 using initial mode 1680x342 +0+0
[ 21.458] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[ 21.458] (==) modeset(0): DPI set to (96, 96)
[ 21.458] (II) Loading sub module "fb"
[ 21.458] (II) LoadModule: "fb"
[ 21.458] (II) Module "fb" already built-in
[ 21.458] (II) UnloadModule: "fbdev"
[ 21.458] (II) Unloading fbdev
[ 21.458] (II) UnloadSubModule: "fbdevhw"
[ 21.458] (II) Unloading fbdevhw

$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 342, maximum 8192 x 8192
HDMI-1 connected primary 1680x342+0+0 (normal left inverted right x axis y axis) 480mm x 300mm
1680x342 59.92*+
1920x1080 60.00 59.94
1280x720 60.00 59.94
800x600 60.32
720x480 60.00 59.94
640x480 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

Finally,
$ source ~/tty2rpi.ini ; source ~/tty2rpi-user.ini ; source ~/tty2rpi-screens.ini ; echo "${WIDTH}x${HEIGHT}"
1680x342

SO it definitely thinks this is what it is outputting, but still nothing on the display? :(

I think that I will try without the KVM in case that is causing the issue, weird that Windows works through it OK, so I suspect it is sending a slightly different mode?

[ojaksch]

Interesting. Everything looks like as it should. When you turn on the display and afterwards the RPi (important!) does the display change its colour? (many displays are displaying "blue" when turned on w/o a connected/active device). And is the tty2tft logo visible while booting up?

There are two options in config.txt you could play with:
hdmi_safe
config_hdmi_boost

[m0vse]

Hi,

No colour change or anything, it simply turns on the backlight and then displays a "no signal" banner.

I am not sure that those settings in config.txt still do anything? In PiOS Bookworm, my understanding is all HDMI settings are now handled in cmdline.txt? I can't find any reference to these settings being moved though?

Thanks so much for your help in trying to get this working!

[ojaksch]

No colour change or anything, it simply turns on the backlight and then displays a "no signal" banner.

...and it still displays "no signal" all the time? That would even more a hint to use hdmi_safe and/or config_hdmi_boost (or remove the KVM, at least for testing).

I am not sure that those settings in config.txt still do anything? In PiOS Bookworm, my understanding is all HDMI settings are now handled in cmdline.txt? I can't find any reference to these settings being moved though?

Is that so? Never heard of that and we are using PiOS for tty2tft - as long as you didn't went another way, but that shouldn't matter what *nix OS you are using for your Pi. In fact I'm using the (almost) same code of tty2tft for a x86 based MAME-O-MAT and with a RPi400/ArchLinux.

Thanks so much for your help in trying to get this working!

Naah, not for that. You are so close, I'm NOT busy these days and I want you to enjoy my project 😃

[m0vse]

I am using the latest 'bare' PiOS ARM64 version. My understanding is that the latest kms driver ignores all *hdmi settings in config.txt in favour of cmdline.txt. Both files have also moved to /boot/firmware.

[ojaksch]

Yes, they moved to /boot/firmware but are still working (tested with RPi Zero/Hyperpixel and RPi 3/HDMI) and can't hurt to try both settings ;)
I'm still using the 32 bit PiOS of Bookworm but that also shouldn't matter. The base and technics are the same...in principle.

[m0vse]

OK so it's not the KVM. So far, the only way I have been able to get anything to display from the Pi on this screen is using the fb device directly and sending a weird (unsupported) resolution (1920x400). That works when connected directly, but not via the KVM!

I wonder if the Pi is mis-interpreting the EDID slightly and sending timings that the screen doesn't support? Maybe seeing if I can get more information on exactly what Windows sends to the screen (as that works both with and without the KVM)

[ojaksch]

In my opinion cmdline.txt and config.txt are controlling the chipset's parameters while bootstrapping the Kernel, DTB's, overlays and all that stuff in /boot before loading any Kernel module like graphic driver etc. Think of a BIOS that the RPi lacks of.

But have you set hdmi_safe and/or config_hdmi_boost ?

[m0vse]

Yes tried them both, config_hdmi_boost (4 and 8)

[ojaksch]

Yes tried them both, config_hdmi_boost (4 and 8)

Damn, very weird.

I wonder if the Pi is mis-interpreting the EDID slightly and sending timings that the screen doesn't support? Maybe seeing if I can get more information on exactly what Windows sends to the screen (as that works both with and without the KVM)

I dind't think so (but I may be wrong) because even if is displaying nothing, all logs and settings are correct.

[ojaksch]

Another thing what is hitting my eyes is the line in your Xorg.0.log

[ 21.456] (WW) modeset(0): Output HDMI-1: Strange aspect ratio (480/80), consider adding a quirk

Dunno if that plays a role, I have to investigate.

[m0vse]

Yes I did wonder about that too, I found comments where people suggested that it is just a warning and can be ignored, but I wonder if it points to another issue?

[m0vse]

Got it!

I added:

vc4.force_hotplug=3

To the beginning of cmdline.txt and now have a display!

[ojaksch]

Dang! Congrats!! And you are getting the tty2tft logo while booting up, the "Your IP addresses" and everything else afterwards?

[m0vse]

I didn't get the logo while booting, but I did get the main tty2rpi screen once booted. It still doesn't work through the KVM, but I can try a few other things...

[ojaksch]

At least something. Keep me informed, please so I could update the docs.
Are you using your setup for MiSTer, MAME or Batocera?

[m0vse]

Yes will do. I might try some better converters/cables, currently it is using a micro-hdmi from the Pi5 to a female HDMI adaptor, then an active HDMI to DP converter and a (cheap) 2m DP-DP cable to the KVM and another (cheap) 2m DP-DP cable from the KVM to the display.

I am using it on MiSTer.

[m0vse]

[m0vse]

I do have another question, I downloaded the suggested library from archive.org, but that is missing a lot of games (and other computers/consoles) do you have a better source of images/videos?

[ojaksch]

Very very nice! Looks like my MAME-O-MAT, in which I will eventually install a MiSTer additionally.

[ojaksch]

I do have another question, I downloaded the suggested library from archive.org, but that is missing a lot of games (and other computers/consoles) do you have a better source of images/videos?

Yes! For marquee sized displays like ours the first source would be MAME's marquees.zip

[m0vse]

Great, thanks for that!

Phil

[m0vse]

Just reading through this document, it seems to have quite a bit of information for KMS and Pi4/5 support https://pip.raspberrypi.com/categories/685-whitepapers-app-notes/documents/RP-004341-WP/Troubleshooting-KMS-HDMI-output.pdf

[m0vse]

Sorry to keep bugging you, but I thought you would be interested to know that when I first set tty2rpi up using the FBDEV=yes option, CPU of the Pi5 was pegged at 100% (on a single core), since moving to the 'correct' method, CPU is much more reasonable.

[ojaksch]

No problem. Don't hesitate to comment or to ask! Yes, that's a fact I'm aware of and why I mentioned that here. When using fbcp for framebuffer displays the decoding for all shown media is done in software. This working reliable but not "the" elegant way :)

[ojaksch]

Just reading through this document, it seems to have quite a bit of information for KMS and Pi4/5 support https://pip.raspberrypi.com/categories/685-whitepapers-app-notes/documents/RP-004341-WP/Troubleshooting-KMS-HDMI-output.pdf

Thanks for document! Saved for future use. And possibly for my RPi5, which delivery is announced for Tuesday.

[ojaksch]

My RPi5 arrived yesterday evening! I prepared a fresh PiOS ARM64 Lite SD card and used my own documentation to install all the stuff. Changed nothing in cmdline.txt and config.txt, just rebooted the RPi after installation and everything is working as normal.

About dtoverlay=vc4-kms-v3d: Looks like that is a stub and and is loading the right/needed version itself. See here for a map file.

I am not sure that those settings in config.txt still do anything? In PiOS Bookworm, my understanding is all HDMI settings are now handled in cmdline.txt? I can't find any reference to these settings being moved though?

Found an info about that, we both are correct in half :) There are some legacy options that are deprecated and aren't working in >=Bookworm

[m0vse]

I suspect that many of my problems have been caused by the HDMI->DP converter!

I bought another one and tried that, interestingly, that seems to work, but not at 1680x342, I only get a display at 800x600, but it does work through my KVM. It does seem to require the vc4.force_hotplug entry in cmdline.txt.

I have noticed that with both HDMI->DP converters, the marquee screen goes blank for a second or two periodically. There doesn't seem to be a pattern to when it will do that. This doesn't happen with my Windows PC (which has DP on the GPU), so I think that is also an issue with the converters? As they are both active (with USB power) they are likely doing a fair bit of work to convert the HDMI signals to DP, which looks to be resolution dependant?

[ojaksch]

All in all, yes, I'm afraid but sure, that all your problems are coming from the converters. Similar to (cheap) whatever2HDMI converters: Works, but with limitations (ghosting, 50/60Hz, weak signals, no RGB etc pp).