* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
@ 2009-12-11 2:36 Dmitry Torokhov
2009-12-11 3:09 ` Janusz Krzysztofik
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Torokhov @ 2009-12-11 2:36 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: linux-input, linux-omap, Tony Lindgren
On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote:
> +
> +/*
> + * This table converts the amstrad mailboard scancodes to normal PC-
> AT scancodes
> + * The diagram below shows the amstrad keyboard, with the raw
> scancodes
> + *
> + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A)
> (1C) (15)
> + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D]
> [0:75][ 6C]
> + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |
> return|
> + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B]
> | 2C|
> + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E]
> [ 55]
> + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E]
> [ 09]
> + *
> + * These scancodes are then translated to AT scancodes using the
> following table
> + * The amstrad keyboard does not produce any extended scancodes,
> but we need to
> + * translate some amstrad scancodes to a AT extended scancode,
> hence the 16bit
> + * value for the translated scancode
> + *
No, please write a proper keyboard driver instead of creating this
Frankenstain monster. It is not a generic serio-style data source so it
should not use serio, should reside in drivers/input/keyboard and create
input device by itself.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-11 2:36 [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port Dmitry Torokhov
@ 2009-12-11 3:09 ` Janusz Krzysztofik
2009-12-11 8:01 ` Dmitry Torokhov
0 siblings, 1 reply; 14+ messages in thread
From: Janusz Krzysztofik @ 2009-12-11 3:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-omap, Tony Lindgren, e3-hacking
Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a):
> On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote:
> > +
> > +/*
> > + * This table converts the amstrad mailboard scancodes to normal PC-
> > AT scancodes
> > + * The diagram below shows the amstrad keyboard, with the raw
> > scancodes
> > + *
> > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A)
> > (1C) (15)
> > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D]
> > [0:75][ 6C]
> > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |
> > return|
> > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B]
> >
> > | 2C|
> >
> > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E]
> > [ 55]
> > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E]
> > [ 09]
> > + *
> > + * These scancodes are then translated to AT scancodes using the
> > following table
> > + * The amstrad keyboard does not produce any extended scancodes,
> > but we need to
> > + * translate some amstrad scancodes to a AT extended scancode,
> > hence the 16bit
> > + * value for the translated scancode
> > + *
>
> No, please write a proper keyboard driver instead of creating this
> Frankenstain monster. It is not a generic serio-style data source so it
> should not use serio, should reside in drivers/input/keyboard and create
> input device by itself.
>
> Thanks.
Hi Dmitry,
Thanks for your opinion.
Lack of support for Amstrad Delta external keybord is not a problem for me,
since I use the machine as an IP phone, not a network terminal. I just
thought it would be nice for other users to have this old but perfectly
working driver integrated into the mainline. But if it is that bad as you
say, I have no problem with dropping it.
I'll see if I'm able to create a proper driver myself when I find some spare
time.
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-11 3:09 ` Janusz Krzysztofik
@ 2009-12-11 8:01 ` Dmitry Torokhov
2009-12-12 20:34 ` Janusz Krzysztofik
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Torokhov @ 2009-12-11 8:01 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: linux-input, linux-omap, Tony Lindgren, e3-hacking
On Fri, Dec 11, 2009 at 04:09:58AM +0100, Janusz Krzysztofik wrote:
> Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a):
> > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote:
> > > +
> > > +/*
> > > + * This table converts the amstrad mailboard scancodes to normal PC-
> > > AT scancodes
> > > + * The diagram below shows the amstrad keyboard, with the raw
> > > scancodes
> > > + *
> > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A)
> > > (1C) (15)
> > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D]
> > > [0:75][ 6C]
> > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |
> > > return|
> > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B]
> > >
> > > | 2C|
> > >
> > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E]
> > > [ 55]
> > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E]
> > > [ 09]
> > > + *
> > > + * These scancodes are then translated to AT scancodes using the
> > > following table
> > > + * The amstrad keyboard does not produce any extended scancodes,
> > > but we need to
> > > + * translate some amstrad scancodes to a AT extended scancode,
> > > hence the 16bit
> > > + * value for the translated scancode
> > > + *
> >
> > No, please write a proper keyboard driver instead of creating this
> > Frankenstain monster. It is not a generic serio-style data source so it
> > should not use serio, should reside in drivers/input/keyboard and create
> > input device by itself.
> >
> > Thanks.
>
> Hi Dmitry,
>
> Thanks for your opinion.
>
> Lack of support for Amstrad Delta external keybord is not a problem for me,
> since I use the machine as an IP phone, not a network terminal. I just
> thought it would be nice for other users to have this old but perfectly
> working driver integrated into the mainline. But if it is that bad as you
> say, I have no problem with dropping it.
>
> I'll see if I'm able to create a proper driver myself when I find some spare
> time.
Yes, that would be great, thank you. In fact it should end up about the
same as this driver, except instead of creating and registering serio
port you will need to register input_dev structure and instead of
translating into atkbd scancodes you need to translate directly into
Linux keycodes (KEY_A, KEY_1 and so on).
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-11 8:01 ` Dmitry Torokhov
@ 2009-12-12 20:34 ` Janusz Krzysztofik
2009-12-12 23:20 ` Dmitry Torokhov
0 siblings, 1 reply; 14+ messages in thread
From: Janusz Krzysztofik @ 2009-12-12 20:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Tony Lindgren, e3-hacking, linux-omap, linux-input
Friday 11 December 2009 09:01:28 Dmitry Torokhov napisał(a):
> On Fri, Dec 11, 2009 at 04:09:58AM +0100, Janusz Krzysztofik wrote:
> > Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a):
> > > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote:
> > > > +
> > > > +/*
> > > > + * This table converts the amstrad mailboard scancodes to normal PC-
> > > > AT scancodes
> > > > + * The diagram below shows the amstrad keyboard, with the raw
> > > > scancodes
> > > > + *
> > > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A)
> > > > (1C) (15)
> > > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D]
> > > > [0:75][ 6C]
> > > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |
> > > > return|
> > > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B]
> > > >
> > > > | 2C|
> > > >
> > > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E]
> > > > [ 55]
> > > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E]
> > > > [ 09]
> > > > + *
> > > > + * These scancodes are then translated to AT scancodes using the
> > > > following table
> > > > + * The amstrad keyboard does not produce any extended scancodes,
> > > > but we need to
> > > > + * translate some amstrad scancodes to a AT extended scancode,
> > > > hence the 16bit
> > > > + * value for the translated scancode
> > > > + *
> > >
> > > No, please write a proper keyboard driver instead of creating this
> > > Frankenstain monster. It is not a generic serio-style data source so it
> > > should not use serio, should reside in drivers/input/keyboard and
> > > create input device by itself.
> >
> > I'll see if I'm able to create a proper driver myself when I find some
> > spare time.
>
> Yes, that would be great, thank you. In fact it should end up about the
> same as this driver, except instead of creating and registering serio
> port you will need to register input_dev structure and instead of
> translating into atkbd scancodes you need to translate directly into
> Linux keycodes (KEY_A, KEY_1 and so on).
Dmitry,
Thanks for your directions. However, before I get to work, please let me still
better understand what I am really supposed to create here, and why you think
it should be done one way and not the other. I'd rather avoid submitting an
input related code that you might find not adequate in the future.
First, I have never submitted a single line of code that would be accepted for
inclusion into drivers/input before. Could you please recommend a
documentation for me to read, from where I could learn what a proper keyboard
driver should look like, and what kind of devices can be considered as generic
serio-style data sources and what can't, and more? Or should I better give up
being that short of required knowledge?
Moreover, please have a look at these two messages posted by Cliff Lawson, who
worked for Amstrad while the E3 (codename Delta) was being developed, being
involved in that development:
http://www.earth.li/pipermail/e3-hacking/2006-April/000445.html
http://www.earth.li/pipermail/e3-hacking/2006-April/000449.html
As one can read, the Amstrad Delta keyboard was described by Cliff as a PS/2
device, even if not connected to a regular PS/2 port but some MPU GPIO lines
directly instead.
Furthermore, it has been proven by Matt Callow, who created the serio driver
you didn't like, that the atkbd keyboard driver already works fine for this
keyboard if fed with scancodes matching what it is told to expect.
Please also note that the E3 keyboard port is supposed to be used not only for
getting input from the keyboard, but from a bundled gamepad as well. Not yet
supported, but who knows if forever.
That said, do you still think there is a need to create a new, separate
keyboard driver for the device in question? Isn't reusing an existing, proven
to be working correctly, keyboard driver module, isn't it a good solution
here? If not, could you please elaborate on why it's not? I always thought
that being PS/2 compatible is enough for a device to be considered as
supported by atkbd, but maybe I just don't understand what the atkbd driver is
designed for and what a supported device should look like.
Moreover, isn't a port, that is supposed to interact with at least two
distinct input devices, isn't it worth of creating a separate driver for it,
be it serio module or anything else that would better match the input subsystem
design?
In your initial answer, you quoted a part of the patch, namely that containing
a description of the driver's scancode translation functionality. I guess you
tried to say that traslating scancodes inside a port driver is wrong. I would
agree with that, without any reservations.
But for your other conclusions, could you please reconsider if still valid,
and elaborate on them if you think they are?
Thanks,
Janusz
PS. To be honest, I have to inform every E3 hacker still interrested in
testing the driver, even if already NAKed upstream, that I happened to fail
with testing the final, submitted version of this particular patch from the
series. I tested everything, patch by patch, after splitting the initial one
into several distinct and then after cleaning them up one by one, but
unfortunatelly missed testing this one after being cleaned up finally. As a
result, it doesn't build. Please use the extra patch below, applied over the
series, if interrested in testing the driver in it's current form. I'm sorry
for that.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
diff -upr git.orig/arch/arm/mach-omap1/include/mach/ams-delta-fiq.h git/arch/arm/mach-omap1/include/mach/ams-delta-fiq.h
--- git.orig/arch/arm/mach-omap1/include/mach/ams-delta-fiq.h 2009-12-11 18:19:19.000000000 +0100
+++ git/arch/arm/mach-omap1/include/mach/ams-delta-fiq.h 2009-12-11 19:19:04.000000000 +0100
@@ -51,6 +51,7 @@
#define FIQ_CIRC_BUFF 30 /*Start of circular buffer */
+extern unsigned int fiq_buffer[];
extern unsigned char qwerty_fiqin_start, qwerty_fiqin_end;
extern void __init ams_delta_init_fiq(void);
diff -upr git.orig/drivers/input/serio/ams_delta_keyboard.c git/drivers/input/serio/ams_delta_keyboard.c
--- git.orig/drivers/input/serio/ams_delta_keyboard.c 2009-12-11 18:19:19.000000000 +0100
+++ git/drivers/input/serio/ams_delta_keyboard.c 2009-12-11 19:23:48.000000000 +0100
@@ -223,7 +223,7 @@ gpio_data:
serio:
kfree(ams_delta_kbd_port);
err:
- return retval;
+ return err;
}
module_init(ams_delta_kbd_init);
_______________________________________________
e3-hacking mailing list
e3-hacking@earth.li
http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-12 20:34 ` Janusz Krzysztofik
@ 2009-12-12 23:20 ` Dmitry Torokhov
2009-12-14 0:11 ` Janusz Krzysztofik
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Torokhov @ 2009-12-12 23:20 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: linux-input, linux-omap, Tony Lindgren, e3-hacking
Hi Janusz,
On Sat, Dec 12, 2009 at 09:34:07PM +0100, Janusz Krzysztofik wrote:
> Friday 11 December 2009 09:01:28 Dmitry Torokhov napisał(a):
> > On Fri, Dec 11, 2009 at 04:09:58AM +0100, Janusz Krzysztofik wrote:
> > > Friday 11 December 2009 03:36:58 Dmitry Torokhov napisał(a):
> > > > On Thu, Dec 10, 2009 at 09:07:50PM +0100, Janusz Krzysztofik wrote:
> > > > > +
> > > > > +/*
> > > > > + * This table converts the amstrad mailboard scancodes to normal PC-
> > > > > AT scancodes
> > > > > + * The diagram below shows the amstrad keyboard, with the raw
> > > > > scancodes
> > > > > + *
> > > > > + * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A)
> > > > > (1C) (15)
> > > > > + * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D]
> > > > > [0:75][ 6C]
> > > > > + * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |
> > > > > return|
> > > > > + * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B]
> > > > >
> > > > > | 2C|
> > > > >
> > > > > + * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E]
> > > > > [ 55]
> > > > > + * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E]
> > > > > [ 09]
> > > > > + *
> > > > > + * These scancodes are then translated to AT scancodes using the
> > > > > following table
> > > > > + * The amstrad keyboard does not produce any extended scancodes,
> > > > > but we need to
> > > > > + * translate some amstrad scancodes to a AT extended scancode,
> > > > > hence the 16bit
> > > > > + * value for the translated scancode
> > > > > + *
> > > >
> > > > No, please write a proper keyboard driver instead of creating this
> > > > Frankenstain monster. It is not a generic serio-style data source so it
> > > > should not use serio, should reside in drivers/input/keyboard and
> > > > create input device by itself.
> > >
> > > I'll see if I'm able to create a proper driver myself when I find some
> > > spare time.
> >
> > Yes, that would be great, thank you. In fact it should end up about the
> > same as this driver, except instead of creating and registering serio
> > port you will need to register input_dev structure and instead of
> > translating into atkbd scancodes you need to translate directly into
> > Linux keycodes (KEY_A, KEY_1 and so on).
>
> Dmitry,
>
> Thanks for your directions. However, before I get to work, please let me still
> better understand what I am really supposed to create here, and why you think
> it should be done one way and not the other. I'd rather avoid submitting an
> input related code that you might find not adequate in the future.
>
> First, I have never submitted a single line of code that would be accepted for
> inclusion into drivers/input before. Could you please recommend a
> documentation for me to read, from where I could learn what a proper keyboard
> driver should look like,
I guess I meant "proper keyboard driver" in the sense of a driver that
creates and registeres its own input_dev and perform direct translation
of data coming form hardware into linux input events.
> and what kind of devices can be considered as generic
> serio-style data sources and what can't, and more?
If a same device can be used on different platforms and several devices
may use the same port then I can see the need of creating a serio
abstraction. But if tere is 1:1 relationship then a driver that attaches
directly to the hardware might make sense.
> Or should I better give up
> being that short of required knowledge?
>
> Moreover, please have a look at these two messages posted by Cliff Lawson, who
> worked for Amstrad while the E3 (codename Delta) was being developed, being
> involved in that development:
>
> http://www.earth.li/pipermail/e3-hacking/2006-April/000445.html
> http://www.earth.li/pipermail/e3-hacking/2006-April/000449.html
>
> As one can read, the Amstrad Delta keyboard was described by Cliff as a PS/2
> device, even if not connected to a regular PS/2 port but some MPU GPIO lines
> directly instead.
>
> Furthermore, it has been proven by Matt Callow, who created the serio driver
> you didn't like, that the atkbd keyboard driver already works fine for this
> keyboard if fed with scancodes matching what it is told to expect.
Of course atkbd would work fine if it is fed the data it expects. The
same can be said for any driver in the tree, isn't it? It is possible
to write HID-to-atkbd or "gpio matrix to atkbd" "serios" but that does
not mean it is the right thing to do.
>
> Please also note that the E3 keyboard port is supposed to be used not only for
> getting input from the keyboard, but from a bundled gamepad as well. Not yet
> supported, but who knows if forever.
Can they be used simultaneously? Would not the translation that you
perform right now cause issues with the gamepad? Are you thinking about
reusing one of the existing gamepad modules in the same fashion as you
do for atkbd but translating the data into its native format?
>
> That said, do you still think there is a need to create a new, separate
> keyboard driver for the device in question? Isn't reusing an existing, proven
> to be working correctly, keyboard driver module, isn't it a good solution
> here? If not, could you please elaborate on why it's not? I always thought
> that being PS/2 compatible is enough for a device to be considered as
> supported by atkbd, but maybe I just don't understand what the atkbd driver is
> designed for and what a supported device should look like.
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.
>
> Moreover, isn't a port, that is supposed to interact with at least two
> distinct input devices, isn't it worth of creating a separate driver for it,
> be it serio module or anything else that would better match the input subsystem
> design?
Yes, if there can be several devices connected to it then it makes sense
to create a port abstraction for different drivers to plug into.
>
> In your initial answer, you quoted a part of the patch, namely that containing
> a description of the driver's scancode translation functionality. I guess you
> tried to say that traslating scancodes inside a port driver is wrong. I would
> agree with that, without any reservations.
Yes, exactly.
>
> But for your other conclusions, could you please reconsider if still valid,
> and elaborate on them if you think they are?
>
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.
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-12 23:20 ` Dmitry Torokhov
@ 2009-12-14 0:11 ` Janusz Krzysztofik
2009-12-17 15:36 ` [RFC][PATCH 4/5] input: serio: add support forAmstrad " witek mark
2010-03-22 21:07 ` [RFC][PATCH 4/5] input: serio: add support for Amstrad " Janusz Krzysztofik
0 siblings, 2 replies; 14+ messages in thread
From: Janusz Krzysztofik @ 2009-12-14 0:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Tony Lindgren, e3-hacking, linux-omap, linux-input
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
_______________________________________________
e3-hacking mailing list
e3-hacking@earth.li
http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support forAmstrad Delta serial keyboard port
2009-12-14 0:11 ` Janusz Krzysztofik
@ 2009-12-17 15:36 ` witek mark
2009-12-17 16:37 ` [RFC][PATCH 4/5] input: serio: add supportforAmstrad " witek mark
2010-03-22 21:07 ` [RFC][PATCH 4/5] input: serio: add support for Amstrad " Janusz Krzysztofik
1 sibling, 1 reply; 14+ messages in thread
From: witek mark @ 2009-12-17 15:36 UTC (permalink / raw)
To: jkrzyszt
Cc: Tony Lindgren, linux-input, e3-hacking, Dmitry Torokhov, linux-omap
Witam,
Od jakiegoś czasu obserwuję grupę dyskusyjną Amstrada. Sam posiadam
jeden egzemplarz i coś tam sobie na nim próbuję uruchomić.
Chciałem się podzielić kilkoma spostrzeżeniami dotyczącymi klawiatury.
Na razie nie odpisuję na grupę tylko do Pana.
Zaintrygowany mailem dotyczącym klawiatury postanowiłem ją rozkręcić aby
zobaczyć co w środku jest. Okazuje się, że płytka klawiatury jest
"przyspawana" do jednej ze stron obudowy. Trzeba by wyłamać parę
zatrzasków, żeby obejrzeć te stronę płytki drukowanej, gdzie są
rozmieszczone elementy - dlatego na razie dałem sobie z tym spokój. Idąc
dalej rozkręciłem tego gamepada. Jak się ponadto okazuje ten gamepad
wpina się między amstrada a klawiaturę. Klawiatura i gamepad mają
interfejs złożony z czterech pinów i po sprawdzeniu miernikiem okazuję
się, że klawiatura i gamepad jeśli się je połączy razem do amstrada to
są one podłączone równolegle do tych pinów (jestem tego pewien na 90%).
Ponadto po rozkręceniu gamepada ukazała mi się płytka drukowana ale
niestety nie wiem co to jest za chip elektroniczny w środku, gdyż ma on
postać "czarnego okrągłego kleksa plastikowego" (szkoda, że nie zrobiłem
zdjęcia). Jedno jest pewne: na tej płytce te cztery piny interfejsu były
opisane jako GND, VCC, CLK i DATA. Czyli wnioskując musi to być jakiś
interfejs szeregowy. Ponadto wiemy już, że klawiatura i gamepad są
podłączane równolegle do amstrada, czyli musi to być interfejs
szeregowy, który niejako "wspiera" połączenie kilku urządzeń do jednej
magistrali.
Może to jest zwykły interfejs szeregowy typu rs232?
Załóżmy na chwilkę, że jest to interfejs rs232. Możemy wtedy stwierdzić,
że:
a) klawiatura generuje jakiś zestaw kodów klawiszy,
b) gamepad generuje ten sam zestaw kodów klawiszy - może i tak być,
wtedy gamepad zachowuje się jako "specjalna klawiatura na potrzeby gier"
i tak naprawdę można powiedzieć że na amstradzie gra się na klawiaturze
a gamepad tylko ułatwia "wciskanie guzików",
c) pisze Pan, że jeśli gamepad i klawiatura są podłączone jednocześnie i
jednocześnie cos na nich naciskamy to obserwuje Pan w sterowniku błędy
typu: parity check failed, invalid stop bit. O ile moja znajomość
protokołów transmisji jest dobra, to wychodzi na to, że te błędy
występują właśnie w transmisji szeregowej rs232 (chyba, że jest jakiś
inny podobny protokół transmisji). O ile naciska Pan przycisk tylko na
jednym urządzeniu to wszystko jest w porządku; urządzenie wysyła np kod
klawisza, a interfejs szeregowy dodaje jeszcze bity parzystości
(kontrola błędów) i stopu. Jeśli teraz zaczniemy coś naciskać na drugim
urządzeniu to ono również wysyła swój kod błędu, bity parzystości i bity
stopu. Wtedy może dochodzić np do kolizji (klawiatura wysyła w danym
momencie bit stopu a gamepad wysyła swój kod klawisza) i port szeregowy
w amstradzie "głupieje" i zgłasza błędy typu parity check failed,
invalid stop bit). Generalnie w porcie szeregowym typu rs232 można
podłączyć kilka urządzeń równolegle, tylko jak przynajmniej dwa zaczną
nadawać w tej samej chwili to zaczynają się kolizje.
W sterownikach linuxa nie jestem za mocny dlatego nie mam pojęcia jak
jest napisany dotychczasowy driver. Gdybym miał oscyloskop to bym
sprawdził komunikację na tych pinach i by się okazało czy to jest
rzeczywiście transmisja typu rs232.
Co Pan myśli o moich tezach? A mogę dostać Pańskie logi ze sterownika?
Może coś uda się wymyślić.
pozdrawiam
Witold Markowski
Dnia 14-12-2009 o godz. 1:11 Janusz Krzysztofik napisał(a):
> 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
>
> _______________________________________________
> e3-hacking mailing list
> e3-hacking@earth.li
> http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
----------------------------------------------------
Kołodziej będzie miażdżył na ringu
18 grudnia, Gala Boksu w Łodzi
Zobacz:
http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fwojak18grudnia.html&sid=926
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add supportforAmstrad Delta serial keyboard port
2009-12-17 15:36 ` [RFC][PATCH 4/5] input: serio: add support forAmstrad " witek mark
@ 2009-12-17 16:37 ` witek mark
0 siblings, 0 replies; 14+ messages in thread
From: witek mark @ 2009-12-17 16:37 UTC (permalink / raw)
Cc: e3-hacking, Tony Lindgren, Dmitry Torokhov, linux-input, linux-omap
I'm sorry for my latest mail written in Polish. I wanted to consult some
amstrad keyboard thing with Janusz Krzysztofik. I accidently put to many
recipients.
regards
Witold Markowski
Dnia 17-12-2009 o godz. 16:36 witek mark napisał(a):
> Witam,
>
>
> Od jakiegoś czasu obserwuję grupę dyskusyjną Amstrada. Sam posiadam
> jeden egzemplarz i coś tam sobie na nim próbuję uruchomić.
> Chciałem się podzielić kilkoma spostrzeżeniami dotyczącymi klawiatury.
> Na razie nie odpisuję na grupę tylko do Pana.
>
> Zaintrygowany mailem dotyczącym klawiatury postanowiłem ją rozkręcić aby
> zobaczyć co w środku jest. Okazuje się, że płytka klawiatury jest
> "przyspawana" do jednej ze stron obudowy. Trzeba by wyłamać parę
> zatrzasków, żeby obejrzeć te stronę płytki drukowanej, gdzie są
> rozmieszczone elementy - dlatego na razie dałem sobie z tym spokój. Idąc
> dalej rozkręciłem tego gamepada. Jak się ponadto okazuje ten gamepad
> wpina się między amstrada a klawiaturę. Klawiatura i gamepad mają
> interfejs złożony z czterech pinów i po sprawdzeniu miernikiem okazuję
> się, że klawiatura i gamepad jeśli się je połączy razem do amstrada to
> są one podłączone równolegle do tych pinów (jestem tego pewien na 90%).
> Ponadto po rozkręceniu gamepada ukazała mi się płytka drukowana ale
> niestety nie wiem co to jest za chip elektroniczny w środku, gdyż ma on
> postać "czarnego okrągłego kleksa plastikowego" (szkoda, że nie zrobiłem
> zdjęcia). Jedno jest pewne: na tej płytce te cztery piny interfejsu były
> opisane jako GND, VCC, CLK i DATA. Czyli wnioskując musi to być jakiś
> interfejs szeregowy. Ponadto wiemy już, że klawiatura i gamepad są
> podłączane równolegle do amstrada, czyli musi to być interfejs
> szeregowy, który niejako "wspiera" połączenie kilku urządzeń do jednej
> magistrali.
> Może to jest zwykły interfejs szeregowy typu rs232?
> Załóżmy na chwilkę, że jest to interfejs rs232. Możemy wtedy stwierdzić,
> że:
> a) klawiatura generuje jakiś zestaw kodów klawiszy,
> b) gamepad generuje ten sam zestaw kodów klawiszy - może i tak być,
> wtedy gamepad zachowuje się jako "specjalna klawiatura na potrzeby gier"
> i tak naprawdę można powiedzieć że na amstradzie gra się na klawiaturze
> a gamepad tylko ułatwia "wciskanie guzików",
> c) pisze Pan, że jeśli gamepad i klawiatura są podłączone jednocześnie i
> jednocześnie cos na nich naciskamy to obserwuje Pan w sterowniku błędy
> typu: parity check failed, invalid stop bit. O ile moja znajomość
> protokołów transmisji jest dobra, to wychodzi na to, że te błędy
> występują właśnie w transmisji szeregowej rs232 (chyba, że jest jakiś
> inny podobny protokół transmisji). O ile naciska Pan przycisk tylko na
> jednym urządzeniu to wszystko jest w porządku; urządzenie wysyła np kod
> klawisza, a interfejs szeregowy dodaje jeszcze bity parzystości
> (kontrola błędów) i stopu. Jeśli teraz zaczniemy coś naciskać na drugim
> urządzeniu to ono również wysyła swój kod błędu, bity parzystości i bity
> stopu. Wtedy może dochodzić np do kolizji (klawiatura wysyła w danym
> momencie bit stopu a gamepad wysyła swój kod klawisza) i port szeregowy
> w amstradzie "głupieje" i zgłasza błędy typu parity check failed,
> invalid stop bit). Generalnie w porcie szeregowym typu rs232 można
> podłączyć kilka urządzeń równolegle, tylko jak przynajmniej dwa zaczną
> nadawać w tej samej chwili to zaczynają się kolizje.
>
> W sterownikach linuxa nie jestem za mocny dlatego nie mam pojęcia jak
> jest napisany dotychczasowy driver. Gdybym miał oscyloskop to bym
> sprawdził komunikację na tych pinach i by się okazało czy to jest
> rzeczywiście transmisja typu rs232.
>
>
> Co Pan myśli o moich tezach? A mogę dostać Pańskie logi ze sterownika?
> Może coś uda się wymyślić.
>
>
> pozdrawiam
>
>
> Witold Markowski
>
>
>
>
>
>
>
>
>
> Dnia 14-12-2009 o godz. 1:11 Janusz Krzysztofik napisał(a):
> > 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
> >
> > _______________________________________________
> > e3-hacking mailing list
> > e3-hacking@earth.li
> > http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
>
> ----------------------------------------------------
> Kołodziej będzie miażdżył na ringu
> 18 grudnia, Gala Boksu w Łodzi
> Zobacz:
> http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fwojak18grudnia.html&sid=926
>
>
>
> _______________________________________________
> e3-hacking mailing list
> e3-hacking@earth.li
> http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
----------------------------------------------------
Podniebny prezent świąteczny
Niepowtarzalny, dla każdego
Ekspresowa dostawa
Sprawdź: http://klik.wp.pl/?adr=www.skacz.pl&sid=933
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-14 0:11 ` Janusz Krzysztofik
2009-12-17 15:36 ` [RFC][PATCH 4/5] input: serio: add support forAmstrad " witek mark
@ 2010-03-22 21:07 ` Janusz Krzysztofik
2010-03-24 16:16 ` Dmitry Torokhov
1 sibling, 1 reply; 14+ messages in thread
From: Janusz Krzysztofik @ 2010-03-22 21:07 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-omap
(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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2010-03-22 21:07 ` [RFC][PATCH 4/5] input: serio: add support for Amstrad " Janusz Krzysztofik
@ 2010-03-24 16:16 ` Dmitry Torokhov
2010-03-24 21:21 ` Janusz Krzysztofik
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Torokhov @ 2010-03-24 16:16 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: linux-input, linux-omap
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2010-03-24 16:16 ` Dmitry Torokhov
@ 2010-03-24 21:21 ` Janusz Krzysztofik
2010-03-24 21:29 ` Dmitry Torokhov
0 siblings, 1 reply; 14+ messages in thread
From: Janusz Krzysztofik @ 2010-03-24 21:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-omap
Hi Dmitry,
Wednesday 24 March 2010 17:16:04 Dmitry Torokhov wrote:
> On Mon, Mar 22, 2010 at 10:07:47PM +0100, Janusz Krzysztofik wrote:
> >
> > 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.
Sure, thank you.
> > The problem persists about different scancodes, giving
> > wrong keystrokes.
>
> This can be dealt with from userspace by loading correct keymap.
Sounds acceptable. I hope the machine's built-in matrix keypad won't be
affected.
> > 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)?
When connected to a PC over a real 2-way i8042 port, the device identifies
itself as:
# grep '' /sys/bus/serio/devices/serio0/input/input2/id/*
/sys/bus/serio/devices/serio0/input/input2/id/bustype:0011
/sys/bus/serio/devices/serio0/input/input2/id/product:0001
/sys/bus/serio/devices/serio0/input/input2/id/vendor:0001
/sys/bus/serio/devices/serio0/input/input2/id/version:ab41
#
Unfortunatelly, it looks exactly the same as my standard AT keyboard.
Can you imagine any other possible way of distinguishing them?
Thanks,
Janusz
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2010-03-24 21:21 ` Janusz Krzysztofik
@ 2010-03-24 21:29 ` Dmitry Torokhov
2010-03-25 13:58 ` Janusz Krzysztofik
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Torokhov @ 2010-03-24 21:29 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: linux-input, linux-omap
On Wednesday 24 March 2010 02:21:22 pm Janusz Krzysztofik wrote:
> Hi Dmitry,
>
> Wednesday 24 March 2010 17:16:04 Dmitry Torokhov wrote:
> > On Mon, Mar 22, 2010 at 10:07:47PM +0100, Janusz Krzysztofik wrote:
> > > 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.
>
> Sure, thank you.
>
> > > The problem persists about different scancodes, giving
> > > wrong keystrokes.
> >
> > This can be dealt with from userspace by loading correct keymap.
>
> Sounds acceptable. I hope the machine's built-in matrix keypad won't be
> affected.
>
The scan code to key code mapping is per-device so it should not.
> > > 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)?
>
> When connected to a PC over a real 2-way i8042 port, the device identifies
> itself as:
>
> # grep '' /sys/bus/serio/devices/serio0/input/input2/id/*
> /sys/bus/serio/devices/serio0/input/input2/id/bustype:0011
> /sys/bus/serio/devices/serio0/input/input2/id/product:0001
> /sys/bus/serio/devices/serio0/input/input2/id/vendor:0001
> /sys/bus/serio/devices/serio0/input/input2/id/version:ab41
> #
>
> Unfortunatelly, it looks exactly the same as my standard AT keyboard.
>
:(
> Can you imagine any other possible way of distinguishing them?
Not automatically. I mean we could assume that if we see AT keyboard on
E3 we'd need special keymap but user would have to override if he
connects a regular one.
--
Dmitry
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2010-03-24 21:29 ` Dmitry Torokhov
@ 2010-03-25 13:58 ` Janusz Krzysztofik
0 siblings, 0 replies; 14+ messages in thread
From: Janusz Krzysztofik @ 2010-03-25 13:58 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-omap
Wednesday 24 March 2010 22:29:21 Dmitry Torokhov napisał(a):
> On Wednesday 24 March 2010 02:21:22 pm Janusz Krzysztofik wrote:
> > Hi Dmitry,
> >
> > Wednesday 24 March 2010 17:16:04 Dmitry Torokhov wrote:
> > > On Mon, Mar 22, 2010 at 10:07:47PM +0100, Janusz Krzysztofik wrote:
> > > > 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.
> >
> > Sure, thank you.
> >
> > > > The problem persists about different scancodes, giving
> > > > wrong keystrokes.
> > >
> > > This can be dealt with from userspace by loading correct keymap.
> >
> > Sounds acceptable. I hope the machine's built-in matrix keypad won't be
> > affected.
>
> The scan code to key code mapping is per-device so it should not.
Hi,
What utility could you advise for this purpose? input-utils' provided
input-kbd? keyfuzz? self compiled keymap.c example from
linux/Documentation/input/? Something else?
Thanks,
Janusz
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port
2009-12-10 19:58 [RFC][PATCH 0/5] omap1: Amstrad Delta: add support for external keyboard Janusz Krzysztofik
@ 2009-12-10 20:07 ` Janusz Krzysztofik
0 siblings, 0 replies; 14+ messages in thread
From: Janusz Krzysztofik @ 2009-12-10 20:07 UTC (permalink / raw)
To: linux-input; +Cc: linux-omap, Tony Lindgren, Dmitry Torokhov
The patch introduces a serio driver that supports a keyboard serial port found
on the Amstrad Delta videophone board.
After initializing the hardware, the driver reads its input data from a buffer
filled in by the board FIQ (Fast Interrupt Request) handler.
Compiles and works on to of patch 3/5: omap1: Amstrad Delta: use FIQ for
processing MPU GPIO interrupts
Created and tested against linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c dated 2009-12-02.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
drivers/input/serio/Kconfig | 9 +
drivers/input/serio/Makefile | 1
drivers/input/serio/ams_delta_keyboard.c | 240 +++++++++++++++++++++++++++++++
3 files changed, 250 insertions(+)
diff -uprN git.orig/drivers/input/serio/Kconfig git/drivers/input/serio/Kconfig
--- git.orig/drivers/input/serio/Kconfig 2009-12-02 15:51:50.000000000 +0100
+++ git/drivers/input/serio/Kconfig 2009-12-10 14:21:05.000000000 +0100
@@ -201,4 +201,13 @@ config SERIO_XILINX_XPS_PS2
To compile this driver as a module, choose M here: the
module will be called xilinx_ps2.
+config SERIO_AMS_DELTA
+ tristate "Amstrad Delta (E3) keyboard support"
+ depends on MACH_AMS_DELTA && AMS_DELTA_FIQ
+ ---help---
+ Say Y here if has an E3 and want to use the separate keyboard
+
+ To compile this driver as a module, choose M here: the
+ module will be called ams_delta_keyboard
+
endif
diff -uprN git.orig/drivers/input/serio/Makefile git/drivers/input/serio/Makefile
--- git.orig/drivers/input/serio/Makefile 2009-12-02 15:51:50.000000000 +0100
+++ git/drivers/input/serio/Makefile 2009-12-10 14:21:05.000000000 +0100
@@ -21,4 +21,5 @@ obj-$(CONFIG_SERIO_PCIPS2) += pcips2.o
obj-$(CONFIG_SERIO_MACEPS2) += maceps2.o
obj-$(CONFIG_SERIO_LIBPS2) += libps2.o
obj-$(CONFIG_SERIO_RAW) += serio_raw.o
+obj-$(CONFIG_SERIO_AMS_DELTA) += ams_delta_keyboard.o
obj-$(CONFIG_SERIO_XILINX_XPS_PS2) += xilinx_ps2.o
diff -uprN git.orig/drivers/input/serio/ams_delta_keyboard.c git/drivers/input/serio/ams_delta_keyboard.c
--- git.orig/drivers/input/serio/ams_delta_keyboard.c 1970-01-01 01:00:00.000000000 +0100
+++ git/drivers/input/serio/ams_delta_keyboard.c 2009-12-10 14:50:47.000000000 +0100
@@ -0,0 +1,240 @@
+/*
+ * Amstrad E3 (delta) keyboard driver
+ *
+ * Copyright (c) 2006 Matt Callow
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * Thanks to Cliff Lawson for his help
+ *
+ * The Amstrad Delta keyboard (or mailboard) is connected to GPIO 0 (clock)
+ * and GPIO 1 (data). It uses normal PC-AT style serial transmission,
+ * but the data and clock lines are inverted on the E3 mainboard,
+ * and the scancodes produced are non-standard
+ *
+ * Due to the strict timing requirements of the interface,
+ * the serial data stream is read using a FIQ handler, and then
+ * the resulting byte stream passed to this driver via a circular buffer.
+ */
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/serio.h>
+#include <asm/fiq.h>
+#include <plat/board-ams-delta.h>
+#include <mach/ams-delta-fiq.h>
+
+MODULE_AUTHOR("Matt Callow");
+MODULE_DESCRIPTION("AMS Delta (E3) Keyboard driver");
+MODULE_LICENSE("GPL");
+
+#define MAX_SCANCODE 0x84
+
+/*
+ * This table converts the amstrad mailboard scancodes to normal PC-AT scancodes
+ * The diagram below shows the amstrad keyboard, with the raw scancodes
+ *
+ * (70) (7A) (46) (7C) (77) Amstrad (72) (69) (1A) (2A) (1C) (15)
+ * [ 71][1:74][2:73][3:6B][4:22][5:1B][6:1D][7:1E][8:79][9:7D][0:75][ 6C]
+ * [Q:21][W:23][E:24][R:26][T:52][Y:5D][U:0D][I:0E][O:32][P:34] |return|
+ * [A:31][S:33][D:35][F:36][G:29][H:5B][J:03][K:76][L:3A][@:3B] | 2C|
+ * [ 3C][Z:3D][X:4E][C:54][V:0B][B:05][N:41][M:42][.:43][ 3E][ 55]
+ * [ 83][ 06][ 49][ 4B ][,:44][ 16][ 2E][ 09]
+ *
+ * These scancodes are then translated to AT scancodes using the following table
+ * The amstrad keyboard does not produce any extended scancodes, but we need to
+ * translate some amstrad scancodes to a AT extended scancode, hence the 16bit
+ * value for the translated scancode
+ *
+ * Translations for the non-obvious keys are:
+ * Store -> Tab
+ * Setup -> Caps Lock
+ * Service -> Backslash
+ * Games -> Left Alt
+ * Internet -> Right Alt
+ * Home -> Home
+ * Office -> Page Up
+ * Mobile -> Page Down
+ * Mobile Msg -> Insert
+ * Email -> Delete
+ * Fax -> End
+ * Stop -> Esc
+ * Symbol -> Left Ctrl
+ * Calc -> Right Ctrl
+ * Address -> Scroll Lock
+ */
+
+static unsigned short trans_table[MAX_SCANCODE] = {
+ 0, 0, 0, 0x003B, 0, 0x0032, 0x007E, 0, /* 00..07 */
+ 0, 0xE074, 0, 0x002A, 0, 0x003C, 0x0043, 0, /* 08..0F */
+ 0, 0, 0, 0, 0, 0xE069, 0xE06B, 0, /* 10..17 */
+ 0, 0, 0xE07A, 0x002E, 0xE071, 0x0036, 0x003D, 0, /* 18..1F */
+ 0, 0x0015, 0x0025, 0x001D, 0x0024, 0, 0x002D, 0, /* 20..27 */
+ 0, 0x0034, 0xE070, 0, 0x005A, 0, 0xE072, 0, /* 28..2F */
+ 0, 0x001C, 0x0044, 0x001B, 0x004D, 0x0023, 0x002B, 0, /* 30..37 */
+ 0, 0, 0x004B, 0x0052, 0x0012, 0x001A, 0xE075, 0, /* 38..3F */
+ 0, 0x0031, 0x003A, 0x0049, 0x0041, 0, 0x0061, 0, /* 40..47 */
+ 0, 0x0014, 0, 0x0029, 0, 0, 0x0022, 0, /* 48..4F */
+ 0, 0, 0x002C, 0, 0x0021, 0x0059, 0, 0, /* 50..57 */
+ 0, 0, 0, 0x0033, 0, 0x0035, 0, 0, /* 58..5F */
+ 0, 0, 0, 0, 0, 0, 0, 0, /* 60..67 */
+ 0, 0xE07D, 0, 0x0026, 0x0066, 0, 0, 0, /* 68..6F */
+ 0x000D, 0x0076, 0xE06C, 0x001E, 0x0016, 0x0045, 0x0042, 0xE011, /* 70..77 */
+ 0, 0x003E, 0x0058, 0, 0x0011, 0x0046, 0, 0, /* 78..7F */
+ 0, 0, 0, 0xE014 /* 80..83 */
+};
+
+static struct serio *ams_delta_kbd_port;
+
+static int check_data(int data)
+{
+ int i;
+ int parity = 0;
+
+ /* check valid stop bit */
+ if (!(data & 0x400)) {
+ printk(KERN_WARNING
+ "Invalid stop bit in AMS keyboard"
+ " data=0x%X\r\n", data);
+ return 0;
+ }
+ /* calculate the parity */
+ for (i = 1; i < 10; i++) {
+ if (data & (1 << i))
+ parity++;
+ }
+ /* it should be odd */
+ if (!(parity & 0x01)) {
+ printk(KERN_WARNING
+ "Paritiy check failed in AMS keyboard "
+ " data=0x%X parity 0x%X\r\n", data, parity);
+ }
+ return 1;
+}
+
+static irqreturn_t ams_delta_kbd_interrupt(int irq, void *dev_id,
+ struct pt_regs *regs)
+{
+ int *circ_buff = &fiq_buffer[FIQ_CIRC_BUFF];
+ /*
+ * Read data from the CIRC buffer, check it, translate the scancode
+ * and then pass it on the serio
+ */
+ fiq_buffer[FIQ_IRQ_PEND] = 0;
+
+ while (fiq_buffer[FIQ_CHAR_CNT] > 0) {
+ int data;
+ u8 original_scancode;
+ unsigned short translated_scancode;
+
+ data = circ_buff[fiq_buffer[FIQ_BACK_OFFSET]] ;
+ fiq_buffer[FIQ_BACK_OFFSET]++;
+ fiq_buffer[FIQ_CHAR_CNT]--;
+ if (fiq_buffer[FIQ_BACK_OFFSET] == fiq_buffer[FIQ_BUF_LEN])
+ fiq_buffer[FIQ_BACK_OFFSET] = 0;
+
+ if (check_data(data)) {
+ original_scancode = (u8) (data >> 1) & 0xFF;
+ if (original_scancode < MAX_SCANCODE) {
+ translated_scancode =
+ trans_table[original_scancode];
+ if ((translated_scancode & 0xff00) != 0) {
+ serio_interrupt(ams_delta_kbd_port,
+ translated_scancode >> 8, 0);
+ }
+ if ((translated_scancode & 0xff) != 0) {
+ serio_interrupt(ams_delta_kbd_port,
+ translated_scancode & 0xff, 0);
+ }
+ } else {
+ serio_interrupt(ams_delta_kbd_port,
+ original_scancode, 0);
+ }
+ }
+ }
+ return IRQ_HANDLED;
+}
+
+static struct serio * __init ams_delta_kbd_allocate_serio(void)
+{
+ struct serio *serio;
+
+ serio = kmalloc(sizeof(struct serio), GFP_KERNEL);
+ if (serio) {
+ memset(serio, 0, sizeof(struct serio));
+ serio->id.type = SERIO_8042;
+ strlcpy(serio->name, "AMS DELTA keyboard adapter",
+ sizeof(serio->name));
+ snprintf(serio->phys, sizeof(serio->phys), "%s/serio0", "GPIO");
+ }
+
+ return serio;
+}
+
+static int __init ams_delta_kbd_init(void)
+{
+ int err;
+
+ ams_delta_kbd_port = ams_delta_kbd_allocate_serio();
+ if (!ams_delta_kbd_port) {
+ err = -ENOMEM;
+ goto err;
+ }
+
+ if (gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_DATA, "kbd-data")) {
+ printk(KERN_ERR "Couldn't request gpio pin for keyboard data");
+ err = -EINVAL;
+ goto serio;
+ }
+ gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
+
+ if (gpio_request(AMS_DELTA_GPIO_PIN_KEYBRD_CLK, "kbd-clock")) {
+ printk(KERN_ERR "Couldn't request gpio pin for keyboard clock");
+ err = -EINVAL;
+ goto gpio_data;
+ }
+ gpio_direction_input(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
+
+ if (request_irq(OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
+ ams_delta_kbd_interrupt, 0, "ams-delta-keyboard", 0) < 0) {
+ printk(KERN_ERR "Couldn't request gpio interrupt %d",
+ OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK));
+ err = -EINVAL;
+ goto gpio_clk;
+ }
+ set_irq_type(OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
+ IRQ_TYPE_EDGE_RISING);
+
+ /* enable keyboard */
+ ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR,
+ AMD_DELTA_LATCH2_KEYBRD_PWR);
+
+ serio_register_port(ams_delta_kbd_port);
+ printk(KERN_INFO "serio: AMS DELTA keyboard adapter\n");
+
+ return 0;
+gpio_clk:
+ gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
+gpio_data:
+ gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
+serio:
+ kfree(ams_delta_kbd_port);
+err:
+ return retval;
+}
+module_init(ams_delta_kbd_init);
+
+static void __exit ams_delta_kbd_exit(void)
+{
+ serio_unregister_port(ams_delta_kbd_port);
+ /* disable keyboard */
+ ams_delta_latch2_write(AMD_DELTA_LATCH2_KEYBRD_PWR, 0);
+ free_irq(OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
+ gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
+ gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
+ kfree(ams_delta_kbd_port);
+}
+module_exit(ams_delta_kbd_exit);
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-03-25 13:58 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-11 2:36 [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port Dmitry Torokhov
2009-12-11 3:09 ` Janusz Krzysztofik
2009-12-11 8:01 ` Dmitry Torokhov
2009-12-12 20:34 ` Janusz Krzysztofik
2009-12-12 23:20 ` Dmitry Torokhov
2009-12-14 0:11 ` Janusz Krzysztofik
2009-12-17 15:36 ` [RFC][PATCH 4/5] input: serio: add support forAmstrad " witek mark
2009-12-17 16:37 ` [RFC][PATCH 4/5] input: serio: add supportforAmstrad " witek mark
2010-03-22 21:07 ` [RFC][PATCH 4/5] input: serio: add support for Amstrad " Janusz Krzysztofik
2010-03-24 16:16 ` Dmitry Torokhov
2010-03-24 21:21 ` Janusz Krzysztofik
2010-03-24 21:29 ` Dmitry Torokhov
2010-03-25 13:58 ` Janusz Krzysztofik
-- strict thread matches above, loose matches on Subject: below --
2009-12-10 19:58 [RFC][PATCH 0/5] omap1: Amstrad Delta: add support for external keyboard Janusz Krzysztofik
2009-12-10 20:07 ` [RFC][PATCH 4/5] input: serio: add support for Amstrad Delta serial keyboard port Janusz Krzysztofik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).