Hardware UO Pilot, Аппаратный UO Pilot Опции

[DarkMaster]

Еще такой хитрый вопрос. Как оно дружит с виртуальными машинами, rdp(сам к себе) и особенно АСТЕРом?

Возможен ли будет последующий апгрейд прошивки? Возможно ли будет шить через USB?

Просто нужно учесть минимальные рандомные "человеческие" паузы м.д нажатиями, а не отсылать 100500 нажатий сразу smile.gif

Вот это кстати трагедия. Причем большая. И беда даже не в том, что в 1 скрипте необходимо будет очень-очень много быстро нажать(хотя и в этом тоже, но это можно контролировать), беда в том, что 2 параллельных скрипта друг друга могут легко запороть. Может быть очередь хотя бы реализовать?

Сообщение отредактировал DarkMaster - 25.1.2014, 22:26

[usb2kbd]

Еще такой хитрый вопрос. Как оно дружит с виртуальными машинами, rdp(сам к себе) и особенно АСТЕРом?

Тестировалось на VMware Workstation 10, ОС XP - девайс успешно определяется в виртуальной системе, нажатия клавиш и мыши работают даже в свернутом состоянии "виртуальной машины". Из хоста также в виртуальную машину отправляется (ну да и это естесственно).

Через RDP в удаленную машину отправляются нажатия прекрасно, самому себе не пробовал, да и не пойму особо зачем.

АСТЕР не пробовал, сайт нашел, суть - разделение ресурсов одной тачки на много юзеров. Посмотрю, поразбираюсь...

Все результаты тестов будут добавлены в раздел сайта "назначение продукта" в преимущества.

Возможен ли будет последующий апгрейд прошивки? Возможно ли будет шить через USB?

Нет, девайс без usb-аплоадера. Да и, честно, не вижу смысла апгрейдить прошивку, т.к. проще переписать DLL/ПО под конкретные нужды, девайс же лишь "исполнитель" команд сверху.

Вот это кстати трагедия. Причем большая. И беда даже не в том, что в 1 скрипте необходимо будет очень-очень много быстро нажать(хотя и в этом тоже, но это можно контролировать), беда в том, что 2 параллельных скрипта друг друга могут легко запороть. Может быть очередь хотя бы реализовать?

Хоть девайс и быстр, да и вероятность 2-х и более одновременных по времени нажатий достаточно мала в пределах одного-трех средних скриптов, сегодня-завтра поставлю творческий эксперимент по посылке ОДНОВРЕМЕННЫХ посылок 2 пакетов в девайс и рассмотрю техническую возможность реализовать буфер. Отпишусь.

Сообщение отредактировал DarkMaster - 27.1.2014, 15:22

[DarkMaster]

вероятность 2-х и более одновременных по времени нажатий достаточно мала

Это лишь вопрос времени. У меня, например, были скрипты по перебору менюшек. Стоит чар и тыкает тупо менюшки 24/7, а чаров 4 штуки. Каждый из них делал около 3 нажатий в секунду, т.е. 12 кликов в секунду. Через сколько будет сбой? Скрипты хоть и были сильно вылизаны на всевозможные огрехи подвисания и прочие проблемы, но сбои все равно были - все лаги и глюки клиента не отловишь. А это еще одно место которое будет регулярно во всех кликах проваливаться. Плюс гонка за производительностью была очень большая, каждая мс экономилась. Сделаешь проверки на все эти клики - скрипты встанут.

Нет, девайс без usb-аплоадера. Да и, честно, не вижу смысла апгрейдить прошивку, т.к. проще переписать DLL/ПО под конкретные нужды, девайс же лишь "исполнитель" команд сверху.

Суть в том, чтобы потом не пришлось бегать искать программатор или тащить его из-за бугра. Брать в городе за 30 баксов, когда он стоит 4 меня жаба задушит, тащить для меня несколько проблемно.

Из хоста также в виртуальную машину отправляется (ну да и это естесственно).

В этот момент поподробнее. Т.е. если я сделаю нажатие в основной ОС, то оно прилетит и в виртуалку? И наоборот?

Через RDP в удаленную машину отправляются нажатия прекрасно, самому себе не пробовал, да и не пойму особо зачем.

Смысл прост - это та же виртуалка только с минимумом требуемых ресурсов. Вопрос по сути тот же самый что и с виртуалками. Возможно ли будет отсылать нажатия не во все сразу. Разделяется ли как-то эмуляция системой. Цель проста до безобразия: запускаем рдп/астер/виртуалку и нас больше не беспокоит проблема активного окна и блокировки компьютера скриптом. С астером все несколько проще - там есть фильтры на оборудавние(но не уверен как отработают), а вот как с остальным не понятно.

Сообщение отредактировал DarkMaster - 27.1.2014, 15:21

[usb2kbd]

Суть в том, чтобы потом не пришлось бегать искать программатор или тащить его из-за бугра. Брать в городе за 30 баксов, когда он стоит 4 меня жаба задушит, тащить для меня несколько проблемно.

Возможно, я включу в раздел сайта схему "подпайки" к микроконтроллеру (МК) разводки на программатор Usbasp. Подпаяться к МК можно при желании будет самому, купить программатор Usbasp с переходником можно будет на Ebay'e - едет где-то 21-30 дней, заливать Firmware также можно будет самому. Но опять же повторюсь, девайс лишь "железка" и выполняет он только строгие функции по нажатиям, перемещениям, большего от него не требуется, основной инструмент - DLL и ПО. Такие действия, как "Прошивка микроконтроллера программатором", "правильное выставление фьюз-битов" и.т.д - это уже действия для людей, более глубоко знакомых с микропроцессорной электроникой, не думаю что этим будет каждый второй заниматься.

На счет буфера согласен, достаточно важная функция, рассмотрю, потестирую как отрабатываются 2 и более одновременных события.

В этот момент поподробнее. Т.е. если я сделаю нажатие в основной ОС, то оно прилетит и в виртуалку? И наоборот?

Установил VMware Workstation 10, запустил на виртуалке XP.

Эксперимент 1: Запустил у себя (на windows 7) скрипт, который через 5 секунд нажимает на машине, на которой подключен девайс (на w7) клавишу "h". Быстро переключился на окно с виртуалкой, сделал его активным. Вижу, как в блокноте, запущенном на вирт машине (xp) отпечатался знак "h".
Эксперимент2: "Перенаправил" usb2kbd, так как будто девайс подключен на виртуальной машине (xp) - это функция VMware.. Девайс на XP в виртуалке был найден и определен, а соотв с моей машины W7 был отключен. Устанавливаю teamviewer соединение (управление) из XP с моей машиной (w7). Запускаю на вирт машине (xp) скрипт, с нажатием клавиши "h", быстро сворачиваю у себя окно с вирт машиной (xp), жду с открытым блокнотом у себя (w7). Через 5 секунд у меня печатается знак "h".

Возможно ли будет отсылать нажатия не во все сразу. Разделяется ли как-то эмуляция системой. Цель проста до безобразия: запускаем рдп/астер/виртуалку и нас больше не беспокоит проблема активного окна и блокировки компьютера скриптом. С астером все несколько проще - там есть фильтры на оборудавние(но не уверен как отработают), а вот как с остальным не понятно.

Насколько я понял тут поднимается извечный программный вопрос - как отослать нажатия в определенное окно... Для понимания вопроса представьте себе Usb2kbd как обычную клавиатуру и его функция - это Simple нажать на клавишу и все, оно не умеет отсылать нажатия "куда-то" - все это уже функции ПО. Каким образом это достигнется - уже задача программиста ПО. Если виртуалки типа АСТЕР умеют как-то устанавливать типа "туннеля" между машиной хостом и вирт машиной, "пробрасывая" определенную клавиатуру или мышь, и нажатие на клавишу на основной машине приведет к пропечатыванию символа ТОЛЬКО на проброшенной вирт машине (причем даже если она в свернутом окне) - то это только плюс этому ПО. Если это действительно так, то тут проблем, уверен, не возникнет, т.к. usb2kbd - цитата "устройство не эмулирует клавиатуру/мышь - оно по сути дела является таковым". (IMG:style_emoticons/default/smile.gif)

[DarkMaster]

Насколько я понял тут поднимается извечный программный вопрос - как отослать нажатия в определенное окно... Для понимания вопроса представьте себе Usb2kbd как обычную клавиатуру и его функция - это Simple нажать на клавишу и все, оно не умеет отсылать нажатия "куда-то" - все это уже функции ПО. Каким образом это достигнется - уже задача программиста ПО. Если виртуалки типа АСТЕР умеют как-то устанавливать типа "туннеля" между машиной хостом и вирт машиной, "пробрасывая" определенную клавиатуру или мышь, и нажатие на клавишу на основной машине приведет к пропечатыванию символа ТОЛЬКО на проброшенной вирт машине (причем даже если она в свернутом окне) - то это только плюс этому ПО. Если это действительно так, то тут проблем, уверен, не возникнет, т.к. usb2kbd - цитата "устройство не эмулирует клавиатуру/мышь - оно по сути дела является таковым". smile.gif

Тут вопрос системного ПО в первую очередь. А если в диспетчере устройств основной машины отключить устройство, то в виртуальной оно останется? Сможет ли работать? Будут ли при этом клики в несколько систем одновременно?

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

[usb2kbd]

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

Скачал Астер v7 - поставлю на 2 разделяемых места, покопаюсь. По кр мере все USB-клавы и мыши он видит корректно (вкл девайс).

[DarkMaster]

На счет буфера согласен, достаточно важная функция, рассмотрю, потестирую как отрабатываются 2 и более одновременных события.

Вот это кстати надо поуму делать не через длл а железкой. Либо дублировать, что более корректно. Крутится у нас несколько пилотов, например, за счет виртуалок или того же астера. Каждый из них будет иметь свою длл. Боюсь даже запуск нескольких вкладок может иметь свои копии функций и не иметь общей области видимости. Т.е. ограничить время повторного нажатия может не получиться просто дллкой. При нескольких копиях пилота тем более дллкой это не решится.

[usb2kbd]

Астер с клавами и мышами у меня все раскидывал корректно

Поставил Астер, настроил 2 рабочих места. Совместимость - 75%. Результат:

1) Делаю место №1 условно "виртуальной машиной". Из устройств управления к месту №1 подвязываю: usb2kbd, 1 реальная резервная клава, 1 реальная резервная мышь. Завожу юзера (админа). Вывожу изображение на резервный свободный монитор. Место №2 - основное ("рабочее"), это "моя машина" с настоящим рабочим монитором, за которым постоянно сижу. Из управления подвязываю: моя клава, моя мышь. При запуске скрипта "hello" на "виртуальной" машине (место №1) - все прекрасно отрабатывает. Ну и, логично, при запуске скрипта "hello" из места №2 - пишет "девайс не подключен". Т.е. место №1 можно свободно использовать как автономное, и не "засорять" основное место (место №2) нажатиями, окнами игр и т.д. Место №2 - это будет Ваше основное раб. место.
И эта схема выше работает прекрасно ....

теперь обратный конфиг:
2) Делаю место №2 условно "виртуальной машиной", а место №1 - "рабочим". Все то же, только логично меняю мониторы и устройства ввода на противоположные. Что происходит: Usb2kbd работает на машине №2 (виртуальной), но упорно управляется только с 1-ой. т.е. запуск скрипта с машины №2 - говорит что девайс не подключен, а запуск с 1-ой - отрабатывает, но отсылает нажатия только во 2-ю. Почему так? Предполагаю что при "пробросе" в "Астере" девайса на виртуальные машины 2, 3, 4, 5 (т.е. на машину с номером больше "1"), каким-то образом "не пробрасываются" управляющие сигналы для usb2kbd - они всегда остается в машине №1.

Выводы: usb2kbd совместимо с "АСТЕР" не полностью, но цель:
Цитата:
----Цель проста до безобразия: запускаем рдп/астер/виртуалку и нас больше не беспокоит проблема активного окна и блокировки компьютера скриптом---

у нас выполняется (виртуалка с окном игры в месте №1, рабочее место №2).

Какие преимущества дает АСТЕР (кто еще не знаком). В виртуальной машине типа vmware - вы не сможете полноценно запускать требовательные игры (Lineage, Wow и т.д), а в "Астере" - сможете, т.к. виртуальная машина в Астере является по сути точной копией "реальной" машины со всеми ее ресурсами (видеокарта, оперативка и.т.д).


Теперь еще одно:

Ну все равно не догоняю одну фразу

Крутится у нас несколько пилотов, например, за счет виртуалок или того же астера.

Обе системы: что vmware, что Астер - полностью "забирают" под себя USB-устройство. Т.е. если мы, например, запустим Астер и рабочему месту №1 "отдадим" usb2kbd, то оно полностью "заберет" его себе, и назначить usb2kbd, одновременно, еще какому-то месту, по кр. мере по опытам, не возможно. Или речь идет о комбинации Ctrl+F12?. Запустить несколько копий Uopilot в пределах одной виртуалки с Usb2kbd можно, ну, или же запустить несколько копий UoPilot в нескольких виртуалках, но БЕЗ usb2kbd, тоже можно, но это ж другое...

В общем не догнал я этот момент как-то.

[DarkMaster]

В общем не догнал я этот момент как-то.

Я думал, что возможно будет сделать так:
Создаем рабочие места(астер в 1 очередь либо виртуалки):
1) Основное раб место.
2) Бот1
3) Бот2
В Бот1 биндим скилл на F18, в Бот2 биндим скил на F19.
Запускаем пилот1 на Бот1 и пилот2 на Бот2.
Дальше по моему плану в пилоте1 и пилоте2 полностью корректно будут нажиматься F18 и F19, нажатия будут проходить в 2 рабочие машины, а за счет уникальности клавиш у нас не будет конфликтов.
Более того такие бинды могли бы позволить оставить устройство и на основной машине. Но если бинды были бы более стандартные(скан коды не бесконечные) я имел бы возможность полностью отрезать устройство от основной машины и оставить на Бот1 F1-5, а на Бот2 F6-10.

если в диспетчере устройств основной машины отключить устройство, то в виртуальной оно останется? Сможет ли работать? Будут ли при этом клики в несколько систем одновременно?

Это про вмварь, все еще актуально.

Как себя ведет система при нескольких подключенных устройствах? Меня интересует более, чем одна вирт машина/два астера. Ну и основное раб место никто не отменял.

Дллка полностью монопольно захватывает устройство? Т.е. одновременно 2 длл не могут работать с 1 устройством?

Сообщение отредактировал DarkMaster - 29.1.2014, 16:04

[usb2kbd]

На пару-тройку дней ухожу в разработку "кольцевого буфера" FIFO для девайса, для кэширования и дальнейшего воспроизведения слишком "быстрых" команд в usb2kbd. В настоящее время опытным путем было определено, что минимальная стабильная пауза м/д пакетами, отправляемыми в usb2kbd из DLL составляет 22 мс и буферизация не требуется. При уменьшении ее (паузы) - уже есть необходимость буферизации. В общем попробую реализовать... Почему решено делать на базе девайса? Дело в том, что в ответ на команду из Dll девайс толком "ответить" (например, что он "занят") назад не умеет. Кстати,

Дллка полностью монопольно захватывает устройство? Т.е. одновременно 2 длл не могут работать с 1 устройством?

Нет, не монопольно, Dll лишь преобразовывает входящие данные в "удобноваримые" для девайса и отсылает их в USB. А вот определить, обработан ли пакет в девайсе или он "пропущен" девайсом, т.к. USB интеррапт девайса был занят обработкой предыдущего пакета - сложно, на практике - даже не возможно. Поэтому и нужен буфер внутри девайса.
2 Dll в комплекте с 2 Uopilot спокойно работают с одним usb2kbd.

если в диспетчере устройств основной машины отключить устройство, то в виртуальной оно останется? Сможет ли работать? Будут ли при этом клики в несколько систем одновременно?

Про Vmware - отключить девайс в основной машине не получается, т.к. при "пробросе" девайса на вирт машину, оно полностью "исчезает" в дисп задач на осн машине и появляется в виртуальной. Отключать на основной машине, получается, нечего.

Как себя ведет система при нескольких подключенных устройствах?

При нескольких подключенных usb2kbd в одной системе? Можно подключать хоть N девайсов, но важно знать, что для того, чтоб они работали и определялись как N независимых мышей/клав, необходимо на уровне прошивки заранее присваивать им разные, уникальные для каждого девайса VID и PID, тогда при подключении они будут прекрасно "сосуществовать". НО есть одно НО. Dll-ка ищет для обращения usb2kbd с конкретными PID и VID, заданными по умолчанию. И соотв. второй девайс, прошитый с другой парой VID PID - она не увидит. В связи с чем после реализации буфера рассмотрю создание .ini файла, который должен будет лежать рядом с DLL-кой, и в котором можно будет задавать другие PID и VID для данной Dll. (все это нужно будет для того, чтоб можно было пользоваться несколькими usb2kbd в пределах одной операционной системы).

Я думал, что возможно будет сделать так:
Создаем рабочие места(астер в 1 очередь либо виртуалки):
1) Основное раб место.
2) Бот1
3) Бот2
В Бот1 биндим скилл на F18, в Бот2 биндим скил на F19.
Запускаем пилот1 на Бот1 и пилот2 на Бот2.
Дальше по моему плану в пилоте1 и пилоте2 полностью корректно будут нажиматься F18 и F19, нажатия будут проходить в 2 рабочие машины, а за счет уникальности клавиш у нас не будет конфликтов.
Более того такие бинды могли бы позволить оставить устройство и на основной машине. Но если бинды были бы более стандартные(скан коды не бесконечные) я имел бы возможность полностью отрезать устройство от основной машины и оставить на Бот1 F1-5, а на Бот2 F6-10.

Все равно не пойму, как один девайс usb2kbd, находясь на основной машине "Астера" (место №1) будет получать и слать нажатия в места №2 и №3?
Допустим, на месте №2 работает Uopilot, там же запущена "линейка" и вот настало событие и этот пилот "хочет" чтоб в линягу полетело нажатие F1 - какие будут его действия, при условии, что usb2kbd в данный момент к месту №2 не подключено, - девайс на раб месте №1. Как послать команду в место №1 и более того, чтоб девайс с места №1 "ответил" назад именно в место №2 - инициатор запроса?

[DarkMaster]

Астер к сожалению прямо сейчас из системы вырезан с особой жестокостью, т.к. необходимо было налить патчи на RDP, который астер так же использовал и не давал модифицировать. Насколько помню там можно было указать раб места девайса через запятую.

Даже если брать не астер, а те же виртуалки или рдп, то принцип не изменяется. На виртуалках ты сам говорил, что прострел идет насквозь во все ОС.

При нескольких подключенных usb2kbd в одной системе?

Угу. Точнее на одном физическом компе, т.к. ос могут быть гостевые/раб места и т.д. Предположим, что что-то не удалось красиво распараллелить, то можно на каждое раб место прокинуть по девайсу. Как только меня ид на девайсине не понятно... шить?

[DarkMaster]

Предчувствуя первую же проблему при написании скриптов - таймауты отсыла клавиш. ИМХО было бы неплохо добавить флаг ожидания нажатия. Негарантированного, но все же. Т.е.:
1) в дллку падает N нажатий.
2) в дллке считаем сколько времени потребуется девайсу на обработку.
3) в дллку прилетает нажатие с флагом ожидания завершения.
4) дллка впадает в спячку пока очередь не будет очищена(сразу можно не кидать на девайс. зачем лишний элемент в буфер?)
5) отсылается команда на девайс
6) дллка опять впадает в спячку на время обработки.
Хочу подчеркнуть, что это контроль только в пределах длл. Ожидание делать лучше чуть больше расчетного, чтобы лишний клик с буфере железки от другой вкладки/пилота не настакивался при агрессивном использовании основной вкладки. Как я уже писал, наиболее корректным способом обработки будет буфер как на стороне железки, так и на стороне длл. Это позволит:
1) Избежать лишней писанины и попыток контроля в скрипте(а их иначе придется делать). Пихать gosub'ы перед каждым вызовом клика на предмет проверки буфера не есть гут.
2) Избежать вопросов почему оно не работает или работает криво. Эти вопросы неизбежно посыпятся как только человек начнет спамить.
3) Повысит стабильность работы в целом. Это не гарантия от осечки, как и буфер на железке кстати. Но ECC тоже не гарантия отсутствия ошибки памяти, но какой дурак будет без ECC добиваться стабильности?
ИМХО данный режим лучше сделать по умолчанию, а если неймется и хочешь самостоятельно контролировать эти задержки, то в параметры добавить флаг "-1". -1, а не, например, 0 потому, что я все-таки надеюсь избавиться от обязаловки четырех параметров, когда частенько нужно будет только два, а -1 позволит спокойно парсить строку в обоих вариантах синтаксиса.

// Чует, чует мое сердце, что прошивка будет обновляться со временем...

[usb2kbd]

Ну вот, в очередной раз хочу Вас порадовать, друзья мои! Три дня усиленного мозгового безвылазного штурма и вот результат, очень даже положительный!

Итак

1. Реализован и жестко оттестирован "кольцевой буфер" внутри девайса размерностью 240 байт (40 пакетов * 6 байт = 240 байт, где 1 пакет - это один раз вызов функции. Например Send (1,4,0,0) - это один пакет - "нажать клавишу А" ). Все присланные из Dll-ки данные теперь последовательно кладутся в буфер девайса и становятся в очередь на обработку. Если очередной пакет пришел в девайс из Dll, но девайс еще "занят" обработкой предыдущего пакета, пакет теперь не теряется безвозвратно, как было ранее, а кладется в буфер, занимая одно из 40 мест в буфере и так далее. Теперь внимание! Работа девайса без заполнения буфера осуществляется, если заданы паузы между пакетами в 25 мс и более, Т.е. для того, чтоб буфер не заполнялся и девайс отрабатывал входящие пакеты без использования буфера - нужна примерно такая схема:

Send (1,4,0,0); // нажать клавишу А
Sleep, 25; // пауза 25 мс
Send (2,4,0,0); // отжать клавишу А
Sleep, 25;

Мы же, придерживаясь математического тождества, примем за эталон такую схему для одной DLL:

Send (1,4,0,0);
; тут любая пауза м.д. нажатием и отжатие клавиши - от 0 и больше.
Send (2,4,0,0);
Sleep, 50;


Это идеальная схема для одной DLL и одного девайса. Если же эти паузы меньше (например наступило какое-то срочное событие, или отработало событие второго скрипта и.т.д), тогда девайс будет класть такие "срочные" нажатия в буфер и по мере возможности исполнять позже. Это как бы нормальная ситуация. Но если таких "срочных" нажатий будет очень много (мне конфет от жадности (с)) и буфер в 40 пакетов будет переполнен, тогда usb2kbd мигнет дополнительным светодиодом (добавил в схему), что будет означать то, что у Вас слишком много "срочных" пакетов - увеличьте паузы в вашем скрипте. Переполнение буфера будет означать, что этот "лишний" пакет не обработан девайсом и отбракован - т.е. примите меры. А принимать меры нужно будет, т.к. предыдущий пакет "нажать" клавишу будет отработан, а пакет "отжать" ее - нет, и будет "залипание" клавиши, паника и.т.д. (IMG:style_emoticons/default/smile.gif)

Теперь о нескольких Dll-ках и одном usb2kbd (нескольких пилотах и одном usb2kbd). Как я уже говорил, Dll-ка лишь отправляет пакет в девайс в удобноваримом для него виде и использование возможно N-го кол-ва DLL. Идеальную схему для одной Dll я уже описал выше. Но несколько Dll будут кидать пакеты чаще в одно дышло (usb2kbd) - не так ли? Вывод - чем больше кол-во активных копий DLL - тем выше нужно ставить паузы в каждом скрипте, чтоб не было того же переполнения буфера.
Сделаем простой расчет: для одной копии DLL важно правило: паузы 50 мс м.д. нажатиями разных клавиш (читаем выше), соотв - для 2 копий - 50*2=100 мс, для 3-х копий - 50*3 = 150 мс. И это нужно будет учесть для всех 3-х скриптов. Кроме того, если у нас будет несколько копий Dll, я бы порекомендовал, если у нас простое нажатие и отжатие одной клавиши (а не комбинация) - "отжимать" клавишу кодом "8" (отжать все клавиши) - так спокойнее против "залипаний".

Итак, выводы и "базовые" паузы для девайса:

Используем 1 копию DLL:

Send (1,4,0,0);
; тут любая пауза м.д. нажатием и отжатие клавиши - от 0 и больше.
Send (2,4,0,0);
Sleep, 50;

Используем 2 копии DLL (ниже код будем юзать во всех 2-х скриптах!!):


Send (1,4,0,0);
; тут любая пауза м.д. нажатием и отжатие клавиши - от 0 и больше.
Send (8,4,0,0); // тут отжимаю клавишу не кодом 2, а кодом 8
Sleep, 100;

Используем 3 копии DLL (ниже код будем юзать во всех 3-х скриптах!!):

Send (1,4,0,0);
; тут любая пауза м.д. нажатием и отжатие клавиши - от 0 и больше.
Send (8,4,0,0); // тут отжимаю клавишу не кодом 2, а кодом 8
Sleep, 150;


Dll-ку насиловать не будем, пусть остается лишь "передатчиком".


PS: Все эти доводы проверял на своей тачке - отрабатываемость 100%. Значения могут несколько отличаться в зависимости от Вашей конкретной системы. В любом случае Вы можете немножко поэкспериментировать и подстроить базовые паузы в скрипте под себя.

[DarkMaster]

все зашибись. только sleep видимо стал причиной возни с железкой, плюсами и может чем-то еще. У нас это wait - не смущай народ (IMG:style_emoticons/default/smile.gif)

и последний уже наверно вопрос: от чипа что-нибудь зависит в плане быстродействия? Там вроде ATMega8? Или это уже ограничения железа/ос?

[usb2kbd]

от чипа что-нибудь зависит в плане быстродействия?

Не думаю. Большинство микроконтроллеров ATMEL работает на стандартной частоте до 16Mhz и даже дело не в этом. Тут, скорее всего, ограничение в спецификации USB и именно HID USB клавиатуры как таковой. Но, согласитесь, навряд-ли человек сможет осознанно без ошибок набирать до 16 знаков в секунду, что умеет Usb2kbd. (IMG:style_emoticons/default/smile.gif)

Еще несколько заметок о запуске виртуалок с использованием одного девайса...

Насколько помню в Астере можно было указать раб места девайса через запятую.

Через запятую только звук можно, а вот мыши/клавы - только строгое одно место (проверял спецом ранее).

На виртуалках ты сам говорил, что прострел идет насквозь во все ОС.

Прострел с локальной машины в виртуальную vmware идет при условии открытого и активного окна этой виртуалки. Если окно не активно/свернуто - сколько в активной машине не жми - все пойдет только в локальную. Более того, из собственного опыта знаю, что при отправлении нажатия из локальной в ЛЮБУЮ виртуальную машину/rdp/team viewer - нажатие-то прийдет туда, но прийдет не настоящим, а сэмулированным. И тут получается теряется смысл usb2kbd, можно обойтись и стандартными средствами API windows. Т.е. отсылать девайсом с основной машины куда-то в виртуальные/rdp/team viewer - не вижу смысла. Исключение составляет, конечно, АСТЕР, где можно пробовать отсылать нажатия в бот-места с основного раб места (место №1 - почему читаем выше топик), быстро временно "пробрасывая" горячей клавишей usb2kbd в нужное нам бот-место (эта важная функция есть в "Астере").

Мое видение реализации схемы "основное и бот-места и один usb2kbd с использованием АСТЕРА":

Cтандартная уже разжеванная выше схема в АСТЕРЕ:

1. Осн раб место №1 с usb2kbd и управляющим uopilot (или любым другим ПО).
2. Бот-место №2 с uopilot, линягой
3. Бот-место №3 с uopilot, Wow

Допустим, uopilot с бот-места №2 хочет послать в свою линягу нажатие. Для этого он должен как-то сообщить об этом своем "желании" в основное место, где живет usb2kbd. Как?

Например, Метод №1 (предпочтительный мной) Uopilot с бот места №2 пишет в условленный файл (например с:\temp\2bot.txt) свое "желание" - код нажатия. Uopilot (или другое управляющее ПО) с основной машины постоянно проверяет этот файл, и если в нем что-то есть, то ПО должно последовательно 1) "пробросить" usb2kbd горячей клавишей в бот-место №2 2) послать в usb2kbd прочитанную клавишу из txt - она пойдет в бот-место №2, т.к. usb2kbd уже "проброшен" туда 3) очистить файл с:\temp\2bot.txt 3) Повторно возвратить usb2kbd назад в осн. тачку по горячей клавише Астера.

Другие методы вы можете придумать самостоятельно, все зависит от изощренности Вашей мысли: например, Uopilot передает "желание" по rdp/team viewer/radmin на основную тачку в режиме управления. Т.е. uopilot с линейкой, если захочет послать настоящие"нажатия в свою линейку делает следующее - 1) сделать активным окно team viewer/rdp/radmin 2) послать туда нужное нажатие. 3) на основной тачке как-то это нажатие "отловить", причем это нажатие должно также нести информацию о том, откуда оно поступило (бот-место №2) 4) дальше по схеме выше из Метода 1 .

Так что все возможно при наличии серого вещества и желания (IMG:style_emoticons/default/smile.gif)

Предположим, что что-то не удалось красиво распараллелить, то можно на каждое раб место прокинуть по девайсу. Как только меня ид на девайсине не понятно... шить?

Пара VID/PID только прошивается в девайс. Соответственно, если человек вздумает собрать 2 и более девайсов - то ему обязательно нужны девайсы с разными парами.

А вот Dll, как я писал выше, на сегодня может работать только с одной парой VID/PID. Вот сейчас займусь тем, что попробую вынести конфиг VID/PID из DLL в .ini файл. При вызове функции из DLL она считает ini файл и поймет, с какой парой ей работать. Естественно, ini файл можно править.

И еще раз напомню, друзья, использование usb2kbd будет обоснованно там и только там, где это действительно необходимо: Например,
цитата с сайта usb2kbd.info ------
- Автоматизация приложений Windows, когда другое программное обеспечение блокирует использование "эмулированных" нажатий;
конец цитаты-----------
Если в этом нет необходимости, пользуйтесь "старыми" схемами на API Windows.

Как-то так )

[DarkMaster]

Пара VID/PID только прошивается в девайс. Соответственно, если человек вздумает собрать 2 и более девайсов - то ему обязательно нужны девайсы с разными парами.

т.е. ты будешь шить ручками под заказ? Я к тому, что мне оно надо.

[DarkMaster]

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

[usb2kbd]

т.е. ты будешь шить ручками под заказ? Я к тому, что мне оно надо.

Да, в МК зашивается свободная пара и в ini для каждой DLL можно будет указать конкретную пару.

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

Можно, конечно, предположить, что защита со временем опуститься до того, что будет проверять VID/PID подключенных USB устройств и их блочить. Но а если "вдруг" устройство представится как, например, Logitech mouse/keyboard? Заблочив его, защита заблочит данные нормальные девайсы (клавиатуры и мыши logitech с данной парой) и у всех в мире - что вызовет бурю негодования, в общем так они делать не будут и не вправе.

