shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-10-30 06:25:37 +03:00
Code
df7f714acc
systemd/rules.d/60-evdev.rules

31 lines
1.1 KiB
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 07:19:58 +03:00
# do not edit this file, it will be overwritten on update
ACTION=="remove", GOTO="evdev_end"
KERNEL!="event*", GOTO="evdev_end"
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03:00
# Execute the match patterns below, from least-to-most specific.
# Device matching the modalias string (bustype, vendor, product, version, other properties)
IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:",
ENV{.HAVE_HWDB_PROPERTIES}="1"
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 07:19:58 +03: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 14:43:05 +03: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 07:19:58 +03:00
IMPORT{builtin}="hwdb 'evdev:atkbd:$attr{[dmi/id]modalias}'", \
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03:00
ENV{.HAVE_HWDB_PROPERTIES}="1"
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 07:19:58 +03:00
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03: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 07:32:48 +03:00
KERNELS=="input*", \
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03:00
IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
ENV{.HAVE_HWDB_PROPERTIES}="1"
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 14:33:22 +03:00
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03: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 07:32:48 +03:00
KERNELS=="input*", \
udev: rework 60-evdev.rules to be "additive" We would execute up to four hwdb match patterns (+ the keyboard builtin): After the first hit, we would skip the other patterns, because of the GOTO="evdev_end" action. 57bb707d48131f4daad2b1b746eab586eb66b4f3 (rules: Add extended evdev/input match rules for event nodes with the same name), added an additional match with ":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user hwdb patterns, because we quit after the first match. In general hwdb properties are "additive". We often have a general rule that matches a wider class and then some specific overrides. E.g. in this particular case, we have a match for all trackpoints, and then a bunch of model-specific settings. So let's change the rules to try all the match patterns and combine the received properties. We execute builtin-keyboard once at the end, if there was at least one match. Fixes #25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226. This also impacts other cases which I think would be very confusing for users. Since we quit after a first successful match, if we had e.g. a match for 'evdev:input:b*v*p*' in out database, and the user added a match using 'evdev:name:*', which is the approach we document in the .hwdb files and which users quite often use, it would be silently ignored. What's worse, if we added our 'evdev:input:b*v*p*' match at a later point, user's match would stop working. If we combine all the properties, we get more stable behaviour.
2022-12-12 14:52:12 +03:00
IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'", \
ENV{.HAVE_HWDB_PROPERTIES}="1"
ENV{.HAVE_HWDB_PROPERTIES}=="1", \
IMPORT{builtin}="keyboard"
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 07:19:58 +03:00
LABEL="evdev_end"
Copy Permalink