On Mon, 22 Apr 2002 03:07, Hans E. Kristiansen wrote: > --- snip --- > --- snop --- > > Right on the spot Although I were not able to get this working immediately, > some research in the documentation indicated that I needed to load the > module evdev.After that, I could see the binary data on the > /dev/input/event0 and /dev/input/event1 interface. > > The data is probably binary scancodes. I'll get on with that tomorrow. It is a struct input_event. (see: <linux/input.h> you always get whole events. I have an example and explaination. Just gve me a day or two.
> However, the data is still being interpreted by the application, what is > the most simple way to prevent that ( apart from not enabling the modules > mousedev and keybdev ( in the drivers/input directory )? I know there is an > usb hotplug script which may need some changes? I would like the mouse > events to pass through, but the keyboard events to be trapped for this > device only. Such that I can use the mouse under X, but lirc for shortcut > keys. Way cool that would be. It is not clear what "application" means in this context. X is an application, and there is a special meaning of application in the HID spec (probably not that). What devices are you planning to have connected under particular circumstances? What data from each device is supposed to go to where? Can you post the device layout (especially /proc/bus/usb/devices with this magic remote control attached? Concept: Attach the X mouse drver to the particular mouse device (eg /dev/input/mouse0) Attach the X core keyboard to the dummy driver Don't enable the keybdev driver (or load the module on some selective basis for debugging) Attach the keys interface on the remote control based on reading one or more /dev/input/event devices. Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
