Trying to run HamClock on /dev/fb0

oxoocoffee commented 2 months ago

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

Running level 3. No desktop installed
$ sudo apt install fbset
$ git clone --depth 1 https://github.com/kj7rrv/hamclock.git
$ cd hamclock/ ESPHamClock
$ make help
$ make hamclock-fb0-1600x960
$ ./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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

@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

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 commented 2 months ago

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

gpu_mem_256=76
gpu_mem_512=76
gpu_mem_1024=76

oxoocoffee commented 2 months ago

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

MichaIng commented 1 week ago

Sorry for the late reply. Interesting that setting 32-bit for DRM (via video= parameter) indeed has an effect on fbset -i output. So they are not totally independent. I started to work on a dietpi-display script, with for now only a menu to set video= mode options, to be shown in dietpi-config whenever a DRM device exists.

Which is great. It is in 32. Would 24 work as well?

I remember reading in RPi docs that it often leads to scrambled output, but not sure whether this had a hardware or software reason. Just try it. With cmdline.txt on the FAT partition, you can revert the change on any other system, if SSH is not possible.

oxoocoffee commented 1 week ago

Great to hear you are working on such script. Perhaps we could collaborate on it? At least I can test and provide informations for different boards I have.

As far as your second pint, I am not sure which are you referring to. If you asking if I did see any corruptions after changing to 32, no I did not experienced any yet. Please note my rPI are always on latest firmware if that could make a difference at some point.

If my understanding is incorrect, could you please explain again? Files? Commands? Etc

Cheers, :)

MichaIng / DietPi