Wireless connect disables external Display Port

Copper Contributor

Using the external Display Port connector from Surface Hub to feed a telepresense system. When we connect a laptop by HDMI/USB, the HUB is mirrored to to Display Port and can be seen by the conference system.

 

When we connect via Miracast/SmartInk the external display is blanked immediately after the connection is made. The two-way communication between the Hub and the laptop works perfectly, but there is no signal sent to the external connector. As soon as the wireless connection is stopped, the display is active again.

 

How do I set the external Display Port connector to always be active?

8 Replies

Hello,

 

At the moment it is not possible because the hub always project the latest connected source for user convinience.

 

RS2 will introduce new capabilities with the serial port. Documentation will be available once we publish RS2. (April 11th)

I'm having difficulty understanding your answer. Let me restate the question.

 

We have a Hub 55, connected to a 90" LCD display via the "Video Output" connector, as shown at https://technet.microsoft.com/en-us/itpro/surface-hub/connect-and-display-with-surface-hub#video-out

 

It is described as "The Surface Hub includes a Video Out port for mirroring visual content from the Surface Hub to another display."

 

This works if we connect the "visual content" to to the Hub by the Display Port, HDMI, or VGA input connectors, and the USB cable for Touchback/Inkback. The sutdents in the back of the classroom can see the instructors content on the 90" external display, but we have to run several cables acrosss the floor, creating a safety hazard.

 

To eliminate the cables and safety hazard, we obtained a Dell E5470, advertised in the Microsoft Store as 80211.ac (Miracast enabled) .As soon as the wireless connection to the Hub is established, the "Video Output" on the Hub 55 is disabled. The attached 90" display goes black with "NO SIGNAL". As soon as the wireless connection is stopped, the Video Output is enabled and we see the Hub again.

 

So actually, the hub almost always projects the connected source - but only when the connected source is attached by a cable running across the floor.

 

How do we get the Video Output to remain active when using wired (VGA, HDMI, or Display Port) and wireless (Miracast)?

Hello Greg,

 

Sorry for the late reply, don't know if you still have the issue but the issue you are mentionning look like HDCP issue.

 

HDCP is designed to protect numerical content to prevent copy. If you send HDCP content to the hub it might block screen mirroring feature because it would be a breach of the security.

Do you know what kind of PC is projecting ? can you try with VGA which does not support HDCP.

We had some issue with MAC devices because they enforce HDCP by default.

 

HTH

 

Eric S.

I just assisted a client with a new Surface Hub installation and am experiencing the same problem.  I thought it could be an HDCP issue as well.  However the poster above who is just connecting to a standard display should be HDCP compliant from end to end.  In both of our cases if it hasn't been made extraordinarily clear, HDMI and VGA guest connections work fine.  However output is discontinued after successfully connecting to Surface's WiDi interface.

 

If this is a limitation of the system I can find no documentation supporting it or reporting the limitation.

Hello,
Nice timing I was preparing my techsummit session yesterday and we faced the exact same issue.
Long story short it is an HDCP issue. We work around it with a samll box that we put between the HUB and the screen. It changed all the behavior.
Not sure I understand all but I can share the reference of the hardware if you wish.

I would be interested in what you have between the HUB Display Port and the external display.

 

The tricky part is that I need to keep the digital audio intact from the laptop through the DP out on the HUB to connect to a Cisco SX80 codec. The codec drives the displays and feeds the audio amplifier. With the DP/HDMI operating, the digital audio is passed along and decoded in the codex. When the HUB Display Port out is disabled, that will require me to run to run 70' of audio cable back to the Cisco SX80, and doing the Digital-Analog-Digital dance as well.

 

Yes, this flaw is not documented anywhere - in fact the Surface HUB product is poorly documented. Had we been aware of this, we would have rejected the proposal and purchased a much less expensive "display only" screen without the crippled version of Win 10.

Greg

I don't think this is necessarily a fault of the Surface Hub, this is a requirement of HDCP which is a well documented standard. However I agree that it could be made clearer in the Miracast information on the Admin guide that HDCP will cause the DisplayPort out to go black when using Miracast.


I will also agree that the Surface Hub used to have quite poor documentation. In fact, when we got our first ones for testing in September 2016, there was almost NO documentation. We had to figure most of it out ourselves. These days though, almost everything is documented.

The case in point is Microsoft cannot account for every scenario and every use of the device with third party peripherals. They can document the device itself and it's various functions, but they can't necessarily say how it will perform in other cases. I'm not looking at Microsoft to explain how the Surface Hub will react to the new AV kit we're installing, I'm having to make reasonable assumptions based on known behaviours.

Regarding the box, my guess is Eric is using a Miracast receiver that then plugs into the Surface Hub over cable for video in. At that point the Hub can then send the video out on DisplayPort as the HDCP won't apply from the Surface Hub side. However I could be wrong and would also like to check what Eric used to get around the problem.

To say that the Hub runs a 'crippled' version of Windows 10 though is wrong. You and I both know that it's not crippled; it's optimised for the device and the use case. Trying to use standard Windows 10 on a large touch-screen is a complete no-go for a meeting room environment. I should know, we trialled it and it was a disaster! The thing that makes it so useful is that the OS is optimised for the type of device it is and the scenarios for which it is being used, restricting issues caused by end users messing around with it and turning a Windows 10 device into an appliance. In a meeting room scenario, where you need to know the device will reset properly and be ready to use from a known good configuration each time this is VITAL.

Given you have a Cisco SX80, I'm a little perplexed why you would have bought a Surface Hub for the room to be honest? We looked at both a Cisco solution (including the SX80 for our boardrooms with the MX700) and the Surface Hub, and would never have tried to marry both together. For us it was clear it's one or the other, otherwise it's getting to be a bit much and introducing too many failure points.

The confirmation on HDCP is appreciated.  I know of the devices of which you speak.

 

Greg, you will not get digital audio out of the display port output of the HUB for very specific reasons.  The HUB is designed to work almost entirely with its own peripherals when it comes to sound and to a lesser extent video.  The reason for not exporting sound by design is for echo cancelling.  The speakers and microphones are engineering to work together to provide a good conferencing solution.  Although you can connect third party USB and bluetooth devices, these would also typically have their own echo cancelling built in.  However exporting just audio out to an external speaker while using wide field microphones built into the surface would cripple the echo cancelling capabilities of the unit.  Although my client is also using theirs as a presentation device, I acknowledge that the surface is really designed to be a self contained conferencing and collaboration device.