Re: Re: [patch] pvfb: Split mouse and keyboard into separate devices.

[Gerd Hoffmann <kraxel@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]

  Hi,

> 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.

That happens to work with Xorg 7.2, and even for that you'll have to
play tricks like providing a dummy keyboard config section because Xorg
expects one device for the keyboard and one for the mouse.

It doesn't work with older Xorg releases, 6.9 for example.

I havn't even checked other applications.  gpm?  framebuffer-based stuff?

Nobody expects mouse and keyboard events coming from a single device.
I still think it is much better to split it.

> 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.)

This is xorg 7.2+ only.  With older xorg releases it just doesn't work
as they don't support keyboards via evdev yet.

> 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

With two separate devices you can also simply change the mouse device
section to use the "evdev" driver instead of the "mouse" driver, config
file attached.

The third section is needed only if you want to be conservative and
continue to use the "mouse" driver unless you know the "evdev" driver
works better with the device in question.  And you better match by name
or id then instead of specifying the device (that requires xorg 7.2+
though).

> 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.

So what?  Nobody forces you to change that in RHEL5.  That is no reason
to not pick the better solution for the long run.  Changes like this
happen all day in linux land.

> Both approaches have the
> same end result

No, see above.

> 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.

Using evdev by default for the mouse maybe?

> So I don't really see any compelling reason to change the way the input
> devices are exposed.

I do.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

[-- Attachment #2: xorg.conf --]
[-- Type: text/plain, Size: 715 bytes --]

# xorg 7.2+ config file, using ...
#  - fbdev for the screen
#  - evdev for the mouse

# keyboard
Section "InputDevice"
  Driver	"kbd"
  Identifier	"Keyboard"
  Option	"XkbModel"	"pc105"
  Option	"XkbLayout"	"us"
EndSection

# mouse, using evdev
Section "InputDevice"
  Driver	"evdev"
  Identifier	"Mouse"
  Option        "evBits"	"+1 ~2-3"	# ev_key && (ev_rel || ev_abs)
  Option        "keyBits"	"~256-287"	# btn_*
EndSection

Section "Screen"
  Device	"fbdev"
  Identifier	"fbdev"
EndSection

Section "Device"
  Driver	"fbdev"
  Identifier	"fbdev"
EndSection

Section "ServerLayout"
  Identifier	"default"
  Screen	"fbdev"
  InputDevice	"Keyboard"	"CoreKeyboard"
  InputDevice	"Mouse"		"CorePointer"
EndSection


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel