Am 28.04.2016 um 00:57 schrieb Michael Mrozek <EvilDragon@openpandora.org>:

Am Wed, 27 Apr 2016 19:38:18 +0200 hat "H. Nikolaus Schaller"
<hns@goldelico.com> geschrieben:

Hi,

thanks for the great work, sounds like we're getting there!

However:

[   17.833109] [CONNECTOR:30:Unknown-1] probed modes :
[   17.838343] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280
1330 1390 1440 0x48 0xa [   17.849178] omap_encoder_update()

This is what puzzles me.

Apparently, Linux finds a 720x1280 resolution - which would mean the
rotation is disabled (and it's also the reason using the framebuffer or
fbturbo-Driver for X doesn't work properly and shows a 720x1280 image
rotated on the 1280x720 screen (meaning: The rotation is correct, but
the right half of the LCD is black and the desktop goes below the LCD).

Shouldn't Linux find a 1280x720 screen mode when the rotator is working
properly?

This appears to report the resolution for the connector (= panel).

For checking if rotation setup is correct, we have to run fbset and xrandr
on the command line:

root@letux:~# fbset

mode "720x1280"
    geometry 720 1280 720 1280 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

root@letux:~# . x 
DISPLAY=:0
XAUTHORITY=/tmp/serverauth.G1HG49BZwS
root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048
HDMI-1 disconnected (normal left inverted right x axis y axis)
None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   720x1280      60.00*+
root@letux:~# 

Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching
the panel driver? Probably only if we make the ssd chip the panel and remove the real
panel from the display aliases?


But I have a first screen output!!!


So the communication of the drivers with each other and the chips is basically working.

Except some timing calculations.

Time for a coffee break :)

BR,
Nikolaus