exynos-drm 1024x768 HDMI output

Daniel Drake drake at endlessm.com
Fri Dec 13 07:46:52 PST 2013


On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake <drake at endlessm.com> wrote:
> What I feel we are missing here is an explanation for why the first
> row of pixels is treated differently from the rest. Every value that I
> tweak seems to have an effect on the first line (which was rendered
> OK) as well as all the others (which were bad). If it were just a
> matter of tweaking e.g. h_fsz then I would expect *all* rows of pixels
> to have been rendered badly in the first place.
>
> Nevertheless, I'm happy to continue throwing values at the variables
> if that is our best option... We need to find a way of making a change
> that effects the only first line, or all the lines except the first.

I have an idea, but my understanding of CRT timings isn't quite strong
enough to tell me exactly how to implement it. Maybe you can help
suggest what variables to tweak in order to try this experiment:

Lets just accept the fact that the first line of the output image is
rendered badly. Specifically, it has 257 black pixels added onto the
end of it. The following rows do not exhibit that problem.

To accept and ignore this oddity, I want to make the device start
outputting the image exactly 1024+257 pixels too early. i.e. I want
1281 junk pixels before the image starts.

Then, I want to adjust the timing parameters appropriately so that
those junk pixels do not appear on the display. I want those 1281 junk
pixels to be sent to the display during the horizontal scans that
happen before the top left visible pixel is clocked. I think I'm
saying: I want to adjust the field of view so that those 1281 junk
pixels are rendered inside the vertical back porch.

Does that make any sense?

Daniel


More information about the dri-devel mailing list