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

[Markus Armbruster <armbru@xxxxxxxxxx>]

Gerd Hoffmann <kraxel@xxxxxxx> writes:

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

Nobody?  Aren't you overstating your case here?  The input layer is
clearly designed to transmit any kind of input event on the same
device, and recent Xorg works fine with 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.

Improvement is good.  Change for change's sake is not.

If we think the proposed change will earn its keep, I'm all for it.

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

If there are evdev clients we care about that can't cope with the
current unified device, I'm fine with splitting it.

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