mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-23 10:13:34 +08:00
Code Issues Packages Projects Releases Wiki Activity
7b37aea98c
systemd/rules.d/60-evdev.rules

26 lines
990 B
Plaintext
Raw Normal View History

udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
# do not edit this file, it will be overwritten on update
ACTION=="remove", GOTO="evdev_end"
KERNEL!="event*", GOTO="evdev_end"
# skip later rules when we find something for this input device
IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:", \
rules.d: import the keyboard builtin instead of running it RUN seems to be used primarily for historical reasons over the more immediate IMPORT command. As a side-effect, RUN also runs *after* all the rules have been processed which is not really what we want here - we expect the device to be updated immediately. Other rules that rely on accurate evdev axes should be able to assume the axes are already present. So let's use IMPORT here. For consistency, the second two rules are split across multiple lines as well.
2020-02-10 12:32:48 +08:00
IMPORT{builtin}="keyboard", GOTO="evdev_end"
udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
# AT keyboard matching by the machine's DMI data
rules: move input_id rule to a separate file This places the input_id call after the evdev hwdb calls. With this the hwdb fixups in evdev can affect the device capabilities assigned in input_id. Remove the ID_INPUT_KEY dependency in atkbd rule because it is now not assigned at this point.
2017-06-12 19:43:05 +08:00
DRIVERS=="atkbd", \
udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
IMPORT{builtin}="hwdb 'evdev:atkbd:$attr{[dmi/id]modalias}'", \
rules.d: import the keyboard builtin instead of running it RUN seems to be used primarily for historical reasons over the more immediate IMPORT command. As a side-effect, RUN also runs *after* all the rules have been processed which is not really what we want here - we expect the device to be updated immediately. Other rules that rely on accurate evdev axes should be able to assume the axes are already present. So let's use IMPORT here. For consistency, the second two rules are split across multiple lines as well.
2020-02-10 12:32:48 +08:00
IMPORT{builtin}="keyboard", GOTO="evdev_end"
udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
rules: Add extended evdev/input match rules for event nodes with the same name Sometimes a system may have 2 input event nodes with the same name where we only want to apply keyboard hwdb rules to 1 of the 2 devices. This problem happens e.g. on devices where the soc_button_array driver is used (e.g. intel atom based tablets) which registers 2 event nodes with the name "gpio-keys". This commit adds a new extended match rule which extends the match to also check $attr{phys} and $attr{capabilities/ev}, allowing to differentiate between devices with an identical name. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2017-02-12 19:33:22 +08:00
# device matching the input device name + properties + the machine's DMI data
rules.d: import the keyboard builtin instead of running it RUN seems to be used primarily for historical reasons over the more immediate IMPORT command. As a side-effect, RUN also runs *after* all the rules have been processed which is not really what we want here - we expect the device to be updated immediately. Other rules that rely on accurate evdev axes should be able to assume the axes are already present. So let's use IMPORT here. For consistency, the second two rules are split across multiple lines as well.
2020-02-10 12:32:48 +08:00
KERNELS=="input*", \
IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'", \
IMPORT{builtin}="keyboard", GOTO="evdev_end"
rules: Add extended evdev/input match rules for event nodes with the same name Sometimes a system may have 2 input event nodes with the same name where we only want to apply keyboard hwdb rules to 1 of the 2 devices. This problem happens e.g. on devices where the soc_button_array driver is used (e.g. intel atom based tablets) which registers 2 event nodes with the name "gpio-keys". This commit adds a new extended match rule which extends the match to also check $attr{phys} and $attr{capabilities/ev}, allowing to differentiate between devices with an identical name. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2017-02-12 19:33:22 +08:00
udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
# device matching the input device name and the machine's DMI data
rules.d: import the keyboard builtin instead of running it RUN seems to be used primarily for historical reasons over the more immediate IMPORT command. As a side-effect, RUN also runs *after* all the rules have been processed which is not really what we want here - we expect the device to be updated immediately. Other rules that rely on accurate evdev axes should be able to assume the axes are already present. So let's use IMPORT here. For consistency, the second two rules are split across multiple lines as well.
2020-02-10 12:32:48 +08:00
KERNELS=="input*", \
IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
IMPORT{builtin}="keyboard", GOTO="evdev_end"
udev: builtin-keyboard: add support for EVDEV_ABS_* Parse properties in the form EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>" and apply them to the kernel device. Future processes that open that device will see the updated EV_ABS range. This is particularly useful for touchpads that don't provide a resolution in the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974). All values in the property are optional, e.g. a string of "::45" is valid to set the resolution to 45. The order intentionally orders resolution before fuzz and flat despite it being the last element in the absinfo struct. The use-case for setting fuzz/flat is almost non-existent, resolution is probably the most common case we'll need. To avoid multiple hwdb invocations for the same device, replace the hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules file. The new 60-evdev.rules is called for all event nodes anyway, we don't need a separate rules file and second callout to the hwdb builtin.
2015-03-19 12:19:58 +08:00
LABEL="evdev_end"
Reference in New Issue Copy Permalink