On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake <drake@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |