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: Re: [patch] pvfb: Split mouse and keyboard into separate devices.
Date: Tue, 06 Feb 2007 19:40:29 +0100	[thread overview]
Message-ID: <8764af3zaa.fsf@pike.pond.sub.org> (raw)
In-Reply-To: <45C840F3.1070808@suse.de> (Gerd Hoffmann's message of "Tue, 06 Feb 2007 09:48:51 +0100")

Gerd Hoffmann <kraxel@suse.de> 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.

  parent reply	other threads:[~2007-02-06 18:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-01 10:59 [patch] pvfb: Split mouse and keyboard into separate devices Gerd Hoffmann
2007-02-01 13:15 ` Markus Armbruster
2007-02-01 13:47   ` Gerd Hoffmann
2007-02-01 17:37 ` Markus Armbruster
2007-02-01 18:05   ` Daniel P. Berrange
2007-02-02  8:39     ` Gerd Hoffmann
2007-02-02 15:25       ` Keir Fraser
2007-02-02 16:29         ` Gerd Hoffmann
2007-02-02 18:11           ` Keir Fraser
2007-02-03  0:28             ` Daniel P. Berrange
2007-02-03  3:51               ` Daniel P. Berrange
2007-02-05  9:20                 ` Gerd Hoffmann
2007-02-05 14:19                 ` Gerd Hoffmann
2007-02-05  9:10               ` Gerd Hoffmann
2007-02-05 20:55                 ` Daniel P. Berrange
2007-02-06  8:48                   ` Gerd Hoffmann
2007-02-06 13:45                     ` Daniel P. Berrange
2007-02-06 15:05                       ` Gerd Hoffmann
2007-02-06 18:40                     ` Markus Armbruster [this message]
2007-02-07  9:35                       ` Gerd Hoffmann

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=8764af3zaa.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.