This is a pair of Xen para-virtual frontend device drivers:

drivers/video/xen-fbfront.c provides a framebuffer, and

drivers/input/xen-kbdfront provides keyboard and mouse.
The backends run in dom0 user space.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 drivers/input/Kconfig            |    9

 drivers/input/Makefile           |    2

 drivers/input/xen-kbdfront.c     |  337 +++++++++++++++++++++++

 drivers/video/Kconfig            |   14

 drivers/video/Makefile           |    1

 drivers/video/xen-fbfront.c      |  550 +++++++++++++++++++++++++++++++++++++++

 include/xen/interface/io/fbif.h  |  124 ++++++++

 include/xen/interface/io/kbdif.h |  114 ++++++++

 8 files changed, 1151 insertions(+)
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig

index 9dea14d..5f9d860 100644

--- a/drivers/input/Kconfig

+++ b/drivers/input/Kconfig

@@ -149,6 +149,15 @@ config INPUT_APMPOWER

 	  To compile this driver as a module, choose M here: the

 	  module will be called apm-power.
+config XEN_KBDDEV_FRONTEND

+	tristate "Xen virtual keyboard and mouse support"

+	depends on XEN_FBDEV_FRONTEND

+	default y

+	help

+	  This driver implements the front-end of the Xen virtual

+	  keyboard and mouse device driver.  It communicates with a back-end

+	  in another domain.

+

 comment "Input Device Drivers"
 source "drivers/input/keyboard/Kconfig"

diff --git a/drivers/input/Makefile b/drivers/input/Makefile

index 2ae87b1..98c4f9a 100644

--- a/drivers/input/Makefile

+++ b/drivers/input/Makefile

@@ -23,3 +23,5 @@ obj-$(CONFIG_INPUT_TOUCHSCREEN)	+= touchscreen/

 obj-$(CONFIG_INPUT_MISC)	+= misc/
 obj-$(CONFIG_INPUT_APMPOWER)	+= apm-power.o

+

+obj-$(CONFIG_XEN_KBDDEV_FRONTEND)	+= xen-kbdfront.o

diff --git a/drivers/input/xen-kbdfront.c b/drivers/input/xen-kbdfront.c

new file mode 100644

index 0000000..84f65cf

--- /dev/null

+++ b/drivers/input/xen-kbdfront.c

@@ -0,0 +1,337 @@

+/*

+ * Xen para-virtual input device

+ *

+ * Copyright (C) 2005 Anthony Ligu...
[ message continues ]

Unless they're actually inter-dependent, could you post this as two

separate patches?  I don't know anything about these parts of the

kernel, so it would be nice to make it very obvious which changes are fb

vs mouse/keyboard.
(I guess input/* vs video/* should make it obvious, but it looks like

input has a config dependency on fb, so I'll avoid making too many

presumptions...)
(Couple of comments below)
--

I could do that do that, but the intermediate step (one driver, not

the other) is somewhat problematic: the backend in dom0 needs both

drivers, and will refuse to complete device initialization unless
Framebuffer: fbif.h xen-fbfront.c

Keyboard/mouse: kbdif.h xen-kbdfront.h
I added the config dependency because having one without the other

doesn't make sense, as explained above.
It's designed that way.  dev->info is initialized so that

xenkbd_remove() does nothing.  Then stuff is stored into dev->info

only when it's sufficiently initialized for xenkbd_remove() to clean
Yes.  xenkbd_probe() initializes info->kbd and info->ptr to null, and

changes that to the device only after input_register_device()

succeeds.  If something goes wrong between input_allocate_device() and

input_register_device(), xenkbd_probe() frees the device with

input_free_device().  This is how input_register_device() wants to be

used according to its function comment:
    /**

     * input_register_device - register device with input core

     * @dev: device to be registered

     *

     * This function registers device with input core. The device must be

     * allocated with input_allocate_device() and all it's capabilities

     * set up before registering.

     * If function fails the device must be freed with input_free_device().

     * Once device has been successfully registered it can be unregistered

     * with input_unregister_device(); input_free_device() should not be

     * called in this case.

     */
There's another bug here: must not call input_unregister_device() when

the device is still null.  Man, I remember checking cleanup multiple

times when this stuff went into Xen (i.e. quite some time ago), and I

[...]
Thanks!

--

That's OK.  In that case keep them together.
    J

--

Groovy. :-)
Thanks,

jaya

--