|
10-24-2016, 09:05 AM | #1 | ||
Junior Member
Join Date: Oct 2016
Posts: 20
|
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, i´ve got no alternative for the "DisplayManager".
According to the description, the firmware should not be the problem? Debug output: Quote:
Quote:
Last edited by Mahdi2016; 02-09-2017 at 07:08 AM. |
||
10-28-2016, 12:17 PM | #2 |
Junior Member
Join Date: Oct 2016
Posts: 20
|
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 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 Has anyone got an idea to get the ad running on a Raspberry or ARM platform? |
10-29-2016, 07:42 PM | #3 |
Junior Member
Join Date: Aug 2016
Posts: 12
|
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. |
11-01-2016, 11:11 AM | #4 |
Junior Member
Join Date: Oct 2016
Posts: 20
|
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. |
11-03-2016, 12:38 PM | #5 |
Senior Member
Join Date: Feb 2010
Posts: 386
|
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 |
11-08-2016, 11:39 AM | #6 |
Junior Member
Join Date: Oct 2016
Posts: 20
|
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 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 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 07:08 AM. |
11-11-2017, 03:57 AM | #7 |
Junior Member
Join Date: Nov 2016
Posts: 17
|
Maybe it's good idea to fill bugreport about this?
|
02-09-2019, 03:56 AM | #8 | |
Junior Member
Join Date: Nov 2016
Posts: 17
|
Quote:
PineBook Pro: https://forum.pine64.org/showthread.php?tid=7093 Asus NovaGo TP370QL, HP Envy x2 12-e011nr/12-e001nf, Lenovo Mixx 630: https://github.com/aarch64-laptops |
|
|
|