> Not off hand, sadly we seem to be having the early adopters
problem on
> a 4.5 year old device :-/
Indeed ...
> It's a pity all the EDID and similarly related monitor detection stuff
> wasn't shared across drivers in a central location. Going from a
> closed driver with a forked kernel we've never supported to a fully
> open upstream doesn't give us a lot of room. I'm not a graphics
> developer, nor really a kernel developers, so we're at a combination
> mercy of upstream and not even the ability to dig into the
> driver/firmware to workout what the other driver does.
When the firmware loads the kernel directly the downstream way (without
uboot) it adds a bunch of parameters to the kernel command line:
dma.dmachans=0x7f35
bcm2708_fb.fbwidth=1776 <- look
bcm2708_fb.fbheight=952 <- here
bcm2709.boardrev=0xa01041
bcm2709.serial=<censored>
smsc95xx.macaddr=<likewise>
bcm2708_fb.fbswap=1
bcm2709.uart_clock=48000000
bcm2709.disk_led_gpio=47
bcm2709.disk_led_active_low=0
vc_mem.mem_base=0x3dc00000 <- and
vc_mem.mem_size=0x3f000000 <- here
[ cmdline.txt content follows ]
So, the downstream firmware -> kernel parameter passing actually pretty
simple. I think at least parts of this are also passed via device tree
these days.
Given that downstream plans to switch to the vc4 driver I expected to
find some way to configure overscan with vc4 too (even if it doesn't
pick up the settings from config.txt). But so far I havn't found
anything. Sad to see you have no idea too.
Well as I mentioned I'm not a kernel/GPU/X developer so I wouldn't
expect myself to have much of an idea.... Jack of all trades...
My understanding is that downstream those are hacks and the intention
is to have it automatically deal with that like pretty much all other
drivers do so hacks won't be needed. I have no idea any form of
timeline for that.