Panel resolution?

I’m trying to understand the display output options on this board;

What I’m understanding here, is that the display interface of the APQ8016 is MIPI_DSI, which drives a bridge chip ADV7533 that converts the output to HDMI.

Questions though…

  1. Output resolution; the APQ8016 data sheet says 1280x720. The Android Display Overview says 1280x800. The board specification says that its been tested only at 1920x1080 (presumably scaled up…). Which is the actual maximum real output resolution? 1280x720 or 1280x800?

  2. I have panels with a native resolution of 1280x800. They can accept 1920x1080 and scale it down, but this is redundant and will result in a “fuzzy” output due to scaling twice. It is unclear whether this board is expected to read the EDID from the display and adjust its output according to native resolution or not. If not, what can be done to cause it to output the panel’s native resolution? I do see configurations for 720p and 1080p on the adv7533 in apq8016-sbc.dtsi file, is it a matter of adjusting those to match the panel?

This is the panel; http://www.chalk-elec.com/?page_id=1280#!/7-open-frame-universal-HDMI-LCD-with-capacitive-multi-touch/p/21750207/category=3094861

Have not yet received it (it is in the mail), hence the questions.

Ok, this is becoming an important point now. I’ve received my LCDs, and though they do technically work, the aspect ratio is messed up, and there is obvious visible signs of image scaling.

With the current version of SW running on the board, the native resolution is 1080p. If you are using Android you may try to reduce the native resolution to 720p by selecting a different panel from the dtsi. Can you try the below and see if this works for you?

  • Reboot the device into fastboot mode
  • fastboot oem select-display-panel adv7533_720p
  • Reboot device

That seems to be part way there.
The output is strange though, black bar on the right side of the screen, and the bottom is cut off.

How can I get this thing to apply a custom resolution? I.e., what part of the kernel has to be hacked to make it output 1280x800?

Are you using Android or Ubuntu?

Also, would be great to run a sanity check by connecting an 1080p native LCD with HDMI input and see if the board drives this one well. Do you have a TV screen or computer screen that can be used for checking this?

Android. It runs 1080p perfectly.

ok, good!
Current Android SW on DB410c is configured to drive a pre-configured display configuration which is currently 1080p. Changing the display resolution configuration to 720p may be possible by selecting a different panel in the dtsi (see fastboot steps above or source code change to select 720p configuration as a default). Other options are not available currently. Are you looking to develop source code of adding additional native display resolution?

I’m suspecting that the LCD model that you have tried did not render well 1080p downscaling to its native resolution?

I wouldn’t say that it renders terribly, but there are visual artifacts that are inherent in scaling by non-whole-numbers. In addition, this display is a different aspect ratio.

I’ve downloaded a full android tree from CAF as per the build instructions and am studying the devicetree and adv7533 driver. It looks to me like the command you provided above allows it to select between the two panel specifications in 8016-sbc.dtsi. Unfortunately, the bulk of the values listed in that section are greek to me. At least I understand qcom,mdss-dsi-panel-width and -height. Guess I’m going to have to take some time to read over Documentation/devicetree/bindings/fb/mdss-mdp.txt.

I am looking to make whatever source changes are necessary to support additional displays. Possibly even implementation of EDID handling.

Ok, so I’ve been able to successfully get the framebuffer to the target resolution by changing just the resolution components from the 8016-sbc.dtsi file. I tried with both the 720p and 1080p sections. The display output is messed up on both, but the 720p output is a lot closer to target (not unexpected, since it shares the same horizontal resolution). The 1080p section’s output was severely messed up, basically a grid of random colors all over the screen.

Better output description;

For the 720p output (with actual 720p framebuffer), the top-left of the display is lined up correctly. There is a black bar on the right side of the screen, about 5% of the screen width, and the bottom of the screen is cut off. HOWEVER, it seems like it is actually outputting correctly on the display, since the mouse cursor renders over the black bar, and stops at the bottom of what is visible.

When I increase the vertical resolution to 800, it shifts the entire display down by about 10% of the screen height, and the space at the top becomes a stretched out reflection of what is below the bottom of the visible area.

What is the relationship between mdss_dsi_panel and adv7533_dsi2hdmi?
I mean, I understand that one of them is the SoC output driver (mdss_dsi_panel), and the other is the hdmi converter chip (adv7533), but they both appear to be setting much the same data.

Why would it need to be set in two places?

Looking at the Linaro kernel, the adv7533 is using drivers/gpu/drm/i2c/adv7511.c … which is very significantly more advanced than the Qcom/CAF adv7533 driver. Significantly, to the point, where it actually implements EDID, and should work with virtually ANY resolution.

I think that the 720p display problem is actually on the Android side of things. The black bar on the right of the screen is probably where it wants to draw the back/home/taskswitcher buttons.

It doesn’t look like it will be trivial to integrate the upstream adv7533 driver into the CAF kernel, but in the very least, it can be used to figure out the proper parameters for the panel. It has all the formulas for calculating the HFP, HBP, HSync, VFP, FBP, VSync… which appear to be key.

