I just installed Gizmod 3.4 and the Gizmod.Keyboards[] array is empty when my onEvent() method is called. This makes it impossible to generate/translate keystrokes.
If it matters, my system is Gentoo. I compiled the source from scratch (not the ebuild), I have tried it with boost-3.4.0 and boost-3.4.1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hrmm... interesting, gizmod isn't seeing any keyboards or mice connected to the system. I'm assuming that the Gyration Receiver is some kind of wireless keyboard / mouse combo?
The unfortunate thing about your keyboard / mouse is that the hardware manufacturer decided to make it difficult to know what kind of devices they are. They have the same description and vendor / and product ID codes.
The simplest thing to do will be to manually tell gizmod which is which. First do this:
cat /dev/input/event2 (then hit some buttons on the keyboard)
If you see garbarge on the screen you know the keyboard is on event2, and the mouse is on event3. If nothing happens it's the other way around. Hit ctrl-c.
Okay now edit /etc/gizmod/GizmoDeviceStrings.py
change KEYBOARD_GIZMOS and MOUSE_GIZMOS to something like:
Thank you very much for this insightful information. I have gotten further in my quest. Here is where I am now.
You wrote:
> I'm assuming that the Gyration Receiver is some kind of wireless
> keyboard / mouse combo?
Yes. It registers as both a mouse and a keyboard. Interestingly enough, my wired more-standard "multi-media" USB keyboard also registers itself as two /dev/inputX nodes.
> The unfortunate thing about your keyboard / mouse is that the
> hardware manufacturer decided to make it difficult to know what
> kind of devices they are. They have the same description and vendor
> / and product ID codes.
This is also true for the above mentioned wired USB keyboard. However, I noticed that there is a way to distinguish what's what.
If I look in the /dev/input/by-path, folder I see something like the following:
It would appear that if the filenames in /dev/input/by-path folder were processed, those with "kbd" in them are keyboards and those with "mouse" in them are mice.
> The simplest thing to do will be to manually tell gizmod which is which.
> edit /etc/gizmod/GizmoDeviceStrings.py
> change KEYBOARD_GIZMOS and MOUSE_GIZMOS to something like:
Since the keyboards and mice move around (sometimes /dev/input2, other times /dev/input5) when plugged in and unplugged, a better solution would be to process the /dev/input/by-path folder. This doesn't seem to be happening now. I noticed that the items in /dev/input/by-path do not belong to the "input" group (I followed your udev rules instructions concerning the input group). Would they be processed if they were part of the input group?
> If you get that far I think everything should work!
I managed to get a value in the Keyboards[] array by plugging in a standard USB keyboard. While not the optimal solution, it will work for now. However, this has not fixed the other problem concerning the onDeviceEvent() never being called.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Agreed the solution I gave isn't optimal in any way. I was just hoping to get you up and running. I'm actually planning a solution to this problem as it seems more and more hardware manufacturers are releasing devices that don't properly describe themselves.
To answer your questions about the by-path folder, if you were to set the perms properly on them it wouldn't matter since gizmod doesn't read those at all. And actually that would just be another dirty hack (it's distro and software specific -- it's actually a udev config thing, so those paths can be anywhere and set to anything).
My plan for the next version is to do two things: do more more low level device probing to get HID hints from the devices as to what type of devices they are (which is how those by-path device nodes are generated). And if that still fails, I'm hoping to implement a very simple learning algorithm that will detect what type of events the devices are emitting and make a guess as to their type. For some things like keyboard, mouse, and joystick it's completely trivial to distinguish. The only case where it wouldn't work is in odd situations like certain esoteric devices, but fortunately usually these devices describe themselves pretty well.
Thanks for your suggests and time on this though.
Let me know if you have any more thoughts!
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just installed Gizmod 3.4 and the Gizmod.Keyboards[] array is empty when my onEvent() method is called. This makes it impossible to generate/translate keystrokes.
If it matters, my system is Gentoo. I compiled the source from scratch (not the ebuild), I have tried it with boost-3.4.0 and boost-3.4.1.
Hey RayDar,
Can you post the output of gizmod -g? (Particularly the startup info)?
Thanks,
Tim.
Here is the first bit of the gizmod -g startup:
GizmoDaemon v3.4 -=- (c) 2007, Tim Burrell <tim.burrell@gmail.com>
Debug Mode Enabled
Registering Devices:
Standard - Directory [input]
Standard - Power Button (FF) [event0] vId: 0x0 pId: 0x2
Standard - Power Button (CM) [event1] vId: 0x0 pId: 0x1
Standard - Gyration GyroPoint RF Technology Receiver [event2] vId: 0xc16 pId: 0x1
Standard - Gyration GyroPoint RF Technology Receiver [event3] vId: 0xc16 pId: 0x1
LIRC device node [/dev/lircd] does not exist -- disabling LIRC support
Loading User Scripts:
Hrmm... interesting, gizmod isn't seeing any keyboards or mice connected to the system. I'm assuming that the Gyration Receiver is some kind of wireless keyboard / mouse combo?
The unfortunate thing about your keyboard / mouse is that the hardware manufacturer decided to make it difficult to know what kind of devices they are. They have the same description and vendor / and product ID codes.
The simplest thing to do will be to manually tell gizmod which is which. First do this:
cat /dev/input/event2 (then hit some buttons on the keyboard)
If you see garbarge on the screen you know the keyboard is on event2, and the mouse is on event3. If nothing happens it's the other way around. Hit ctrl-c.
Okay now edit /etc/gizmod/GizmoDeviceStrings.py
change KEYBOARD_GIZMOS and MOUSE_GIZMOS to something like:
KEYBOARD_GIZMOS = ["keyboard", "/dev/input/event2"]
MOUSE_GIZMOS = ["mouse", "/dev/input/event3"]
(but obviously change to suite your system as we discovered in the first step.
Then run gizmod -g and you should see something like this:
Registering Devices:
...
Mouse - Gyration GyroPoint RF Technology Receiver [event2] vId: 0xc16 pId: 0x1
Keyboard - Gyration GyroPoint RF Technology Receiver [event3] vId: 0xc16 pId: 0x1
...
If you get that far I think everything should work!
Let me know how you fare.
Thanks,
Tim.
Thank you very much for this insightful information. I have gotten further in my quest. Here is where I am now.
You wrote:
> I'm assuming that the Gyration Receiver is some kind of wireless
> keyboard / mouse combo?
Yes. It registers as both a mouse and a keyboard. Interestingly enough, my wired more-standard "multi-media" USB keyboard also registers itself as two /dev/inputX nodes.
> The unfortunate thing about your keyboard / mouse is that the
> hardware manufacturer decided to make it difficult to know what
> kind of devices they are. They have the same description and vendor
> / and product ID codes.
This is also true for the above mentioned wired USB keyboard. However, I noticed that there is a way to distinguish what's what.
If I look in the /dev/input/by-path, folder I see something like the following:
usb-Gyration_GyroPoint_RF_Technology_Receiver-event-kbd -> ../event2
usb-Gyration_GyroPoint_RF_Technology_Receiver-event-mouse -> ../event3
usb-Gyration_GyroPoint_RF_Technology_Receiver-mouse -> ../mouse0
usb-_USB_Keyboard-event-kbd -> ../event5
It would appear that if the filenames in /dev/input/by-path folder were processed, those with "kbd" in them are keyboards and those with "mouse" in them are mice.
> The simplest thing to do will be to manually tell gizmod which is which.
> edit /etc/gizmod/GizmoDeviceStrings.py
> change KEYBOARD_GIZMOS and MOUSE_GIZMOS to something like:
>KEYBOARD_GIZMOS = ["keyboard", "/dev/input/event2"]
>MOUSE_GIZMOS = ["mouse", "/dev/input/event3"]
Since the keyboards and mice move around (sometimes /dev/input2, other times /dev/input5) when plugged in and unplugged, a better solution would be to process the /dev/input/by-path folder. This doesn't seem to be happening now. I noticed that the items in /dev/input/by-path do not belong to the "input" group (I followed your udev rules instructions concerning the input group). Would they be processed if they were part of the input group?
> If you get that far I think everything should work!
I managed to get a value in the Keyboards[] array by plugging in a standard USB keyboard. While not the optimal solution, it will work for now. However, this has not fixed the other problem concerning the onDeviceEvent() never being called.
Agreed the solution I gave isn't optimal in any way. I was just hoping to get you up and running. I'm actually planning a solution to this problem as it seems more and more hardware manufacturers are releasing devices that don't properly describe themselves.
To answer your questions about the by-path folder, if you were to set the perms properly on them it wouldn't matter since gizmod doesn't read those at all. And actually that would just be another dirty hack (it's distro and software specific -- it's actually a udev config thing, so those paths can be anywhere and set to anything).
My plan for the next version is to do two things: do more more low level device probing to get HID hints from the devices as to what type of devices they are (which is how those by-path device nodes are generated). And if that still fails, I'm hoping to implement a very simple learning algorithm that will detect what type of events the devices are emitting and make a guess as to their type. For some things like keyboard, mouse, and joystick it's completely trivial to distinguish. The only case where it wouldn't work is in odd situations like certain esoteric devices, but fortunately usually these devices describe themselves pretty well.
Thanks for your suggests and time on this though.
Let me know if you have any more thoughts!
Tim.