The following device properly got assigned ID_PATH with eudev 3.2.1,
but does not get it any more with recent versions:
P: /devices/platform/rt5651-sound/sound/card0
E: DEVPATH=/devices/platform/rt5651-sound/sound/card0
E: SOUND_FORM_FACTOR=internal
E: SOUND_INITIALIZED=1
E: SUBSYSTEM=sound
E: USEC_INITIALIZED=507638688065
This results in pulseaudio giving a non-stable card name by using a
device number.
I tracked the problem to commit
47367bc4df, which changed (without
explaining why it does so) the rules for "internal" sound cards,
notably preventing `IMPORT{builtin}="path_id"` from being reached.
Signed-off-by: Yann Dirson <yann@blade-group.com>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This fixes#182 by ensuring @bindir@ is fully expanded at installation
time. See "Installation Directory Variables" in the GNU Autoconf
manual, in particular the note about AC_CONFIG_FILES.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Commit bb070c1 forgot to include the installation of 60-input-id.rules
and 70-joystick.rules via the Makefile. Without this, commits dba4728
and 5df0137 leave the system without any useable input devices.
Update to match systemd v235-1952-gba3182b91
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This commit adds a rules file to extract the properties from hwdb
to set on i2c IIO devices. This is used to set the ACCEL_MOUNT_MATRIX
property on IIO devices, to be consumed by iio-sensor-proxy or
equivalent daemon.
The hwdb file contains documentation on how to write quirks. Note
however that mount information is usually exported in:
- the device-tree for ARM devices
- the ACPI DSDT for Intel-compatible devices
but currently not extracted by the kernel.
Also note that some devices have the framebuffer rotation that changes
between the bootloader and the main system, which might mean that the
accelerometer is then wrongly oriented. This is a missing feature in the
i915 kernel driver: https://bugs.freedesktop.org/show_bug.cgi?id=94894
which needs to be fixed, and won't require quirks.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
It is often suggested that users set noop on SSDs and it turns out that
udev can do this for users.
Setting noop disables the IO priorization and IO reordering logic inside
the kernel, but leaves front/back merging in place. This reduction in
overhead should increase the number of requests sent to solid state
media to the maximum possible,which is said to improve performance on
SSDs. Unfortunately, few benchmarks try real world work loads with a
clear cache to measure the actual difference.
The benchmarks conducted by Daniel Nashed cleared the cache. They favor
noop, although the workload seems somewhat unrealistic:
http://blog.nashcom.de/nashcomblog.nsf/dx/linux-io-performance-tweek.htm
The BFQ developers' benchmarks on SSDs appear to account for both. They
show noop as being far better than CFQ and second only to BFQ, which is
out of tree:
https://lwn.net/Articles/600366/
In addition, I have experienced lockup-like effects on ext4 on an OCZ
Vertex 2 SSD with the discard mount option enabled when recursively
unlinking a subdirectory path that contains millions of files. The
system was useless for hours. Setting noop allowed the unlink to finish
in minutes. This is because the reordering from CFQ interleaved the
TRIM command with write IOs, effectively putting barriers between them
because because TRIM is a non-queued command prior to SATA 3.1.
A good default should perform well in general and have the property that
poor performance in the worst case scenarios is minimized. The
previous examples contradict CFQ's ability to achieve that on solid
state media.
I believe that we should implement a udev rule to set noop on solid
state media by default. It should be said that Milan Broz wrote it
first, although there is only one way to write this rule in a manner
consistent with the codebase:
http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6045
It should be said that this will be a regression for those that rely on
the "Block IO Controller" cgroup because it is only supported by CFQ
when CONFIG_CFQ_GROUP_IOSCHED=y. My experience as a ZoL developer is
that very few users rely on this behavior and consequently, I believe
that the benefit from enabling this far outweighs the harm to the few
that need it. Those that do need it should be able to disable this rule
themselves. Container management software that expects the Block IO
Controller to be supported should be modified to enable CFQ explicitly
if it does not already do that.
This has been tested against both a SATA mechanical drive and a SATA
solid state drive. It changes the elevator to noop on the solid state
drive, but does not touch it on the mechanical drive.
Signed-off-by: Richard Yao <ryao@gentoo.org>
The main purpose of this hwdb was to tag touchpads that have the physical
trackstick buttons wired to the touchpad (Lenovo Carbon X1 3rd, Lenovo *50
series). This hwdb is not required on kernels 4.0 and above, the kernel now
re-routes button presses through the trackstick's device node. Userspace does
not need to do anything.
See kernel commit cdd9dc195916ef5644cfac079094c3c1d1616e4c.
This reverts commit 001a247324b44c0e0b8fdba41a6fc66e7465b8b6.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
It is not udev's task to apply any of these setting that way, or
from udev rules files. Things need to be sortet out in the kernel,
or explicit whitelist can possibly be added to the hardware database.
Until that is sorted out, and general agreement, udev is not
willing to maintain any such lists or power management settings
in general.
"Thanks for digging this out! I thought my Kinesis keyboard got broken
and ordered a new one, only to find out that the new one doesn't work
as well. I'm not sure whether we should start collecting a blacklist
of keyboards which don't work with USB autosuspend, or rather a
whitelist? Or revert this wholesale?"
https://github.com/systemd/systemd/issues/340
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The original commit (1aff206) doesn't explain why these were removed.
This adds them back since they are in fact needed.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
When processing an event, the watch is disabled, make sure it is restorted after
a CHANGE event has been processed.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The intention was to turn this rule from using a blacklist to a whitelist, but
there was a stray '!'.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
USB and PCI soundcards have a nice set of ID_* properties. It would
be handy for firewire soundcards to have the same.
Note that this removes the explicit setting of ID_ID in the firewire
conditional. Because we are now setting ID_SERIAL, ID_ID will come
from later in the file.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The ALSA id sysattr is generated by the sound subsystem and is not
a stable identifier. It is generated though some string manipulation
then made unique if there is a conflict. This means that it is
enumeration-dependent and shouldn't be used for ID_ID.
If ID_ID is supposed to be system-unique, it is not already since
for firewire it is generated from the guid and there are broken
firewire devices that have duplicate guids across devices.
This is tracked for PulseAudio at
https://bugs.freedesktop.org/show_bug.cgi?id=90129.
This is essentially a revert of systemd
ed1b2d9fc7.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
We only care about whether our direct parent is removable, not whether any
further points up the tree are - the kernel will take care of policy for
those itself. This enables autosuspend on devices where the root hub reports
that its removable state is unknown.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
On Mon, Mar 23, 2015 at 8:55 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
> On Tue, Mar 17, 2015 at 11:50 PM, Kay Sievers <kay@vrfy.org> wrote:
>> On Tue, Mar 17, 2015 at 5:00 PM, Mantas Mikulėnas <grawity@gmail.com>
>> wrote:
>> > Accidentally dropped in 1aff20687f4868575.
>> > ---
>> > rules/60-persistent-storage.rules | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> > +KERNEL!="loop*|mmcblk[0-9]*|mspblk[0-9]*|nvme*|sd*|sr*|vd*",
>> > GOTO="persistent_storage_end"
>>
>> We can't do that, we need to ignore the mmc*rpmb devices:
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01cf83947f467f3c46d9831cd67955fc46b9
>>
>> Maybe "mmcblk*[0-9]" will work?
>
> Yeah, that would probably work (the names are like mmcblk0p1 etc.)
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
We should never access parents, as the sysfs hierarchy is in no way
stable. Use KERNELS== etc. to match on a parent, then access it via
$attr{} (which accesses the matching device, not the current device).
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
We match on the evdev node, but only the parent has a "name" attribute.
Use $attr{device/name} to access it.
This is borked since 2013, I wonder how that ever worked? Maybe this will
suddenly fix all the DMI-based key detections.
Thanks to Peter Hutterer for catching this!
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
The 60-keyboard rules are already guared by KERNEL!="event*" bail-outs,
therefore, KERNELS="input*" is always true. Drop it!
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
