From: Greg Kroah-Hartman <gregkh@suse.de>

This patch adds the Mimio Xi interactive whiteboard driver to the tree.

It was originally written by mwilder@cs.nmsu.edu, but cleaned up and
forward ported by me to the latest kernel version.


Cc: Phil Hannent <phil@hannent.co.uk>
Cc: <mwilder@cs.nmsu.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/input/misc/Kconfig  |   11 
 drivers/input/misc/Makefile |    1 
 drivers/input/misc/mimio.c  |  913 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 925 insertions(+)

--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -164,6 +164,17 @@ config INPUT_POWERMATE
 	  To compile this driver as a module, choose M here: the
 	  module will be called powermate.
 
+config INPUT_MIMIO
+	tristate "Mimio Xi interactive whiteboard support"
+	depends on USB_ARCH_HAS_HCD
+	select USB
+	help
+	  Say Y here if you want to use a Mimio Xi interactive
+	  whiteboard device.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called mimio.
+
 config INPUT_YEALINK
 	tristate "Yealink usb-p1k voip phone"
 	depends on EXPERIMENTAL
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ATI_REMOTE)		+= ati_r
 obj-$(CONFIG_INPUT_ATI_REMOTE2)		+= ati_remote2.o
 obj-$(CONFIG_INPUT_KEYSPAN_REMOTE)	+= keyspan_remote.o
 obj-$(CONFIG_INPUT_POWERMATE)		+= powermate.o
+obj-$(CONFIG_INPUT_MIMIO)		+= mimio.o
 obj-$(CONFIG_INPUT_YEALINK)		+= yealink.o
 obj-$(CONFIG_HP_SDC_RTC)		+= hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_UINPUT)		+= uinput.o
--- /dev/null
+++ b/drivers/input/misc/mimio.c
@@ -0,0 +1,913 @@
+/*
+ * Hardware event => input event mapping:
+ *
+ *
+ *
+ input.h:#define BTN_TOOL_PEN            0x140 black
+ input.h:#define BTN_TOOL_RUBBER         0x141 blue
+ input.h:#define BTN_TOOL_BRUSH          0x142 green
+ input.h:#define BTN_TOOL_PENCIL         0x143 red
+ input.h:#define BTN_TOOL_AIRBRUSH       0x144 ...
[ message continues ]

Prefer not to select entire subsystems, but to depend on them.



---
~Randy
--

[ message continues ]

Thanks, will fix.

Thanks for the review, I appreciate it.

greg k-h
--

[ message continues ]

I have been given the protocol document for the whiteboards, I am not all=
owed to
share it with anybody unfortunately.

I am just waiting for approval of funds for me to start development of th=
is
driver and an X11 library to make the ink capture work.

I expect to start work at the end of October, I could do with a mentor to=
 help
me with this.

Just so you do not get the wrong idea, I plan on sticking around to maint=
ain the
driver once its complete even if its my spare time to do so.

Regards
Phil Hannent


[ message continues ]

That's great news, and not that big of a deal about the "no share" issue

Um, what's wrong with the driver that I just posted?  Does it not work
properly?  I'll gladly accept patches for things that are wrong, but

If you need help on the kernel side, feel free to contact me off-list.

thanks,

greg k-h
--

[ message continues ]

Hello.  I am the original developer of the mimio Xi driver for 2.4 
kernel linux. I have been observing this particular thread of emails for 
quite some time. I haven't been able to devote much attention to the 
developments in this thread because my primary research emphasis lies 
elsewhere.  Recent events, however, have provoked me to pay close 
attention to this thread.

I would like to thank gregkh@suse.de for his work folding in the 
2.6-specific mods to the driver.  This is something that I do not have the 
time to do, and I am glad to see that he has taken up the slack so 
that others may benefit from this work.


What _is_ wrong with the driver?  I am guessing that phil@hannet.co.uk is 
just struggling with creating X bindings for the module, but I would like 
to hear some elaboration on what is actually happening here.  Enlighten 
me.



--

[ message continues ]

grumble.

- should be written in C


ooh, a semaphore - I remember them.

checkpatch used to warn about newly-added semaphores but a) it broke and

I believe that gcc does the right thing here, but an explict `static' would set
minds at ease.


--

[ message continues ]