Hallo!
I have a question about accessing events of multiple keyboards: Is this already implemented in hid ? Because I found this in the archive:
- keyboard doesn't seem to work at all (keyboard is detected; i get
button-presses; but i do not get which key is pressed: the label is
very empty: '')
Its still alpha, lots of stuff isn't implemented yet. Like that.
If not, is there any other object, which can do that?
(I want to use 2 additional keyboards as a controller - on linux/debian)
Thanks, LG Georg
hi georg,
I read:
(I want to use 2 additional keyboards as a controller - on linux/debian)
http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
HTH
x
Unless you want to be an alpha tester for the [hid] object (which would
be much appreciated :), I would suggest using [linuxevent] for now.
Each USB keyboard should have its out /dev/input/event? device, so you
would have one [linuxevent] object for each keyboard. This is a lower
level than getting the info from X.
IIRC, the keyboard keys are not yet fully mapped with the [hid] object.
Its not the most exciting project, it basically involves writing a
lookup table to translate Linux input key types to [hid] key types.
.hc
On Mar 2, 2005, at 11:08 AM, Georg Holzmann wrote:
Hallo!
I have a question about accessing events of multiple keyboards: Is this already implemented in hid ? Because I found this in the
archive:
- keyboard doesn't seem to work at all (keyboard is detected; i get
button-presses; but i do not get which key is pressed: the label is
very empty: '')
Its still alpha, lots of stuff isn't implemented yet. Like that.
If not, is there any other object, which can do that?
(I want to use 2 additional keyboards as a controller - on
linux/debian)Thanks, LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list
"Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice, it
can change entire economies."
- Amy Smith
Hallo!
Unless you want to be an alpha tester for the [hid] object (which would
be much appreciated :), I would suggest using [linuxevent] for now.
Of course I want to be an alpha-tester :) - but I tried it and it didn't work. If I press a key, it is detected, but not which key ... (I tried it with the hid version from your hp) I also tried [linuxevent] and there is the same problem.
IIRC, the keyboard keys are not yet fully mapped with the [hid] object.
Its not the most exciting project, it basically involves writing a
lookup table to translate Linux input key types to [hid] key types.
If you give me a hint how I shouldcan make it I would do it ...
Thanks, LG Georg
hi,
Am Donnerstag 03 März 2005 16:48 schrieb Georg Holzmann:
Hallo!
Unless you want to be an alpha tester for the [hid] object (which would be much appreciated :), I would suggest using [linuxevent] for now.
Of course I want to be an alpha-tester :) - but I tried it and it didn't work. If I press a key, it is detected, but not which key ... (I tried it with the hid version from your hp) I also tried [linuxevent] and there is the same problem.
hmm, even linuxevent doesnt report them ? altough i know that it is a different object than the ev_dev i once wrote for jmax, i am pretty sure that at least with the event-interface you have to get the values.
for example, pressing the key "a" generates a event of type 1 (key event), with a id of 30 (thats the id for the key), and a 1 as event value (=pressed). if the auto-repeat snaps in, the event-value will become 2. on release, it becomes 0 .... key "s" is id 31, btw, so the id's are more or less orientated by the physical arrangement of the keys, instead of the alphabet ....
there might be a trap with the event system you might be falling into .... on newer kernels, the event system also outputs event of type "0", which i suppose is some kind of sync, or idle indication, i dont know. maybe you are not filtering out the "0" event ...... if i dont do it here, i always see only that 0 event, because it is sent after each other event ...
greets,
chris
On Mar 3, 2005, at 10:48 AM, Georg Holzmann wrote:
Hallo!
Unless you want to be an alpha tester for the [hid] object (which
would be much appreciated :), I would suggest using [linuxevent] for
now.Of course I want to be an alpha-tester :) - but I tried it and it
didn't work. If I press a key, it is detected, but not which key ... (I tried it with the hid version from your hp) I also tried [linuxevent] and there is the same problem.
[linuxevent] is quite a simple object, it just dumps data from the
/dev/input/event? device to Pd land. Are you sure you are getting data
from the device? You can "cat /dev/input/event0" and then try the
different devices.
IIRC, the keyboard keys are not yet fully mapped with the [hid]
object. Its not the most exciting project, it basically involves
writing a lookup table to translate Linux input key types to [hid]
key types.If you give me a hint how I shouldcan make it I would do it ...
In the Pd CVS, you'll need to work on the file
externals/hcs/hid/hid_linux.c. The events are gotten by the while loop
in hid_get_events(); You'll need to implement a function that does a
table lookup using the event code define(i.e. KEY_A) and translates it
to a lowercase string/symbol name "key_a". This table should be
auto-generated from /usr/include/linux/input.h. I think the table
should include all KEY_? types there (KEY_ESC -> KEY_MEDIA).
I didn't create a separate build system, use the externals build system
in externals/build/linux.
It would be awesome if you got this working!
.hc
Thanks, LG Georg
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger Dykstra
-
Christian Klippel -
CK -
Georg Holzmann -
Hans-Christoph Steiner