Page 2 of 2

Re: Linux thread

Posted: 21 Oct 2025, 02:21
by Hyote
ablemor wrote:
20 Oct 2025, 15:30
Don't look for the solution on Linux, it's completely unnecessary.
If u have floaty mouse, etc, then its EMI/RFI, bad grounding, and return noise from neutral wire
Yeah but it's performant as hell. Menci nagyon.

Re: Linux thread

Posted: 21 Oct 2025, 03:40
by Hyote
## Started using evdev instead of libinput

sudo vim /etc/X11/xorg.conf.d/20-evdev.conf

;paste these in, save with :wq

Section "InputClass"
Identifier "Mouse"
MatchIsPointer "on"
Driver "evdev"
Option "AccelerationScheme" "none"
Option "AccelerationProfile" "-1"
Option "VelocityReset" "30000"
EndSection

## Services

set disable_services \
kdeconnect.service \
cups.service \
bluetooth.service \
ModemManager.service \
avahi-daemon.service \
atd.service \
lvm2-monitor.service \
fstrim.timer \
ondemand.service \
thermald.service \
irqbalance.service \
snapd.service \
snapd.socket \
fwupd.service \
colord.service \
PackageKit.service \
tracker-miner-fs.service \
geoclue.service \
upower.service \
cups-browsed.service \
systemd-timesyncd.service \
systemd-oomd.service \
accounts-daemon.service \
wpa_supplicant.service \
smartd.service \
speech-dispatcher.service \
apport.service \
whoopsie.service \
rsyslog.service \
ufw.service \
unattended-upgrades.service

Added iomem=relaxed to the GRUB_CMDLINE_LINUX_DEFAULT config for the next few settings.

sudo pacman -S msr-tools
sudo modprobe msr

sudo wrmsr 0x1a0 0x0
sudo wrmsr 0x610 0x00FFC000
sudo wrmsr 0x638 0x0
sudo wrmsr 0x640 0x0
sudo wrmsr 0x618 0x0
sudo wrmsr 0x48 0x0
sudo wrmsr 0x49 0x0
sudo wrmsr 0x1FC 0x0
sudo wrmsr 0x1AD 0x31313131 (your OC multiplier instead of 31 convertex to hex) 31 hex = 49

## These were the same settings I showed here: https://github.com/Hyyote/In-depth-Windows-tweaking

cd /tmp
vim devmem2.c

;paste in these contents and save with :wq

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <ctype.h>
#include <sys/mman.h>

#define MAP_SIZE 4096UL
#define MAP_MASK (MAP_SIZE - 1)

int main(int argc, char **argv) {
int fd;
void *map_base, *virt_addr;
unsigned long read_result, writeval, target;
int access_type = 'w';

if(argc < 2) {
fprintf(stderr, "Usage: %s {address} [type] [data]\n", argv[0]);
exit(1);
}

target = strtoul(argv[1], 0, 0);
if(argc > 2) access_type = tolower(argv[2][0]);

if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) {
perror("open");
exit(1);
}

map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, target & ~MAP_MASK);
if(map_base == (void *) -1) {
perror("mmap");
exit(1);
}

virt_addr = map_base + (target & MAP_MASK);

switch(access_type) {
case 'b':
read_result = *((unsigned char *) virt_addr);
break;
case 'h':
read_result = *((unsigned short *) virt_addr);
break;
case 'w':
read_result = *((unsigned long *) virt_addr);
break;
}

if(argc > 3) {
writeval = strtoul(argv[3], 0, 0);
switch(access_type) {
case 'b':
*((unsigned char *) virt_addr) = writeval;
break;
case 'h':
*((unsigned short *) virt_addr) = writeval;
break;
case 'w':
*((unsigned long *) virt_addr) = writeval;
break;
}
}

munmap(map_base, MAP_SIZE);
close(fd);
return 0;
}

;compile with these below

gcc -o devmem2 devmem2.c
sudo mv devmem2 /usr/local/bin/
sudo chmod +x /usr/local/bin/devmem2

