Hello Jerome,
Thank you for your question.
It is common for portrait displays to take larger LCD panels and effectively 'cut' these down to the desired size. As you have noticed this results in some 'hidden' pixels being clocked to the screen where the original LCD pixels would have been. This happens because the display driver on the LCD panel usually expects to be driven with the RGB/timing signals for the size of the original LCD panel to ensure the pixel data is latched correctly onto the remaining pixels.
Typically the datasheet for the LCD will provide the timing details for the original display panel size (in your case 360x960). And these are the settings that the BT817 display registers should be configured to use.
However as the BT817 in such a case is clocking data out for pixels that are not physically present on the LCD panel, this can affect where the (0,0) point is on the screen depending on the orientation of the remaining pixels on LCD panel. In your case it sounds like the have remove pixels on the left hand side of the original LCD panel (in portrait orientation), these would be the first to be clocked out by EVE. so in a sense what you see as the (0,0) point on the screen is actually (120,0) in regards to the RGB signals being clocked to the display.
There is no register setting similar to REG_ROTATE which would adjust for this, however it may be possible to adjust the display timing settings such as HOffset or VOffset to shift the RGB signal clocking to align with the pixels available on your display. Please note however this is not possible with all LCD panels.
The best approach to mitigate this behaviour in this case would be to add an offset in code, by either:
- Using a global variable with your required offset and add this to all of positioning variables used in your display list
- Or calling VERTEX_TRANSLATE_X and/or VERTEX_TRANSLATE_Y at the beginning of your display lists to let the BT817 compute the required positional change for placing items on the screen
Best Regards,
BRT Community