Odroid C2 1280x390 screen resolution is possible?

General Discussion
1

All,

I’m running an Odroid C2 and trying to drive a 14.9" 1280x390 60hz LCD marquis display. On a Pi I can change the boot config files to the following and the display works like a champ.

[HDMI:1]
hdmi_group=2
hdmi_mode=87
hdmi_timings=1280 0 8 128 64 390 0 1 3 24 0 0 0 67 0 42009500 8

On the Odroid I can’t even find the config file to attempt the changes. I love how fast and light Odroid is, it is really snappy, but I need some help stretching out this display if it is even possible? Any help pointing me in the right direction would be greatly appreciated.

G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=5
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’

Linux DietPi 5.10.110-meson64 #22.05.1 SMP PREEMPT Sat May 28 07:50:27 UTC 2022 aarch64 GNU/Linux

2

That is actually a good question. Are those files present?

cat /sys/class/graphics/fb0/mode
cat /sys/class/graphics/fb0/modes
cat /sys/class/graphics/fb1/mode
cat /sys/class/graphics/fb1/modes

There is also the video kernel command-line parameter. I’ll have a closer look when I’m back home from work.

3

Hey there Michalng - yes the fb0 files are there, not fb1. I can play with them to see if I get the right resolution unless you have some suggestions?

4

What did you find @MichaIng? I’ve had no luck.

5

Does cat /sys/class/graphics/fb0/modes show 1280x390 and if so, does it work to echo this to /sys/class/graphics/fb0/mode to change the resolution?

6

cat /sys/class/graphics/fb0/modes only shows U: 1920X1080p-0

Is there any way to add @MichaIng?

7

@MichaIng any ideas?

8

Since KMS is used, we need to check differently. What does this show?

