feat: Add video scaling via --video-scale CLI arg and gsmenu slider

[DmtryJS]

This PR adds the ability to scale the video output size via a new --video-scale pixelpilot command-line argument.
It also integrates this setting into the gsmenu system, allowing users to adjust the scale via a slider in the 'system' menu.

• Adds --video-scale <factor> CLI option to pixelpilot.
• Updates drm.c to use the scale factor when setting CRTC_W and CRTC_H.
• Adds corresponding get/set handlers in gsmenu.sh.
• Adds a slider in gs_system.c to control the value via the menu.
• Saves/loads the setting from /config/setup.txt.

This feature is particularly beneficial for users of binocular FPV goggles, where the native video resolution may exceed the effective display area of the lenses. By reducing the output size, users can avoid image distortion, cropping, or edge stretching — enabling a more natural, immersive, and fully visible visual experience across a wider range of headset models and lens configurations.

The slider range is 0.5 to 1.0

discuss in telegram https://t.me/c/1809358416/138076/268251

my setup.txt

root@radxa-zero3:~# cat /config/setup.txt
# Set the screen_mode to your HDMI display's desired mode. Format is WxH@fps - Common values would be 1920x1080@60, 1920x1080@120. 1280x720@60, 1280x720@120
[screen mode]
screen_mode = 1280x720@60
# Set desired display scale factor, can be in range 0.5 <= factor <= 1.0
[video scale]
video_scale = 0.80

# Set the rec-fps to the fps at which your camera is shooting. e.g. 60, 90, 120
[dvr recording]
rec_fps = 90

# Set the gpio_layout. Accepted values are Ruby, Bonnet, Runcam, and Custom.
[gpio]
gpio_layout = Ruby

# Setting osd to "ground" enables the vrx-side msposd_rockchip process.
[msposd]
osd = air

tested on pnp 2.0.0 debian 11 image

[henkwiedig]

Fixes: #74

I like it, one thought: Why limiting to max 1 ? Maybe someone wants to zoom in because of frame in the image.

[DmtryJS]

Fixes: #74

I like it, one thought: Why limiting to max 1 ? Maybe someone wants to zoom in because of frame in the image.

Thanks Henk! hmm, honestly, I haven't thought about that, but it's resonable. I have doubts that the current implementation might cause unexpected behavior when scaling up; an experiment is needed. I'll try increasing the allowable coefficient and get back to you with the results.

If everything goes well, it would probably make sense to change this coefficient from 0.5 to 1.5, with a default value of 1.

[DmtryJS]

Fixes: #74

I like it, one thought: Why limiting to max 1 ? Maybe someone wants to zoom in because of frame in the image.

Unfortunately, the experiment was unsuccessful.

I increased the possibility to set the coefficient to 1.5 and got an error. If I interpreted it correctly, the DRM rejected the attempt to set the CRTC_W and CRTC_H to a size exceeding the physical capabilities of the display or the plane. This seems to be a limitation at the GPU level, and it might already be necessary to use the RGA, as in your feature with screen rotation.

Nov 21 19:32:13 radxa-zero3 bash[2099]: Running command: gsmenu.sh values air wfbng air_channel
Nov 21 19:32:13 radxa-zero3 bash[2099]: [2025-11-21 19:32:13.591] [info] Frame info changed 1280(1280)x720(720)
Nov 21 19:32:13 radxa-zero3 bash[2099]: test-only atomic commit failed for plane 76: Numerical result out of range
Nov 21 19:32:13 radxa-zero3 bash[2099]: pixelpilot: /usr/src/PixelPilot_rk/src/main.cpp:222: void init_buffer(MppFrame): Assertion `ret >= 0' failed.
Nov 21 19:32:14 radxa-zero3 bash[2085]: /config/scripts/stream.sh: line 76:  2099 Aborted                 pixelpilot --osd --osd-custom-message --osd-confi>

[seriyps]

looks like this variable is only used to pass as an argument to modeset_prepare. Can you please define it as a local variable in the main() function?

[DmtryJS]

tnx! Moved to main().