This is a cache of https://discuss.96boards.org/t/which-mipi-dsi-display-touch-panel-works-with-the-dragonboard/1103. It is a snapshot of the page at 2024-11-14T05:59:52.427+0000.
Which MIPI DSI display + touch panel works with the <strong>dragonboard</strong>? - <strong>dragonboard</strong>410c - 96Boards Forum

Which MIPI DSI display + touch panel works with the dragonboard?

Products Support dragonboard410c
#1

Which MIPI DSI display + touch panel works with the dragonboard?

DB410C with Waveshare Display and Android
#2

As answered here: http://www.96boards.org/forums/topic/which-mipi-dsi-display-touch-panel-works-with-the-hikey-board

#3

Quick Summary ( December 2016 )

There are no known MIPI DSI displays + touch panels available for HiKey an dragonboard.

#4

Is there any HDMI display with cap. touchscreen (7-11 inch) which work with dragonboard/android out of box?

Regards,
Irvin

#5

No, not that we have found so far.

We have success with the Toshiba DSI bridge with small LCD.

Toshiba Bridges: http://toshiba.semicon-storage.com/us/product/assp/interface-bridge.html

Helpful links:

  • Follow their DSI porting guide as we found it to be a good resource (not complete but enough to get you going).

  • Here are links to their already premade DTSI for known LCD screens. I had a hard time figuring out where to even source them (the links are in the porting guide as well fyi).

    • Our backup plan was to use the FBTFT project since our screens also had SPI input (but we couldn’t use it b/c our supplier didn’t break out those pins. But I found Adafruit had screen that did have the SPI pins available).

    #6

    Please check this out:

    http://www.96boards.org/product/linksprite-7-display-kit/, https://www.arrow.com/en/products/96boards-display-7/linksprite-technologies-inc, http://learn.linksprite.com/project/hdmi-touch-screen-for-96boards/

    #7

    Vchong, thanks for answer.
    Will this LCD (http://www.96boards.org/product/linksprite-7-display-kit/) also work with Android installation on dragonboard? Only Debian is mentioned on page.

    #8

    @irvin you’re welcome.

    I don’t have the hardware to try either so can’t really say for sure but it seems like some effort will be required to get it to work. According to http://www.96boards.org/forums/topic/problem-with-connecting-monitor-to-db-410c/#post-19104, “the display drivers for Android are hard coded to show video in HDMI mode at 1920×1080”, but the spec for this screen is only 800×480. The post also mentioned recompiling AOSP for other video timings, but again, not sure how the screen will react to it.

    FYI the user in http://www.96boards.org/forums/topic/problem-with-connecting-monitor-to-db-410c is also trying to do display AOSP using an ASUS VT207 touchscreen display.

    #9

    Yes, i already aware of Display porting guide, timings, building from scratch. Actually it should not be a problem (it takes time), but I’m surprised that there is no LCD out of the box, even with HDMI (1920×1080) and USB touch screen.

    Android release note says:

    • Lilliput USB touch HDMI display support added to work out of the box

    I checked Lilliput site, they is so many LCD so don’t know which one is “out of box”. However there is no LCD with diagonal less than 10 inch with native 1920x1080 resolution.

    #10

    Some quick detective work reveals that it MIGHT this: http://www.lilliputuk.com/monitors/hdmi/779gl/

    Sources:
    https://portland.source.codeaurora.org/patches/quic/la/PATCH_8x16_129905_410c_LA.BR.1.2.4-01810-8x16.0/kernel/0004-ttyHS4-uart-and-USB-lilliput-touch-changes.patch
    #ifdef CONFIG_USB_HID_LILLIPUT_MULTITOUCH
    /*Lilliput Capacitive TouchScreen */
    #define USB_VENDOR_ID_LILLIPUT 0x1391
    #define USB_PROD_ID_LILLIPUT 0x2112
    #endif

    http://forum.odroid.com/viewtopic.php?f=51&t=15495&start=50
    VID: 1391
    PID: 2112
    Brand: Lilliput 779GL-70NP/C/T - 7" HDMI Capacitive Touchscreen monitor
    Board: U3+

    #11

    Hello halfbit,

    It is my request that you share me the information regarding the porting. I am doing something very similar. (using a Toshiba bridge). This is for qualcomm SD210.

    I understand that Toshiba does very little in bringing up. I am seeing that on LVDS TX side only clock and one data lane toggles when i have configured for all four lanes.

    I have clueless now after one month of this work. I see nothing but a flash of white light popping up and gone. Nothing on the display.

    Please help.

    #12

    Hey,
    Sorry, I can’t tell you specifics about the Toshiba board and our source code/binaries is not published externally.

    But I can prob direct you on hints though.

    Here is something to work of off, its a similar chipset: https://github.com/ultragtx/kernel-glass/tree/master/drivers/video/omap2/displays

    Looks like the RPI guys finally releasing their source for the driver: https://patchwork.kernel.org/patch/9723275/

    We wrote our own I2C library to interface with the Toshiba to configure it correctly. We wrote a DSI dtsi configuration and matched it with our LCD configuration and set it all up through the I2C library. This is pretty crucial, the LVDS will be weird if isn’t configured to match the DTSI.

    Also, depending on the LCD you’re using, you may need to have another driver for it. We have a SPI interface/driver to also configure the LCD independently of the bridge and DTSI files. This isn’t really necessary but we had some weird color data quirks and tweaked it on the LCD side rather than hacking the Qualcomm driver.

    One hint that wasn’t documented was that the Toshiba bridge comes up in sleep mode and requires the I2C wake up command to put it into active mode. Otherwise, the display never turns on. That took me a while of probing and scoping to figure that out:s

    #13

    hello Jaime,

    Do you think driver is necessary? i am just trying to get it done by on-commands. I just want to see something on the display.

    I am only trying to read from the registers through i2c driver.

    The analysis from registers shows below info

    " This bit is set if the synchronization FIFO in PPI from HS data RX clock to system clock is full when an additional HS data is written. Assertion of this bit means there was an omission in RX data. An overflow may happen for example when the system clock is slower than the line rate byte clock "

    But system clock is way higher than the rate byte clock.

    Can you make out something??

    Thanks a lot for response

    Manju

    #14

    Hey,

    Yes and no. There is probably a way to do it without a driver but I haven’t seen it.

    No idea without context. It’s too specific and the error/state flags are not useful if you’re not actively working on it. I’m not an expert on the chip, took trial and error to figure it out… I’ve mostly ignore many of the error/state flags and only focused on the lane setup and PPI configuration but this was specific to my application, I don’t know if you would need more configuration like clock configurations.

    Do read over RPI’s implementation: rpi_bridge_enable() in https://patchwork.kernel.org/patch/9723275/. They have a known working setup and I would try to match theirs.