[systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
David Herrmann
dh.herrmann at gmail.com
Tue Apr 7 05:06:33 PDT 2015
Hi
On Tue, Apr 7, 2015 at 1:52 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 07-04-15 13:46, David Herrmann wrote:
>>
>> Hi
>>
>> On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>
>>>> The series looks reasonable, but I wonder why we cannot merge it into
>>>> 60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
>>>> case, please make this a builtin of input_id which uses
>>>> udev_device_get_parent_subsystem_devtype() and look for the
>>>> serio/atkbd (?) parent device, instead of hard-coding the path.
>>>
>>>
>>>
>>> Why would we want to merge this into keyboard rules/hwdb? Trackpoints
>>> always have a separate driver, input device and event node.
>>
>>
>> Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
>> now trackpoint:foobar, instead of a single lookup for evdev:foobar.
>>
>> To me, it looks much easier if we have one generic evdev rule, which
>> searches the hwdb based on the input-modalias via
>> evdev:input:<modalias> and the legacy fallback,
>> evdev:name:<name>:<dmi>
>>
>> Depending on what properties where found, we simply apply them to the
>> evdev node.
>
>
> Ah, I see so what you're suggesting is in essence dropping the
>
> ENV{ID_INPUT_KEY}=="", GOTO="keyboard_end"
>
> Rule from rules/60-keyboard.rules
>
> And s/keyboard/evdev/ as one of Peter's updated patches is already doing,
> while keeping the hwdb bits the same, except that the prefix for the
> matches would be evdev instead of pointingstick ?
>
> And teaching the keyboard^Wevdev builtin to handle
> POINTINGSTICK_SENSITIVITY and write the sysfs attribute ?
Exactly. Peter already did most of this in his series, so we might
wanna wait for him to push it.
I'm actually only waiting for Kay to ACK the prefix 'evdev', then I'd
push it myself and we can rebase your series.
Thanks
David
More information about the systemd-devel
mailing list