Trying to run HamClock on /dev/fb0

[oxoocoffee]

Creating a bug report/issue

• [ x] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

    G_DIETPI_VERSION_CORE=9
    G_DIETPI_VERSION_SUB=3
    G_DIETPI_VERSION_RC=0
    G_GITBRANCH='master'
    G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
• Kernel version | uname -a
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  RPi 3 Model B (aarch64)
• Power supply used | (EG: 5V 1A RAVpower)
  200W USB 4 port charger
• SD card used | (EG: SanDisk ultra)
  SanDisk 32G

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
  Git HamClock, Web HamClock
• Was the software title installed freshly or updated/migrated?
  Build by me. Compiles fine. Fails to run.
• Can this issue be replicated on a fresh installation of DietPi?
  Yes. I just setup fresh unit

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. Running level 3. No desktop installed
2. $ sudo apt install fbset
3. $ git clone --depth 1 https://github.com/kj7rrv/hamclock.git
4. $ cd hamclock/ ESPHamClock
5. $ make help
6. $ make hamclock-fb0-1600x960
7. $ ./hamclock-fb0-800x480

Expected behaviour

• Application starts in full screen

Actual behaviour

• application log file generated in ~/.hamclock/ shows: fails setting 32 bit color mode
• sudo fbset -i

mode "1920x1080"
    geometry 1920 1080 1920 1080 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

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

• sudo fbset -depth 32

ioctl FBIOPUT_VSCREENINFO: Invalid argument

• Setting following in /boot/config.txt

framebuffer_width=1280
framebuffer_height=800
framebuffer_depth=32
framebuffer_ignore_alpha=1

• sudo reboot

Extra details

• $ dmesg | grep fb0

[    1.047981] simple-framebuffer 3e812000.framebuffer: fb0: simplefb registered!
[    8.209655] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device

• $ dmesg | grep vc4

[    8.077290] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    8.083042] rc rc0: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0
[    8.083233] input: vc4-hdmi as /devices/platform/soc/3f902000.hdmi/rc/rc0/input3
[    8.090506] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[    8.090972] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[    8.091281] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.091547] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.091846] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.092099] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[    8.103570] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[    8.209655] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device

• Add permissions, followed by reboot

sudo usermod -a -G video $USER
sudo usermod -a -G tty $USER
sudo usermod -a -G input $USER

• dietpi-config / Display Resolution /

 Hardware: RPi 3 Model B (aarch64)                                                                                    │ 
 Current resolution: vc4-kms-v3

 vc4-kms-v3d       : OpenGL | 1920 x 1080 

[MichaIng]

Since you enabled the KMS driver, isn't it possible to use KMS/DRM with HamClock instead of the framebuffer device?

I actually was not aware that /dev/fb0 is internally already using KMS/DRM in this case. However, using DRI directly seems more natural, when possible.

Also, did you check whether the mode/depth is reported as supported?

cat /sys/class/drm/HDMI-A-1/modes
tvservice -m DMT
tvservice -m CAE

/etc/fb.modes contains all supported modes for fbset, and could be expanded.
I am generally not sure whether framebuffer_* settings still affect the resolution when KMS/DRM is enabled, or whether one needs to use the kernel command-line video= parameter already. At least with the new kernel/firmware stack this is the case. That the framebuffer is named vc4drmfb however looks like it could work.

And another thing:

sudo usermod -a -G render "$USER"

The render group is required for direct DRI access (/dev/dri/card0 etc). So in case this is indirectly done as well when using it via /dev/fb0, this might be needed.

[oxoocoffee]

I am checking several things and will reply with more output/findings. Thank you for a quick reply. I am also installing the rPI 5 with the latest image and will test it as well.

[oxoocoffee]

@MichaIng

• I did not have time yet to look at what changes would be needed in HamClock to make it work with DRI. I will look into it at some not a distant point.
• As for /sys/class/drm/HDMI-A-1/modes I think you mean /sys/class/drm/card1-HDMI-A-1/modes. Your path does no exist on my rPI 5. Here is /sys/class/drm listing

card0  card1  card1-HDMI-A-1  renderD128  version

cat /sys/class/drm/version prints drm 1.1.0 20060810
cat /sys/class/drm/card1-HDMI-A-1/modes prints

1920x1080
1920x1080
1920x1080i
1920x1080i
1680x1050
1280x1024
1440x900
1280x960
1280x800
1280x720
1280x720
1280x720
1280x720
1280x720
1024x768
800x600
720x480
720x480
720x480
720x480
720x480

• sudo apt install fbset fbcat fbterm fbi
• sudo fbset -i

mode "1920x1080"
    geometry 1920 1080 1920 1080 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        : 4147200
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 3840
    Accelerator : No

• I do not have tvservice installed.
• So I did write two small samples one for fb and the other for DRI. Here is my groups output adm tty dialout sudo audio video users input render netdev gpio i2c spi which I added post-installation followed by a reboot.
• Both samples fail but for different reasons.
• fb will not work when forced to create a 32-bit plane. A 16-bit works.
• drm I think I might create a separate ticket if that is the preference.
• I did try to switch from default "dtoverlay=vc4-kms-v3d" to "dtoverlay=vc4-fkms-v3d". Same as above. 16-bit: ok, 32-bit: fails.
• sudo install drm-info which produces a lot of output which I have not looked at yet.
• If needed I can attach my samples to each ticket for a reference if it might be worth it.

[oxoocoffee]

Forgot to add cat /boot/config.txt | grep gpu_mem

gpu_mem_256=76
gpu_mem_512=76
gpu_mem_1024=76

[oxoocoffee]

I changed the color depth from default 16 to 32 by adding a kernel parameter.

$ cat /boot/cmdline.txt 
root=PARTUUID=f0cf2e93-02 rootfstype=ext4 rootwait net.ifnames=0 logo.nologo console=tty1 video=HDMI-A-1:1920x1080M-32@60

After reboot, I see the following

$ fbset -i

mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

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

Which is great. It is in 32. Would 24 work as well?
But now I am wondering about the last entry

Accelerator : No

Is there a way to enable it to get hardware acceleration? At least 2D operations, line lines, and bitmaps.

---

Perhaps I should open a separate request for this?
Is there a way? or could there be a way to add an option during the first boot, to increase console font size? On my 10.1" 1920x1080 touch screen and a few similar the text is almost not readable. I have to SSH and edit /etc/default/console-setup and change it from 8x16 to 16x32, save and run setupcon