| Age | Commit message (Collapse) | Author |
|---|
|
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
ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Fixup for 51c0c2869845a058268d54c3111d55d0dd485704.
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>
|
|
we don't want to run usb_id and input_id on ACTION=="remove"
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
These are handled by a different driver than MemoryStick Pro.
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>
|
|
This line was accidentally lost in 52346b5f5424.
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>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
strings like we prefix the "name" strings
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>
|
|
Drop the restriction not to match on bluetooth devices. They are supported
just fine!
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>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Newly added kernel drivers repeatedly pass our blacklist and
cause trouble for the devices, because they do not expect to
be examined by udev's default rules which include blkid.
This turns the blacklist into a whitelist. Device type which
need support for additional symlinks need to be added to the
whitelist now.
Note, that the by-id, by-path symlinks are only intended for
hotpluggable devices. There is no reason for exotic, or for
statically configured devices to provide them.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
We don't actually want a by-path/ symlink for MMC RPMB devices, so just add
them to the blacklist. This will prevent creating wrong by-path links and
blkid'ing those.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Linux 3.10+ exposes RPMB (Replay Protected Memory Block) partitions of MMC
devices [1] ; trying to read them with blkid or other unspecific means will
cause kernel buffer I/O errors and timeouts. So don't run blkid on these.
Also ensure that /dev/disk/by-path creates proper symlinks and exposes the
-rpmb partition separately, instead of letting the "normal" partition symlink
point to the rpbm device (this is a race condition).
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=090d25fe224c0
https://launchpad.net/bugs/1333140
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
|
|
|
|
Currently used to tag devices in the new Lenovo *50 series and the X1 Carbon
3rd. These laptops re-introduced the physical trackpoint buttons that were
missing from the *40 series but those buttons are now wired up to the
touchpad.
The touchpad now sends BTN_0, BTN_1 and BTN_2 for the trackpoint. The same
button codes were used in older touchpads that had dedicated scroll up/down
buttons. Input drivers need to work around this and thus know what they're
dealing with.
For the previous gen we introduced INPUT_PROP_TOPBUTTONPAD in the kernel, but
the resulting mess showed that these per-device quirks should really live in
userspace.
The list currently includes the X1 Carbon 3rd PNPID, others will be added as
get to know which PNPID they have.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Ejecting a CD with the hardware drive button only causes a change uevent, but
the device node stays around (just without a medium). Pick up these uevents and
mark the device as SYSTEMD_READY=0 on ejection, so that systemd stops the
device unit and consequently all mount units on it.
On media insertion, mark the device as SYSTEMD_READY=1 again.
https://bugs.freedesktop.org/show_bug.cgi?id=72206
https://bugzilla.opensuse.org/show_bug.cgi?id=909418
https://bugs.archlinux.org/task/42071
https://bugs.launchpad.net/bugs/1168742
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=87037
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
If not backslash-escaped, it splits the rule in two.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
The Avocent KVM over IP devices doesn't work correctly with USB power
management enabled.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
This will do until all net properties are imported.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Resolve spotted issues related to missing or extraneous commas, dashes.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
udev seems to have a race condition with swapon to see which can open
/dev/zram0 first, causing swapon to fail. Seems to be most noticeable
on arm devices one out of every 7 times or something.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Note: some of these rules are premature because we have yet
to add udev_builtin_net_link. These commits were authored by
Kay Sievers
David Herrmann
Tom Gundersen
Lennart Poettering
Bastien Nocera
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
Otherwise systemd-udevd will rename on "change" and "move" events,
resulting in weird renames in combination with biosdevname
systemd-udevd[355]: renamed network interface eth0 to em1
systemd-udevd[355]: renamed network interface eth1 to p3p2
systemd-udevd[357]: renamed network interface eth0 to p3p1
systemd-udevd[429]: renamed network interface p3p2 to ens3f1
systemd-udevd[428]: renamed network interface p3p1 to ens3f0
systemd-udevd[426]: renamed network interface em1 to enp63s0
or
systemd-udevd[356]: renamed network interface eth0 to em1
systemd-udevd[356]: renamed network interface eth0 to p3p1
systemd-udevd[420]: renamed network interface p3p1 to ens3f0
systemd-udevd[418]: renamed network interface em1 to enp63s0
systemd-udevd[421]: renamed network interface eth1 to p3p1
|