for i in /sys/class/drm/*/status; do echo "$i: $(<$i)"; done
9

@MichaIng this is the result:

/sys/class/drm/card0-HDMI-A-1/status: connected

10

Still, hoping to get this resolved @MichaIng - any further thoughts?

11

1 more ping @MichaIng

12

Please try to add video=HDMI-A-1:1280x390 to the extraargs= line in /boot/armbianEnv.txt.

13

Blockquote

There is no /boot/armbianEnv.txt. so I added it to /boot/dietpiEnv.txt which had no effect and looks like this:

rootdev=UUID=eefd4803-778c-4c63-8a32-646fb9cf0cc3
rootfstype=ext4
# The init system logs to the console defined last.
consoleargs=console=tty1 console=ttyAML0,115200 console=ttyS1,115200 console=ttyS2,115200 console=ttyS3,115200 console=ttyS4,115200 console=ttyS5,115200 console=ttyS6,115200 console=ttyS7,115200 console=ttyS0,115200
verbosity=4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
extraargs=net.ifnames=0 video=HDMI-A-1:1280x390
docker_optimizations=off
overlay_path=amlogic
overlay_prefix=meson
overlays=
user_overlays=
14

Does it work to run this on console?

fbset -fb /dev/fb0 -xres 1280 -yres 390

There is also another method via vga= cmdline option, but the standard modes do not include 1280x390: VESA BIOS Extensions - Wikipedia
Can you do:

apt install hwinfo
hwinfo --framebuffer

to check for available modes.

16

I may have gotten it to work in a slightly different way, although I have a hard time navigating the autostart process in DietPi. I rebuilt the timings string that I first posted for fb:

fbset -g 1280 390 1280 390 32 -pixclock 42009500 -left 8 -right 128 -upper 64 -lower 390 -hslen 1 -vslen 3

This seemed to work, as witnessed by:

root@DietPi:~# fbset -g 1280 390 1280 390 32 -pixclock 42009500 -left 8 -right 128 -upper 64 -lower 390 -hslen 1 -vslen 3
root@DietPi:~# fbset

mode "1280x390"
    geometry 1280 390 1280 390 32
    timings 0 8 128 64 390 1 3
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

root@DietPi:~#

Now I need to run this at boot, so I created a new file in the /etc/init.d/ directory

sudo nano /etc/init.d/screenres

I add the following lines to the file:

#!/bin/sh

fbset -g 1280 390 1280 390 32 -pixclock 42009500 -left 8 -right 128 -upper 64 -lower 390 -hslen 1 -vslen 3

And made the file executable by running the following command:

sudo chmod +x /etc/init.d/screenres

I tried to update the boot sequence to run the script by running the following command:

sudo update-rc.d screenres defaults

This rebooted with the stock resolution, so I added the following:

sudo chmod 755 /etc/init.d/screenres

This didn’t help; it still boots with 1280x720 enabled.

Can you or @Joulinar please tell me exactly how to autoboot boot this script so it will load with 1280x390 and I can see if this is the correct timing?

It seems we are getting close to a solution!

17

Don’t use a sysvinit service when systemd is used. Also sysvinit services look different: They need a “start” and “stop” function + some commented meta information at the top as a minimum. But as this is a short oneshot step, better do it like that:

cat << '_EOF_' > /var/lib/dietpi/postboot.d/screenres
#!/bin/dash
fbset -g 1280 390 1280 390 32 -pixclock 42009500 -left 8 -right 128 -upper 64 -lower 390 -hslen 1 -vslen 3
_EOF_

Scripts in this directory are executed on DietPi at the end of the boot process, similar to how /etc/rc.local was used to work (which is basically deprecated).

If you need it to run earlier (if you want to see the boot process properly), then a systemd service is required. Let me know, then I show you how to do that.

18

Well, that is too bad. After trying your solution fbset reports:

root@DietPi:~# fbset

mode "1280x390"
    geometry 1280 390 1280 390 32
    timings 0 8 128 64 390 1 3
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

but the screen is still displaying 1280x720 after a reboot. So the config is changing but the screen isn’t. Is there some reason this would all back to 1280x720?

19

And when you run the script manually on console, it changes the LCD resolution as well?

Can you try to add either --all or --fb /dev/fb0?

The man page says that /dev/fb0 is used by default, if not defined, and it is the only one in your case anyway. But probably fbset still behaves differently when not called from the TTY this framebuffer is attached to. The script is currently started from a systemd service that has its STDOUT set to /dev/console, not /dev/tty1 and has no STDIN. Not sure whether this is relevant, but something makes a difference here.

Another test, bind STDOUT, STDERR and STDIN to /dev/tty1.

cat << '_EOF_' > /var/lib/dietpi/postboot.d/screenres
#!/bin/dash
fbset -g 1280 390 1280 390 32 -pixclock 42009500 -left 8 -right 128 -upper 64 -lower 390 -hslen 1 -vslen 3 &> /dev/tty1 < /dev/tty1
_EOF_
20

The screen has not changed to 1280x390 either by script or manually @MichaIng

When I ran your latest script and restarted the ODROID it started reporting the boot sequence on the full length of the screen and then dropped to 1/3 of the screen. The remaining 2/3 of the screen was frozen and still displaying the boot sequence where it froze. When the desktop came up the display resolution had changed from 1280x720 to 1920x1080, so something happened.

root@DietPi:~# fbset

mode "1280x390"
    geometry 1280 390 1280 390 32
    timings 0 8 128 64 390 1 3
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

root@DietPi:~#

FB still thinks it is 1280x390

Michael, I am not seeing a 1280x390 in /etc/fb.modes - I wonder if adding the profile there will have an effect?

21

Looks like it may be a lost cause @MichaIng

[ 2114.817547] meson-drm d0100000.vpu: [drm] User-defined mode not supported: "1280x390": 60 37651 1280 1288 1416 1552 390 391 394 404 0x20 0x6
[ 2125.522445] export_store: invalid GPIO 199
[ 2125.522570] export_store: invalid GPIO 200