[PATCH v2 2/3] config: Introduce InputAttributes in NewInputDeviceRequest

Daniel Stone daniel at fooishbar.org
Sun Nov 29 14:50:23 PST 2009


On Sun, Nov 29, 2009 at 09:05:47AM -0800, Dan Nicholson wrote:
> On Sat, Nov 28, 2009 at 8:25 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> > On Fri, Nov 27, 2009 at 02:01:00PM -0800, Dan Nicholson wrote:
> >> In order to give NewInputDeviceRequest more information, a new
> >> InputAttributes type is introduced. Currently, this collects the product
> >> name, device path, and sets booleans for having keys and/or a pointer.
> >> Only the HAL backend fills in the structure, though.
> >
> > Any reason you can't just fill in InputOptions? The Xorg and KDrive NIDR
> > implementations already recognise device/path as a valid option.
> I'm not sure I'm following exactly, but the options do get merged back
> into idev->commonOptions. If you mean it should be done in the config
> backend and passed through NIDR, I don't think I can do that here
> since I'm relying on using xorg.conf. That could only happen the the
> xfree86 ddx. Right now the only DDX-independent config store is HAL,
> and this is an effort to move away from it.
> Can you clarify?

Well, you've created a new InputAttributes type to contain a couple of
specialised values, and changed the NewInputDeviceRequest API to take
not only InputOptions (key, value), but also InputAtributes (specific

Is there any reason not to, rather than fill in the name or path fields
of InputAttributes, instead have an InputOption with a key of 'name' or
'path'? This is completely backend-independent, and both Xorg and KDrive
already recognise common attributes passed in as InputOptions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091130/a2c9f25d/attachment.pgp 

More information about the xorg-devel mailing list