On Mon, Feb 05, 2007 at 10:10:45AM +0100, Gerd Hoffmann wrote:
> Daniel P. Berrange wrote:
> > - One input device supplies both mouse & keyboard events - this is
> > basically same as current PVFB setup (appears /dev/input/event0)
> > - A second device supplies only mouse events (/dev/input/event1)
>
> Bad idea IMHO ...
Yep, that's unneccessary since I realized you can have a single
device doing both mouse&keyboard, and get absolute co-ords from it
with no issues.
> > from event1 no longer get reported via the unified mouse channel. Of
> > course we still have the relative coords coming in on event0 though
> > and thus into X via the 'mouse' driver which mess things up.
>
> ... exactly thats why.
>
> As long as /dev/input/event* isn't used there is absolutely no
> difference in having a single or two separate devices for keyboard and
> mouse events. In both cases all events go through the kernel's keyboard
> driver and /dev/input/mice. The mouse "just works" with the default
> X-Server configuration, using relative coordinates though.
Yep, I was mistaken in my previous mail about the dual device not working
with relative mouse out of the box.
> Having two separate devices allows to handle mouse events only via
> /dev/input/event to (optionally) have a better configuration with
> absolute coordinates, without messing up the keyboard.
>
> You can even create a configuration file which works fine in both cases:
> xen virtual mouse being present and being not present.
>
> Why do you want to keep the device with both keyboard and mouse events?
>
> It makes things much more complicated IMHO.
AFAICT, there is zero difference in complexity of configuration. In both
cases, if you have a default Xorg config, the relative mouse will work
out of the box.
With the existing single keyboard+mouse device there is a single
config section to add:
Section "InputDevice"
Identifier "XenInput0"
Driver "evdev"
Option "CorePointer"
Option "SendCoreEvents"
Option "Device" "/dev/input/event0"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
(Possibily with the extra 'Option' tags you noted in the previous
mail for legacy xorg releases of evdev.)
While with the two separate devices, there is a single section to add:
Section "InputDevice"
Identifier "XenInput0"
Driver "evdev"
Option "CorePointer"
Option "Device" "/dev/input/event1"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
So there is only 1 line difference in the Xorg config required to get the
absolute mouse working in both cases. If we were implementing PVFB from
scratch today, I think I'd agree that having separate devices for mouse
and keyboard would be the approach to take. At this time, though we already
have done releases with the current single device. Both approaches have the
same end result - relative mouse just works, and absolute mouse requires 1
section added to the xorg config.
In addition, Xorg is moving towards auto-configuring all devices so I hope
that we'll be able to get X to auto-configure absolute mouse correctly
without need for any config at all regardless of which impl we have.
So I don't really see any compelling reason to change the way the input
devices are exposed.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home