(dropping Tony and e3-hacking for now) Monday 14 December 2009 01:11:34 Janusz Krzysztofik wrote: > Hi Dmitry, > > Sunday 13 December 2009 00:20:03 Dmitry Torokhov napisał(a): > > atkbd is supposed to support PS/2 devices speaking AT keyboard protocol. > > We also do support such devices behind dumb controllers that do not > > allow querying the device but we expect those to at least produce the > > standard scancodes. > > As far as I can understand, using the atkbd driver is not a good idea in > this case because of the keyboard not producing standard scancodes, > correct? > > Isn't the hpps2atkbd.h provided keycode table an already supported way of > introducing exceptions to this standard scancodes requirement? Why couldn't > this method be reused here? > > What I am afraid of is if the driver supposed to be created instead > wouldn't require reiplementing most of the atkbd code. > > > I would need to know a bit more about the gamepad, but so far I still > > think that current attempot of creating intermediate serio module which > > allows to use atkbd driver is not the proper solution. > > I modified the serio driver to send exactly what it gets from the buffer > and examined its output with serio_raw. The gamepad (can be connected > simultaneously) appeared to send exactly the same scancodes as the keyboard > did. I couldn't see how those might be destinguished whether coming from > the keybord or from the gamepad. Thus, handling them both together as a > single device would probably be the only option here. > > With both devices connected and keys pressed simultaneously, errors occure > at the lowest level: parity check failed, invalid stop bit, etc. I don't > think it would be possible to do anything about this. But this also means > that trying to query them in order to get a sensible response would > probably be not reliable. > > Any thoughts? > > Thanks, > Janusz Hi Dmitry, You probably missed my last message. Meanwhile, I've connected the Amstrad Delta keyboard to a PC. I can confirm it speaks PS/2 protocol and is automatically detected by atkbd/i8042 drivers. The initial handshake sequence actually looks exactly the same as that of a standard AT keyboard. The problem persists about different scancodes, giving wrong keystrokes. OTOH, the Amstrad Delta gamepad seems simplified. Connected alone to a PC, works as well but only when i8042.dumbkbd is set. However, when both devices are connected in parallel, initial keyboard handshake allows for both being used (not simultaneously) in default 2-way i8042 mode. Resuming, if there were a boot/module option to atkbd allowing for non-default scancode table, or another similiar possibility, both devices would work with a PC using exsisting drivers. Even if the chance of anyone using this tiny keyboard with a PC is rather low, do you still suggest that creating a new, standalone keyboard driver for it is a good idea? Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
