25 лет USB!

Гальванической развязки питания не вижу.

Оно обычно в питальнике свитча и в DC-DC конвертерах девайсов. Для периферии аналогичной USB - нафиг не нужно.

Потом подключите в устройство с 48 вольтами и всё сгорит.

Стабилитроны кому придумали? Да и втыкать мышь в свитч который обслуживает, например, камеры - как-то маразматично.

Конкретно драйверов устройств ввода для Ethernet из коробки нет.

Да неужели. socat - udp4-listen:12345,reuseaddr,fork | evemu-play /dev/input/event22 Клава/мышь шлёт по UDP на порт 12345 пакеты типа E: 12345.1234 0002 0000 -001 например. Можно ещё 100500 способов придумать.

непонятно как автоматически выбирать к какому компьютеру какое устройство ввода относится, в USB такой проблемы нет.

Замени все USB порты подключённые к USB хабу чипсета, который подключён к USB контроллеру чипсета на Ethernet порты подключённые к свитчу чипсета который подключен к Ethernet контроллеру чипсета. Отдельный VLAN + какая-нибудь локальная подсеть. Девайсы разного назначения различаются портом, например. Для большинства девайсов типа флешек или там принтеров/сканеров вообще нафиг не надо ничего, они могут просто интерфейс HTTP/FTP/SAMBA/etc. выставлять и быть обычными серваками.

Проблем вообще никаких.

это чревато жестким оверинжинирнгом, ибо каждая сраная мышка, каждый сраный USB-UART переходник отныне обзаведется своим сетевым интерфейсом, вынужден будет получать свой адрес непонятно откуда, ну и прочий геморр суть которого - передать нажатие кнопки мыши по сети.

Для мышки достаточно реализовать следующие вещи:

1. на NDP «у кого такой-то адрес» отвечать «у меня»;
2. отвечать на пинги;
3. при нажатии на кнопку посылать multicast UDP-пакет.

Для пунктов 1 и 2 ответ можно формировать в том же буфере, где был получен запрос. Понимать, что это за запрос можно наложив на первые несколько байт маску и сравнив с шаблоном.

Адрес можно не получать, ограничиться захардкоженным link-local, расчитанным по EUI-64 из MAC-адреса.

Для пункта 3 достаточно константного массива, к которому в конец нужно добавить payload. Если MAC не умеет tx checksum offload, то ещё одну контрольную сумму посчитать.

Пока что выглядит сильно проще, чем USB.

Ну и на кой хер нам куча несовместимых друг с другом разъемов ?

В 90-е не было проблем, че куда пхнуть. Мыши себе спокойно сидели в COM, принтеры в LPT, клавиатуры были сначала в разъеме который я уже не помню как зовется, потом перекочевали в ps/2. Проблема появилась когда захотелось избавиться от зоопарка разъемов, и все устройства бы работали со всеми устройствами.

Как хорошо что этим всем занимался Штеуд, а то мы бы сейчас сидели с ноутбуками обставленными свичами, без радиомышей, блютуз-адаптеров и флешек, а только бы и занимались тем что ставили самбу и фтп.

Ну, ты решил одну из задач USB, еще десяток остался.

Конкретно эта задача на Ethernet/IP/UDP решается проще, чем на USB.

Если не рассматривать вопросы стандартизации, то какую задачу на USB-стеке решить проще для низкоскоростных устройств, типа мышей и клавиатур?

Бро, USB не решает задачу по подключению мыши. Он решает задачу по подключению ВСЕГО, одновременно решая и программные проблемы и аппаратные проблемы в комплексе.

Если взять одну задачу - ее можно решить, накостылив в Ethernet. Если взять другую задачу - ее тоже можно решить, добавив в Ethernet костыли. И третью и четвертую. Но когда ты сложишь эти решения воедино - ты получишь несуразного монстра с кучей разъемов и стандартов.

Я понимаю, что USB стандартизован, для него есть куча всего готового, и это его главный плюс. Никаким образом не собираюсь это оспаривать. И не собираюсь никому советовать подключать мыши через Ethernet.

