Engage 10

Engage 10 Wireless LCD Model number : W10T200-HWH1WH

These devices were intended to be WUSB touchscreens. They include an internal WUSB device dongle, an internal USB hub, a USB displaylink video chip feeding VGA to an LCD driver, and a USB HID touchscreen.

The LCD seems to be 1024 x 600 native resolution. They will do 1024 x 768, but it does not look as good.

The box should include the display, an external WUSB host dongle, a 12 volt (usually 3 amp) power supply and a USB A to USB A cable. The cable was included just to allow pairing between the WUSB dongles, but it can be used to connect the display directly to the computer.

The pairing process seems to be tricky...

The displaylink chip is a DL-125, old and well supported.

• The current raspbian image has a kernel module driver for it.

• Current Ubuntu distrubtions seem to hot plug the display and bring up GUI to configure it, but guess the resolution badly.

• Current Debian distrubtions seem to have the driver, but they do not bring up any GUI to configure it.

• Windows XP works after installing a displaylink driver, I have not tried newer versions on the metal, and had trouble with 7 on a VM.

In general, plugging the display into a linux computer should cause a new fb device to show up in /dev/ and you can then do what you like with it, including x11. A solid green screen is generally a good sign.

Wired USB Connection

I have not actually gotten WUSB to work. I have not tried very hard because it does not seem very useful.

Instead, I have been using the included USB cable. There is some weirdness here. I have seen the external USB port (labeled ¨WUSB¨) work just fine. I have also just seen the external port on a new looking display not work.

Opening the case, removing the dongle from the internal port and plugging the cable in there seems to permanently disable the external port.

However, the internal port seems to always work, so it seems like the best bet.

If lsusb lists a displaylink device, USB is working.

A solid green screen means the driver is working.

Raspberry Pi Config

To configure raspbian to use the display create /usr/share/X11/xorg.conf.d/60-pluggable.conf with the following text:

Section "Device" 
  Identifier "displaylink device" 
  driver "fbdev" 
  Option "fbdev" "/dev/fb1" 
  Option "ShadowFB" "off"
EndSection 

Section "Monitor" 
  Identifier "displaylink monitor" 
  DisplaySize 221 129
  Modeline "1024x600_60.00"   49.00  1024 1149 1245 1312  600 601 611 624 -hsync +vsync
  Option "DPMS" "off"
EndSection 

Section "Screen" 
  Identifier "displaylink screen" 
  Device "displaylink device" 
  Monitor "displaylink monitor"
  DefaultDepth    16
  SubSection "Display"
    Depth    16
    Modes     "1024x600_60.00"
  EndSubSection
EndSection 

Section "ServerLayout" 
  Identifier "Default Layout" 
  Screen 0 "displaylink screen" 0 0 
EndSection

That should take care of the display, it is probably not optimal for any particular use. I have been playing with this a lot, and there may be interesting examples on the talk page.

You might want to enable SSH before rebooting, just in case...

/dev/fb0 is the HDMI/composite output, displaylink devices start at /dev/fb1, but if you have other framebuffer devices it could get tricky...

Hacking

Touch Screen

The touch screen seems to stream HID absoulte X and Y events.. Raspbian seems to convert these to mouse events by default, and gets the axis wrong. This can probably be fixed in software, but it is an area that needs work.

USB

Opening the case, removing the dongle from the internal port and plugging the cable in there seems to permanently disable the external port. It is possible that successfully pairing WUSB does the same. This might be some magic in U28, but I have not dug into it. By just looking at the board, it seems that both USB ports are connected to the host pins on the USB hub chip.

I have removed R311 (near CN5 pin 1) and connected pins 1 of the USB ports together. This allows a pi to be powered from the external port (CN5).

The USB hub is an NEC 720114, which has 4 downstream ports. The unused ports are available at R115-116 and R303-304.

I took things one step further by removing R303, R304 and U2, then connecting the USB side (bottom) R303 pad to CN5 pin 2 and R304 to pin 3. This turns CN5 into a functional external USB port. I guess it would be good to dig up a reference design for the 720114 and see if it calls for any external components, but the direct connection works for me.

Case

The case comes apart easily. There are screws in the corners and plastic clips holding the bottom of the case to top.

It is easy to notch the bottom case half to clear a USB cable plugged into the internal port. I used a round file. you can make it a tight fit on the cable or put a cable tie around the cable inside the case to take any tension.

VGA

I have cut the traces on the displaylink (left) side of J5 and fed VGA into J5. This has worked briefly a few times, I think I was just having trouble generating acceptable resolutions. I think it has promise.

Interestingly, the ¨Searching¨ icon was still present, so it must come from the RTD2033V chip.

Power

12 volt current draw is about 550mA for the screen and 800mA for the screen and a pi 2B.

DC in (12v nominal, 12.10 right now) and ground are available at J7.

A slightly lower voltage (11.75v right now) is on J4 and TC4. This is unregulated, with a 14.35v supply it is 14.00v.

5 volts and ground is available at J3 and TC22.

3.3 volts and ground is available at U8 and TC16.

1.25 volts is made by U27.

It would be nice to know how much 5v current is available...

Power Saving

Raspbian seems to try to put the display into some power saving mode. It fails to turn off the LCD, but the display glitches when you would expect it to turn the LCD back on.

Well, I turned off DPMS in xorg.conf, and now the screen blanks. Different, but not really better...

It would be nice to know exactly what is going on with that...

Buttons

It would be nice to figure out how the buttons work. At least 4 of them should come over the USB somehow. I did not see them in /dev/input/ so they might be connected to the displaylink rather than the HID...