The DPI for three logitech models, the M185, M510, and M705, appear to
have always been different here than what logitech's given specs say.
With my M510, this results in jumpy behavior when transitioning from
fast motion to slow motion, making clicking specific buttons or
highlighting specific text *very* frustrating.
This patch changes those 3 mice to the published resolution, which
resolves the problem with my M510. I have chosen to fix those 3 simply
because they were already grouped together, and all incorrect as
compared to logitech's web site, and as such I have not tried other mice
or investigated if there are other non-matching values in the database
as well.
Signed-off-by: Peter Jones <pjones@redhat.com>
Scope units don't have a main or control process we can watch, hence
let's explicitly watch the PIDs contained in them early on, just to make
things more robust and have at least something to watch.
This reworks how systemd tracks processes on cgroupv1 systems where
cgroup notification is not reliable. Previously, whenever we had reason
to believe that new processes showed up or got removed we'd scan the
cgroup of the scope or service unit for new processes, and would tidy up
the list of PIDs previously watched. This scanning is relatively slow,
and does not scale well. With this change behaviour is changed: instead
of scanning for new/removed processes right away we do this work in a
per-unit deferred event loop job. This event source is scheduled at a
very low priority, so that it is executed when we have time but does not
starve other event sources. This has two benefits: this expensive work is
coalesced, if events happen in quick succession, and we won't delay
SIGCHLD handling for too long.
This patch basically replaces all direct invocation of
unit_watch_all_pids() in scope.c and service.c with invocations of the
new unit_enqueue_rewatch_pids() call which just enqueues a request of
watching/tidying up the PID sets (with one exception: in
scope_enter_signal() and service_enter_signal() we'll still do
unit_watch_all_pids() synchronously first, since we really want to know
all processes we are about to kill so that we can track them properly.
Moreover, all direct invocations of unit_tidy_watch_pids() and
unit_synthesize_cgroup_empty_event() are removed too, when the
unit_enqueue_rewatch_pids() call is invoked, as the queued job will run
those operations too.
All of this is done on cgroupsv1 systems only, and is disabled on
cgroupsv2 systems as cgroup-empty notifications are reliable there, and
we do not need SIGCHLD events to track processes there.
Fixes: #9138
Fedora 28 is out already, let's advertise it. While at it, drop "container"
from "f28container" — it's a subdirectory under /var/lib/machines, it's pretty
obvious that's it a container.
To make the switch easier in the future, define the number as an entity.
This way we don't need to repeat the argument twice.
I didn't replace all instances. I think it's better to leave out:
- asserts
- comparisons like x & y == x, which are mathematically equivalent, but
here we aren't checking if flags are set, but if the argument fits in the
flags.
Also, allow run-cocinnelle.sh to be started from any directory.
Unfortunately set -x does not work nicely anymore, because the list is
too verbose. Replace it by an echo line.
Previously, we'd not care about failures that were seen earlier and
remain in "exited" state. This could be triggered if the main process of
a service failed while ExecStartPost= was still running, as in that case
we'd not immediately act on the main process failure because we needed
to wait for ExecStartPost= to finish, before acting on it.
Fixes: #8929
Let's show a message at the time of logout i.e. entering the "closing"
state, not just e.g. once the user closes `tmux` and the session can be
removed completely. (At least when KillUserProcesses=no applies. My
thinking was we can spare the log noise if we're killing the processes
anyway).
These are two independent events. I think the logout event is quite
significant in the session lifecycle. It will be easier for a user who
does not know logind details to understand why "Removed session" doesn't
appear at logout time, if we have a specific message we can show at this
time :).
Tested using tmux and KillUserProcesses=no. I can also confirm the extra
message doesn't show when using KillUserProcesses=yes. Maybe it looks a
bit mysterious when you use KillOnlyUsers= / KillExcludeUsers=, but
hopefully not alarmingly so.
I was looking at systemd-logind messages on my system, because I can
reproduce two separate problems with Gnome on Fedora 28 where
sessions are unexpectedly in state "closing". (One where a GUI session
limps along in a degraded state[1], and another where spice-vdagent is left
alive after logout, keeping the session around[2]). It logged when
sessions were created and removed, but it didn't log when the session
entered the "closing" state.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1583240#c1
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1583261Closes#9096
The function is similar to path_kill_slashes() but also removes
initial './', trailing '/.', and '/./' in the path.
When the second argument of path_simplify() is false, then it
behaves as the same as path_kill_slashes(). Hence, this also
replaces path_kill_slashes() with path_simplify().
We don't need a temporary variable when parsing just one number, because
our parsing functions do not touch the output variable on error.
TAKE_PTR is more expressive than 'n = NULL'.
First, ellipsize() and ellipsize_mem() should not read past the input
buffer. Those functions take an explicit length for the input data, so they
should not assume that the buffer is terminated by a nul.
Second, ellipsization was off in various cases where wide on multi-byte
characters were used.
We had some basic test for ellipsize(), but apparently it wasn't enough to
catch more serious cases.
Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8686.
Add accelerometer orientation quirk for the Onda V891w tablet, this
does a partial match on the BIOS version because the other strings are
somewhat generic.
The BIOS match is done for both the W89* and D89* BIOS versions which are
for the Windows only and Dual boot versions respectively.
Michael Prokop