sudo devmem2 0xA0702024 h 0x0
sudo devmem2 0xA0702044 h 0x0
sudo devmem2 0xA0702064 h 0x0
sudo devmem2 0xA0702084 h 0x0
sudo devmem2 0xA07020A4 h 0x0
sudo devmem2 0xA07020C4 h 0x0
sudo devmem2 0xA07020E4 h 0x0
sudo devmem2 0xA0702104 h 0x0

## Startup:
; set affinities on startup as well
sudo sysctl kernel.split_lock_mitigate=0
sudo cpupower frequency-set -g performance
sudo wrmsr 0x1a0 0x0
sudo wrmsr 0x610 0x00FFC000
sudo wrmsr 0x638 0x0
sudo wrmsr 0x640 0x0
sudo wrmsr 0x618 0x0
sudo wrmsr 0x48 0x0
sudo wrmsr 0x49 0x0
sudo wrmsr 0x1FC 0x0
sudo wrmsr 0x1AD 0x31313131 (your OC multiplier instead of 31 convertex to hex) 31 hex = 49
sudo devmem2 0xA0702024 h 0x0
sudo devmem2 0xA0702044 h 0x0
sudo devmem2 0xA0702064 h 0x0
sudo devmem2 0xA0702084 h 0x0
sudo devmem2 0xA07020A4 h 0x0
sudo devmem2 0xA07020C4 h 0x0
sudo devmem2 0xA07020E4 h 0x0
sudo devmem2 0xA0702104 h 0x0

Re: Linux thread

Posted: 22 Oct 2025, 00:40
by Hyote
Since I have a fresh experience with CachyOS, Windows 11 24H2 and made 25H2 work with all my tweaks not long ago, the newest Windows clears everything else.

Also I haven't seen anyone talk about this, but now I made my ISO with the Pro for Workstations edition instead of the regular Pro, and it's been going really well so far, too well even. Regarding versions, I remember 23H2 being pretty responsive but still preferred older versions of Windows 10 to it and 24H2 had really weird mouse input. 25H2 tops everything in every aspect and I'd even say it's worthy of replacing Windows 7 even. These are just words of praise, nothing business related.

Re: Linux thread

Posted: 22 Oct 2025, 10:20
by agendarsky
ablemor wrote:
20 Oct 2025, 15:30
Don't look for the solution on Linux, it's completely unnecessary.
If u have floaty mouse, etc, then its EMI/RFI, bad grounding, and return noise from neutral wire
Linux is actually a lot better for seeking for solution, especially when it comes to cs2 performance thanks to native vulkan linux build , it perform a lot better and by better i mean a lot more better 1% lows and average fps especially on amd cards , but nvidia works fine too.
Im not gonna take a look on emi / rfi or grounding solutions because i have no problem with electricity in my house and as i said i know exact moment when my cs 1.6 went to and everything else went to sewers almost 15 years ago. Im not even mad about this anymore because it became kind of obsession that i cant simply stop just because of being curious. Yeah so tldr 15 years ago i swithed from agp/pci to pci-e modern build and here i am. I think it lies in architecture complexity changes and that is so much things to cover, things are dynamic are changing runtime. Who ever took a look about ACPI tables and what they say? Did you know that memory has its own scheduler that isn't accessible from any known firmware? FSB and North bridge was replaced by pch that can be a bottleneck.Back in agp era gpu was connected directly to northbridge and memory through agp aperture, that was just simple physical address window handled by northbridge, no packet translation, no layers.
Today everything goes through pch via dmi or cpu pcie root complex and gpu communicates using pci-e BARs (base address registers).
Each bar is basically memory range assigned by bios/uefi and used for mmio (registers or vram access).
So when cpu writes to gpu register it goes as pcie packet through root complex instead of raw address line like before.
In short, old agp was just one timing domain, everything synced together, now there are multiple layers and domains that constantly talk through packet protocols.
So yeah, complexity went up, determinism went down. but im not giving up , everyone from us , occasionally has that state when games suddenly "accelerates" for few moments and goes to sewers quickly after, and that is hope for me that we can find solution why is this pattern happening and we will find a solution.