AndyD wrote:You normally don't want to set framebuffer_height and framebuffer_width. On the Raspberry Pi the framebuffer is a single layer rendered by the compositor onto the display. The framebuffer width and height is independent of the display width and height. Normally, if there is no overscan settings the framebuffer width and height will be the same as the display. However, changing the framebuffer width and height doesn't change the display width and height.
Yes, I understand this, and I use these options only to obtain full screen access - in the price of reduced resolution on Y axis. So I can output picture on every part of the screen, but the pixel resolution is not 1:1 relative to hardware possibilities.
Yes, I've seen it, and used it as a start for my hdmi_timing
There is mention that
So this may be the limit!
May be, and the next post in that thread asks:
dom wrote: 2560x1080 is not possible. 1920x1200 is the maximum resolution supported.
Is that a firmware limitation at present, as I had supposed, or a hardware limit of the gpu?
I guess the answer to this question would put a bold point in this discussion. I have seen somewhere in the code repositories this 1200 limit for the framebuffer, but in later code it is gone, and I thought that the latest firmware would allow me to overcome this limit. Unfortunately the limit seems to be deeper in the hardware.
When you tried hdmi_timings
did you set group and mode as follows?
Yes, I did, but with or without this lines I obtain the same results. Since my tvservice gives the following:
Code: Select all
[email protected]:~# tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
(prefer) mode 87: 1080x1920 @ 60Hz 4:3, clock:136MHz progressive
I think it does not play a big role, because system anyway choose proper mode, but then cuts vertical resolution on some later stage, and finally I obtain 1080x1200