Luke Kenneth Casson Leighton wrote: >> Can you >> point me at the relevant bit of the kernel code? > > aw gawd come on, gordan :) The point I was getting at is that the Tegra FB driver doesn't do this at all. It's very minimalistic. >> If you're right, then a >> 720p panel may not be implausible. But my understanding is that the screen >> gets setup by the boot loader, and the Tegra FB driver just works based on >> that, it doesn't configure anything itself. > > hmmm, that sounds about right. and if you don't mind a bit of > "bzzzt" and not being able to see anything during the boot process, > you should be able to overwrite whatever crud settings the bootloader > decided to set, once you've started the linux kernel. > > the tegra fb kernel driver _should_ be setting them anyway. I'll take another look, but I'm 99% certain it doesn't. And my post to the nvidia tegra developer forum regarding this went predictably unanswered. >> The latter may be difficult >> given that nvidia aren't exactly renowned for publishing their specs. > > it's nothing to do with nvidia, and everything to do with the timings > of the LCD. ahh, i see what you mean, you'd need to know where the > registers are for blopping in the hsync, vsync etc. etc. timings. That's what I'm talking about. > yep, you're right. *sigh* that'll need investigating. > > ok - start here. > https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi You're missing the point - there is no code that does the screen geometry setup already available that I'm aware of. The really shocking part is that the binary closed-source Xorg driver doesn't handle EDID either. Or rather - it _does_ (it's reported on Xorg.log) - but it is always the same regardless of the panel used. So either it is hard-coded in the driver or it is somewhere sufficiently low-level to intercept and override what comes back from the panel. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
