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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We _always_ return NULL from destructors to allow direct assignments to
the variable holding the object. Especially on hashmaps, which treat NULL
as empty hashmap, this is pretty neat.
udev uses inotify to implement a scheme where when the user closes
a writable device node, a change uevent is forcefully generated.
In the case of block devices, it actually requests a partition rescan.
This currently can't be synchronized with "udevadm settle", i.e. this
is not reliable in a script:
sfdisk --change-id /dev/sda 1 81
udevadm settle
mount /dev/sda1 /foo
The settle call doesn't synchronize there, so at the same time we try
to mount the device, udevd is busy removing the partition device nodes and
readding them again. The mount call often happens in that moment where the
partition node has been removed but not readded yet.
This exact issue was fixed long ago:
http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=bb38678e3ccc02bcd970ccde3d8166a40edf92d3
but that fix is no longer valid now that sequence numbers are no longer
used.
Fix this by forcing another mainloop iteration after handling inotify events
before unblocking settle. If the inotify event caused us to generate a
"change" event, we'll pick that up in the following loop iteration, before
we reach the end of the loop where we respond to settle's control message,
unblocking it.
Commit 9ea28c55a2 (udev: remove seqnum API and all assumptions about
seqnums) introduced a regresion, ignoring the timeout option when
waiting until the event queue is empty.
Previously, if the udev event queue was not empty when the timeout was
expired, udevadm settle was returning with exit code 1. To check if the
queue is empty, you could invoke udevadm settle with timeout=0. This
patch restores the previous behavior.
(David: fixed timeout==0 handling and dropped redundant assignment)
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.
Aarch64 and ARM32 lack an EFI capable objcopy, so use the ldflags + -O
binary trick gnu-efi and the Red Hat shimloader are using.
(David: rebase to systemd-git and added EFI_ prefixes)
Verified for the 5,1 Macbook, the others are guesses based on the list of
supported devices of the moshi trackpad protector.
http://www.moshi.com/trackpad-protector-trackguard-macbook-pro#silver
Resolution calculated based on the min/max settings set in the kernel driver,
divided by the physical size. This is probably slightly off, but still better
than no resolution at all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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.
No changes in the mapping, but previously we opened the device only on
successful parsing. Now we open the mapping as soon as we have a value that
looks interesting. Since errors are supposed to be the exception, not the
rule, this is probably fine.
Rather than building a map and looping through the map, immediately call the
ioctl when we have a successfully parsed property.
This has a side-effect: before the maximum number of ioctls was limited to the
size of the map (1024), now it is unlimited.
systemctl and logind were unconditionally using functions that were not compiled
on non-EFI systems. Add stubs returning -EOPNOTSUPP to fix compile again.
There was a bug where is_efi_*() could return a negative error value, which would be treated as 'true',
just make this a bool in the helper library to avoid the problem.
Users might have hard time figuring out why exactly their systemctl request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
Always create files first, and then adjust their ACLs, xattrs, file
attributes, never the opposite. Previously the order was not
deterministic, thus possibly first adjusting ACLs/xattrs/file
attributes before actually creating the items.
