Intel USB 3.1 eXtensible-Hostcontroller

[Erido]

I have connected a second monitor to the USB 3.1 port on my HP EliteBook 850 G5. Everything worked fine at first. However, when I remove the plug from the USB 3.1 port and plug it back in, the monitor no longer receives a signal. I then have to switch off the laptop and reset the USB 3.1 port by pressing the power button for approx. 30 seconds
(I found this in a forum). What is the problem or is there a driver from Intel that solves this problem?
The driver on my laptop is from Microsoft (driver version: 10.0.22621.2506).

[Diego_INTEL]

Hello @Erido,

Thank you for contacting Intel Embedded Community.

You may try running the driver support assistant but it seems this is an old processor.

https://www.intel.com/content/www/us/en/support/intel-driver-support-assistant.html

Maybe using a multiport device can help by not having to remove the plug.

Best regards,

@Diego_INTEL 

[NeMo-1]

I'm sorry that I don't have a OP to quote however from memory I am nearly certain that this is a UEFI firmware bug and whether it's Intel or WHQL signed drivers eXtensible Host Controller despite saying it's a 3.0 controller I can assure you that this device is properly controlling the USB 3.1 gen2 monitor at Intel Spec 3.2.

Unfortunately the general consensus is that it's a UEFI firmware bug having just last minute launched the fancy new USB capabilities and these UEFI are a slightly outdated version of what is shipping now the BIOS will choke every time the USB is reattached as far as I know there's no updates available the community solution that 'everyone' more less is accepting as solved is to–

"I then have to switch off the laptop and reset the USB 3.1 port by pressing the power button for approx. 30 seconds"

--this is both the workaround dirty fix that you posted as well as community solution #1--

That's necessary because to make the monitor connected to UEFI video there's a bios variable that gets set to the NVRAM and the UEFI of this first generation tech was never programmed with code to allow USB Controller to modify the NVRAM variables representing each video device in UEFI prior to this chipset could never reassign them automatically after reconnected it gets a new disiplay variable but the graphics are still pointing to the now detached and reattached removable display.

#2

There's an extremely moderate to moderate-extreme difficulty actual real solution but most people are far too lazy and uncomfortable working with anything lower than Windows but because this is not a windows issue either we have to go to the BIOS NVRAM itself. When you are running Windows or another UEFI OS the UEFI shell is usually accessible via boot manager, various escape signals, but Windows is fully controlling the displays and GPUs by taking over control of those things with aforementioned drivers. In my personal opinion RS232 UART-to-USB or UART-to-JTAG serial port console or virtual emulated console UEFI drivers for WHY¿

TO CONTINUE TO ACCESS THE UEFI SHELL POST-SECONDARY BOOT WHILE WINDOWS IS STILL CONTROLLING THE MACHINE because you'll have to manually name every display adapter that you use USING UEFI SHELL CODE and requiring to be aware of device vendor's VERY SPECIFIC MEMORY ADDRESSES that are not going to be the same for a Lenovo as a ASUS though maybe identical Intel 945's as THESE VARIABLES ARE SOMETIMES blocked FROM END USED, sometimes found on some forum device builder message boards by the system manufacturer, sometimes an option right in the bios setup phase like click with your mouse exposed, most people actually have at the address space to look at what is in memory and figure it out it is possible to Turn-Key provision a way to switch video intelligently.

Basically the very next generation of bios for newer hardware took care of it naming every adapter fb0 fb1 fb2 etc. and so forth and the USB controller spec updates was a rushed release so you unplug the monitor and relocate and when you plug in the monitor again it's created fb3 except fb2 still exists! The conflict and yes the reboots but yeah-

Just so you know if you're a contractor and someone is demanding perfect pinbutton function with a machine based on this chipset it's doable like not impossible at all there's a couple ways you could go about it

WARNING if you know your way around a UEFI bios shell and do manage TO create MEMORY RESIDENT static device names for multiple displays you'd just need to set the bit to memory to manually initialize the specific graphics adapter and you want enabled and attache all the USB  hot plug no problem it's assising displays identifiers like Linux assigns dev files sda sdb sdX ... except it's in the freaking BIOS and not about storage

So #2 in summary is the capability is there to statically assign displays TO AVOID COLD REBOOT AND the dummy way of enumerateting for the actual MUX devices BUT now that you will no longer be concerned with rebooting you should know after reprogramming NVRAM if you cold restart for any reason ALL video is permanently discoupled THINK BLACK SCREEN OF DEATH so IF YOU NEED TO BE HOT PLUGGING THIS MONITOR PEACE OF CAKE BUT ONCE YOU GO THAT WAY it's not easy to just reset your firmware and get video on boot THAT'S JUST IF YOU REBOOT WITH THE MONITOR NOT ATTACHED could even write a usermode driver and bake a gui into your Sysprep to toggle the ways displays enumerated by UEFI improvised modes or just basically the additional logic that's in the windows and the Intel Chipset but missing from UEFI bios probably stubs hiding partial implementations.

Of course #3 sweet 3 buy a newer computer mfg about literally just a year later or maybe some experimental community homebrew BIOS like flash the EEPROM and compile yourself something cobbled from TianoCore sunset.

That's it that's all I never post more than two threads daily hope maybe I helped someone could be hosting a mri medical the trolls don't know could always be important?! 

NeMo-1 has not configured a signature