[[!meta date="2015-01-18 10:58"]] [[!tag linux hardware usability]] [[!summary trying the LS-7T display from pollin.de with linux]] [[!img media/ls-7t.jpg size=400x alt="" style="float: right" caption="screenshot from pollin.de LS-7T article"]] # motivation a few weeks ago i bought the 7" (17,78 cm) display set with touchscreen (LS-7T) from pollin.de 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): 00ffffffffffff003674300001000000 0a140103807341780acf74a3574cb023 09484c21080081804540614095000101 010101010101011d007251d01e206e28 5500c48e2100001e011d8018711c1620 582c2500c48e2100009e000000fc004d 537461722044656d6f0a2020000000fd 00324b1e5012000a2020202020200138 you can paste it into [edidreader.com](http://www.edidreader.com/) 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](http://www.elchs-kramkiste.de/lapurd/node/170) 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](http://filthypants.blogspot.de/2013/03/xrandr-overscan-fix-for-intel-hd4000.html) with the default 1280x720 resolution can help here but i gave up on that. ## in detail: DPMS with most monitors, [DPMS](https://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling) 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. # summary 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: