As long as I remember V-USB works well when PS/2 singnal is handled by hardware USART of AVR.
V-USB can block 50us at max and this prevents from handling PS/2 signal with ISR of pin interrupt(on falling edge). This is reason why hardware USART is needed for V-USB.
Thank you! That is very helpful. Most projects regarding V-USB just implement a small, partial keyboard or a mouse and don't provide enough information about its limitations.
My intention is to build a keyboard with trackpoint, additional PS/2 mouse and a KM switch that allows to connect all this to two diffrent computers without having to reconnect after each switch. As I (or rather QMK or TMK) will have to do some processing anyway (reading keyboard matrix, perhaps applying some minor modifications to keyboard actions, reading two PS/2 lines and merging them into one mouse), the input for the microcontroller(s) that control(s) the USB port doesn't have to be PS/2 - won't fit directly into the protocol either as it'll have to include keyboard actions (press/release key; LED control is probably less important) and mouse movement packages.
The job of the microcontroller with V-USB would be to simulate a (mostly) idle keyboard and mouse for the computer it's connected to and to process and forward keypresses and mouse movement that are passed on to it from another microcontroller (perhaps a teensy?).
Hope I won't run out of ports there...hardware ports seem to be quite limited in their amount, even in larger AVRs. Scanning keyboard matrix, reading two ps/2 ports, serving hardware USB and passing on information to the USART of the V-USB controlled other microcontroller - not *that* stressful for a microcontroller, but if it runs out of timers or other ressources...
I've also taken a look at the ATmega32u4 found on some Arduino boards. At first that looked very promising - AVR that can do hardware USB *and* is sold soldered on a tiny board with accessible pins (SMD soldering is far beyound my skill level) - but it seems it can handle only 6 USB endpoints (3 pairs of in/out). Two endpoints are taken up for general USB control; two more are used by the Arduino hard/software for programming the chip and talking to it - so there isn't enough left for controlling a keyboard and a mouse at the same time if I understand that right.
You can build firmware for V-USB with 'make -f Makefile.vusb' and I think it still works.
TMK firmware is rather big in terms of flash size, it requires 16KB at least by default configuration. I tested it on ATMega168 and ATmega328 years ago. You will have to disable many features and rewrite some code to use it on ATtiny with small flash.
Yes, those ATtiny seem to be pretty small, but I don't have to go that small. Most important is that it can be soldered and programmed without too much hassle. TMK seems to be written in C without using the Arduino libraries - that ought to help a lot already. And it looks very intresting. I think I'll have to dig deeper into TMK.