Что я предлагаю: Изначально usb2kbd прошивается "свободной" общедоступной парой VID/PID, девайс будет полностью функционален, но с этой парой может быть использован только для "учебных" целей - это правило использования данной "свободной" пары VID/PID.

Для продвинутых пользователей usb2kbd может по желанию комплектоваться программатором usbasp (отдельная стоимость) или же без него - (можно самостоятельно заказать и купить в Китае). В следующем релизе usb2kbd я добавляю на девайс пины именно для этого программатора и любой пользователь сможет его "прошить" по несложной инструкции (имея девайс, программатор usbasp и инструкцию на сайте как шить от А до Я).

Ну, а умея "шить" девайс, все дороги открыты (IMG:style_emoticons/default/smile.gif)

[DarkMaster]

Но а если "вдруг" устройство представится как, например, Logitech mouse/keyboard? Заблочив его, защита заблочит данные нормальные девайсы (клавиатуры и мыши logitech с данной парой) и у всех в мире - что вызовет бурю негодования, в общем так они делать не будут и не вправе.

Согласно лицензионному соглашению по под винду не имеет права изменить или блокировать какие-либо части/программы/функции ос. По факту смотрим на л2 и понимаем, что виртуальная клавиатура заблокирована. Т.е. формально это нарушени ЛС. На это надеятся ну вообще не стоит. В данный должен быть либо рандомный набор набор либо реальные бренды и рандомные ид и какие-то еще индефикаторы. Так же не стоит под конкретную модель косить. Все это будет заблокировано легко и просто. Если что иннова с этого форума вообще не слазила. Есть еще один забавный пример. Есть ид торрентклиетов, накручивальщики счетчиков со стандартными наборами ид улетают сразу не смотря даже на очень быстрое и активное обновление этих ид.

Что я предлагаю: Изначально usb2kbd прошивается "свободной" общедоступной парой VID/PID, девайс будет полностью функционален, но с этой парой может быть использован только для "учебных" целей - это правило использования данной бесплатной пары VID/PID.

Простите, но это свинство. Да и выпускать заведомо примитивно детектируемый девайс, как минимум странно. Смысл девайса тогда в чем, если он улетит в бан листы со следующим же апдейтом?

Ну, а умея "шить" девайс, все дороги открыты

я не уверен в правильности открытой прошивки, т.к. это потенциально сильно увеличивает шанс детекта девайса.

Сообщение отредактировал DarkMaster - 3.2.2014, 15:42

[usb2kbd]

В данный должен быть либо рандомный набор набор либо реальные бренды и рандомные ид и какие-то еще индефикаторы. Так же не стоит под конкретную модель косить. Все это будет заблокировано легко и просто.

Ну вы хотите, прям универсальный девайс-трансформер-призрак-все-в-одном. Как говорилось в известном произведении "я не волшебник" (с). Я предлагаю инструмент, который что-то умеет + инструкцию, как его приспосабливать под разные нужды (разные пары), а нужды у всех разные. При этом не хочу и не могу нарушать правила "хорошего тона".

я не уверен в правильности открытой прошивки, т.к. это потенциально сильно увеличивает шанс детекта девайса.

Не путайте прошивку с исходным кодом, кто сказал что исходный код будет открытым? Даже если файл прошивки (.hex) будет открытым, он нигде в системе не фигурирует, это бинарный код, понятный только микроконтроллеру, да и притом не каждому, и никаких зацепок к алгоритму, имея его, защита иметь не будет.

Простите, но это свинство. Да и выпускать заведомо примитивно детектируемый девайс, как минимум странно. Смысл девайса тогда в чем, если он улетит в бан листы со следующим же апдейтом?

Это моя позиция и позиция сайта. А смысл кому-то получить девайс с каким-то "левым" ID, который все равно не будет возможности изменить в дальнейшем? Я же не буду при малейших изменениях в какой-то системе защиты слать новый девайс с новой прошивкой... Отсюда необходимость в программаторе за 4 бакса из Китая. Во-вторых, такой системы детекции еще нет и неизвестно, будет ли и когда.. Поэтому, пока есть - пользуемся....

Нельзя объять необъятное (с). Сколько будем живы, будут новые методы защиты. Так вот наша задача - оперативно адаптироваться под изменяющийся мир. И возможность самостоятельного залива прошивки (.hex) по несложной инструкции - выход.

Вы уж совсем хотите интегрировать "софт" и "железо", затирая м.д ними границы... но это не возможно, всегда будут определенные барьеры.