> Not off hand, sadly we seem to be having the early adopters
> a 4.5 year old device :-/
> 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:
bcm2708_fb.fbwidth=1776 <- look
bcm2708_fb.fbheight=952 <- here
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
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.