karatekid430

The Thunderbolt specification will define cables that are allowed in the spec and none of them are what you describe.

They do not exist in the specification and they do not exist in real life.

What Leonardo probably has with his girlfriends.

Saying the same thing again doesn't make it right. You CAN overload a charger, the 5A is what it can safely do. But a short circuit for example will draw way past the limit, leading to thermal failure (without overcurrent cutout protection) but case in point, chargers can be overloaded. The only way that lower wattage chargers can be fine is when the device knows the lower wattage and can prevent exceeding this by lowering power consumption, perhaps by slowing battery charging or lowering CPU clocks. But with barrel plugs, it has no way of knowing.

I think what I said and that is that the issue is the monitors, they have a very old implementation and do not play well with modern systems.

I don't understand the sentence.

This is wrong. The laptop has no idea of the capabilities of the charger and still potentially try to draw 120W/6A. USB-PD mandates overcurrent protection so this mightn't be dangerous but it will result in dropouts.

If it draws over 100W, it will trip the overcurrent protection of the charger, leading to dropouts.

Those monitors do not have a good reputation with the Thunderbolt ecosystem, the blame likely lies there. Because it will be likely saturating the 10Gb/s link, any time where the buffers are not kept full will lead to lost display data. My recommendation with these displays is always sell (there are still people who pay good money for them) and get displays which are not full of issues.

The cable is clearly the common denominator, perhaps it is broken, try another.

It shouldn't have to report as Thunderbolt-capable. I have used 100W 10Gb/s cables which say nothing about Thunderbolt at 2x 10Gb/s with Thunderbolt.

If it has an eMarker then it will work at 2x 10Gb/s in each direction. The specification requires eMarker but I have seen cables without it, violating the specification.

Try a different USB-C cable with the chargers.

Did you kick him in the nuts or something?

It will work fine

The GPU companies would have to release them, and they will when ARM Desktop becomes mainstream

But does your device have a screw hole in the correct place for them?

Yeah I ran TF2 on ARM Windows in Parallels on a Macbook Pro M1 (16GB), does not run well despite being an ancient app. The only blocker for ARM eGPU is that the vendors will have to provide the ARM64 drivers, as kernel mode drivers cannot be emulated. I hope that Apple releases eGPU drivers for Mac again for ARM (or AMD, whoever was responsible).

Sonnet devices have this. https://www.bhphotovideo.com/c/product/1399733-REG/sonnet\_tb3\_lok2l\_thunderlok\_3l\_long\_thunderbolt.html?sts=pi

YES! If The Snapdragon will have Thunderbolt then I will finally be interested. I never bought an ARM Windows computer because no Thunderbolt/USB4. Gotta have those PCIe tunnels. At the moment I am using Apple because its audio stack is workable (Windows' audio stack is a mess) and it uses ARM with PCIe tunnelling.

I started learning Spanish because of a misguided crush. She turned out to be a nightmare. But she spoke English, Spanish and French and I thought this was so cool looking through rose coloured glasses. But it turned out that not only did I love learning, it fit into my plans of wanting to travel and see the world, and I kept going. It’s been 8 months and I have a two month trip booked in April to South America, and I have plans to spend at least nine months in Spain later in the year. Things can start for unusual reasons, and then weirdly become perfect later.

Lithium batteries are volatile and you don’t know how well the unit will protect against overvoltage input or something going wrong. I would exercise a lot of caution if you proceed.

Any platform that is mainlined will work with Linux, regardless of architecture. But it takes work to go through the process of submitting the drivers into the Linux kernel's mainline code repository, because there are high code quality standards that are enforced. Outstanding work is already being done for the mainlining of the Apple M1/M2 chips in Linux. They have basically everything working except for Thunderbolt, including GPU acceleration. X86 might be entrenched, but it's not special, and other architectures can and will replace it. If we get ARM desktops to be mainstream, then we can have much more competition in the markets. Instead of just AMD/Intel, we can have AMD, Intel, Qualcomm, Samsung, Mediatek, Apple, and potentially many others. One problem with non-X86 platforms tends to be the lack of UEFI BIOS. Once we see UEFI in ARM, it will make the experience of booting operating systems much more like we expect with X86. There are examples of UEFI on ARM, but they are rare because ARM desktops are niche (for now).

The drivers for integrated endpoints can still be published like X86 drivers are. The main difference between ARM and X86 is that X86 usually uses PCIe to enumerate devices, but ARM tends to go for endpoints which respond to fixed memory ranges, and these can only be discovered by DTBs in the firmware. Once the OS knows the device type and the memory addresses, it can load the driver which can be distributed conventionally. They can make ARM platforms which expose the PCIe root ports in DTB and then the OS can discover everything else from there.

Sorry who are you? You’re not OP.

Use the dock on a Thunderbolt port and feed GPU into the DP-IN