2

I'm running Armbian on an Allwinner H3-based SBC (NanoPi M1):

NanoPi M1

As you can see, it has a CVBS out, and fair enough, after a bit of tinkering with the bootloader's script.bin (which compiles in and out of an .ini-like FEX format with bin2fex and fex2bin), and also figuring out the pin order for video on a 3.5mm TRRS jack, I got it talking to one of those old TVs.

But, I was soon reminded of one of the shortcomings of those old TVs: overscan.

tv photo

This is not even the TV this will be used on, so I can't trust on it having any "auto-fit" option. I'd rather have the framebuffer waste some space on black borders. I'm accessing it via SSH.

I've looked at what boot options the script.bin allows, and it does not offer overscan, just setting the resolution. I've also looked at xrandr, fbset and the files in /sys/devices/platform/disp/graphics/fb*, but I can't seem to figure out how overscan can be solved - I only manage to clip the screen to one side. Maybe I have to tell the desktop environment (Xfce) not to use the full framebuffer? Their docs seem scarce. I don't know what I'm doing, really.

When looking at solutions for other single-board computers, the solutions I find are specific to each board (Like the Raspberry Pi having a solution specific to its Broadcom boot script). By looking for general-purpose Linux solutions, I find most people solving it from the specific graphics card drivers.

It's simple to describe: I just don't want the whole screen to be used. But I have no idea where to look.

Paste with dmesg.

fbset looks like this:

mode "720x480"
    geometry 720 480 720 480 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/24
endmode

I've tried adjusting the timings (e.g., fbset -left N), but even if it did report the change (by calling fbset again), nothing changed - changing e.g., -xres, on the other hand, caused visible results (screen clipping).

The display module is tv. modinfo tv gives me:

filename:       /lib/modules/3.4.112-sun8i/kernel/drivers/video/sunxi/disp2/tv/tv.ko
alias:          platform:tv
license:        GPL
description:    tv driver
author:         zengqi
depends:
intree:         Y
vermagic:       3.4.112-sun8i SMP preempt mod_unload modversions ARMv7 p2v8
Improve this question
7
  • I don't think trying a smaller virtual size (fb or X) than screen size will work, and I also don't think xfvwm4 can restrict window placement to a smaller area. If your hardware supports it (what driver is used for composite mode? dmesg?) you can try to fiddle with the display timings (fbset) for a TV-compatible modeline with larger borders and less resolution. But there may be hardware restrictions on what modelines work. Any links to hardware documentation of the TV output part?
    – dirkt
    Dec 27, 2016 at 8:46
  • I've edited the question with more info (if that was not it please say) - also, do you mean this can't be done outside of the module that drives the display? (I thought X could clip the screen or something).
    – Camilo Martin
    Dec 27, 2016 at 14:12
  • Both X and fb can use a larger "virtual" framebuffer, and then display parts of that on the various "heads" (displays), but the problem is that you need it the other way around: A smaller virtual buffer than what is displayed, and I don't think that will work, because normally the virtual framebuffer defaults to the maximum of all display extents.
    – dirkt
    Dec 27, 2016 at 15:14
  • TV kernel source seems to be here All of drv_tv.c, tv_ac200.c and de_tve.c seem to use hardcoded timings (from a quick look). So, not unexpectedly, to change the TV modeline you very likely must change the source code (and try to find some hardware docs before you do that). I'm afraid I can't think of an easier way.
    – dirkt
    Dec 27, 2016 at 15:21
  • Thanks for pointing me in that direction, I wouldn't know where to look. I now see why the framebuffer should be set to the full screen, but X is drawing to the framebuffer, right? Isn't this process configurable? (Isn't this how desktop compositing such as Compiz work?)
    – Camilo Martin
    Dec 27, 2016 at 17:27

1 Answer 1

Reset to default
1

Please try these commands:

devmem2 0x01E00130 w 0xF0050398
devmem2 0x01E00130 w 0x30050398
fbset -xres 670 -vxres 670

xresolution is reduced to 670, but everything is OK for my Orange Pi Zero. Maybe change to correct address of "TV ENCODER RE-SYNC PARAMETERS REGISTER (Offset 0x130)" for your SoC.

Improve this answer
1
  • Ok it's been a month and I've been meaning to try it but have to comment I really didn't yet, I just appreciate a lot that you've added a possible solution to this problem. Given the 2 upvotes I believe someone had tried it, so now it's three :) if someone can comment confirming it works for them before I get around to it I'll accept your answer. It's really above what I would have been able to come up with on my own, I didn't even knew you could do that devmem2 stuff from userland.
    – Camilo Martin
    May 18, 2017 at 0:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .