patch to make the imon PAD generate mouse events

[DataPath]

First of all, I apologize for my long absence.

I'm starting to free up again to be able to do more development on the driver.

My current plan is to write a userspace USB driver for the device.

I really felt that doing such remote-specific and involved data processing in a kernel driver was the wrong way to go, but saw no alternatives. But lately, a lot of attention has been given to usbfs, sysfs, and libusb as a means of developing USB drivers in userspace.

My intent is to have a plug-in system that will allow filtering remote data to LIRC, to a /dev/input device node as keyboard/mouse data, and as DBUS events that can be read from other processes.

I think my ideal would be to actually eliminate binary plugins, and replace it with scriptlets, along the lines of LUA or possibly python or perl.

First things first, though - I need to start on the USB driver part, and work from there.

[oliver]

Ok after reading all of this thread, some e-mail correspondance with Michaelb and getting my iMon working, I finally get what this thing is all about : )

DataPath so if I undertand correctly, you want to make it into a nice USB driver, to be included in the kernel source, that then generates lirc events and sends those to lirc, and then also accepts /dev/lcd/0 data to be displayed on the LCD? Sounds awesome. I guess your earlier comment about using DBUS should be up to the lirc folks. The driver would submit lirc info to lirc, lirc would then distribute and forward it via DBUS (and the old way for backwards compatibility). Or do I got things all confused here?

SiliconFiend I noticed in your lircd.conf you are only using single mouseclicks? Why not use both events generated from the mousbuttons, e.g. press and release. Atleast in the lircd.conf they both should be available no?

MouseRightClickRls 0x688281B7
MouseRightClickDown 0x688481B7
MouseLeftClickRls 0x688281B7
MouseLeftClickDown 0x688301B7

Is what I got on them, seems to work just fine.

I think i'll try your http://vorticon.no-ip.info/pub/patches/ ... rnel.patch next and see if it makes the pad work as I would expected the default driver to work.

[SiliconFiend]

SiliconFiend I noticed in your lircd.conf you are only using single mouseclicks? Why not use both events generated from the mousbuttons, e.g. press and release. Atleast in the lircd.conf they both should be available no?

MouseRightClickRls 0x688281B7
MouseRightClickDown 0x688481B7
MouseLeftClickRls 0x688281B7
MouseLeftClickDown 0x688301B7

Is what I got on them, seems to work just fine.

I think i'll try your http://vorticon.no-ip.info/pub/patches/ ... rnel.patch next and see if it makes the pad work as I would expected the default driver to work.

Yes, I realize my lircd.conf is probably incomplete, but I have no use for the Release events, so they're not included. I think I'll the driver stabilize a bit before I make a big effort to make my lircd.conf comprehensive.

By the way, I recently changed over to using the "pad2keys" patch that's floating around. I'm using Gentoo, so when lirc 0.8.0 was marked stable I noticed that it was listed as a supported driver so I tried it out. That patch is based on the most recent patch posted on this string, but it ditches the mouse support. However, it is sufficient for my purposes for now (and it works with my lircd.conf without any modification). If DataPath eventually gets the user-space driver released, I think that will be the best overall to support mouse/keyboard mode for the pad.

[oliver]

I just mentioned it as I guess your files are the most generic/usable out there right now and even though the events are maybe not used, it's always nice to have a complete lircd.conf?

Anyway, it's good to see someone is still reading these forums

Anybody know btw if the VFD is dimmable etc? I was looking through the code and noticed it'll only let you write simple 32char strings to it. I also found out the chip used for these VFD's actually let's you update the CGRAM for the charachters (right now it's just some basic ascii chars, no art possible).
Anybody experimented around with that? (anybody got the samsung/nec chips number handy as I put mine back into the case again for now)

http://www.oreillynet.com/digitalmedia/ ... _di_1.html talks about the d16314agj chip, used by the samsung VFD panel. Appearantly the USB controller chip is probably a PIC that handles the IR stuff on one of it's pins and the rest to do some sort of mini parallel port thing. Maybe that could help support the 'new' usb driver to be able to support much more then 'just' the standard array of chars.

[ironstorm]

Ok, I've missed something here...

I've patched using http://vorticon.no-ip.info/pub/patches/ ... rnel.patch, the patch was clean however it doesn't seem to provide any working directional stuff... I think it's an issue with my config file...

When I do mode2 --device=/dev/lirc0 I get

Code: Select all

# Tap right on DPAD
code: 0x6912f9b7
code: 0x691af9b7
code: 0x693af9b7
code: 0x692ad9b7

# Keyboard / Mouse key
code: 0x299115b7
code: 0x299155b7

# Tap right again on DPAD
code: 0x6932f9b7
code: 0x693af9b7
code: 0x697ab9b7
code: 0x68b2c1b7


These codes don't match those in the lircd.conf that I cut and paste from earlier in the thread.

I'm running this on an Sillverstone LC20M, other keys seem to work normally...

What am I missing here?

-G

[oliver]

Ok, I've missed something here...

I've patched using http://vorticon.no-ip.info/pub/patches/ ... rnel.patch, the patch was clean however it doesn't seem to provide any working directional stuff... I think it's an issue with my config file...

When I do mode2 --device=/dev/lirc0 I get

Code: Select all

# Tap right on DPAD
code: 0x6912f9b7
code: 0x691af9b7
code: 0x693af9b7
code: 0x692ad9b7

# Keyboard / Mouse key
code: 0x299115b7
code: 0x299155b7

# Tap right again on DPAD
code: 0x6932f9b7
code: 0x693af9b7
code: 0x697ab9b7
code: 0x68b2c1b7


These codes don't match those in the lircd.conf that I cut and paste from earlier in the thread.

I'm running this on an Sillverstone LC20M, other keys seem to work normally...

What am I missing here?

-G

Right 0x688a81b7

This is what I have in my lircd.conf for right. Looks like your right is something different everytime. Makes me wonder wether the pad has 4 directions, or 8. I have some issues with the pad going up when I press right, or goes right when I press up/down ...

[Czarny]

Hi - I've read most of this forum in search of a solution to the iMON mouse/joystick remote control problem. I ran, as all of You here, on the same problem with trying to use the josytick/mouse/pad feature (whatever You'll call it).

I got confused while reading the forum and especially this post. Let me reasume to get things straight.

The problem is in the fact, that the joystick doesn't produce a normal otuput of a 4/8/16/32 way joystick, but something totally different, dependant on mode, preasure, dirrection and probabelly a lot more stuff.

So here I have two requests/suggestsions:

1. As I got confused in regards of the implementation of this strange behaviour, a seperate kernel module, some tweaking of lirc, then again a symbiotic driver...I' totally out of it. Even more with the avalanche of patches of other ppl patches including something else. Could anyone point out the outcome of this patching other ppls patches? I *think* there is a patch making the 'mouse' usable and one making the 'mouse' behave as a 4 way joystick. But I've seen some other patches here, that change behaviour from the mousish to the joystickish with the Moue/Keyboard button. Could anyone clear this one for me? Which patch is the newest outcome of the pathcing avalanche, working with lirc 0.8.1pre2 (or simillar), giving both mouse and joystick function??

2. I've seen a long dispute in how the driver works. Did anyone tried two obvious sollutions? One could reverse engeneer the windows driver, or in the contrarry - if this really is a mouse, why not send all of its input to every mouse driver linux has? I doubt, that ppl from Soundforge built a totally new mouse device, new protocol - they could've use some other, already existing protocol and that test would ease a lot of work (if it suceedeed).

Thx 4 the reply and sorry for not being able to scoop the patch myself, but this thread is confusing and with the rest of forum read bout the joystick stuff I'm totally spaced out.

Thx 4 the good work (without the pad the set is usuable as well - I use the Thermaltake Mozart with 'MediaLab', which is the iMon VFD panel).
Cz@rny

[SiliconFiend]

The problem is in the fact, that the joystick doesn't produce a normal otuput of a 4/8/16/32 way joystick, but something totally different, dependant on mode, preasure, dirrection and probabelly a lot more stuff.

That's correct--like the previous poster noticed, without any patch you'll see the raw codes from the pad when you use mode2. I believe the raw codes are basically a delta-x, delta-y pair, because the pad is pressure-sensitive and so the deltas are variable.

So here I have two requests/suggestsions:

1. As I got confused in regards of the implementation of this strange behaviour, a seperate kernel module, some tweaking of lirc, then again a symbiotic driver...I' totally out of it. Even more with the avalanche of patches of other ppl patches including something else. Could anyone point out the outcome of this patching other ppls patches? I *think* there is a patch making the 'mouse' usable and one making the 'mouse' behave as a 4 way joystick. But I've seen some other patches here, that change behaviour from the mousish to the joystickish with the Moue/Keyboard button. Could anyone clear this one for me? Which patch is the newest outcome of the pathcing avalanche, working with lirc 0.8.1pre2 (or simillar), giving both mouse and joystick function??

I believe the patch hosted on my web server (http://vorticon.no-ip.info/pub/patches/lirc-0.8.0-imon-keys-kernel.patch) is the cumulative effort of all the coders in this thread. It includes the mouse/keyboard switching (not mouse/joystick) by pressing the mouse/keyboard button. It also includes some fixes for the recent kernel changes to the USB api (the .owner field). I don't know if the patch will apply cleanly on lirc-0.8.1. It should unless other changes have been made to the imon driver, in which case maybe they've fixed this problem and the patch isn't needed.

I don't use my own patch anymore. I have Gentoo and they have a modified form of this patch which only enables keyboard mode (no mouse) but that's exactly what I need, so I use it. In case anyone's interested, just add this line to your make.conf

Code: Select all

LIRC_DEVICES="imon_pad2keys"

Then all you have to do is emerge lirc-0.8.0-r5 and make sure your lircd.conf codes match (they should) and you're on your way.

2. I've seen a long dispute in how the driver works. Did anyone tried two obvious sollutions? One could reverse engeneer the windows driver, or in the contrarry - if this really is a mouse, why not send all of its input to every mouse driver linux has? I doubt, that ppl from Soundforge built a totally new mouse device, new protocol - they could've use some other, already existing protocol and that test would ease a lot of work (if it suceedeed).

I think reverse engineering the windows driver would be a difficult task and probably pointless, considering that the protocol and codes are understood (thanks to Venky). The mouse/keyboard patch on my site uses the kernel mouse driver (as far as I know there are no other linux mouse drivers).

The original author of this patch (DataPath) had been working on a "next generation" user-space driver which would just "do the right thing" and you could configure the behavior of the mouse/keyboard button, etc. with configuration files instead of having to patch and recompile. I haven't heard anything from DataPath on this subject in a while, though.

[mouser]

So I'm running fully-updated FC6 (2.6.18-1.2849.fc6-i686 kernel). I installed LIRC with yum via the instructions given in various MythTV setup guides:

yum -y install lirc-lib
yum -y install lirc-kmdl-$KVER
yum -y install lirc

But in order to apply the patch(s) discussed here, I had to get the current CVS source, which I did. I applied the patch (the pad2keys one first), did an autogen, setup.sh, make, make install... and got no change. mode2 still returns the pressure-sensitive codes for the pad, and irw returns nothing for the pad except the very occasional match. I tried rebooting and still nothing.

Tried the other patch (lirc-0.8.0-imon-keys-kernel.patch) on fresh source and had the same results.

Am I missing a step to enable the changes that I though would be put in place when I did a make install?

[SiliconFiend]

So I'm running fully-updated FC6 (2.6.18-1.2849.fc6-i686 kernel). I installed LIRC with yum via the instructions given in various MythTV setup guides:

yum -y install lirc-lib
yum -y install lirc-kmdl-$KVER
yum -y install lirc

But in order to apply the patch(s) discussed here, I had to get the current CVS source, which I did. I applied the patch (the pad2keys one first), did an autogen, setup.sh, make, make install... and got no change. mode2 still returns the pressure-sensitive codes for the pad, and irw returns nothing for the pad except the very occasional match. I tried rebooting and still nothing.

Tried the other patch (lirc-0.8.0-imon-keys-kernel.patch) on fresh source and had the same results.

Am I missing a step to enable the changes that I though would be put in place when I did a make install?

I would guess that your previous installation is still active. Maybe when you run ./configure you might need to specify the target path? Sorry I can't help more; I use Gentoo so all that mess is handled automagically (and I can still apply patches by modifying the ebuild).

[remy.bohmer]

I have ported the patch posted earlier in this thread to 0.8.1pre3 and a 2.6.19(-RT) kernel.
Maybe someone out there can use it?
I tested it with the LC16M, FC6 + 2.6.19-RT kernel. IT will also work with normal (non-RT) kernels

Remy

Code: Select all

--- lirc-0.8.1pre3.orig/drivers/lirc_imon/lirc_imon.c   2006-12-03 21:30:50.000000000 +0100
+++ lirc-0.8.1pre3/drivers/lirc_imon/lirc_imon.c   2006-12-03 22:01:25.000000000 +0100
@@ -53,6 +53,7 @@

#include <linux/errno.h>
#include <linux/init.h>
+#include <linux/input.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/slab.h>
@@ -71,7 +72,7 @@
#define MOD_AUTHOR   "Venky Raju <dev@venky.ws>"
#define MOD_DESC   "Driver for Soundgraph iMON MultiMedian IR/VFD"
#define MOD_NAME   "lirc_imon"
-#define MOD_VERSION   "0.3"
+#define MOD_VERSION   "0.3M"

#define VFD_MINOR_BASE   144   /* Same as LCD */
#define DEVFS_MODE   S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
@@ -86,6 +87,7 @@
#define   TRUE      1
#define FALSE      0

+#define CURSOR_LIMIT   16

/* ------------------------------------------------------------
  *                     P R O T O T Y P E S
@@ -97,14 +99,17 @@
static int imon_probe (struct usb_interface *interface,
         const struct usb_device_id *id);
static void imon_disconnect (struct usb_interface *interface);
-static void usb_rx_callback (struct urb *urb, struct pt_regs *regs);
-static void usb_tx_callback (struct urb *urb, struct pt_regs *regs);
#else
static void * imon_probe (struct usb_device * dev, unsigned int intf,
            const struct usb_device_id *id);
static void imon_disconnect (struct usb_device *dev, void *data);
+#endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 19) || !defined(KERNEL_2_5)
static void usb_rx_callback (struct urb *urb);
static void usb_tx_callback (struct urb *urb);
+#else
+static void usb_rx_callback (struct urb *urb, struct pt_regs *regs);
+static void usb_tx_callback (struct urb *urb, struct pt_regs *regs);
#endif

/* VFD file_operations function prototypes */
@@ -121,6 +126,14 @@
static int __init imon_init (void);
static void __exit imon_exit (void);

+typedef enum {
+  MOUSE_KEY_NONE,
+  MOUSE_KEY_N,
+  MOUSE_KEY_E,
+  MOUSE_KEY_S,
+  MOUSE_KEY_W
+} pad_key_t;
+
/* ------------------------------------------------------------
  *                     G L O B A L S
  * ------------------------------------------------------------
@@ -163,7 +176,17 @@
      struct completion finished;  /* wait for write to finish  */
      atomic_t busy;           /* write in progress         */
      int status;           /* status of tx completion   */
+
   } tx;
+   int key_x;
+   int key_y;
+   int mode_kbd;              /* keyboard/mouse mode       */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)
+   struct input_dev mouse;           /* mouse interface           */
+#else
+   struct input_dev * mouse;        /* mouse interface           */
+#endif
+   int last_count;              /* number of times pressed   */
};

#define LOCK_CONTEXT   down (&context ->sem)
@@ -532,10 +555,10 @@
/**
  * Callback function for USB core API: transmit data
  */
-#ifdef KERNEL_2_5
-static void usb_tx_callback (struct urb *urb, struct pt_regs *regs)
-#else
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 19) || !defined(KERNEL_2_5)
static void usb_tx_callback (struct urb *urb)
+#else
+static void usb_tx_callback (struct urb *urb, struct pt_regs *regs)
#endif
{
   struct imon_context *context;
@@ -577,6 +600,10 @@
   context ->rx.count = 0;
   context ->rx.initial_space = 1;
   context ->rx.prev_bit = 0;
+   context ->key_x = 0;
+   context ->key_y = 0;
+   context ->last_count = 0;
+   context ->mode_kbd = 1; /* init keyboard mode       */

   usb_fill_int_urb (context ->rx_urb, context ->dev,
      usb_rcvintpipe (context ->dev,
@@ -707,6 +734,89 @@
   if (context ->ir_onboard_decode) {

      /* The signals have been decoded onboard the iMON controller */
+      /* mouse pad */
+      if(buf[0] & 0x40) {
+         pad_key_t key;
+         int rel_x = (buf[1] & 0x08) | (buf[1] & 0x10) >> 2 | (buf[1] & 0x20) >> 4 | (buf[1] & 0x40) >> 6;
+         int rel_y = (buf[2] & 0x08) | (buf[2] & 0x10) >> 2 | (buf[2] & 0x20) >> 4 | (buf[2] & 0x40) >> 6;
+         if(buf[0] & 0x02) rel_x |= ~0x10+1;
+         if(buf[0] & 0x01) rel_y |= ~0x10+1;
+
+         /* keyboard direction key emulation */
+         if(context->mode_kbd) {
+            if( context->last_count > 32 )
+            {  /* Hopefully eliminate drift*/
+               context->last_count=0;
+               context->key_y=0;
+               context->key_x=0;
+            }
+            context->last_count++;
+            if(buf[1] & 0x01 || buf[1] >> 2 & 0x01) {
+               //   warn("press\n");
+               /* mouse pressed */
+            }
+
+            if(abs(context->key_x) > CURSOR_LIMIT
+            || abs(context->key_y) > CURSOR_LIMIT ) {
+               if(abs(context->key_y)> abs(context->key_x)) {
+                  /* mouse s/n */
+                  if(context->key_y > 0 && rel_y > 0) { /* mouse s */
+                     key = MOUSE_KEY_S;
+                     buf[0] = 0x68;
+                     buf[1] = 0x82;
+                     buf[2] = 0x91;
+                  } else if(context->key_y < 0 && rel_y < 0) { /* mouse n */
+                     key = MOUSE_KEY_N;
+                     buf[0] = 0x69;
+                     buf[1] = 0x02;
+                     buf[2] = 0x81;
+                  }
+               } else {
+                  /*mouse e/w*/
+                  if(context->key_x > 0 && rel_x > 0) { /* mouse e */
+                     key = MOUSE_KEY_E;
+                     buf[0] = 0x68;
+                     buf[1] = 0x8A;
+                     buf[2] = 0x81;
+                  } else if(context->key_x < 0 && rel_x < 0) { /* mouse w */
+                     key = MOUSE_KEY_W;
+                     buf[0] = 0x6A;
+                     buf[1] = 0x82;
+                     buf[2] = 0x81;
+                  }
+               }
+            } else {
+               context->key_x += rel_x;
+               context->key_y += rel_y;
+               return; /* discard those key codes */
+            }
+         } else {
+            /* mouse emulation */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)
+            struct input_dev *mouse = &context->mouse;
+#else
+            struct input_dev *mouse = context->mouse;
+#endif
+            input_report_key(mouse, BTN_LEFT, buf[1] & 0x01);
+            input_report_key(mouse, BTN_RIGHT, buf[1] >> 2 & 0x01);
+            input_report_rel(mouse, REL_X, rel_x);
+            input_report_rel(mouse, REL_Y, rel_y);
+            input_sync(mouse);
+            return;
+         }
+      }
+
+      /* a key was pressed or a synthetic mouse key let through,
+      * so reset count */
+      context->key_x = 0;
+      context->key_y = 0;
+      context->last_count = 0;
+      /* mouse/kbd button 29 91 15 b7 */
+      if((buf[0] == 0x29) && (buf[1] == 0x91) && (buf[2] == 0x15) && (buf[3] == 0xb7)) {
+         //   warn("toggle kbd %d -> %d\n", context->mode_kbd, !context->mode_kbd);
+         context->mode_kbd = !context->mode_kbd;
+         return;
+      }

      lirc_buffer_write_1 (context ->plugin ->rbuf, buf);
      wake_up (&context ->plugin ->rbuf ->wait_poll);
@@ -769,10 +879,10 @@
/**
  * Callback function for USB core API: receive data
  */
-#ifdef KERNEL_2_5
-static void usb_rx_callback (struct urb *urb, struct pt_regs *regs)
-#else
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 19) || !defined(KERNEL_2_5)
static void usb_rx_callback (struct urb *urb)
+#else
+static void usb_rx_callback (struct urb *urb, struct pt_regs *regs)
#endif
{
   struct imon_context *context;
@@ -1087,6 +1197,41 @@
#endif
   }

+   /* register with kernel input system for PAD mouse */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)
+   context->mouse.evbit[0] = BIT(EV_KEY) | BIT(EV_REL);
+   context->mouse.keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_RIGHT) | BIT(BTN_MIDDLE);
+   context->mouse.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+   context->mouse.keybit[LONG(BTN_MOUSE)] |= BIT(BTN_SIDE) | BIT(BTN_EXTRA);
+   context->mouse.relbit[0] |= BIT(REL_WHEEL);
+   context->mouse.private = context;
+
+   context->mouse.id.bustype = BUS_USB;
+   context->mouse.id.vendor = le16_to_cpu(dev->descriptor.idVendor);
+   context->mouse.id.product = le16_to_cpu(dev->descriptor.idProduct);
+   context->mouse.id.version = le16_to_cpu(dev->descriptor.bcdDevice);
+   context->mouse.dev = &dev->dev;
+
+   input_register_device(&context->mouse);
+#else
+   context->mouse = input_allocate_device();
+   context->mouse->evbit[0] = BIT(EV_KEY) | BIT(EV_REL);
+   context->mouse->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_RIGHT) | BIT(BTN_MIDDLE);
+   context->mouse->relbit[0] = BIT(REL_X) | BIT(REL_Y);
+   context->mouse->keybit[LONG(BTN_MOUSE)] |= BIT(BTN_SIDE) | BIT(BTN_EXTRA);
+   context->mouse->relbit[0] |= BIT(REL_WHEEL);
+   context->mouse->private = context;
+
+   context->mouse->id.bustype = BUS_USB;
+   context->mouse->id.vendor = le16_to_cpu(dev->descriptor.idVendor);
+   context->mouse->id.product = le16_to_cpu(dev->descriptor.idProduct);
+   context->mouse->id.version = le16_to_cpu(dev->descriptor.bcdDevice);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
+   context->mouse->dev = &dev->dev;
+#endif
+
+   input_register_device(context->mouse);
+#endif
   info ("%s: iMON device on usb<%d:%d> initialized",
         __FUNCTION__, dev ->bus ->busnum, dev ->devnum);

@@ -1152,6 +1297,11 @@
#endif
   }

+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)
+   input_unregister_device (&context ->mouse);
+#else
+   input_unregister_device (context ->mouse);
+#endif
   UNLOCK_CONTEXT;

   if (!context ->ir_isopen && !context ->vfd_isopen)


[mike.mbp]

Hey guys, I've been reading up on this patch, the one on Silicon Feind's site, and I have been trying to apply it and get it installed unsucessfully with the built in package installer with ubuntu edgy. I have a fresh install of edgy, so what would be the easiest way to install lirc and apply the patch for the driver?

thanks, sorry for the noob post.

-Mike

[ryanskow]

remy.bohmer - thanks for the port - any chance you have one for lirc 0.8.2? Does anyone know if support will be built in to lirc for this remote any time in the near future? It is kind of a pain to have to re-compile the kernel module after every kernel update...

[DataPath]

The original author of this patch (DataPath) had been working on a "next generation" user-space driver which would just "do the right thing" and you could configure the behavior of the mouse/keyboard button, etc. with configuration files instead of having to patch and recompile. I haven't heard anything from DataPath on this subject in a while, though.

I actually made a userspace lirc driver for the remote, but without mouse support. I had decided on how I wanted to do it, but to make it work from userspace, I'd basically have to write a kernel mouse driver that the userspace lirc driver could write to. I wasn't really happy about having to do that, especially since I didn't think such a thing would be admitted into mainline kernel.

I recently noticed that there is a kernel option (saw it in 2.6.20) for supporting userspace input drivers.

I'm willing to pick up this project again and finish it out, to have a fully userspace imon PAD lirc driver with mouse and keyboard support that is completely native.

[dacorsa]

NEEDS new version of this patch for new kernel 2.6.23!!!

hi to all

thanks