18 jan 2015


a few weeks ago i bought the 7” (17,78 cm) display set with touchscreen (LS-7T) from and here is my experience with that device. i don’t want to make the product look bad because of my maybe-exotic requirements, anyway here is what i think about it.

what i liked

  • display quality is quite good
  • the manual from pollin is really good, thanks a lot pollin guys!
  • the screen controller board provides for VGA/DVI/HDMI input!
  • if VGA and HDMI plug is attached i like that the screen stays on VGA input, even though there is no VGA input signal at times, for example if you reboot the computer attached to the VGA input. other vendors often will jump to the active display source which can be very annoying.
  • instant power off using the attached controls of the screen is very fast (but why is this not DPMS controllable?)
  • the touch overlay, the transparent matrix with the USB connector, worked out of the box on linux

what i disliked

  • the screen controller board provides a broken/incomplete EDID information
  • the display resulution is pretty much random and might or might not work, depending on the used graphis driver i suppose. it worked with my laptop but didn’t work with the odroid u3
  • the display lacks DPMS support, therefore the screen will always draw power, even if your screen powersaving setting tells it to go to sleep

EDID resolution issue

the LS 7T manual clearly states that the native display resolution is 1024x600. but it never showed up on any computer as a default resolution and therefore i was looking into the EDID information.

looking into EDID

this is the EDID string provided by the monitor (see /var/log/X.0.log):


you can paste it into and then you will recover these modes:

Timing Bitmap
720x400 @ 70 Hz
720x400 @ 88 Hz
640x480 @ 60 Hz
640x480 @ 67 Hz
640x480 @ 72 Hz
640x480 @ 75 Hz
800x600 @ 56 Hz
800x600 @ 60 Hz
800x600 @ 72 Hz
800x600 @ 75 Hz
832x624 @ 75 Hz
1024x768i @ 87 Hz
1024x768 @ 60 Hz
1024x768 @ 72 Hz
1024x768 @ 75 Hz
1280x1024 @ 75 Hz
1152x870 @ 75 Hz

however, xrandr on linux (odroid u3) shows these:

HDMI-1 connected 1024x768+0+0 708mm x 398mm
  1280x720       60.0 +   50.0  
  1920x1080      50.0     60.0     30.0     24.0  
  1920x1080i     60.0     25.0     30.0  
  1280x1024      60.0  
  1440x576i      25.0  
  1024x768       60.0* 
  1440x480i      30.0  
  720x576        50.0  
  720x480        59.9  
  640x480        60.0  

testing with various operating systems

i also tested the display with:

  • u3 (HDMI),
  • a linux computer (VGA),
  • a windows computer (HDMI) and
  • a mac os x (HDMI) and

none of these could use the display with the native 1024x600 display resolution out of the box and it always looked broken.

making it work anyway

with a big effort i was able to make the display work from my laptop (VGA) using 1024x600 as well as from the odroid u3 (HDMI). by default the screen runs on 1024x600 but the odruid u3+ does only support this mode by default so we have to add it manually.

the odroid u3 modes supported by default:

# export DISPLAY=:0
# xrandr
Screen 0: minimum 320 x 200, current 640 x 480, maximum 4096 x 4096
HDMI-1 connected 640x480+0+0 708mm x 398mm
   1280x720       60.0 +   50.0
   1920x1080      50.0     60.0     30.0     24.0
   1920x1080i     60.0     25.0     30.0
   1280x1024      60.0
   1440x576i      25.0
   1024x768       60.0
   1440x480i      30.0
   720x576        50.0
   720x480        59.9
   640x480        60.0*

in elchs-kramkiste you will find a manual how to adapt the raspberry pi to boot with the correct resolution. however, the u3 works differently and thus the raspberry pi fixes don’t apply directly. the u3 default output resolutions are only 720p or full hd. my first attempt was to fix the x-server and maybe, if that had worked reliably i would have looked into the .scr files which have the potential to make also the linux kernel boot work properly (that is before X starts).

so here is what i did in order to get X working:

cvt 1024 600
# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
Modeline "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync

you can enable this in your configuration (to test it):

export DISPLAY=:0
xrandr --newmode  "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync
xrandr --addmode HDMI-1 "1024x600_60.00"
xrandr --output HDMI-1 --mode 1024x600_60.00

WARNING: using xrandr is not a persistent change and will vanish if you reboot. when i wanted to make this setup permanent on my odroid u3, by modifing the xorg.conf, i broke my complete configuration and in the end even these xrandr settings weren’t accepted anymore!?! i want to document them here anyway, maybe they work for you?!

WARNING: odroid u3 only: when using the default 1280x720 resolution with the u3 the display was missing the top ~ 18 pixels as well as the bottom ~ 18 pixels. so there seems to be some overscan issue as well with using the 1280x720 resolution. maybe using xinput –transform with the default 1280x720 resolution can help here but i gave up on that.

in detail: DPMS

with most monitors, DPMS can be activated instantly using this command:

xset dpms force off

normally this will power off parts of the display, that is it powers off LED background illumination among other power saving features. at least it usually means that the monitor cools down pretty fast indicating it does not drain much power. however, IIRC, the LS-7T will just show a ‘no input signal’ or ‘no signal’ banner and waste all the energy!

DPMS is very handy if the display should not be powered like 24/7, which is probably a requirement most users will have. i could imagine that this would even be a nice feature for CAR installations as power drain is a problem there as well, especially if the motor is not running.


i sold the display to a friend who desperately wanted it. thus i’m glad i got rid of it! my conclusion goes like this: why does someone produce a display without proper EDID and DPMS?

if you have a usecase similar to mine i would recommend:

article source