Go Back   DisplayLink Forum > DisplayLink Graphics Technology > Linux and Open Source

Reply
 
Thread Tools Search this Thread Display Modes
Old 10-24-2016, 10:05 AM   #1
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Default Display HP S410u possible workling with RaspberryPi

i've an Display HP S140u (DL 41xx). I would like to use this display on a RaspberryPi 2. Currently, I've translated dkms to evdi module. The udev.rules are installed, and the modules are successfully loaded. At the moment, ive got no alternative for the "DisplayManager".
According to the description, the firmware should not be the problem?

Debug output:
Quote:
Bus 001 Device 004: ID 17e9:ff06 DisplayLink
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x17e9 DisplayLink
idProduct 0xff06
bcdDevice 1.28
iManufacturer 1 DisplayLink
iProduct 2 HP S140u USB Monitor
iSerial 3 CNC611046J
bNumConfigurations 1
and loaded modules:
Quote:
evdi 43794 0
drm_kms_helper 139888 1 evdi
drm 350602 2 evdi,drm_kms_helper
syscopyarea 3289 3 evdi,udlfb,drm_kms_helper
sysfillrect 3890 3 evdi,udlfb,drm_kms_helper
sysimgblt 2544 3 evdi,udlfb,drm_kms_helper
fb_sys_fops 1805 2 udlfb,drm_kms_helper
loaded kernel is 4.4.0-1-rpi2 on actual rasbian jessi.

Last edited by Mahdi2016; 02-09-2017 at 08:08 AM.
Mahdi2016 is offline   Reply With Quote
Old 10-28-2016, 01:17 PM   #2
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Default

After testing this, i've loaded the udl and the evdi module. The LED of this display, blinked white for 1 second.

lsusb:
Code:
Bus 001 Device 004: ID 17e9:ff06 DisplayLink
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lsmod:
Code:
evdi                   43794  0
drm_kms_helper        139888  2 udl,evdi
drm                   350602  3 udl,evdi,drm_kms_helper
syscopyarea             3289  2 evdi,drm_kms_helper
sysfillrect             3890  2 evdi,drm_kms_helper
sysimgblt               2544  2 evdi,drm_kms_helper
fb_sys_fops             1805  1 drm_kms_helper
The old module udlfb has been added to the blacklist.

Has anyone got an idea to get the ad running on a Raspberry or ARM platform?
Mahdi2016 is offline   Reply With Quote
Old 10-29-2016, 08:42 PM   #3
RobertCochran
Junior Member
 
Join Date: Aug 2016
Posts: 11
Default

These are your options:

1. Hope that DisplayLink releases the DisplayLinkManager code as open source

2. Hope that DisplayLink releases a DisplayLinkManager build for ARM

3. Hope that someone is able to reverse engineer the protocol for these devices and write their
own (hopefully open source) driver.

That's all you can do. DisplayLink has not been doing well at all when it
comes to supporting Linux users IMO.
RobertCochran is offline   Reply With Quote
Old 11-01-2016, 12:11 PM   #4
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Question

is it possible that DisplayLink will support ARM in the near future?
Especially in the ARM environment, there are many solutions that may work very fine with such a display. At my company we have already installed & configured such a display.
Mahdi2016 is offline   Reply With Quote
Old 11-03-2016, 01:38 PM   #5
mlukaszek
Senior Member
 
mlukaszek's Avatar
 
Join Date: Feb 2010
Posts: 319
Default

tl;dr: no compatible ARM platform found yet, except for Chromebooks and Android devices.

The main use case we'd like to enable is being able to extend screens - to be able to use multiple monitors simultaneously.

While DisplayLinkManager can be compiled for ARM (and in fact it already has been compiled for ARM; there are Chromebooks which use ARM binary of DLM, as well as our Android app), that's not all you need.

We have not yet seen an ARM based platform which would support cross-device DRM prime support well (necessary to use output offloading, think xrandr --setprovideroutputsource ...). This is required for evdi to get pixels that we display on a device.

Last time I tried, Raspberry Pi was almost there - with Eric Anholt's experimental vc4 module for the GPU. However, I only managed to use one screen at a time - i.e. only DisplayLink-connected screen was operable, not the built-in HDMI. Other devices I tried (e.g. BBB) didn't even get close to this.

You could argue that certain use cases would be fine with just accessing a plain framebuffer through /dev/fbX - so, legacy fbdev interface. Sadly, neither UDL nor evdi don't support this mode anymore - last driver that did was pre-DRM legacy driver "udlfb" - which only supported USB2.0-era devices.

If someone confirms he's successful with second screen driven by UDL on any ARM-based platform, configured in a way that both screens can be used - both the built-in and UDL-driven, I think we'd be happy to release ARM binary of DLM for use with evdi.

Regards,
Michal
mlukaszek is offline   Reply With Quote
Old 11-08-2016, 12:39 PM   #6
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Lightbulb

Thanks for the note.

After some testing this , i got some problems with the new kernel. At the first bootup the "rainbowscreen" comes up too. The kernel 4.9.0-rc2 works _not_ fine.

I`ve builded the kernel 4.4.26 (stable) and the newest versions from the extra modules e.g. libdrm, mesa, xserver, evdev ..
After this, i activated experimental opengl (vc4) and rebooted the system - works fine.

The output from glxgears -info
Code:
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = Gallium 0.4 on VC4 V3D 2.1
GL_VERSION    = 2.1 Mesa 13.1.0-devel (git-00baaa4)
GL_VENDOR     = Broadcom
The output from lsmod:
Code:
Module                  Size  Used by
bnep                   10340  2
bluetooth             326105  5 bnep
cfg80211              427855  0
rfkill                 16037  3 cfg80211,bluetooth
vc4                   109413  1
evdev                  11396  4
sg                     18319  0
drm_kms_helper        101028  2 vc4
drm_mipi_dsi            8702  1 vc4
drm                   262564  4 vc4,drm_kms_helper
syscopyarea             2945  1 drm_kms_helper
sysfillrect             3443  1 drm_kms_helper
sysimgblt               2069  1 drm_kms_helper
snd_bcm2835            20447  1
fb_sys_fops             1309  1 drm_kms_helper
snd_pcm                75762  1 snd_bcm2835
snd_timer              19288  1 snd_pcm
snd                    51908  5 snd_bcm2835,snd_timer,snd_pcm
i2c_bcm2708             4834  0
bcm2835_wdt             3225  0
bcm2835_gpiomem         3040  0
uio_pdrv_genirq         3164  0
uio                     8000  1 uio_pdrv_genirq
i2c_dev                 5859  0
fuse                   83781  3
ipv6                  347530  46
My problem is, the Display HP S140u (DL 41xx) doesn't work as it should be.
I need this display as the primary (standalone) display on my RaspberryPi2 (raspian jessie).

Has anyone some experience to get the display working on an rasperrypi?

Last edited by Mahdi2016; 02-09-2017 at 08:08 AM.
Mahdi2016 is offline   Reply With Quote
Old 11-08-2016, 08:55 PM   #7
mlukaszek
Senior Member
 
mlukaszek's Avatar
 
Join Date: Feb 2010
Posts: 319
Default

See, but that's just half way through. The only thing that changed so far is using a DRM-compatible module for the built-in GPU (vc4).

Now, the trick is to add `udl` (for older devices) or evdi (for newer) on top of that, and call `xrandr --setprovideroutputsource ...`.

So - what you could do now is to try to build evdi (I remember I used rpi-update and rpi-source combo for getting kernel sources and building the module afterwards). Then, despite lacking DLM, you can try to build and run monitorsim from here.

Alternatively, if you have an older device that can be driven with UDL, try this instead.

If everything works, meaning that you still get to see the main HDMI output, plus additionally you see the second screen (in a window, in case of monitorsim), please do report back.

Note: I'd recommend to experiment via ssh.

Fingers crossed!

Cheers,
Michal
mlukaszek is offline   Reply With Quote
Old 11-11-2016, 10:42 AM   #8
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Exclamation

Hi Michal,

i've built the evdi module and it works fine.

here is the output from lsmod:
Code:
#lsmod | grep evdi
evdi                   36280  0
drm_kms_helper        101028  3 vc4,evdi
drm                   262564  5 vc4,evdi,drm_kms_helper
syscopyarea             2945  2 evdi,drm_kms_helper
sysfillrect             3443  2 evdi,drm_kms_helper
sysimgblt               2069  2 evdi,drm_kms_helper
After that I started building the evdipp package.

After 'make install' the build breaks up with the following message:
Code:
make install
[  5%] Performing download step (git clone) for 'github_evdi'
Cloning into 'github_evdi'...
remote: Counting objects: 389, done.
remote: Total 389 (delta 0), reused 0 (delta 0), pack-reused 389
Receiving objects: 100% (389/389), 524.26 KiB | 871.00 KiB/s, done.
Resolving deltas: 100% (226/226), done.
Checking connectivity... done.
Already on 'devel'
Your branch is up-to-date with 'origin/devel'.
[ 11%] No patch step for 'github_evdi'
[ 16%] Performing update step for 'github_evdi'
Already on 'devel'
Your branch is up-to-date with 'origin/devel'.
[ 22%] No configure step for 'github_evdi'
[ 27%] Performing build step for 'github_evdi'
[ 33%] No install step for 'github_evdi'
[ 38%] Completed 'github_evdi'
[ 44%] Built target github_evdi
Scanning dependencies of target evdipp
[ 50%] Building CXX object libevdipp/CMakeFiles/evdipp.dir/buffer.cpp.o
[ 55%] Building CXX object libevdipp/CMakeFiles/evdipp.dir/evdi.cpp.o
[ 61%] Building CXX object libevdipp/CMakeFiles/evdipp.dir/screen.cpp.o
In file included from /usr/src/evdipp/libevdipp/screen.cpp:1:0:
/usr/src/evdipp/libevdipp/screen.hpp:25:11: error: ‘size_t’ does not name a type
     const size_t BUFFER_COUNT = 2;
           ^
/usr/src/evdipp/libevdipp/screen.hpp:26:19: error: ‘unique_ptr’ is not a member of ‘std’
     std::map<int, std::unique_ptr<Buffer>> buffers;
                   ^
/usr/src/evdipp/libevdipp/screen.hpp:26:19: error: ‘unique_ptr’ is not a member of ‘std’
/usr/src/evdipp/libevdipp/screen.hpp:26:44: error: ‘buffers’ was not declared in this scope
     std::map<int, std::unique_ptr<Buffer>> buffers;
                                            ^
/usr/src/evdipp/libevdipp/screen.hpp:26:44: error: template argument 2 is invalid
/usr/src/evdipp/libevdipp/screen.hpp:26:44: error: template argument 4 is invalid
/usr/src/evdipp/libevdipp/screen.hpp:36:5: error: ‘size_t’ does not name a type
     size_t bufferToUpdate;
     ^
/usr/src/evdipp/libevdipp/screen.hpp:42:14: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
 typedef std::shared_ptr<Screen> ScreenPtr;
              ^
/usr/src/evdipp/libevdipp/screen.cpp: In constructor ‘Screen::Screen(const Evdi&, std::vector<unsigned char>&)’:
/usr/src/evdipp/libevdipp/screen.cpp:8:3: error: class ‘Screen’ does not have any field named ‘bufferToUpdate’
 , bufferToUpdate(0)
   ^
/usr/src/evdipp/libevdipp/screen.cpp: In member function ‘virtual void Screen::on_mode_change(evdi_mode)’:
/usr/src/evdipp/libevdipp/screen.cpp:60:22: error: ISO C++ forbids declaration of ‘buffer_id’ with no type [-fpermissive]
     for (const auto& buffer_id : buffers | boost::adaptors::map_keys) {
                      ^
/usr/src/evdipp/libevdipp/screen.cpp:60:34: error: range-based ‘for’ loops are not allowed in C++98 mode
     for (const auto& buffer_id : buffers | boost::adaptors::map_keys) {
                                  ^
/usr/src/evdipp/libevdipp/screen.cpp:60:34: error: ‘buffers’ was not declared in this scope
/usr/src/evdipp/libevdipp/screen.cpp:66:25: error: ‘BUFFER_COUNT’ was not declared in this scope
     for (int i = 0; i < BUFFER_COUNT; ++i) {
                         ^
/usr/src/evdipp/libevdipp/screen.cpp:67:22: error: ‘make_unique’ is not a member of ‘std’
         buffers[i] = std::make_unique<Buffer>(i, mode.width, mode.height, mode.bits_per_pixel/8 * mode.width);
                      ^
/usr/src/evdipp/libevdipp/screen.cpp:67:45: error: expected primary-expression before ‘>’ token
         buffers[i] = std::make_unique<Buffer>(i, mode.width, mode.height, mode.bits_per_pixel/8 * mode.width);
                                             ^
/usr/src/evdipp/libevdipp/screen.cpp: In member function ‘void Screen::update()’:
/usr/src/evdipp/libevdipp/screen.cpp:107:29: error: ‘bufferToUpdate’ was not declared in this scope
     if (evdi.request_update(bufferToUpdate)) {
                             ^
/usr/src/evdipp/libevdipp/screen.cpp:110:5: error: ‘bufferToUpdate’ was not declared in this scope
     bufferToUpdate = (bufferToUpdate + 1) % BUFFER_COUNT;
     ^
/usr/src/evdipp/libevdipp/screen.cpp:110:45: error: ‘BUFFER_COUNT’ was not declared in this scope
     bufferToUpdate = (bufferToUpdate + 1) % BUFFER_COUNT;
                                             ^
libevdipp/CMakeFiles/evdipp.dir/build.make:100: recipe for target 'libevdipp/CMakeFiles/evdipp.dir/screen.cpp.o' failed
make[2]: *** [libevdipp/CMakeFiles/evdipp.dir/screen.cpp.o] Error 1
CMakeFiles/Makefile2:112: recipe for target 'libevdipp/CMakeFiles/evdipp.dir/all' failed
make[1]: *** [libevdipp/CMakeFiles/evdipp.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2
Please i need some help and i havent any ideas anymore.

Best regards
Michael

Last edited by Mahdi2016; 11-11-2016 at 11:01 AM.
Mahdi2016 is offline   Reply With Quote
Old 11-12-2016, 03:26 PM   #9
mlukaszek
Senior Member
 
mlukaszek's Avatar
 
Join Date: Feb 2010
Posts: 319
Default

Hi,

You need a C++14 compliant compiler. For the reasons I can't fully understand you sometimes must pass CXX flags manually, as cmake setting that I think should work doesn't

Have a look at https://github.com/mlukaszek/evdipp/...er/.travis.yml - this is the configuration for Travis CI. I was forced to run cmake with -DCMAKE_CXX_FLAGS="-std=c++14" as you'll see.

Cheers,
Michal
mlukaszek is offline   Reply With Quote
Old 11-14-2016, 12:40 PM   #10
Mahdi2016
Junior Member
 
Join Date: Oct 2016
Posts: 20
Exclamation

Hi Michal,

i've built the evdipp package without errors.

After reboot and plug in the HP s140u Monitor and type "sudo monitorsim EDIDv1_1600x900"
a new clear window opened and after 10 seconds the window closed automatically. The output of the terminal window is at follows:
Code:
pi@raspberrypi:~ $ sudo monitorsim EDIDv1_1600x900
[libevdi] ioctl: drop_master error=-1
[libevdi] ioctl: drop_master error=-1
[libevdi] ioctl: drop_master error=-1
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

Please i need some help and i havent any ideas anymore.

Best regards
Michael

Last edited by Mahdi2016; 02-09-2017 at 08:09 AM.
Mahdi2016 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 07:37 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.