I’m trying to set up a new display working at 1280x800 -16@60
Customization is stil in progress but i’ve already did many tests with something like this:
clock-frequency = <83460000>;
hactive = <1280>;
vactive = <800>;
hback-porch = <200>;
hfront-porch = <64>;
vback-porch = <24>;
vfront-porch = <1>;
hsync-len = <136>;
vsync-len = <3>;
de-active = <1>;
hsync-active = <1>;
vsync-active = <1>;
pixelclk-active = <1>;
No matter what kind of front/back porch or hsync-active (even pixclock) i choose, the output remains the same and when i get settings from fbset i got always the same data:
# D: 83.500 MHz, H: 49.703 kHz, V: 59.811 Hz
geometry 1280 800 1280 800 16
timings 11976 200 72 22 3 128 6
fbset seems responding and so the screen does when i set some params from command line (not for every params)
fbset --left value
Why there’s no clear link between fbset timings and my device tree? maybe dtb has some errors? or what?
P.S: Are resolution and refresh frequency somewhat limitated by this device?
Thanks in advance.
fbset should reflect your changes to the device tree. Can you please show me the output of the
vidargs environment variable on U-Boot? It could be that U-Boot is not fetching the proper timings you added.
Also, if you’re really using our Linux BSP v2.8b2, I recommend you to update to the latest stable version (2.8.7).
Sorry, i desappeared from the forum for a while, anyway fbset was working, initially we didn’t get that LCD monitor under test had a processing image logic not allowing us to appreciate fbset behaviour.
So is everything working now?
I think it was a “false alarm”, then
Hi André, we cannot sense it directly, i can state for sure that our monitor is doing something on his own over image positioning…my opinion now is fbset works.
Thanks for suggesting us to move to 2.8.7, i’ll take into account seriously.
Thanks for the feedback.
Honestly, we only advise moving to BSP 2.8b7 if your environment is strictly built upon our BSP 2.8 base, and moving to a newer BSP could cause a major impact on your project and your time-to-market.
But, if you have the opportunity, I’d like to suggest you move to BSP 3.0.4 (or BSP 3.0b4), because it’s our current major LTS BSP, and it has a lot more improvements.
I’ m gonna spend a few hours giving a try to bsp 3.
I just need:
- rtc clock
- qt 5 + x11
- m4 rpmsg
- some basic stuff like eth, uart, sd card
Well, I can say for sure that they are OK for the BSP 3.0.4.
Please let me know if you need any further assistance.
Can I close this issue for the moment?
Bsp 3.0.4 has just passed first round of testing, this is not a complete check up for our platform but it’s enough to let us using new platform for our dev purpouses!
Yes, it’s a start. Good to know.
If you have any other issues, please let us know.