From: Gerd Hoffmann <kraxel@redhat.com>
To: Ladi Prosek <lprosek@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PULL v2 8/9] input-linux: refine mouse detection
Date: Thu, 14 Apr 2016 10:07:15 +0200 [thread overview]
Message-ID: <1460621235.13389.8.camel@redhat.com> (raw)
In-Reply-To: <CABdb7349qeT8wz3wahBoLAWHXXcsr+v-XLgXJvCQH0Bx=+-yZA@mail.gmail.com>
On Do, 2016-04-14 at 09:42 +0200, Ladi Prosek wrote:
> On Wed, Apr 13, 2016 at 5:45 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > Read absolute and relative axis information, only classify
> > devices as mouse/tablet in case the x axis is present.
>
> I, too, had to come up with a heuristic to classify input devices in
> my guest driver and what I ended up with is different.
>
> For example my Dell keyboard has two endpoints, one with a bunch of
> keys and LEDs, so it would be classified as a keyboard. The second one
> with special keys (KEY_MUTE, KEY_WWW, KEY_BACK, ..) *and* with a mouse
> (REL_X, REL_Y, REL_WHEEL, BTN_LEFT, ...). The reason for this are the
> zoom in/out buttons. Pressing them generates Ctrl down on the first
> endpoint and mouse wheel up/down on the second one. Releasing them
> then translates to Ctrl up. Crazy.
So they are building os-specific hotkeys into the hardware. Crazy
indeed.
It's not obvious though why the second function has keyboard keys.
Possibly they want the first function look like a pretty standard
keyboard without any extra fluff, to sidestep compatibility issues with
old software not expecting that.
> So I wouldn't use exclusive OR when classifying because there are
> combo devices out there. Maybe anything with an EV_KEY (minus BTN_*)
> would be a keyboard?
Right now each device type has its own callback function, we have to
reorganize that to support a device being classified as both mouse and
keyboard. Worth considering, but not 2.6 material.
There surely is more room for improvements, not only in input-linux but
in the input system in general and in the virtual input devices, for
example to support all those extra keys on multimedia keyboards.
cheers,
Gerd
next prev parent reply other threads:[~2016-04-14 8:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-13 15:44 [Qemu-devel] [PULL v2 0/9] virtio-input; live migration support, various bugfixes Gerd Hoffmann
2016-04-13 15:44 ` [Qemu-devel] [PULL v2 1/9] virtio-input: add parenthesis to const_le{16, 32} Gerd Hoffmann
2016-04-13 15:44 ` [Qemu-devel] [PULL v2 2/9] move const_le{16, 23} to qemu/bswap.h, add comment Gerd Hoffmann
2016-04-13 15:44 ` [Qemu-devel] [PULL v2 3/9] virtio-input: add missing key mappings Gerd Hoffmann
2016-04-13 15:44 ` [Qemu-devel] [PULL v2 4/9] virtio-input: retrieve EV_LED host config bits Gerd Hoffmann
2016-04-13 15:44 ` [Qemu-devel] [PULL v2 5/9] virtio-input: implement pass-through evdev writes Gerd Hoffmann
2016-04-13 15:45 ` [Qemu-devel] [PULL v2 6/9] virtio-input: add live migration support Gerd Hoffmann
2016-04-13 15:45 ` [Qemu-devel] [PULL v2 7/9] virtio-input: fix emulated tablet axis ranges Gerd Hoffmann
2016-04-13 15:45 ` [Qemu-devel] [PULL v2 8/9] input-linux: refine mouse detection Gerd Hoffmann
2016-04-14 7:42 ` Ladi Prosek
2016-04-14 8:07 ` Gerd Hoffmann [this message]
2016-04-13 15:45 ` [Qemu-devel] [PULL v2 9/9] virtio-input: support absolute axis config in pass-through Gerd Hoffmann
2016-04-14 9:06 ` [Qemu-devel] [PULL v2 0/9] virtio-input; live migration support, various bugfixes Peter Maydell
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=1460621235.13389.8.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=lprosek@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).