IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Something has to so we can have udev rules rely on this. Right now the ID_BUS
setting is inconsistent: usb is set, ata and pci are set, bluetooth is not
set, rmi is too new to be featured.
70-mouse even relied on bluetooth even though it was never set
Since the introduction of the whitelist in 60-persistent-storage.rules
block device symlinks are no longer created for scm block devices.
Add scm to the whitelist.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
blkid reports PARTUUID values also for partitions that are defined by a
dos partitioning scheme. Instead of limiting the partitioning scheme to
"gpt or dos" just drop the test for the partitioning scheme and trust
blkid to do the right thing.
Currently, 99-systemd.rules.in contains a line for network block
devices, which mark them as inactive until the first change event, and
as active from then on forward. This is not correct. A network block
device can be connected or disconnected; this state is signalled by the
presence or absense of a "pid" file, which contains the PID of the
nbd client userspace process that started the connection.
Update the rules file so that it checks for the presence of that file to
decide what to set SYSTEMD_READY to.
Note that current kernels do issue a change event upon connecting the
device, but not yet upon disconnecting. While it's possible to wait
until that's been fixed, the behaviour of the rule with TEST!="pid" in
the absence of a proper uevent is exactly the same as the behaviour of
the old rule; so it should be safe to apply now.
Signed-off-by: Wouter Verhelst <w@uter.be>
The "SYSTEMD_READY=0" will cause automatic unmount
of mountpoint that is on top of such DM device
if this is used with multipath which sets
DM_UDEV_DISABLE_OTHER_RULES_FLAG in case
we have a CHANGE event thatcomes after DM multipath
device reload when one of the paths is down or up.
See https://bugzilla.redhat.com/show_bug.cgi?id=1312011
With this rework we introduce systemd-rfkill.service as singleton that
is activated via systemd-rfkill.socket that listens on /dev/rfkill. That
way, we get notified each time a new rfkill device shows up or changes
state, in which case we restore and save its current setting to disk.
This is nicer than the previous logic, as this means we save/restore
state even of rfkill devices that are around only intermittently, and
save/restore the state even if the system is shutdown abruptly instead
of cleanly.
This implements what I suggested in #1019 and obsoletes it.
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 001a247324.
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
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.
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.
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.
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.
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 1aff20687f.
>> > ---
>> > 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.)
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).
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!
This reverts commit ba76ee29bc. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
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.
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.
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.
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=090d25fe224c0https://launchpad.net/bugs/1333140
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.
This rule is only run on tablet/touchscreen devices, and extracts their size
in millimeters, as it can be found out through their struct input_absinfo.
The first usecase is exporting device size from tablets/touchscreens. This
may be useful to separate policy and application at the time of mapping
these devices to the available outputs in windowing environments that don't
offer that information as readily (eg. Wayland). This way the compositor can
stay deterministic, and the mix-and-match heuristics are performed outside.
Conceivably, size/resolution information can be changed through EVIOCSABS
anywhere else, but we're only interested in values prior to any calibration,
this rule is thus only run on "add", and no tracking of changes is performed.
This should only remain a problem if calibration were automatically applied
by an earlier udev rule (read: don't).
v2: Folded rationale into commit log, made a builtin, set properties
on device nodes themselves
v3: Use inline function instead of macro for mm. size calculation,
use DECIMAL_STR_MAX, other code style issues
v4: Made rule more selective
v5: Minor style issues, renamed to a more generic builtin, refined
rule further.
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/)
blueness> poettering, was there a reason for not removing
50-firmware.rules when you nuked userland firmware
loading?
Followup for v216-119-gbe2ea723b1.
SYSTEMD_READY is currently set to 0 for all loop devices (loop[0-9]*)
that do not have a backing_file. Partitioned loop devices (ex. loop0p1),
however, are matched by this rule and excluded by systemd even though
they are active devices.
This change adds an additional check to the rule, ensuring that only
top level loop devices (loop[0-9]+$) are excluded from systemd.
Re-apply the keymaps when "udevadm trigger" is called. Hooking into
"add" only would just remove all keymap content from the udev database
instead of applying the new config.
Update comment to be a bit more specific.
Change match to blacklist the serial number of the broken devices
instead of whitelisting the serial number of the fixed devices.
This allows to do something useful with the serial number in the
future.
Add the first 3270 terminal device that is associated with the Linux preferred
console to the list of virtualization consoles. This is required to
automatically start a getty if the conmode=3270 kernel parameter is specified
for Linux on z/VM instances. Note that a queued upstream patch also enable
the 3270 terminal device if it is associated with the Linux preferred console.
How
To successfully start agetty on a 3270 terminal, a change in the agetty
parameter order is required. Previously, agetty would started like this:
/sbin/agetty --keep-baud 3270/tty1 115200,38400,9600 TERM
The agetty program interprets the "3270/tty1" as baud rate and fails to start
with the "bad speed: 3270/tty1" error message. Fixing this in agetty is more
complex rather than reordering the command line parameters like this:
/sbin/agetty --keep-baud 115200,38400,9600 3270/tty1 TERM
According to agetty sources and "agetty --help", agetty accepts the "tty",
"baudrate tty", and "tty baudrate" specifications.
P.S. The "tty: Set correct tty name in 'active' sysfs attribute" introduces
a change to display the terminal device which is associated with the
Linux preferred console. This change helps to let systemd handle this
particular case only. Without the changes of this commit, no additional
3270 terminal device can be managed by systemd.
https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/commit/?id=723abd87f6e536f1353c8f64f621520bc29523a3
Before it was placed in /dev/disk/by-id, which makes it a bit too much
API. However, it's mostly an implementation detail for now, hence move
it out of the stable block device dir.
Check existence of loop/backing_file in sysfs and mark loop devices with
SYSTEMD_READY if missing. Such loop files is uninitialized and it's not
ready for use yet (there's no file attached).
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.
Ensure to start getty programs on all essential system consoles on Linux on
System z. Add these essential devices to the list of virtualization_consoles
to always generate getty configurations.
For the sake of completion, the list of essential consoles is:
/dev/sclp_line0 - Operating system messages applet (LPAR)
/dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
/dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
/dev/hvc0 - Already handled by systemd (IUCV HVC terminal on z/VM)
Depending on the environment, z/VM or LPAR, only a subset of these terminals
are available.
See also RH BZ 860158[1] "Cannot login via Operating System Console into RHEL7
instance installed on a LPAR". This bugzilla actually blocks the installation
of Linux on System z instances in LPAR mode.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=860158
The path_id-builtin provides useful unique aliases for DRM devices. If we
want to configure DRM render-nodes for compositors, we want to avoid
storing the whole sys-path in configuration files. Hence, allow users to
store the short PATH_ID instead.
Load path_id-builtin unconditionally on DRM devices now to always provide
this alias.
This introduces a new key NamePolicy, which takes an ordered list of naming
policies. The first successful one is applide. If all fail the value of Name
(if any) is used.
The possible policies are 'onboard', 'slot', 'path' and 'mac'.
This patch introduces a default link file, which replaces the equivalent udev
rule.
This tool applies hardware specific settings to network devices before they
are announced via libudev.
Settings that will probably eventually be supported are MTU, Speed,
DuplexMode, WakeOnLan, MACAddress, MACAddressPolicy (e.g., 'hardware',
'synthetic' or 'random'), Name and NamePolicy (replacing our current
interface naming logic). This patch only introduces support for
Description, as a proof of concept.
Some of these settings may later be overriden by a network management
daemon/script. However, these tools should always listen and wait on libudev
before touching a device (listening on netlink is not enough). This is no
different from how things used to be, as we always supported changing the
network interface name from udev rules, which does not work if someone
has already started using it.
The tool is configured by .link files in /etc/net/links/ (with the usual
overriding logic in /run and /lib). The first (in lexicographical order)
matching .link file is applied to a given device, and all others are ignored.
The .link files contain a [Match] section with (currently) the keys
MACAddress, Driver, Type (see DEVTYPE in udevadm info) and Path (this
matches on the stable device path as exposed as ID_PATH, and not the
unstable DEVPATH). A .link file matches a given device if all of the
specified keys do. Currently the keys are treated as plain strings,
but some limited globbing may later be added to the keys where it
makes sense.
Example:
/etc/net/links/50-wireless.link
[Match]
MACAddress=98:f2:e4:42:c6:92
Path=pci-0000:02:00.0-bcma-0
Type=wlan
[Link]
Description=The wireless link
Changing the default MODE= for the group accessi, but not specifying
a GROUP= does not provide anything.
It disables the default logic that the mode switches to 0660 as soon
as a GROUP= is specifed, which make custom rules uneccesarily complicated.
https://bugs.freedesktop.org/show_bug.cgi?id=70665
Devices should show up in systemd regardless whether the user invoked
"udevadm trigger" or not. Before this change some devices might have
suddenly disappeared due issuing that command.
Since the kernel no longer exposes a large number of "dead" loop devices
it is OK to expose them now in systemd, so let's do that. This has the
benefit that mount dependencies on loop devices start to work.
Much like for rfkill devices we should provide some stability regarding
enumeration order, hence include the stable bits of the device path in
the file name we store settings under.
Let's include the stable device path for the rfkill devices in the name
of the file we store the rfkill state in, so that we have some stability
regarding enumeration order.
As many laptops don't save/restore screen brightness across reboots,
let's do this in systemd with a minimal tool, that restores the
brightness as early as possible, and saves it as late as possible. This
will cover consoles and graphical logins, but graphical desktops should
do their own per-user stuff probably.
This only touches firmware brightness controls for now.
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver has
> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
> uevents and they don't match the default rule for autoloading modules matching
> MODALIAS:
>
> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>
> any more. However, there are some modules whose module aliases match specific
> CPU features through the modalias string and those modules should be loaded
> automatically if a compatible CPU is present. Yet, with the processor driver
> bound to the CPU devices the above rule is not sufficient for that, so we need
> a new default udev rule allowing those modules to be autoloaded even if the
> CPU devices have drivers.
Otherwise, when a network device is renamed, systemd-sysctl is run twice
with the same network device name: once for ACTION="add" and once for
ACTION="move".
