[[PageOutline]] = Ventana LVDS Support = [=#devkit] == Gateworks LCD Development Kits == Gateworks offers packaged LCD touchscreens that are plug and play with the Ventana board that have a LVDS interface. Gateworks offers a 7" display. Use the following part numbers for ordering: * [#WSVGA-7in 7" WSVGA (1024x600) display with backlight and 5pt capacitive touch]: * GW17047 7" LCD [wiki:ventana/LVDS#displays Display] * GW10109 (8in) GW16113 (36in) GW16114 (60in) Cable * GW16131 Touch Interface (for 7" LCD) * GW10111 Aluminum Bezel (for 7" LCD) * EOL 8" Model - For reference only - [#XGA-8in 8" XGA (1024x768) display with backlight and 5pt capacitive touch]: * GW17030 8" LCD [wiki:ventana/LVDS#DLC800FIGT38XGATouchscreenDisplay Display] * GW10109 (8in) GW16113 (36in) GW16114 (60in) Cable * GW16114-2 Touch Interface (for 8" LCD) [=#lvdsspecs] == Ventana LVDS Connector Specifications == The Ventana GW5400/GW5300/GW5200 designs all support LVDS via a 30 pin connector that provides: * 3D+C (3 differential pairs data, 1 differential pair clock at 2.5V) for [http://en.wikipedia.org/wiki/Low-voltage_differential_signaling LVDS Video in compliance iwth EIA-644] * Signalling is 1.0V to 1.4V (1.2V common mode) with a 400mV swing (3.3V logic level) * the maximum pixel clock (85MHz) and the maximum clock of the LVDS serializer results in a maximum resolution of WXGA (1366x768@60Hz with 35% blanking) * 3D+C allows for 6bit-per-color for 18bit color (262K colors) for 6bit per color * displays which support 4D+C for 6bit-per-color (24bit color) typically use the 4th data pair for bit7/bit8 thus can likely be interfaced with Ventana as 6bit 3D+C (consult display datasheets) * 1xPWM (3.3V) For backlight brightness * 1xGPIO (3.3V) For control * 1xGPIO (3.3V) for touchscreen controller IRQ# * 1xi2c (3.3V) for EDID and touchscreen or backlight controller * 3.3VDC (always-on power) * 5.0VDC (always-on power) Refer to the individual product manuals for more details. The LVDS video output is available through a 30-pin connector in a 1x30 configuration with 1mm pin spacing. * The mating connector for a discrete wire plug is a Hirose DF19-30S-1C, available from Digi-Key as part number H3104-ND[http://www.digikey.com/product-detail/en/DF19-30S-1C/H3104-ND/679730 link here]. * The crimp contacts for the discrete wire connector are Hirose DF19A-3032SCFA, available from Digi-Key as part number H12154CT-ND [http://www.digikey.com/product-detail/en/DF19A-3032SCFA/H12154CT-ND/3739512 link here]. * Crimp Gun [http://www.digikey.com/product-detail/en/HT302%2FDF19S/H3131-ND/679757 H3131-ND ] IMX6 LVDS details: * Display interface clock: 20-85 MHz * Serializer clock: 140-595 MHz * while the IMX6 itself has 2 LVDS ports each supporting up to 4D+C (4 data pairs plus 1 clock pair) which can be used as separate displays or combined (see [http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf IMX6DQRM section 39.4.2]), the Ventana designs only bring out 3D+C (3 data pairs plus 1 clock pair) of the first lvds port * for details on bitmapping supported see [http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf IMX6DQRM] section 39.5.2 Ventana 30-pin LVDS connector pinout: ||= Pin =||= Signal =||= Notes =|| || 1 || BACK_EN# || GPIO1_IO10 (gpio10) || || 2 || 3.3V || || || 3 || 3.3V || || || 4 || 3.3V || || || 5 || BACK_ADJ || PWM4 or GPIO1_IO18 (gpio18) || || 6 || SCL || I2C3 - /dev/i2c-2 || || 7 || SDA || I2C3 - /dev/i2c-2 || || 8 || TX0- || differential pair || || 9 || TX0+ || differential pair || || 10 || GND || || || 11 || TX1- || differential pair || || 12 || TX1+ || differential pair || || 13 || GND || || || 14 || TX2- || differential pair || || 15 || TX2+ || differential pair || || 16 || GND || || || 17 || CLK- || differential pair || || 18 || CLK+ || differential pair || || 19 || GND || || || 20 || 5V || || || 21 || 5V || || || 22 || GND || || || 23 || GND || || || 24 || 5V || || || 25 || 5V || || || 26 || 5V || || || 27 || SCL || I2C3 - /dev/i2c-2 || || 28 || SDA || I2C3 - /dev/i2c-2 || || 29 || TOUCH_IRQ || IMX6 GPIO7_IO12 (gpio204) || || 30 || N/C || || * The BACK_EN# signal is an ARM GPIO and can be routed to various LVDS display features. Typically this is either used as a RST# or a backlight enable. * The BACK_ADJ signal can be an ARM GPIO or a PWM. Note that the Ventana bootloader always configures BACK_EN# (gpio10) as output-low but leaves BACK_ADJ as a high-impediance input with a 100k pull-up unless the {{{panel}}} env is set to one of the supported LVDS configurations (see [#displays below]) in which case the bootloader {{{enable_lvds}}} function drives BACK_EN# low making it appropriate if connected to an active low enable or active high reset and BACK_ADJ high making it 100% brightness. Note that the Ventana Linux kernel does not configure BACK_EN# (gpio10) (thus leaving it configured from the bootloader and exportable/managable by userspace) but does configure BACK_ADJ as PWM4 adjustable via {{{/sys/class/backlight}}}. If the above configuration is not compatible with your LVDS display you will need to make adjustments to the bootloader and/or kernel. [=#power] === LVDS Power Pins === The LVDS connector that we use has three pins assigned to 3.3V and five pins assigned to 5V. The maximum current depends on the wire gauge of the cable used with the connector and the 5V supply on the board. A 36 gauge cable is 0.5A per contact, a 30 gauge cable is 0.9A per contact, and a 28 gauge cable is 1A per contact. LVDS Connector 3.3V: - The GW52xx, GW53x, and GW54xx all have 30W available from the 3.3V supply and you can subtract ~3W for baseboard operation and additional power depending on PCIe devices (ie radios) to determine what is left for LVDS. - The limiting factor for the 3.3V current is going to be the connector and cable combination. Since 3.3V power has 3 pins, there is between 1.5A and 3A available depending on the wire gauge. LVDS Connector 5V: - 5V power supplies on the Ventana products have a much lower current rating than the 3.3V supply therefore you should pay careful attention to the 5V power needs of your display. - GW52xx has a 1A capable 5V supply shared between CAN transceiver, HDMI DDC, and LVDS. - GW53xx-B and earlier board revisions have a 800mA capable 5V supply shared between front-panel USB, CAN transceiver, HDMI DDC, and LVDS. - GW53xx-C, D, and E board revisions have a 1.6A capable 5V supply shared between front-panel USB, CAN transceiver, HDMI DDC, and LVDS. - '''Note''' - The 3.3V to 5V boost part used on these revisions has an inrush limitation of 100mA at power-up, causing some displays to not reliably power on - GW53xx-F and above have a 700mA capable 5V supply shared between CAN transceiver, HDMI DDC, and LVDS. - GW54xx has a 600mA capable 5V supply shared between CAN transceiver, HDMI DDC, FAN power, and LVDS. [=#displays] == Supported Displays == While you should be able to make a wide variety of LVDS displays work, Gateworks provides software support and cables for several readily available displays. Please contact sales@gateworks.com for details. [=#gw17047] === GW17047 DLC0700XDP21LF 7" WSVGA Touchscreen Display - Recommended === The GW17047 DLC0700XDP21LF 7" WSVGA Touchscreen Display is a low-cost display supporting: * 7" LCD 1024x600 display with backlight * Physical size (W/H/D): 165.75 x 105.39 x 5.39mm * Active area: 153.6 x 90.00mm * Resolution: 1024x600 24bit RGB * Pixel pitch: 0.05 x 0.15mm * Pixel config: RGB stripes * Mode: Transmissive, normally black * Brightness: 200 nits * Contrast: 700:1 * Backlight: LED * Interface: LVDS * Technology: IPS TFT * Power consuption: 1W to 2W (typ) * operating temperature: -20C to +70C * 5pt Capacitive touch via FT5406 touch controller * 10-point capacitive touch * scanning frequency: >100 Hz * channels: 28 (drive) * 16 (induction) * active area: up to 8.9" * transmission: i2c i2c-2@0x38 * operating temperature: -40C to +85C * !SmarterGlass LVDS-7 adapter board provides pwm-controlled backlight * [http://dev.gateworks.com/datasheets/DLC0700XDP21LF-C-1%20SPEC.pdf DLC0700XDP21LF-C-1 Datasheet] Gateworks Bootloader support: * you can enable display out in the bootloader via: {{{#!bash setenv panel DLC0700XDP21LF saveenv }}} Android Kitkat+ support: * Enable display and touch support for Android !KitKat by setting the {{{display}}} env variable in the bootloader: {{{#!bash setenv display DLC0700XDP21LF saveenv }}} Yocto Support: * For the touch controller, use a fixfdt variable in the bootloader to invert the touch controller: {{{ setenv display DLC700JMGT4 setenv fixfdt "${fixfdt}; fdt resize; fdt rm /soc/aips-bus@02100000/i2c@021a8000/edt-ft5x06@38 invert" saveenv }}} [=#WSVGA-7in] === GW17029 DLC700JMGT4 7" WSVGA Touchscreen Display - End of Life === This display is no longer carried by Gateworks. [[CollapsibleStart(Expand Details)]] The GW17029 DLC700JMGT4 7" WSVGA Touchscreen Display is a low-cost display supporting: * 7" LCD 1024x600 display with backlight * Physical size (W/H/D): 165.75 x 105.39 x 5.39mm * Active area: 153.6 x 90.00mm * Resolution: 1024x600 24bit RGB * Pixel pitch: 0.05 x 0.15mm * Pixel config: RGB stripes * Mode: Transmissive, normally black * Brightness: 200 nits * Contrast: 700:1 * Backlight: LED * Interface: LVDS * Technology: IPS TFT * Power consuption: 1W to 2W (typ) * operating temperature: -20C to +70C * 5pt Capacitive touch via FT5406 touch controller * 10-point capacitive touch * scanning frequency: >100 Hz * channels: 28 (drive) * 16 (induction) * active area: up to 8.9" * transmission: i2c i2c-2@0x38 * operating temperature: -40C to +85C * !SmarterGlass LVDS-7 adapter board provides pwm-controlled backlight * [http://dev.gateworks.com/datasheets/DLC0700DDG-4%20SPEC%20V1.1.pdf DLC0700JMG Datasheet] Gateworks Bootloader support: * you can enable display out in the bootloader via: {{{#!bash setenv panel DLC700JMGT4 saveenv }}} Yocto support: * you can enable display and touch support for Yocto by setting the {{{video}}} env variable in the bootloader: {{{#!bash setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-WSVGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off' saveenv }}} * Alternatively, you can enable support for this using version v1.06+ bootscript {{{#!bash setenv display DLC700JMGT4 saveenv }}} Android Kitkat+ support: * you can enable display and touch support for Android !KitKat by setting the {{{display}}} env variable in the bootloader: {{{#!bash setenv display DLC700JMGT4 saveenv }}} [[CollapsibleEnd]] [=#XGA-8in] === GW17030 DLC800FIGT3 8" XGA Touchscreen Display - End of Life === This display is no longer carried by Gateworks. [[CollapsibleStart(Expand Details)]] The GW17030 DLC800FIGT3 8" XGA Touchscreen Display is a low-cost display supporting: * 8" LCD 1024x768 display with backlight * Physical size (W/H/D): 168.80 x 139.17 x 4.43mm * Active area: 162.05 x 121.54mm * Resolution: 1024x768 24bit RGB * Pixel pitch: 0.05275 x 0.15825mm * Pixel config: RGB stripes * Mode: Transmissive, normally black * Brightness: 280 nits * Contrast: 800:1 * Backlight: LED * Interface: LVDS * Technology: IPS TFT * Power consuption: 1W to 2W (typ) * operating temperature: -10C to +50C * Capacitive touch via GT9110 touch controller * 10-point capacitive touch * scanning frequency: 100 Hz * channels: 42 (drive) * 30 (induction) * active area: 7" to 12.1" * transmission: 7.0Kbps (max) i2c i2c-2@0x14 * gesture and !HotKnot support * operating temperature: -40C to +85C * !SmarterGlass LVDS-7 adapter board provides pwm-controlled backlight * [http://dev.gateworks.com/datasheets/DLC0800FIG-5.pdf DLC800FIG Datasheet] Gateworks Bootloader support: * you can enable display out in the bootloader via: {{{#!bash setenv panel DLC800FIGT3 saveenv }}} Yocto support: * you can enable display and touch support for Yocto by setting the {{{video}}} env variable in the bootloader: {{{#!bash setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off' saveenv }}} * Alternatively, you can enable support for this using version v1.06+ bootscript {{{#!bash setenv display DLC800FIGT3 saveenv }}} Android !KitKat+ support: * you can enable display support for Android !KitKat by setting the {{{display}}} env variable in the bootloader: {{{#!bash setenv display DLC800FIGT3 saveenv }}} [[CollapsibleEnd]] [=#XGA-10in] === Freescale MCIMX-LVDS1 10" XGA Touchscreen Display === [[CollapsibleStart(Expand Details)]] The 'Freescale LVDS1' or 'MCIMX-LVDS1' was originally designed for an i.MX53 dev kit and is a LCD+Backlight-controller+Touchscreen-controller. This is the display used in many of the Gateworks demo videos and is directly compatible with our LVDS connector. Its available from a few distributors if you search but always $500: * [https://www.digikey.com/products/en?keywords=MCIMX-LVDS1 Digikey] * [http://www.newark.com/freescale-semiconductor/mcimx-lvds1/daughter-card-10-1in-lcd-module/dp/45T2344 Newark] * [http://www.mouser.com/ProductDetail/Freescale-Semiconductor/MCIMX-LVDS1/?qs=Bd5/XmnHbhsyKVtPrY51Kg== Mouser] Details: * Display: 10in 1024x768 pixel 128dpi LCD HSD100PXN1 * Touch Controller: [http://dev.gateworks.com/datasheets/EXC7200_Datasheet.pdf EXC7200] on i2c-2@0x04 * IRQ via gpio-11 on GW5200/GW5300, gpio-204 on GW5400 * Backlight: White LED (PWM Driven) on i.MX6 pwm4 * Power Consumption: approximately 700mW to 1.5mW depending on BL brightness * supports [http://www.ecnmag.com/articles/2010/04/content-adaptive-lcd-backlight-control Content Adaptive Backlight Control] (CABC) via gpio-10 * when enabled this sets backlight automatically according to content - this can cause annoying flickering and is usually best disabled by de-asserting the gpio (driving low)) Gateworks Bootloader support: * you can enable display out in the bootloader via: {{{#!bash setenv panel Hannstar-XGA saveenv }}} Yocto support: * you can enable display and touch support for Yocto by setting the {{{video}}} env variable in the bootloader: {{{#!bash setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off' saveenv }}} * Alternatively, you can enable support for this using version v1.06+ bootscript {{{#!bash setenv display Hannstar-XGA saveenv }}} Android !KitKat+ support: * you can enable display and touch support for Android !KitKat setting the {{{display}}} env variable in the bootloader: {{{#!bash setenv display Hannstar-XGA saveenv }}} [[CollapsibleEnd]] === Gateworks LCD Setup === This setup applies to the Gateworks 7 and 8" LCD kits. * 7" WSVGA (1024x600) display with backlight and 5pt capacitive touch: * GW17029 7" LCD Display * GW10109 (8in) GW16113 (36in) GW16114 (60in) Cable * GW16114-1 Adapter Board (for 7" LCD) * 8" XGA (1024x768) display with backlight and 5pt capacitive touch: * GW17030 8" LCD Display * GW10109 (8in) GW16113 (36in) GW16114 (60in) Cable * GW16114-2 Adapter Board (for 8" LCD) Procedure: 1. Plug the small ribbon cable on the LCD into the adapter board slot as pictured [[Image(lcdadapterboard.jpg,400px)]] 2. Take the GW10109/GW16113/GW16114 Cable and plug the side with two connectors into the LCD and the Adapter board. [[Image(lcdcables.jpg,400px)]] 3. Plug the single end of the cable onto the Ventana board LVDS connector. [[Image(ventanalvdsconnector.jpg,400px)]] [=#touchcontroller] == Touchscreen sensors Touchscreen's are displays that have bonded to them a thin transparent sensor layer to detect touch events. These can have a variety of features and technologies: * resistive touch vs capacitive (each has their pro's and con's) * communication channels (I2C vs USB typically) - the Ventana LVDS connector itself supports an i2c channel although USB can be picked up from the main-board on different connectors * multi-touch vs single-touch * other features... There is a large variety of touch sensor controllers (the chip) and touch sensor's (the layer with the micro-wires or elements that connect to the controller chip). Each controller chip has a certain number of sensor circuits that can limit the size of the display. Various controller drivers are available for Linux for USB and I2C busses which register events through the Linux Input API. The panels that we offer 'out-of-the-box' support for listed below use one of the following controller chips: * !FocalTech FT5x06 (used on the DLC700JMGT4 7" WSVGA Touchscreen Display) * Goodix GT9110 (used on the DLC800FIGT3 8" XGA Touchscreen Display) * eGalax (used on the Freescale MCIMX-LVDS1 10" XGA Touchscreen Display) [=#backlight] == Backlight Controllers Touchscreens typically have a backlight behind the display element to illuminate the display. These can be LED strips or other technology that have varied electrical needs. A Backlight controller is an integrated circuit or simple circuit typically interfacing to either an existing pulse width modulated (PWM) signal to vary brightness, a simple GPIO controlled on/off control, or a more complex circuit configured over a bus such as I2C. The panels that we offer 'out-of-the-box' support for all have an integrated backlight controller on-board that is controlled via a PWM signal from the processor. [=#software] == Software Support and Configuration === U-Boot Gateworks U-Boot Bootloader: * supports 'display' (not touch) of the various displays below * very easy to add additional support to {{{gw_ventana.c}}} by knowing the display timings * the {{{panel}}} env variable enables display output maching one of the device names in the displays array * un-setting {{{panel}}} will auto-detect displays that have that capability (typically i2c probing the touch controller) * setting {{{panel}}} to none disables display out completely * the {{{display}}} env variable will select the 'native-mode' device-tree node for the LCD display to timings for the kernel (supported in the 3.10.53 vendor kernel used on the Android Kitkat BSP, Yocto v1.8 BSP, and the latest OpenWrt (see: https://github.com/Gateworks/openwrt)) [=#bootscript] === Bootloader boot script Most Gateworks BSP's load and execute a U-Boot bootscript from the OS that performs any OS specific kernel configuration. The bootloader will load and execute a script (if found) from the first ext2/3/4 partition on a block storage device, or the ubi boot/rootfs volume of a NAND ubi partition named {{{boot/6x_bootscript-ventana}}}. The source for these scripts can be found here: - [https://github.com/Freescale/meta-freescale-3rdparty/blob/master/recipes-bsp/u-boot/u-boot-script-gateworks-imx/6x_bootscript-yocto.txt Yocto Bootscript] - [https://github.com/Gateworks/android_device_gateworks/blob/imx_l5.1.1_2.1.0-ga/ventana/6x_bootscript.txt Android 5.1 Bootscript] - [https://github.com/Gateworks/openwrt/blob/16.02/target/linux/imx6/image/bootscript-ventana OpenWrt 16.02] One of the things the Yocto and Android bootscripts do is configure the 'video=' kernel parameters based on the display env variable to values that are appropriate for the kernels used there. You can always override this by setting the bootloader 'video' env parameter manually, or you can add to the bootloader script to configure the parameters for your device specifically. As an example, lets take the 'AUO G101EVN01.0' 1280x800 10.1" LVDS display: * for Yocto using the 3.14 kernel (see wiki:Yocto/Video_Out Yocto/Video_Out) {{{#!bash setenv video 'video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off' }}} * for Android using the 3.14 kernel: {{{#!bash setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off' }}} * for OpenWrt 16.02 using the 4.4 kernel (see wiki:linux/display): {{{#!bash setenv video 'video=LVDS-1:1280x800@60M video=HDMI-A-1:d' }}} [=#linux] === Linux kernel From the Linux perspective there are various drivers responsible for different functions of a touchscreen: - Display Timings - Display Driver kernel parameters - Touch input events - Backlight brightness Note that the kernel drivers and API's differ over time in various kernel versions. ==== Display Timings For Linux Kernel support, the device-tree specifies the display timings. The device tree file you modify will depend on the board you are using, such as GW52xx, GW53xx, or GW54xx. For example, the GW53xx device-tree in the Gateworks 3.14 vendor kernel is [https://github.com/Gateworks/linux-imx6/blob/gateworks_fslc_3.14_1.0.x_ga/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi here]. The Ventana kernel specifies multiple {{{display-timings}}} within the {{{lvds-channel@0}}} node and the {{{native-mode}}} property points to which one to use. This {{{native-mode}}} property gets set by the bootloader prior to booting the kernel based on the {{{display}}} env variable. Therefore, you can either add an additional timing and set the {{{display}}} variable, or you can simply overwrite the default timing0. The display timing device-tree bindings are documented in [https://lxr.missinglinkelectronics.com/linux+v3.14/Documentation/devicetree/bindings/video/display-timing.txt Documentation/devicetree/bindings/video/display-timing.txt]. All values are identical to those used in the bootloader except that the bootloader uses 'pixclock' which is in units of picoseconds, and the kernel uses 'clock-frequency' in units of Hz. ==== Display Driver kernel parameters The Linux display drivers use kernel parameters to configure the various IMX display output devices. The parameters vary greatly depending on which kernel version you are using: * Modern mainline kernel or Gateworks kernel above 4.x: see [wiki:linux/display#kms] * Freescale Linux Kernels (3.0.35, 3.10.17, 3.10.31, 3.10.53, 3.14.28, 3.14.48): - the video kernel parameter can specify display details for mxcfb0, mxcfb1, mxcfb2, mxcfb3 devices (IMX6Q can support 4 simultaneous display out, while IMX6DL can support 2). - see [wiki:Yocto/Video_Out#DisplaysDevices here] for details ==== Touch Linux Touchscreen controllers are typically I2C or USB based devices with drivers in the {{{drivers/input/touchscreen}}} directory. The driver for the specific controller device on your touchscreen must be enabled which also requires enabling the Linux Input subsystem. I2C based touch controllers are configured via Linux device-tree and each driver can have its own set of properties (device-tree bindings) which are documented in the kernel's Documentation/devicetree/bindings/input/touchscreen directory. There is a set of common properties supported for all I2C based touch controllers as well to handle mapping of touch sensor coordinates to display coordinates. Note that the display coordinate system may differ from the touch controller coordinate system and that the display coordinate system is dependent upon any library or framework you are using and for the orientation of the device. For example for raw kernel Linux display coordinate 0,0 is at the top-left of the screen. The touch controller will report x and y coordinates depending on its physical sensors and orientation and depending on screen orientation this could be such that 0,0 is at the bottom-left of the screen. Additionally the resolution of the display may be 1024x768 yet the touch controller resolution may be 1024x1024 requring you to scale the output. The Linux kernel touchscreen core can invert and swap axis as well as clip values outside a min and size via device-tree properties. Any scaling would need to be performed in userspace and there are methods to use depending on the software stack your GUI application uses. Example: * The Gateworks GW17047 DLC0700XDP21LF 7" WSVGA Touchscreen Display has a display resolution of 1024x600 and a touch controller of matching 1024x600 resolution. However when oriented such that its display 0,0 is at the top left the touch controller reports this as 1024,600 and reports the bot right as 0,0. In this case the touch controller x and y axis need to be inverted to match the display. The device-tree for this would look like: - GW54xx (where touch IRQ is on the IMX pad GPIO_17__GPIO7_IO12) {{{#!bash &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; touchscreen: touchscreen@38 { compatible = "edt,edt-ft5406", "edt,edt-ft5x06"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_touch>; reg = <0x38>; interrupt-parent = <&gpio7>; interrupts = <12 IRQ_TYPE_EDGE_FALLING>; touchscreen-inverted-x; touchscreen-inverted-y; touchscreen-size-x = <1024>; touchscreen-size-y = <600>; }; }; &iomuxc { pinctrl_touch: touchgrp { fsl,pins = < MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 >; }; }; }}} You must also ensure the Linux input driver compatible with your device is enabled in the kernel. For example a FT5406 I2C based touch controller is enabled via kernel CONFIG_TOUCHSCREEN_EDT_FT5X06: {{{#!bash # zcat /proc/config.gz | grep EDT CONFIG_TOUCHSCREEN_EDT_FT5X06=y }}} One your kernel has the proper driver enabled, and any required device-tree nodes and properties are configured boot that kernel with the proper device tree and verify you have a Linux input device registered: * check /proc/bus/input/devices {{{#!bash # cat /proc/bus/input/devices I: Bus=0018 Vendor=0000 Product=0000 Version=0000 N: Name="generic ft5x06 (81)" P: Phys= S: Sysfs=/devices/soc0/soc/2100000.aips-bus/21a8000.i2c/i2c-2/2-0038/input/input0 U: Uniq= H: Handlers=event0 B: PROP=2 B: EV=b B: KEY=400 0 0 0 0 0 0 0 0 0 0 B: ABS=2608000 3 }}} * check /sys/class/input {{{#!bash # ls -l /sys/class/input/ total 0 lrwxrwxrwx 1 root root 0 Jan 1 01:22 event0 -> ../../devices/soc0/soc/2100000.aips-bus/21a8000.i2c/i2c-2/2-0038/input/input0/event0 lrwxrwxrwx 1 root root 0 Jan 1 01:22 input0 -> ../../devices/soc0/soc/2100000.aips-bus/21a8000.i2c/i2c-2/2-0038/input/input0 }}} For interrupt based controllers such as an I2C controller you should also see interrupts increasing for the interrupt registered by that driver. For example for the edt-ft5406 I2C device/driver: {{{#!bash # cat /proc/interrupts | grep edt-ft 283: 149 0 0 0 gpio-mxc 12 Edge edt-ft5406 }}} - the interrupt number and name vary depending on the kernel and the device/driver you have. The above is for a FT5406 I2C based touch controller which shows 149 interrupt events (which should increase as you touch/release the touchscreen Once you verify you have a Linux input device registered and interrupts are firing you can use either {{{evtest}}} (standard Linux) or {{{getevent}}} (Android) to verify input events are occuring: * evtest: {{{#!bash root@ventana:~# evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: EP0810M09 /dev/input/event1: gsc_input /dev/input/event2: mma845x_a /dev/input/event3: fxos8700_m Select the device event number [0-3]: 0 Input driver version is 1.0.1 Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 Input device name: "EP0810M09" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 863 Min 0 Max 1023 Event code 1 (ABS_Y) Value -3374 Min 0 Max 599 Event code 47 (ABS_MT_SLOT) Value 3 Min 0 Max 4 Event code 53 (ABS_MT_POSITION_X) Value 0 Min 0 Max 1023 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min 0 Max 599 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min 0 Max 65535 Properties: Testing ... (interrupt to exit) Event: time 1430493672.054573, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0 Event: time 1430493672.054573, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 63 Event: time 1430493672.054573, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 128 Event: time 1430493672.054573, type 3 (EV_ABS), code 0 (ABS_X), value 63 Event: time 1430493672.054573, type 3 (EV_ABS), code 1 (ABS_Y), value 128 Event: time 1430493672.054573, -------------- EV_SYN ------------ Event: time 1430493672.129208, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 }}} * Android {{{getevent}}}: {{{#!bash root@ventana:/ # getevent /dev/input/event0 0003 0039 00000022 0003 0036 00000251 0003 0035 0000033b 0003 0030 0000003e 0003 0032 0000003e 0001 014a 00000001 0003 0000 0000033b 0003 0001 00000251 0000 0000 00000000 0003 0030 00000038 0003 0032 00000038 0000 0000 00000000 0003 0039 ffffffff 0001 014a 00000000 0000 0000 00000000 }}} ==== Backlight Linux backlight controllers exist for various devices under the kernel menu of Device Drivers -> Graphics support -> Backlight & LCD device support. Most commonly used are: * a pulse width modulated (PWM) signal is used to vary a backlight between 0 and 100% * a general purpose IO (GPIO) signal is used to enable/disable a backlight In the above cases the Linux device-tree bindings must specify the details which can vary greatly ===== PWM For PWM based backlight controllers you must configure CONFIG_BACKLIGHT_PWM to enable the drivers/video/backlight/pwm_bl.c driver which provides you with a way to control brightness between 0 and 100%. Note that you also need the driver for your PWM controller which in the case of an IMX pin supporting PWM is CONFIG_PWM_IMX27. This requires also configuring a device-tree node specifying the PWM, a set of brightness levels, and the default brightness. See [https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml Documentation/devicetree/bindings/leds/backlight/pwm-backlight] for details. Example: * The Gateworks GW17047 DLC0700XDP21LF 7" WSVGA Touchscreen Display has an on-board PWM based backlight controller: - GW54xx: * J5.5: BACK_ADJ: MX6QDL_PAD_SD1_CMD (this is our PWM) * J5.1: BACK_EN#: MX6QDL_PAD_SD2_CLK (this is a GPIO enable) {{{ / { backlight { compatible = "pwm-backlight"; pwms = <&pwm4 0 5000000>; /* 1 / (5000000 / 1000000000) = 200 Hz */ brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 >; default-brightness-level = <100>; enable-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; }; }; &pwm4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pwm4_backlight>; status = "okay"; }; &iomuxc { pinctrl_pwm4_backlight: pwm4grpbacklight { fsl,pins = < /* J5.1: BACK_EN# */ MX6QDL_PAD_SD2_CLK__GPIO1_IO10 0x1b0b1 /* J5.5: BACK_ADJ */ MX6QDL_PAD_SD1_CMD__PWM4_OUT 0x1b0b1 >; }; }; }}} - PWM4 with a 200Hz frequency with 100 levels of brightness. You can specify as many brightness levels as you wish each with a cooresponding PWM value from 0 to 255 (where 255 is 100% duty cycle). - IMX6 pad SD1_CMD configured as PWM4 - this is J5.5 BACK_ADJ - IMX6 pad SD2_CLK configured as GPIO1_IO10 - this is J5.1 BACK_EN# In some cases the device tree node used by the linux {{{pwm-backlight}}} driver may need to be adjusted if "flickering" exists ([https://i.stack.imgur.com/LF3Y4.jpg example]). This phenomenon is caused by a PWM frequency setting that is too low for the connected display's backlight which creates a visual artifact that may be detectable by the human eye. The {{{pwms}}} property above includes the {{{pwm-specifier}}} which although PWM controller dependent, typically encodes the chip-relative PWM number and the PWM period in nanoseconds. Therefore in the above example you could alter the 5000000 value to come up with a different backlight frequency. If you want to make an adjustment to this frequency, you could alter your device-tree or you can use the {{{fixfdt}}} script in the bootloader. For example, to change the backlight frequency to {{{10kHz}}} you would run the following command from the bootloader: {{{#!bash # The third value of the pwms property is in nanoseconds so to convert to Hz: # 1 / (100000 / 1000000000) = 10 kHz setenv fixfdt "fdt addr ${fdt_addr}; fdt set /backlight pwms <0x3d 0 100000>" }}} The Linux backlight core provides sysfs attributes: - brightness R/W, set the requested brightness level - actual_brightness RO, the brightness level used by the HW - max_brightness RO, the maximum brightness level supported For full documentation see: * [https://www.kernel.org/doc/html/latest/gpu/backlight.html Backlight core API] * [https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#abi-file-stable-sysfs-class-backlight sysfs-class-backlight] Example: {{{#!bash # ls /sys/class/backlight/ backlight # cat /sys/class/backlight/backlight/max_brightness # show max brightness value 100 # echo 0 > /sys/class/backlight/backlight/brightness # set 0% # echo 50 > /sys/class/backlight/backlight/brightness # set 50% # echo 100 > /sys/class/backlight/backlight/brightness # set 100% }}} ===== GPIO For GPIO based backlight controllers you must configure CONFIG_BACKLIGHT_GPIO to enable the drivers/video/backlight/gpio_backlight.c driver which provides you with just a basic on/off control. Note that you also need the driver for your GPIO controller which in the case of an IMX GPIO is CONFIG_GPIO_MXC. This requires also configuring a device-tree node specifying the GPIO. See [https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml Documentation/devicetree/bindings/leds/backlight/gpio-backlight] for details Example: * A backlight controller with a GPIO enable connected to J5.1 BACK_EN# signal: - GW54xx: * J5.1: BACK_EN#: MX6QDL_PAD_SD2_CLK {{{ / { backlight { compatible = "gpio-backlight"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_backlight>; gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>; default-on; }; }; &iomuxc { pinctrl_backlight: backlightgrp { fsl,pins = < /* J5.1: BACK_EN# */ MX6QDL_PAD_SD2_CLK__GPIO1_IO10 0x1b0b1 >; }; }; }}} - IMX6 pad SD2_CLK configured as GPIO1_IO10 - this is J5.1 BACK_EN# The Linux backlight core provides sysfs attributes: - brightness R/W, set the requested brightness level - actual_brightness RO, the brightness level used by the HW - max_brightness RO, the maximum brightness level supported For full documentation see: * [https://www.kernel.org/doc/html/latest/gpu/backlight.html Backlight core API] * [https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#abi-file-stable-sysfs-class-backlight sysfs-class-backlight] Example: {{{#!bash # ls /sys/class/backlight/ backlight # cat /sys/class/backlight/backlight/max_brightness # show max brightness value 1 # echo 0 > /sys/class/backlight/backlight/brightness # set off # echo 1 > /sys/class/backlight/backlight/brightness # set on }}} [=#selection] == Selecting a LCD & Touchscreen Display == Selecting a usable display can be complex. Gateworks has broken down the selection process: 1. Size * Typical sizes range from 4" to 15", with something like 7" the most common 2. Backlight * Voltage - LED's can require a large boost voltage. If this voltage is not available on the board, display driver boards are often created for boosting to a higher voltage. Current must also be taken into consideration. 5V and 3.3V are supplied on the Gateworks SBC 30 pin connector. * Backlight Adjustment * PWM - Supported on Gateworks 30 pin connector * Analog 3. Video Interface * LVDS - 6 bit mode - Gateworks has a 30 pin LVDS connector as documented on this wiki page. * Ventana will not support 8 bit mode. Some displays support both 6 & 8, others only support 8-bit. 4. Touchscreen * Capacitive - Similar to most cell phones. More expensive. More sensitive. * Resistive - Requires a physical press, less sensitive, but good for gloves, etc * Controller - The touchscreen itself outputs signals that are typically best interpreted via a specific touchscreen controller. This controller then interfaces with the Gateworks SBC. Gateworks has a I2C interface on the LVDS connector for this interface. USB interfaces also exist, but USB is not on the LVDS connector, and thus a separate cable would be needed. * '''VERY IMPORTANT: Controller software driver''' - A touchscreen controller will not work if the proper driver is not loaded in the Linux software. Be sure a driver is supported for this touchscreen controller chip. Look for possibly supported chips here: [http://lxr.free-electrons.com/source/drivers/input/touchscreen/?v=3.10] * Bonding - Touchscreens are bonded to LCD displays. Some combinations are pre-bonded but otherwise bonding is a very complex process and requires very expensive machinery. It is highly recommended that the LCD and touchscreen be bought pre-bonded. 5. Cabling * Often cabling will need to be created to mate connectors. Gateworks has a 30 pin connector that may have to mate to a 20 pin connector along with backlight and touchscreen. For cabling, companies such as Quadrangle can create a custom cables. === Touch input libraries [=#tslib] ==== tslib The tslib project provides a cross-platform library that provides access to touchscreen devices and the ability to apply filters to their input events. Linux input events are translated via a 5-pt matrix configured by default in /etc/pointercal. References: * http://www.tslib.org/ * https://github.com/libts/tslib tslib uses several env variables that can be used to specify the linux input dev, pointercal, ts.conf etc: * TSLIB_TSDEVICE - Touchscreen device file name. Default: automatic detection (on Linux) * TSLIB_CALIBFILE - Calibration file. Default: ${sysconfdir}/pointercal * TSLIB_CONFFILE - Config file. Default: ${sysconfdir}/ts.conf * TSLIB_PLUGINDIR - Plugin directory. Default: ${datadir}/plugins * TSLIB_CONSOLEDEVICE - Console device. Default: /dev/tty * TSLIB_FBDEVICE - Framebuffer device. Default: /dev/fb0 tslib consists of several applications to test and calibrate your touchscreen: - ts_print will show you touch events (filtered) - ts_test will show your touch events on the display - ts_calibrate prompt for touch events on the display at the four corners and center in order to create /etc/pointercal to translate (filter) events Example: * install libts and tools {{{#!bash # apt install libts-bin }}} * run ts_calibrate to create /etc/pointercal {{{#!bash # ts_calibrate xres = 1024, yres = 600 Took 2 samples... Top left : X =  961 Y =  530 Took 1 samples... Top right : X =   48 Y =  539 Took 3 samples... Bot right : X =   67 Y =   71 Took 1 samples... Bot left : X =  966 Y =   57 Took 2 samples... Center : X =  514 Y =  293 1041.238403 -1.020124 -0.026010 623.628540 -0.013489 -1.062863 Calibration constants: 68238600 -66854 -1704 40870120 -884 -69655 65536 # cat /etc/pointercal -66854 -1704 68238600 -884 -69655 40870120 65536 1024 600 0 }}} * run ts_test to test input {{{ # ts_test }}} [=#adding] == Adding Support for a Touchscreen Adding support for a new LCD requires modifying the source code of the software: - display timings - touch controller configuration - see [#touchcontroller] - backlight controller configuration - see [#backlight] While the code changes can be fairly simple, determining the timings can be complicated and involves translating timings from the manufacturers datasheet to the display timings that Linux drivers need. === Handling Screen rotation As an example let's assume you have a touchscreen display using an edt-ft5x06 touch controller and your screen's display 0,0 agrees with the touch input 0,0 both in the top-right corner of the display (determined with evtest) but you want to rotate your screen 90deg clockwise to put it in 'portrait mode'. This would cause the x/y coordinates to be wrong requiring some mapping in the Linux input subsystem. This scenario would require us to dt fragment: {{{ &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; touchscreen: touchscreen@38 { compatible = "edt,edt-ft5406", "edt,edt-ft5x06"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_touch>; reg = <0x38>; interrupt-parent = <&gpio7>; interrupts = <12 IRQ_TYPE_EDGE_FALLING>; touchscreen-swapped-x-y; touchscreen-inverted-y; touchscreen-size-x = <1024>; touchscreen-size-y = <600>; }; }; &iomuxc { pinctrl_touch: touchgrp { fsl,pins = < MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 >; }; }; }}} Again, use the 'evdev' application to determine where the touch sensor's 0,0 coordinate is and make it match the display's 0,0. Hint, run 'evdev /dev/input/event0 | grep ABS_X' to show only the X coordinate then switch to the Y coordinate to help understand the mapping. === Determining Display Timing values ==== Linux The display timing device-tree bindings are documented in [https://lxr.missinglinkelectronics.com/linux+v3.14/Documentation/devicetree/bindings/video/display-timing.txt Documentation/devicetree/bindings/video/display-timing.txt]. All values are identical to those used in the bootloader except that the bootloader uses 'pixclock' which is in units of picoseconds, and the kernel uses 'clock-frequency' in units of Hz. As an example, lets take the 'AUO G101EVN01.0' 1280x800 10.1" LVDS display: * 1280x800 active pixels (6.5.1 Timing Characteristics) * pixclock = (1/68.93MHz)*(1000000) = 14507 (68.93MHz is from typical clock frequency specified in 6.5.1 Timing Characteristics) We would add an additional device-tree node to {{{display-timings}}} in arch/arm/boot/dts/imx6qdl-gw53xx.dtsi (to add it to the GW53xx - add it to the other board dtsi files as needed) {{{ timing3: g101evn010 { clock-frequency = <68930000>; hactive = <1280>; vactive = <800>; hback-porch = <220>; hfront-porch = <40>; vback-porch = <21>; vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; linux,phandle = <&timing3>; }; }}} * Note that 'timing3' needs to be unique from the other timings already defined * Note the 'linux,phandle' property that needs to reference itself (timing3 in this example). This is un-conventional but necessary in order for the Ventana U-Boot bootloader to adjust the 'native-timing' property to match (case-insenstive) the display named 'G101EVN010' in this example based on the env variable. Now, after our kernel device-tree is built and updated on our target board we can set the {{{display}}} variable as follows: {{{#!bash Ventana > setenv display G101EVN010; saveenv; reset }}} To verify the device tree has the correct information once the board is booted, browse through the directory structure for the display-timings, and you should see your display: {{{ root@ventana:~# ls /proc/device-tree/soc/aips-bus\@02000000/ldb\@020e0008/lvds-channel\@0/display-timings/ dlc700ctp dlc700jmgt4 dlc800figt3 hsd100pxn1 name native-mode }}} Then, to verify the correct information, you can use something like the following command to see the values: {{{ root@ventana:~# hexdump -C /proc/device-tree/soc/aips-bus\@02000000/ldb\@020e0008/lvds-channel\@0/display-timings/dlc700ctp/hactive 00000000 00 00 03 20 |... | 00000004 }}} The hex value of 0x0320 is decimal 800, which is correct for this example, of a horizontal active resolution of 800 pixels. You can easily experiment with different timing values by using the Ventana bootloader 'fixfdt' script to alter the timings of the default display which is the 'hsd100pxn1' (unless you've changed it by setting the {{{display}}} env variable). Note that the timings represented in the device-tree are hex values. Here is an example of setting up a {{{fixfdt}}} script for overriding the values and setting them for a 1280x800 pixel display (0x500 x 0x320) with a refresh rate of 60Hz (0x3c) and a clock-frequency of 68930000Hz (0x41bc9d0) and margins of 220/40/21/7: {{{ setenv timing_path '/soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0/display-timings/hsd100pxn1' setenv fixfdt '\ fdt addr ${fdt_addr}; \ fdt set ${timing_path} clock-frequency <0x41bc9d0>; \ fdt set ${timing_path} hactive <0x500>; \ fdt set ${timing_path} vactive <0x320>; \ fdt set ${timing_path} hback-porch <0xdc>; \ fdt set ${timing_path} hfront-porch <0x28>; \ fdt set ${timing_path} vback-porch <0x15>; \ fdt set ${timing_path} vfront-porch <0x0x7>; \ fdt set ${timing_path} hsync-len <0x3c>; \ fdt set ${timing_path} vsync-len <0xa>; \ '; saveenv; reset }}} The display timing device-tree bindings are documented in [https://lxr.missinglinkelectronics.com/linux+v3.14/Documentation/devicetree/bindings/video/display-timing.txt Documentation/devicetree/bindings/video/display-timing.txt]. [=#uboot] ==== U-Boot The Ventana U-Boot Bootloader specifies an array of displays via the {{{displays}}} variable [https://github.com/Gateworks/u-boot-imx6/blob/gateworks_v2015.04/board/gateworks/gw_ventana/gw_ventana.c#L328 here]. The {{{struct display_info_t}}} structure (defined [https://lxr.missinglinkelectronics.com/uboot/arch/arm/include/asm/imx-common/video.h#L11 here]) defines a bus/addr, pixel format, detect function, enable function, and video mode which includes a unique name, resolution and timings details. The {{{panel}}} env variable is used by U-Boot to determine which panel to configure and the value must match one of the video mode names in the array. Note that the {{{display}}} env variable can also be used for configuring the display for the Linux kernel (see below). The video-mode structure is described [https://lxr.missinglinkelectronics.com/uboot/include/linux/fb.h#L598] - some of it is self-explanatory and comes straight out of the manufacturers datasheet and some is not: * name - unique name that needs to match the {{{panel}}} and/or {{{display}}} env variable * refresh - refresh rate * xres/yres - display resolution or 'active pixels' * left_margin/right_margin/upper_margin/lower_margin - the margins (in units of pixclock periods) for video blanking * pixclock - the frequency of the pixel clock (from the datasheet) (in units of picoseconds) (for example, 64MHz would be pixclock=(1/64000000)*100000=15625) * hsync_len/vsync_len - hsync and vsync period (in units of pixclock periods) * sync - flags describing the polarity details of the sync signals (see [https://lxr.missinglinkelectronics.com/uboot/include/linux/fb.h#L74 here]) - for LVDS displays this is always FB_SYNC_EXT * vmode - videomode flags (see [https://lxr.missinglinkelectronics.com/uboot/include/linux/fb.h#L83 here]) - for LVDS displays this is always FB_VMODE_NONINTERLACED * flag As an example, lets take the 'AUO G101EVN01.0' 1280x800 10.1" LVDS display: * 1280x800 active pixels (6.5.1 Timing Characteristics) * pixclock = (1/68.93MHz)*(1000000) = 14507 (68.93MHz is from typical clock frequency specified in 6.5.1 Timing Characteristics) We would add an additional structure to {{{displays}}} in board/gateworks/gw_ventana/gw_ventana.c: {{{ { /* AUO G101EVN01.0 */ .bus = 0, .addr = 0, .detect = NULL, .enable = enable_lvds, .pixfmt = IPU_PIX_FMT_LVDS666, .mode = { .name = "AUOG101EVN01.0", .refresh = 60, .xres = 1280, /* 1024x768 active pixels */ .yres = 800, .pixclock = 14507, /* 68.93MHz */ .left_margin = 220, .right_margin = 40, .upper_margin = 21, .lower_margin = 7, .hsync_len = 60, .vsync_len = 10, .sync = FB_SYNC_EXT, .vmode = FB_VMODE_NONINTERLACED } } }}} After rebuilding the bootloader and updating the board, we can set {{{panel}}} as such: {{{ Ventana > setenv panel AUOG101EVN01.0; saveenv; reset }}} Depending on how you connected the LVDS display to the Gateworks Ventana board, you may need to manipulate the two GPIO signals going to the LVDS connector: * GPIO1_IO10 (gpio10 BACK_EN#) * GPIO1_IO18 (gpio18 BACK_ADJ) (in the kernel this would be the backlight PWM signal) By default these are configured in the {{{enable_lvds}}} function as gpio10/BACK_GPIO low, and gpio18/BACK_ADJ high. The gpio18/BACK_ADJ signal is configured as a PWM for backlight brightness in the kernel, however the Ventana bootloader does not have PWM support so this is defaulted to a gpio out driven high (which would be 100% backlight). The gpio10/BACK_GPIO signal can be used to connect to a RST# or EN# signal and if connected must be adjusted for your display. As the bootloader defaults this to output-low, you may need to change that to output high if you connected it to an active-high enable: {{{ Ventana > setenv preboot 'gpio set 10'; saveenv; reset }}} Note that there is no support for touch-screen control in the Ventana bootloader.