I have the same issue with ZenScreen additionally LG 38UC99-W monitor experiences same behavior.  As original poster mentioned using the monitors through a docking station works, directly plugged into pixel slate does not.  

Using same monitors on pixelbook or samsung chromebook pro (gen1) do not exhibit this behavior, they work flawless.  

Also happy to answer questions.

The only way I got this to work was plugging my slate power into a USB-D hub with PD and then the hub into the Slate. Then using the zenscreen USB-C to USB-C with the USB-C to TYPE-2 dongle plugged into the hub the screen came to life and worked.

I do not claim any mastery over USB-C but I thought one of the major selling points was PD (power distribution) and data over the same port.

PS the hub I used is Novoo (looks like a door hanger and lots of sockets)

Benson, do you know if that's intentional?

It's not intentional, but it's possible this is a known issue, marcheu. See b/119441488.

We should acquire one of these zenscreen monitors and try it with the systems that Wills and David have modified.

> The zenscreen only draws 8 watts.

This may not be the issue, but for what it's worth, the Pixel Slate only advertises 7.5W (5V/1.5A). Therefore, if the monitor truly needs 8W, the slate may not be able to provide that.

We should get one of these and confirm. Also, if an overcurrent event is happening on VBUS, that should be logged in the EC log/dmesg.

ASUS ZenScreen MB16AC 15.6 inch FHD IPS USB Type-C Portable Eye Care Monitor
https://www.asus.com/us/Monitors/MB16AC/
https://www.asus.com/us/Monitors/MB16AC/specifications/


Important details (in my opinion):

1.) This is a DisplayLink **and** DP-AltMode monitor!
This might be causing some enumeration issues, depending on its internal interface selection logic.
[DisplayLink is an extremely sub-optimal, lossy interface using USB data.]

"15.6” FHD IPS USB Type-C portable monitor with hybrid signal solution for compatibility with USB Type-C and Type-A sources (Note: DisplayLink driver needed for Type-A connection)
*DisplayLink drivers are required for USB mode, but not for USB-C mode"

2.) This monitor may be trying to request a 5v/3a PD contract in excess of Nocturne's 5v/1.5a maximum if the spec sheet is to be trusted.

"Power Consumption
Power Consumption(Typical):<8W* <======= greater than 7.5w, at partial brightness and no USB things no less.
Power Saving Mode:0W
Power Off Mode:0W
*measuring a screen brightness of 200 nits without audio/ USB/ Card reader connection"


I think the Type-A connection assumes BC1.2 power (5v/1.5a). And even then the monitor might exceed it.

Type-A uses implicit voltage/current contract -- and many ports I've seen don't have hard OCP shutoff until 5v/2.1a (12w Apple) or so if that. Whereas Nocturne will simply REJECT a (5v/3a) PD SRC-CAP->REQUEST. So I think this monitor is simply overcurreting Type-A ports even with BC1.2 CDP (USB data+BC1.2) signaling.

Or the monitor was naively designed, assuming it would be used on Apple products like MacBooks -- whose Type-A ports support "Apple 12w"  proprietary CDP signaling (5v/2.4a). I've seen a number of Type-A products that don't honor 100/500/900ma/1.5a USB-IF requirements.

I'm very interested in seeing which of these above issues it may be.

I'm not prepared to speculate that the monitor requests 5V 3A, or that what's happening is an overcurrent event. (that should show up in our logs too, by the way).

Let's wait and see what it says when I put it on the PD analyzer. I should have it by Friday.

Also, Nathan, you missed one bad thing they did. The monitor comes with a spec forbidden USB-A plug to USB-C receptacle adapter.

I commented in #3 and I want to add something... I now have two PD capable hubs.  I discovered that if I plugged the hub into ZenScreen with the Type-A, then added the power to hub (the screen would start to boot), then plugged the hub into the Slate.... those three steps worked.  Any other arrangement failed.

Richard:

If you're using USB Type-A anywhere in the process, you're probably falling back to the proprietary DisplayLink method, which uses USB data lines instead of a DP Alternate Mode.

That basically points to there being some issue with DP Alt Mode, but we will see when I get one in my lab.

ACK. thanks

Additional debug on this is happening on buganizer at b/122657574.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

This issue has been tracked down for both the MB16AC and the MB16AP monitors.

Both monitors violate the USB Type-C specification by overdrawing the power source capabilities advertised by the Pixel Slate.

The Pixel Slate advertises 5V 1.5A capable out of each of its USB-C ports.

The MB16AC has been measured to draw almost 7A in inrush current on attach.
The MB16AP, since it has a battery, does not have this problem of inrush current, but when it is turned off, it draws 5V 2A blindly from whatever is attached to it, despite the 5V 1.5A current limit provided by the Pixel Slate via Rp resistor.

The Pixel Slate's new SN5S330 USB Type-C power path controller implements a strict overcurrent protection which cuts off power and signals overcurrent at 1.6 to 1.8A. In both conditions, the MB16AC and MB16AP trip the PPC's OCP.

Asus's monitors draw an excessive amount of current at connect and at other times, and Pixel Slate's protection circuitry is working as intended.

We are in the process of reporting this issue to Asus. From Chrome OS's and the Pixel Slate's perspective, everything is working properly. The new PPC has helped discover bad products in the ecosystem.