All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: Xen devel list <xen-devel@lists.xensource.com>,
	"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [patch] pvfb: Split mouse and keyboard into separate devices.
Date: Wed, 07 Feb 2007 15:31:24 +0100	[thread overview]
Message-ID: <877iuu2g5f.fsf@pike.pond.sub.org> (raw)
In-Reply-To: <45C9B880.5060107@suse.de> (Gerd Hoffmann's message of "Wed, 07 Feb 2007 12:31:12 +0100")

Gerd Hoffmann <kraxel@suse.de> writes:

>   Hi,
>
> This patch creates two separate input devices for keyboard and mouse
> events.  Also includes some key bitmap fixes (allow all keyboard keys,
> allow eight mouse buttons).
>
> I hope everyone is happy with that now after the lengthy discussion ;)
>
> please apply,
>   Gerd
>
> -- 
> Gerd Hoffmann <kraxel@suse.de>
> pvfb: Split mouse and keyboard into separate devices.
>
> This patch creates two separate input devices for keyboard and mouse
> events.  The reason for this is to separate them in the linux input
> layer and allow them being routed different ways.
>
> Use case:  Configure the X-Server like this to get the mouse
> events directly from the linux input layer, which has the major
> advantage that absolute coordinates work correctly:
>
> Section "InputDevice"
>   Driver       "evdev"
>   Identifier   "Mouse"
>   Option       "Device" "/dev/input/event<nr>"
> EndSection
>
> This makes the keyboard stop working though in case mouse and
> keyboard events are coming through the same input device, at least
> with older Xorg (6.9) versions.
>
> Signed-off-by: Gerd Hoffmann <kraxel@suse.de>

New, not mentioned in the changelog:

* Initialization of struct input_dev members phys, id.bustype,
  id.vendor, id.product.

* Take care of the FIXME regarding initialization struct input_dev
  member keybit (thanks!).

* Take care of the TODO to enable all pointer buttons.  Perhaps should
  better go in together with the fix to tools/xenfb/vncfb.c posted by
  Daniel.

No objections to any of these.  They ought to be documented in the
changelog, though.  You might prefer separate changesets for some of
them.

> ---
>  linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c |   93 +++++++++++++++-------
>  1 file changed, 65 insertions(+), 28 deletions(-)
>
> Index: build-32-unstable-13816/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c
> ===================================================================
> --- build-32-unstable-13816.orig/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c
> +++
> build-32-unstable-13816/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c
[...]
> @@ -56,23 +58,36 @@ static irqreturn_t input_handler(int rq,
>  	rmb();			/* ensure we see ring contents up to prod */
>  	for (cons = page->in_cons; cons != prod; cons++) {
>  		union xenkbd_in_event *event;
> +		struct input_dev *dev;
>  		event = &XENKBD_IN_RING_REF(page, cons);
>  
> +		dev = info->ptr;
>  		switch (event->type) {
>  		case XENKBD_TYPE_MOTION:
> -			input_report_rel(info->dev, REL_X, event->motion.rel_x);
> -			input_report_rel(info->dev, REL_Y, event->motion.rel_y);
> +			input_report_rel(dev, REL_X, event->motion.rel_x);
> +			input_report_rel(dev, REL_Y, event->motion.rel_y);
>  			break;
>  		case XENKBD_TYPE_KEY:
> -			input_report_key(info->dev, event->key.keycode, event->key.pressed);
> +			dev = NULL;
> +			if (test_bit(event->key.keycode, info->kbd->keybit))
> +				dev = info->kbd;
> +			if (test_bit(event->key.keycode, info->ptr->keybit))
> +				dev = info->ptr;
> +			if (dev)
> +				input_report_key(dev, event->key.keycode,
> +						 event->key.pressed);
> +			else
> +				printk("xenkbd: unhandled keycode 0x%x\n",
> +				       event->key.keycode);
>  			break;
>  		case XENKBD_TYPE_POS:
> -			input_report_abs(info->dev, ABS_X, event->pos.abs_x);
> -			input_report_abs(info->dev, ABS_Y, event->pos.abs_y);
> +			input_report_abs(dev, ABS_X, event->pos.abs_x);
> +			input_report_abs(dev, ABS_Y, event->pos.abs_y);
>  			break;
>  		}
> +		if (dev)
> +			input_sync(dev);

Can !dev happen?

>  	}
> -	input_sync(info->dev);
>  	mb();			/* ensure we got ring contents */
>  	page->in_cons = cons;
>  	notify_remote_via_irq(info->irq);
[...]

  reply	other threads:[~2007-02-07 14:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07 11:31 [patch] pvfb: Split mouse and keyboard into separate devices Gerd Hoffmann
2007-02-07 14:31 ` Markus Armbruster [this message]
2007-02-07 14:36   ` Daniel P. Berrange
  -- strict thread matches above, loose matches on Subject: below --
2007-02-01 10:59 Gerd Hoffmann
2007-02-01 13:15 ` Markus Armbruster
2007-02-01 13:47   ` Gerd Hoffmann
2007-02-01 17:37 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877iuu2g5f.fsf@pike.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kraxel@suse.de \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.