jrgd

A bit of basic information beforehand that should be relevant:

• OS: Fedora 40 (x86_64)
• Desktop: KDE Plasma 6.1.3 (5.27.x -> current) (Wayland)
• Motherboard: ASUS PRIME X470-PRO
• Primary keyboard: Keychron S1 (tested on stock firmware, Windows layers)

The issue in some more detail: alt-tabbing windows in KDE sometimes leaves behind an alt keypress in the window that was alt-tabbed from that won't go away until alt is registered as pressed again by the window.

This has certainly been an interesting issue that has been a problem for at least a year at this point. I've finally gone in to do basic troubleshooting regarding the issue. I have pretty much ruled out hardware at this point. Originally, I had my primary keyboard plugged into my monitor's USB hub. In testing, I tried another keyboard, migrated the connect to my motherboard rather the monitor's USB hub, and the alternate keyboard plugged into the motherboard. All tests eventually result in the same issue happening over time.

One thing I see as a potential pattern but cannot fully confirm is that it appears these remnants of alt keypresses only show up in XWayland windows, and not native Wayland applications. Applications I have seen it occur in include Minecraft Java Edition, various Proton games, Electron applications that don't enable native Wayland support (e.g. Discord), Steam. This issue also occurs less if I allow XWayland apps to always see modifier keypresses. Though I assume this is more from the tendency to alt-tab back into affected windows, registering another alt keypress.

At this point, I am pretty confident this is software-related, but I cannot find any existing bug reports within the past three years (especially noting any relevant to KDE) that describe this problem. I am unsure of how one would go to debug this category of issue or even find the root cause component that is causing the issue. I am curious if anyone here has also had this irritating quirk occur and/or if you know any workarounds/fixes for this given problem.

Greetings all!

I have been working on getting a new network setup. The current test host (A server running OpenSUSE Leap 15.6 w/ Wicked) is able to get routes and obtain an address via DHCP from the router of the network (running OPNSense 24.7.6), but is unable to resolve routes and obtain an address via the local DHCPv6 server. Admittedly, I am not great with IPv6 doubled with the ISP for this network granting a statically-defined /128 address for the router and manually-delegated /64 address blocks.

The OPNSense configuration has a /64 address block assigned as its address space for the LAN interface. The configuration has the ISC DHCPv6 server allocating address range 2602:xxxx:xxxx:xxxx::8888:0 - 2602:xxxx:xxxx:xxxx::8888:ffff. The radvd server is set to managed, set with an automatic source address, set to advertise the default gateway, set to use the dhcpv6 dns configuration, and set with no additional routes advertised.

As noted, the OpenSUSE machine is unable to get any routes beyond link-local via ipv6 nor is it able to automatically be assigned an ipv6 address from the DHCPv6 server. I have done some diagnostics, but have been unable to determine any conclusive issue.

Starting ip route and address checks:

ip -6 addr

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::xxxx:xxxx:xxxx:a4ee/64 scope link proto kernel_ll [OpenSUSE Leap 15.6 Server link-local address]
       valid_lft forever preferred_lft forever

ip -6 route

fe80::/64 dev eth0 proto kernel metric 256 pref medium

The eth0 interface noted is using a standard configuration as provided by Wicked (BOOTPROTO=dhcp, STARTMODE=auto, ZONE=public). Testing dhcpv6 address acquisition by hand results in nothing:

wicked test dhcp6 -m auto eth0

wicked: eth0: Request to acquire DHCPv6 lease with UUID <$uuid-a> in mode auto

However, testing in forced managed mode does get results from the DHCPv6 server:

wicked test dhcp6 -m managed eth0

wicked: eth0: Request to acquire DHCPv6 lease with UUID <$uuid-b> in mode managed
INTERFACE='eth0'
TYPE='dhcp'
FAMILY='ipv6'
UUID='<$uuid-b>'
IPADDR='2602:xxxx:xxxx:xxxx::8888:807/128' [theoretical bound address on LAN]
PREFIXLEN='128'
DNSSERVERS='2602:xxxx:xxxx:xxxx::1' [LAN address of router]
DNSSEARCH='<$domain>'
ACQUIRED='1729020515'
CLIENTID='<$clientid>'
SERVERID='<$serverid>'
SERVERADDR='fe80::xxxx:xxxx:xxxx:a4ee' [OpenSUSE Leap 15.6 Server link-local address]

So unless I am mistaken at this point, this likely means that something is going wrong with the Router Advertisements for the system to not automatically try get assigned an ipv6 address. Checking a router advertisement broadcast to the OpenSUSE server, I am not seeing anything out of the ordinary:

radvdump

#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::xxxx:xxxx:xxxx:4eb4 [router link-local on LAN]
# received by interface eth0
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 1800;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvLinkMTU 1500;
        AdvSourceLLAddress on;

        prefix 2602:xxxx:xxxx:xxxx::/64 [public /64 address block manually delegated as LAN]
        {
                AdvValidLifetime 86400;
                AdvPreferredLifetime 14400;
                AdvOnLink on;
                AdvAutonomous off;
                AdvRouterAddr off;
        }; # End of prefix definition


        RDNSS 2602:xxxx:xxxx:xxxx::1 [LAN address of router]
        {
                AdvRDNSSLifetime 600;
        }; # End of RDNSS definition


        DNSSL <$domain>
        {
                AdvDNSSLLifetime 600;
        }; # End of DNSSL definition

}; # End of interface definition

sysctl -a | grep eth0.accept_ra

net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_from_local = 0
net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rt_info_min_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1

Am I missing something with why Wicked doesn't actually get a proper route to the LAN nor an address via IPv6?

To recap: IPv4 works, this is the only device connected to the network thus far, IPv6 configuration appears (to me at least) correct for the router advertisements and DHCPv6 config.

EDIT:

Found the source of the problem. The OPNSense configuration is in fact correct for what I want to do. The issue is on the OpenSUSE machine. I forgot about a funny little Linux kernel networking quirk regarding ipv6 forwarding. In OpenSUSE, enabling forwarding for IPv6 from the installer keeps net.ipv6.conf.*.accept_ra set to 1. However, setting net.ipv6.conf.*.forwarding to 1 will disable accepting routes from RA, and in my case of expecting automatic IPv6 configuration from DHCPv6 without forcing managed mode on the Linux server.

Unless I feel like bypassing some functionality provided by the router, one needs to set net.ipv6.conf.*.accept_ra to 2 for all affected network interfaces. This enforces accepting routes with forwarding enabled. This in turn for my case also allows for DHCPv6 resolution to function without forcing or bypassing it from the OpenSUSE machine. I can only assume the reason this isn't just default if applied from the installer is that fully-manual static IP addressing is expected rather than wanting to use DHCP reservations for assigning addresses.

So in short:

All is good with the OPNSense configuration. I needed to change the sysctl flag net.ipv6.conf.eth0.accept_ra = 1 to net.ipv6.conf.eth0.accept_ra = 2, in order to forcefully accept RA routes and normal DHCPv6 address assignment on my ethernet interface. This is necessary because I need forwarding over IPv6 for the affected machine.

cross-posted from: https://lemm.ee/post/38676431

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.

A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn't work for other games without a secondary launcher that is targeted through Steam.

I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.

The usage for this is simple. Just copy the 'shim' file into the game directory, override the Steam launch arguments to include "./shim %command%", and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like "DRI_PRIME=1 gamemoderun ./shim %command% -novid".

The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of 'target', another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.

So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.

I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.