The current documentation provides very contradictory information about HDMI support. First it talks about 1920x1080@60 LCD panel
and then suddently about 1920x1080@30 support.
The android documentaion says that one needs to set the kernel command line parameter to
video=HDMI-A-1:1280x800@60
I have found two HDMI threads from 2017 in the board archive,
but it is still not clear from this discussion if the ADV7355 driver does not support 1920x1080@60 , or if it is a problem of kirin_drm driver. I can not imagine that ADV7355 hardware is a problem here.
The mini-datasheet
http://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf says
“The HDMI transmitter supports video resolutions up to a
maximum TMDS clock frequency of 148.5 MHz.”.
I have tested the board with 3 Dell LCD monitors, and they provide consistent results. The 1920x1080@60 mode leads to kernel (4.14-rc7 used by RPB) crash,
the 800x600@60 does not show anything on the display, and only
1280x720@60 is working properly with the RPB Xorg server.
The 1280x720@60 console framebuffer suffers from pixel line overruns, which are eventually fixed by vrefresh, but the user experience is pretty disappointing.
I have compiled the list of tested vrefresh=60Hz modes
reported through EDID, only 4 of them are working:
640x480 -- dss_pxl0_clk = 23454
800x600 -- dss_pxl0_clk = 40000
1024x768 ok dss_pxl0_clk = 64000
1280x720 ok dss_pxl0_clk = 72000
1280x800 ok dss_pxl0_clk = 80000
1600x900 -- dss_pxl0_clk = 117272
1600x1200 ok dss_pxl0_clk = 160000
1920x1080 -- dss_pxl0_clk = 169636
1920x1200 -- dss_pxl0_clk = 192000All modes with 50Hz or 75Hz are not working.
I don’t really have any intelligense specific to RPB but on the hardware side… the video hardware in the SoC of both Hikey and Hikey960 has a fairly inflexible pixel clock PLL which restricts the range of pixel clocks in can generate.
In the AOSP code base there are some hacks to recognise some CEA-861 video modes that the hardware can’t hit exactly and mutate the pixel clock to one that does work. 1080p60 is one these modes… with the pixel clock modified the mode is actually 1080p58 and does cause problems with some monitors (typically strict TV-like devices that blank the image if it is “unhappy”).
It looks like your display is monitor like and these tend to be more compatible. However if it possible that the 1080p60 mode ends up out of spec if it does not use CEA-861 timings and isn’t picked up by the hacks to recognise specific pixel clocks (because the PLL code tends to round up).
https://bugs.96boards.org/show_bug.cgi?id=598 contains some useful attachments describing some of the impact.
PS 50Hz cannot workaround these issues… CEA-861 modes are designs so that 1080p50 and 1080p60 have different active areas and hence both use the same pixel clock.
My results show that the supported working pixel clocks all lie 8MHz apart (64,72,80,160 MHz),
which seems to be the minimal PLL divisor step.
I don’t understand why 800x600@60 does not work with 40 MHz pixclock, and why does the kernel code select 169636 kHz for 1920x1080@60 instead of 148.5MHz (which will be hacked into supported 144 MHz).
The 1920x1080@30 mode works, but only my most expensive Dell LCD monitor supports it 
I have installed full KDE on Debian 9 now, and tested it with video= 1920x1080@30 , 1600x1200@60 and 1280x720@60.
The 1600x1200@60 looks/feels like a software (hardware?) stretched image (16:9 → 4:3 aspect ratio).
1920x1080@30 feels a bit slow and has spurious line distortions (missing hardware acceleration?).
1280x720@60 works well, so probably it should be made the default video mode.
