Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
Date: Wed, 24 Mar 2010 09:16:04 -0700	[thread overview]
Message-ID: <20100324161604.GA6338@core.coreip.homeip.net> (raw)
In-Reply-To: <201003222207.48707.jkrzyszt@tis.icnet.pl>

On Mon, Mar 22, 2010 at 10:07:47PM +0100, Janusz Krzysztofik wrote:
> (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,
> 

Hi Janusz,

> 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.

OK, since the device really speaks PS/2 protocol I withdraw my objection
of using serio + atkbd combo, however we should not be doing translation
in serio.

> The problem persists about different scancodes, giving 
> wrong keystrokes.

This can be dealt with from userspace by loading correct keymap.

> 
> 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.

You can train UDEV to load proper keymap. What does teh device report as
'version' in sysfs (output of 'cat
/sys/bus/serio/devices/serio0/input/input3/id/bustype', please adjust
serioX and inputX to match yours)?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html