{{{#!html
Gateworks offers packaged LCD touchscreens that are plug and play with the Ventana board that have a LVDS interface.
Gateworks offers a 7" and 8" display. Use the following part numbers for ordering:
The Ventana GW5400/GW5300/GW5200 designs all support LVDS via a 30 pin connector that provides:
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.
IMX6 LVDS details:
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 |
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 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.
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:
LVDS Connector 5V:
Touchscreen's are displays that have bonded to them a thin glass sensor to detect touch events. These can have a variety of features and technologies:
There is a large variety of touch sensor controllers (the chip) and touch sensor's (the glass 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.
The panels that we offer 'out-of-the-box' support for listed below use one of the following controller chips:
Gateworks U-Boot Bootloader:
Freescale Linux Kernels (3.0.35, 3.10.17, 3.10.31, 3.10.53, 3.14.28, 3.14.48):
Linux Display Driver Support:
Linux Touchscreen Driver Support:
There is a command line tool called evtest that can be used to check for touch events.
An example is shown below:
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
It is important verify the touchscreen is detected by running the following command in the example example:
root@ventana:/ # cat /proc/bus/input/devices I: Bus=0018 Vendor=0416 Product=1001 Version=28bb N: Name="Goodix Capacitive TouchScreen" P: Phys=input/ts S: Sysfs=/devices/soc0/soc.1/2100000.aips-bus/21a8000.i2c/i2c-2/2-0014/input/input0 U: Uniq= H: Handlers=mouse0 event0 B: PROP=2 B: EV=b B: KEY=400 0 0 0 0 0 0 0 0 0 0 B: ABS=2658000 3
You can see if interrupts are being sent to the touchscreen controller.
Run the command:
cat /proc/interrupts
Find the touch controller in the list.
Note the number of interrupts it currently has.
Then touch the screen a few times.
Then check the interrupts again to verify if it has increased.
In addition to the above information, here is some more information that may be relevant to Android.
To detect touch events on Android, where evtest may not exist, try using the getevent command.
Example shown below, adjust command as necessary.
Note that values should appear on the serial console when the screen is touched.
This verifies the touchscreen is getting events.
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
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@… for 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:
Details:
Gateworks Bootloader support:
setenv panel Hannstar-XGA saveenv
Yocto support:
setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off'
saveenv
setenv display Hannstar-XGA saveenv
Android KitKat+ support:
setenv display Hannstar-XGA saveenv
The GW17029 DLC700JMGT4 7" WSVGA Touchscreen Display is a low-cost display supporting:
Gateworks Bootloader support:
setenv panel DLC700JMGT4 saveenv
Yocto support:
setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-WSVGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off'
saveenv
setenv display DLC700JMGT4 saveenv
Android Kitkat+ support:
setenv display DLC700JMGT4 saveenv
The GW17030 DLC800FIGT3 8" XGA Touchscreen Display is a low-cost display supporting:
Gateworks Bootloader support:
setenv panel DLC800FIGT3 saveenv
Yocto support:
setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off'
saveenv
setenv display DLC800FIGT3 saveenv
Android KitKat+ support:
setenv display DLC800FIGT3 saveenv
This setup applies to the Gateworks 7 and 8" LCD kits.
Selecting a usable display can be complex. Gateworks has broken down the selection process:
Adding support for a new LCD requires modifying the source code of the software.
While the code changes are fairly simple, determining the timings can be complicated and involves translating timings from the manufacturers datasheet to the display timings that Linux drivers need.
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 Documentation/devicetree/bindings/video/display-timing.txt.
The Ventana U-Boot Bootloader specifies an array of displays via the displays variable here. The struct display_info_t structure (defined 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:
As an example, lets take the 'AUO G101EVN01.0' 1280x800 10.1" LVDS display:
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:
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.
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:
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:
setenv video 'video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off'
setenv video 'video=mxcfb0:dev=ldb,bpp=32,LDB-XGA,if=RGB666 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off'
setenv video 'video=LVDS-1:1280x800@60M video=HDMI-A-1:d'
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 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 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:
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>; };
Now, after our kernel device-tree is built and updated on our target board we can set the display variable as follows:
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.
If your display has a touch-screen controller you need to add support for that separately which typically involves enabling a driver and adding a device-tree binding for that driver (not described here).
}}}