@DonutEspresso I went through the U3818DW's manual hoping to find a solution, but I came up empty. The only toggle I could find about which USB "upstream" port to use seems to apply only when using PIP/PBP. I would have expected the display to be designed so that when only a single source is being shown, the display would use USB-C for USB data unless there was also a connection on the "upstream" USB port, in which case it would use that instead -- for the exact reason you describe. A system that only supports DisplayPort HBR2 over USB-C, which is still most systems today, can't run enough display bandwidth to drive this display at its native resolution and refresh rate while also running USB 3.x data. And I believe the display itself only supports HBR2 anyway. So the cabling setup you're apparently attempting would have been the solution that I myself would have attempted in order to maintain USB 3.x data while handling video and power over USB-C.
You didn't specify which system you're using, but if it has another suitable display output connector available and the U3818DW allows you to use the USB-C port purely for power and USB data, then you could run video over a separate cable and use your USB-C connection only for power and USB 3.x data. I know that Dell's newer USB-C displays allow this type of setup since on some of their new displays, the USB-C input is the ONLY "upstream" USB data path available at all, but I'm not sure whether the U3818DW would allow it.
Otherwise, if the USB data path is forced to the USB-C port whenever a device is attached there, and that can't be overridden, that does seem like a glaring oversight, and one that should be fairly easy to fix with a firmware update. So if that's truly the case, hopefully Dell comes through here, although given that the U3818DW is a "2018 model year display", I wouldn't hold my breath, sadly.
Thanks @jphughan, that seems to be my conclusion as well after trying out various combinations of inputs.
if it has another suitable display output connector available and the U3818DW allows you to use the USB-C port purely for power and USB data, then you could run video over a separate cable and use your USB-C connection only for power and USB 3.x data
I tried this, actually, with Apple hardware (I know, I know - not officially supported), and it gets super wacky. Even if I attach the HDMI/DP connectors first, then USB-C, MacOS ends up showing two monitors. It seems the USB-C video input supersedes all other inputs. This design choice appears to be reinforced by the menu design's conspicuous lack of customization around the USB-C input as well.
In any case, per the manual, the USB-C input only supports USB 2.x data, presumably to make space for video. So that leaves folks w/ bandwidth hungry USB 3.x devices in quite a bind! You have be all-in on USB-C, or not use it at all, which seems like such a strange design choice for a higher end product like this.
@DonutEspresso Bummer, although now that you mention it, I have a feeling I know why that behavior occurs. In fact I even wrote a post about it. Basically there are two possible designs for how displays should handle non-active inputs, each with a philosophy behind them. The first is for the display to essentially disable any inactive inputs, so that devices connected to them don't even detect a display, and switching to another input is functionally equivalent to disconnecting the display from whatever system you were using up until the switch. That would be handy in your situation. It's also preferred by some people who switch their display back and forth between multiple source systems, since that behavior means that applications cannot get "lost" on a display that the system still sees as connected but that isn't actually displaying any content from that system, because it's set to a different input.
The alternative and seemingly more common design is for the display to maintain "presence" on all inputs so that any system detects it, even when the display isn't using the input that system is connected to. The advantage to THIS scenario is, ironically enough, ALSO situations where a display is being used with multiple source systems, and here's why. The advantage of the method above was that it avoids "lost" applications. But the CATCH to that design is that if the display essentially disconnects itself from non-active inputs, then the source system will see that display as disconnected, in which case it will pull all applications that were on that display back to other remaining displays -- but if won't automatically put them BACK onto that display when you switch the input back to that system. So if you have your workspace nicely arranged on that display and need to quickly switch it to another input, when you switch it back, you'll have to move all of your windows back over to that display again. If you switch multiple times per day, this becomes annoying fast. That's why the "presence on inactive displays" design seems to be more common. It allows brief switches without disrupting the arrangement of your applications on the source systems.
Full blown KVM switches also have to deal with this. The ones that tend to get good reviews are the ones that keep "advertising" the presence of the attached displays to ALL source systems so that you can switch back and forth without disrupting the application layout of your source systems. The ones that tend to get bad reviews are the cheaper ones that only present the attached displays to the active source system.
All that said, I agree it's bizarre that you can't assign the upstream USB interface to be used when the USB-C video input is in use.
Ah, the "presence" use case hadn't occurred to me, that makes total sense. Thanks for sharing such a detailed response.
Though, as I think through it, if that was the goal for this monitor, then it makes even less sense to re-route USB data via USB-C as soon as its plugged in? Any USB keyboards/mice would be effectively stuck to the USB-C device.
@DonutEspresso Yeah, I wondered about that too. My guess is that the USB-C port is only forced as the data path when it's the active input, and if you use any OTHER input, you can choose which "upstream" USB-B port is in use. But I haven't worked with that display, so I'm not sure.
I have a dell notebook connected via USB-C and a desktop connected via HDMI, and my mouse, keyboard and wireless headset dongle connected to the monitor.
I can confirm, that the USB-C data stream is only active when selected as a image source. Sadly enough, that wen USB-C is active, there is no possible way to assign USB upstream in the USB selection menu of the monitor (only DP, HDMI1, HDMI2 is present) A firmware update would be good to select USB upstream and plug USB3.0 type A to the source with USB-C video stream.
Dell still hasn’t fixed this. If I have a laptop connected to USB-C and a desktop connected via USB1 and DP; When I switch from laptop to desktop via DDM, the video switches to DP, but the usb hub portion switches back to usb-c.
jphughan
9 Legend
•
14K Posts
2
May 13th, 2020 08:00
@DonutEspresso I went through the U3818DW's manual hoping to find a solution, but I came up empty. The only toggle I could find about which USB "upstream" port to use seems to apply only when using PIP/PBP. I would have expected the display to be designed so that when only a single source is being shown, the display would use USB-C for USB data unless there was also a connection on the "upstream" USB port, in which case it would use that instead -- for the exact reason you describe. A system that only supports DisplayPort HBR2 over USB-C, which is still most systems today, can't run enough display bandwidth to drive this display at its native resolution and refresh rate while also running USB 3.x data. And I believe the display itself only supports HBR2 anyway. So the cabling setup you're apparently attempting would have been the solution that I myself would have attempted in order to maintain USB 3.x data while handling video and power over USB-C.
You didn't specify which system you're using, but if it has another suitable display output connector available and the U3818DW allows you to use the USB-C port purely for power and USB data, then you could run video over a separate cable and use your USB-C connection only for power and USB 3.x data. I know that Dell's newer USB-C displays allow this type of setup since on some of their new displays, the USB-C input is the ONLY "upstream" USB data path available at all, but I'm not sure whether the U3818DW would allow it.
Otherwise, if the USB data path is forced to the USB-C port whenever a device is attached there, and that can't be overridden, that does seem like a glaring oversight, and one that should be fairly easy to fix with a firmware update. So if that's truly the case, hopefully Dell comes through here, although given that the U3818DW is a "2018 model year display", I wouldn't hold my breath, sadly.
DonutEspresso
1 Rookie
•
3 Posts
0
May 13th, 2020 16:00
Thanks @jphughan, that seems to be my conclusion as well after trying out various combinations of inputs.
I tried this, actually, with Apple hardware (I know, I know - not officially supported), and it gets super wacky. Even if I attach the HDMI/DP connectors first, then USB-C, MacOS ends up showing two monitors. It seems the USB-C video input supersedes all other inputs. This design choice appears to be reinforced by the menu design's conspicuous lack of customization around the USB-C input as well.
In any case, per the manual, the USB-C input only supports USB 2.x data, presumably to make space for video. So that leaves folks w/ bandwidth hungry USB 3.x devices in quite a bind! You have be all-in on USB-C, or not use it at all, which seems like such a strange design choice for a higher end product like this.
jphughan
9 Legend
•
14K Posts
0
May 13th, 2020 17:00
@DonutEspresso Bummer, although now that you mention it, I have a feeling I know why that behavior occurs. In fact I even wrote a post about it. Basically there are two possible designs for how displays should handle non-active inputs, each with a philosophy behind them. The first is for the display to essentially disable any inactive inputs, so that devices connected to them don't even detect a display, and switching to another input is functionally equivalent to disconnecting the display from whatever system you were using up until the switch. That would be handy in your situation. It's also preferred by some people who switch their display back and forth between multiple source systems, since that behavior means that applications cannot get "lost" on a display that the system still sees as connected but that isn't actually displaying any content from that system, because it's set to a different input.
The alternative and seemingly more common design is for the display to maintain "presence" on all inputs so that any system detects it, even when the display isn't using the input that system is connected to. The advantage to THIS scenario is, ironically enough, ALSO situations where a display is being used with multiple source systems, and here's why. The advantage of the method above was that it avoids "lost" applications. But the CATCH to that design is that if the display essentially disconnects itself from non-active inputs, then the source system will see that display as disconnected, in which case it will pull all applications that were on that display back to other remaining displays -- but if won't automatically put them BACK onto that display when you switch the input back to that system. So if you have your workspace nicely arranged on that display and need to quickly switch it to another input, when you switch it back, you'll have to move all of your windows back over to that display again. If you switch multiple times per day, this becomes annoying fast. That's why the "presence on inactive displays" design seems to be more common. It allows brief switches without disrupting the arrangement of your applications on the source systems.
Full blown KVM switches also have to deal with this. The ones that tend to get good reviews are the ones that keep "advertising" the presence of the attached displays to ALL source systems so that you can switch back and forth without disrupting the application layout of your source systems. The ones that tend to get bad reviews are the cheaper ones that only present the attached displays to the active source system.
All that said, I agree it's bizarre that you can't assign the upstream USB interface to be used when the USB-C video input is in use.
DonutEspresso
1 Rookie
•
3 Posts
0
May 13th, 2020 18:00
Ah, the "presence" use case hadn't occurred to me, that makes total sense. Thanks for sharing such a detailed response.
Though, as I think through it, if that was the goal for this monitor, then it makes even less sense to re-route USB data via USB-C as soon as its plugged in? Any USB keyboards/mice would be effectively stuck to the USB-C device.
jphughan
9 Legend
•
14K Posts
0
May 13th, 2020 19:00
@DonutEspresso Yeah, I wondered about that too. My guess is that the USB-C port is only forced as the data path when it's the active input, and if you use any OTHER input, you can choose which "upstream" USB-B port is in use. But I haven't worked with that display, so I'm not sure.
PeC-
2 Posts
1
May 14th, 2020 03:00
I have a dell notebook connected via USB-C and a desktop connected via HDMI, and my mouse, keyboard and wireless headset dongle connected to the monitor.
I can confirm, that the USB-C data stream is only active when selected as a image source. Sadly enough, that wen USB-C is active, there is no possible way to assign USB upstream in the USB selection menu of the monitor (only DP, HDMI1, HDMI2 is present) A firmware update would be good to select USB upstream and plug USB3.0 type A to the source with USB-C video stream.
mike.french
2 Posts
0
April 12th, 2021 13:00
Dell still hasn’t fixed this. If I have a laptop connected to USB-C and a desktop connected via USB1 and DP; When I switch from laptop to desktop via DDM, the video switches to DP, but the usb hub portion switches back to usb-c.
Makes the KVM useless with a USB-C laptop.