I have a logitech mouse that has been working well for a long time. Except that every once in a while it suddenly won't scroll one line at a time and instead requires multiple turns of the wheel to move a page.
I've been putting up with this as I am able to fix it by running solaar and toggling scroll wheel resolution off then on again. Only a couple of mouse clicks.
Now it seems to have gotten worse, or I am finally tired of having to stop my workflow to fix it. It seems to be related to the mouse going to sleep during inactivity, though it is random enough so I cannot be sure.
I am on the latest fedora 34 code, and I have been seeing issue since before 32.
Any ideas where to look for a solution?
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:
turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.
The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?
My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).
Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...
Am I forgetting some other reason we still need it?
IRC: adamw | Twitter: adamw_ha
I'm using KDE on Fedora 35, and I have no applet for choosing an access
point. I believe that should be the Network Manager applet. It's installed
kf5-networkmanager-qt.x86_64 5.89.0-1.fc35 @updates
but I do no see it in the system tray.
I originally installed the XFCE spin and then installed KDE over that.
(This was because of problems with Wayland.)
PS I thought I sent this before, but do not see it in the archives.
I just installed Fedora 35 - KDE Spin on a new "Dell Inspiron 17 2-in-1
QHD+ Touchscreen" laptop.
If I go to system settings ->Input Devices -> Virtual Keyboard
and turn the Virtual Keyboard "on", then every time I click on an input
field the virtual keyboard pops up.
Is there a way to configure the Virtual Keyboard so it only comes up if
I click / touch an input field on the touchscreen, and not pop up if I
click with the mouse?
I'm running KDE/Plasma on Wayland both in my main workstation and in my
development virtual machine. On both machine it looks like Python is
unable to change the system's locale when running a script  in
Konsole, while the same script from a linux terminal runs fine.
I tried to create a new user and logging in as this new user the script
runs fine in Konsole also. I cannot find any setting which may cause
that, I also tried to delete the konsole configuration file under
.config so as to reset from scratch, but with my main user I can't get
to run the script right.
Any idea where I might look to find the cause?