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

[Dan Nicholson]

On Sun, Nov 29, 2009 at 2:50 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> 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
> values).
>
> 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.

Oh, I see what you mean. That seems alright, except I was hoping that
there would be more than name and path to match on. These patches
support boolean pointer and keyboard attributes, and probably boolean
touchpad and touchscreen attributes would be needed. If it's not a
problem to overload InputOptions in this way (drivers would probably
ignore them), then that would work.

--
Dan