@doitright: Thank you for your progress updates on getting the touchscreen display working. It’s been helpful to me. Do you recommend the panel you purchased? I’m looking for something similar for a car install.

The panel is actually very nice. I do now have it working at native resolution, I can provide you with the hacks to make it work as needed. You WILL have to compile your own kernel :wink:

The only major thing I have to warn you about for those panels, is the company that is selling them; they are COMPLETELY unresponsive to any kind of email or web form inquiry. If you think you will need warranty or tech support, this could be a deal breaker. If you consider the panels as disposable, then keep on reading.

IF YOU CAN FIT IT, I suggest the black frame panel rather than the open frame. Two reasons;

  1. The open frame’s GLASS is entirely transparent. That means that to make it look nice, you will need to add a cover/surround all the way in to the edge of the display area. This naturally means a raised plastic bezel that will interfere with your finger reaching the digitizer at the extreme edges.
  2. Along the same lines, you need to make a cover to fill in the gaps between the screen and your DDIN faceplate. DDIN is roughly 1.5 inches WIDER than the display area of these panels. Be aware that the actual glass, even on the OPEN FRAME panel, is actually slightly taller than a DDIN opening. The glass is 4.25 inches tall. DDIN is 4 inches – 1/4 inch smaller. In addition, there is a ribbon cable that wraps over the top edge of the glass from the digitizer.

For some unknown reason, they ship with a digitizer firmware that poorly emulates a mouse. I.e., touch the screen, and a mouse cursor will jump to that point. There is apparently no way to actually “click” the mouse.

They do have firmware on their website (and open source software to install it) to swap the firmware over to multitouch. Android as ships with db410c works perfectly with the multitouch firmware, nothing else to do.

The last thing I can say about the panels has to do with certain instances of flickering; one of my panels starts up a minimum brightness, the other about medium. The one that starts at minimum seems to have a minor backlight flickering BEFORE the HDMI signal sets up the monitor. I believe that it is purely a firmware issue, since it stabilizes completely when it has synced up. There is another flicker I’ve seen occasionally that appears to be due to the HDMI cable. Bad quality cables seem to cause a loss of sync and the screen will lose all output. It is especially prevalent when driving the display with 1080p input.

Also note that I have already inquired about powering these things (the db410c) straight off of wacky car power, and they are apparently designed to take the kind of power a car will typically put out, EXCEPT for three situations that can happen to cars in extreme circumstances;

  1. Voltage inversion due to booster cables being hooked up backwards,
  2. over-voltage 24V due to moron tow truck drivers doing dangerous things to make an engine crank,
  3. over-voltage potential due to high-current boost chargers.

Yeah, for the (great!) price of these panels I would consider them disposable and not worry about support. I have the black frame model in my shopping cart on the site now. I was simply awaiting your response before pulling the trigger.

I have to take some measurements, but I may even go with the 10" since I have quite a bit of extra room around the head unit as it is. Especially since it sounds like I’ll need to make some extra modifications anyhow to accommodate the DDIN size difference with the 7".

I would be very interested in getting the info from you on recompiling the kernel in order to get the panel to display in its native resolution.

Good to know, regarding the multi-touch firmware and the default firmware issue, thanks.

I have actually already read your previous conversation regarding the auto-power concerns, that was helpful info for sure and something I hadn’t considered until then.

Thank you again for yet another detailed and insightful response @doitright !

Ok, hopefully this patch makes it through this forum without serious molestation;
Note: I think that ONLY the changes to the apq8016-sbc.dtsi actually made any impact
Note2: This patch should not work… yet it does.


From 69df9a20a022f164e4e0ec7d1c836d7dfaab94ef Mon Sep 17 00:00:00 2001
Date: Tue, 21 Jul 2015 09:10:27 -0400
Subject: [PATCH] Display timings 1280x800 chalkboard 7

---
 arch/arm/boot/dts/qcom/apq8016-sbc.dtsi   | 10 +++++-----
 drivers/video/msm/mdss/adv7533_dsi2hdmi.c | 16 ++++++++--------
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm/boot/dts/qcom/apq8016-sbc.dtsi
index df2b260..947b02d 100644
--- a/arch/arm/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm/boot/dts/qcom/apq8016-sbc.dtsi
@@ -83,7 +83,7 @@
 		adv7533@39 {
 			compatible = "adv7533";
 			reg = <0x39>;
-			adv7533,video-mode = <3>; /* 3 = 1080p */
+			adv7533,video-mode = <3>; /* 2 = 720p */
 			adv7533,main-addr = <0x39>;
 			adv7533,cec-dsi-addr = <0x3C>;
 			adv7533,audio = <1>;
@@ -378,7 +378,7 @@
 		qcom,mdss-dsi-virtual-channel-id = <0>;
 		qcom,mdss-dsi-stream = <0>;
 		qcom,mdss-dsi-panel-width = <1280>;
-		qcom,mdss-dsi-panel-height = <720>;
+		qcom,mdss-dsi-panel-height = <800>;
 		qcom,mdss-dsi-h-front-porch = <110>;
 		qcom,mdss-dsi-h-back-porch = <220>;
 		qcom,mdss-dsi-h-pulse-width = <40>;
@@ -408,8 +408,8 @@
 		qcom,mdss-dsi-lane-1-state;
 		qcom,mdss-dsi-lane-2-state;
 		qcom,mdss-dsi-panel-timings = [A4 24 18 00 4E 52 1C 28 1C 03 04 00];
-		qcom,mdss-dsi-t-clk-post = <0x03>;
-		qcom,mdss-dsi-t-clk-pre = <0x20>;
+		qcom,mdss-dsi-t-clk-post = <0x04>;
+		qcom,mdss-dsi-t-clk-pre = <0x1C>;
 		qcom,mdss-dsi-bl-min-level = <1>;
 		qcom,mdss-dsi-bl-max-level = <4095>;
 		qcom,mdss-dsi-dma-trigger = "trigger_sw";
@@ -417,7 +417,7 @@
 		qcom,mdss-dsi-bl-pmic-control-type = "bl_ctrl_wled";
 		qcom,mdss-dsi-reset-sequence = <1 20>, <0 1>, <1 20>;
 		qcom,mdss-pan-physical-width-dimension = <160>;
-		qcom,mdss-pan-physical-height-dimension = <90>;
+		qcom,mdss-pan-physical-height-dimension = <100>;
 		qcom,mdss-dsi-force-clock-lane-hs;
 		qcom,mdss-dsi-always-on;
 	};
diff --git a/drivers/video/msm/mdss/adv7533_dsi2hdmi.c b/drivers/video/msm/mdss/adv7533_dsi2hdmi.c
index 9f8ea01..7397032 100644
--- a/drivers/video/msm/mdss/adv7533_dsi2hdmi.c
+++ b/drivers/video/msm/mdss/adv7533_dsi2hdmi.c
@@ -216,20 +216,20 @@ static struct adv7533_reg_cfg tg_cfg_720p[] = {
 	{ADV7533_MAIN, 0x17, 0x02},
 	/* Control for Pixel Clock Divider */
 	{ADV7533_CEC_DSI, 0x16, 0x24},
-	/* h_width 0x898 2200*/
+	/* h_width 0x672 1650*/
 	{ADV7533_CEC_DSI, 0x28, 0x67},
 	{ADV7533_CEC_DSI, 0x29, 0x20},
-	/* hsync_width 0x2C 44*/
+	/* hsync_width 0x28 40*/
 	{ADV7533_CEC_DSI, 0x2A, 0x02},
 	{ADV7533_CEC_DSI, 0x2B, 0x80},
-	/* hfp 0x58 88 */
+	/* hfp 0x6E 110 */
 	{ADV7533_CEC_DSI, 0x2C, 0x06},
 	{ADV7533_CEC_DSI, 0x2D, 0xE0},
-	/* hbp 0x94 148 */
+	/* hbp 0xDC 220 */
 	{ADV7533_CEC_DSI, 0x2E, 0x0D},
 	{ADV7533_CEC_DSI, 0x2F, 0xC0},
-	/* v_total 0x465 1125 */
-	{ADV7533_CEC_DSI, 0x30, 0x2E},
+	/* v_total 0x33E 830 */
+	{ADV7533_CEC_DSI, 0x30, 0x33},
 	{ADV7533_CEC_DSI, 0x31, 0xE0},
 	/* vsync_width 0x05 5*/
 	{ADV7533_CEC_DSI, 0x32, 0x00},
@@ -237,7 +237,7 @@ static struct adv7533_reg_cfg tg_cfg_720p[] = {
 	/* vfp 0x04 4  */
 	{ADV7533_CEC_DSI, 0x34, 0x00},
 	{ADV7533_CEC_DSI, 0x35, 0x50},
-	/* vbp 0x24 36 */
+	/* vbp 0x14 20 */
 	{ADV7533_CEC_DSI, 0x36, 0x01},
 	{ADV7533_CEC_DSI, 0x37, 0x40},
 	/* Test Pattern Disable (0x55[7] = 0) */
@@ -267,7 +267,7 @@ static struct adv7533_reg_cfg tg_cfg_pattern_720p[] = {
 	{ADV7533_CEC_DSI, 0x2E, 0x0D},
 	{ADV7533_CEC_DSI, 0x2F, 0xC0},
 	/* v_total 0x465 1125 */
-	{ADV7533_CEC_DSI, 0x30, 0x2E},
+	{ADV7533_CEC_DSI, 0x30, 0x33},
 	{ADV7533_CEC_DSI, 0x31, 0xE0},
 	/* vsync_width 0x05 5*/
 	{ADV7533_CEC_DSI, 0x32, 0x00},
--
libgit2 0.21.4