Я лишь ставлю под сомнение то, что USB-стек сделан удобным для реализации в устройствах. Предлагаю пока оставить в стороне стек, находящийся на стороне host (можно обсудить это потом отдельно, тут IP и Ethernet тоже могут выиграть по простоте программной реализации) и рассмотреть только device. Предположим, что мы заглянули в альтернативную вселенную, где везде вместо USB используется Ethernet, и всё, что необходимо для стороне хоста в программной части (discovery, address allocation, драйвера) и аппаратной (разъёмы, доставка питания, свитчи) уже реализовано и стандартизовано.

На примере мыши видно, что изготовить мышь, которая подключается по Ethernet проще, чем сделать мышь (не используя слишком готового чипа, который реализует USB-мышь целиком, или готового USB HID, потому что в альтернативной вселенной будут аналогичные чипы для Ethernet HID, а используя программную реализацию, как и в примере с PIC и Ethernet выше).

Мне кажется, что решая все задачи по-одной на Ethernet и IP можно сделать стек более красивым и простым, чем существующий в USB. Я пока не могу придумать пример задачи, которую бы USB LS решал бы в случае программной реализации проще, чем Ethernet.

Только что придумал задачу, которую в случае USB пока массово никак не решили — подключение любых устройств без проводов, то есть такой удлинитель USB по воздуху. Можно накостылить коробочку с одноплатником, wifi и usb/ip, но ничего совсем готового я пока не видел. В случае с Ethernet можно обойтись парой точек доступа.

Ну и на кой хер нам куча несовместимых друг с другом разъемов ?

А зачем куча? Вот те кренделя, которые упарывались придумыванием с нуля USB разъёмов для периферии и самого USB могли бы гораздо быстрее придумать один стандартный разъём для Ethernet периферии.

а то мы бы сейчас сидели с ноутбуками обставленными свичами,

Можно подумать сейчас в ноутбуках нету USB хабов. У меня вот в ноуте 3 (три) USB хаба и 2 (два) USB хост-контроллера. Абсолютно всю их функциональность можно было бы реализовать одним Ethernet свитчом. А Ethernet контроллер и так есть.

без радиомышей, блютуз-адаптеров и флешек

С какого перепугу? Ethernet

1. проще чем USB,
2. в отличии от USB не требует отчислений в USB-IF
3. не требует затрат на написание прошивок и драйверов

поэтому радиомыши, BT-адаптеры и флешки были бы даже дешевле.

а только бы и занимались тем что ставили самбу и фтп.

Самба и фтп была бы во флешках и прочих принтерах со сканерами. Всё что нужно пользователю - просто открыть URL и скачать/залить файлы. Без всякого дрочева с драйверами вообще.

Если взять одну задачу - ее можно решить, накостылив в Ethernet.

В Ethernet вообще не надо ничего костылить. Нужно просто выбрать подходяший для задачи RFC и всё. Более того, даже реализация этого RFC будет уже готова и не надо будет городить велосипедов.

Это в USB приходится постоянно изобретать костыли, как только задача выходит за убогие рамки какого-нибудь очередного упоротого USB класса.

Но когда ты сложишь эти решения воедино - ты получишь несуразного монстра с кучей разъемов и стандартов.

Ещё раз - для Ethernet не нужно кучи разных разъёмов как для USB. Достаточно одного. Вообще одного. Хоть для девайсов, хоть для компьютеров. Никаких A/B/miniA/miniB/micro. Одного достаточно. И не надо никаких извращений со всякими OTG и прочим бредом. Даже для 1/10Gbit всё что понадобилось бы - добавить 2 пары в провод и 4 контакта в разъём, при этом ни новых контроллеров/хабов не надо было бы придумывать, ни стек, ни ещё что-либо переписывать с нуля, а не как в USB3.0, когда мало того, что ещё кучу разъёмов с кучей лишних контактов придумали которые ещё и не обязательны для создателей проводов и девайсов из-за чего полный бардак теперь, так ещё и весь стек для 3.0 пришлось писать с нуля, который, к примеру, в линуксе был написан немного некомпетентным мальчико-девочкой из Intel, из-за чего оно достаточно долго было глючным и малоюзабельным.