<ashkitten>
and the keys themselves are only $10 apiece. i dont see any downside to getting 4 of these instead of a single yubikey for the same price
<ashkitten>
ofc they do say it's experimental
<ashkitten>
but still
<ashkitten>
sigh, i should really get a yubikey for real though actually. i don't have money rn and won't for a while tho
endformationage has quit [Ping timeout: 272 seconds]
<colemickens>
I'm still just waiting for one that has USB-A/USB-C/NFC all in one.
<ashkitten>
colemickens: yeah, the dream
<colemickens>
Or even better, I've been thinking about getting the newer Trezor with a screen - it can let you do on-ext-hw PIN entry with GPG agent etc.
<ashkitten>
oh cool
<colemickens>
But the Trezor isn't actually super secure as I understand it, at the hardware level, so...
<ashkitten>
oh i wonder if when i get my cosmo i'll be able to make it work as a usb keyboard to type passwords into computers
<ar>
TIL: ip addr flush dev wlan0 # didn't know flush worked in addresses too
lovesegfault has joined #nixos-chat
<eyJhb>
ashkitten: should be possible
<eyJhb>
But you can use you current phone for that, right? :D RUbberDucky
<jtojnar>
or is it like some people with baseball caps bumping their forehead into doorframes?
<clever>
srk: so i need to detect the model of pi, and then output the clock on the right pin
<__monty__>
jtojnar: I've never seen that happen o.O
<viric>
damn it I bought a new keyboard and I bet it has a low sampling frequency
<viric>
if I press two keys close enough in time, it always outputs the same order no matter which I press first
<clever>
viric: ive got an old wireless keyboard, and it has a crappy buffer and power saving combination
<viric>
it's a Cherry Stream 3.0
<viric>
wired
<clever>
viric: if i press 2 keys rapidly while its "off", only the 1st key every goes thru
<clever>
once it wakes up, it doesnt drop keys
<viric>
power saving by ignoring keypresses. clever.
<clever>
the problem, is that if i hit 4 keys in a row, the 2nd key is always lost
<viric>
This world of keyboards is HELL
<srk>
viric: they cheaped out on keyboard matrix :)
<viric>
I make two fingers fall quick over KM
<viric>
(with care k being first) And it types mk
<srk>
clever: common/broadcom/bcm2708_chip/axi_dma_lite14.h:// This file was generated by the create_regs script
<viric>
It's not the matrix this time! It's the sampling frequency
<clever>
viric: ive found that with one of my older laptops, i would sometimes be typing so fast, that i wasnt pressing keys, i was dragging and rolling a finger across many keys
<srk>
clever: any idea where does create_regs come from?
<viric>
They get the two key presses in the same sample.
<clever>
srk: i suspect those are generated by processing the verilog that created the original gates in the chip
<clever>
srk: obviously, locked behind NDA
<srk>
ah, right
<viric>
I was typing the whole day in this new Cherry keyboard and swapping letters quite often
<viric>
I thought I was not used to the push-force of the keys....
<clever>
srk: some of the hw blocks are now supported by linux itself, you can compare the addresses from these headers to device-tree to get a compatible name, then search for that in the linux source
<srk>
clever: guess I'll try to reconstruct .h files into SVD files to allow easy inspection
<clever>
that reads the ST_CLO (clock lower 32bits), on an rpi4
<clever>
line 10 should be 0x20000000 for an rpi1, 0x3f000000 on 2/3, and 0xfe000000 on an rpi3
<clever>
4*
<clever>
there is a proper library to handle all of that for you, which i didnt bother looking up
<srk>
like the arm regs are mapped at different locations on linux?
<clever>
yeah
<clever>
2 layers of mapping are at play, which is explained on the pdf you previously linked
<srk>
ok, good to know
<clever>
page 5, the registers within the 0x7e00_0000 space, are remapped to an arm physical address (0x2000_0000 on the rpi1, and then they keep moving it)
<clever>
and then linux itself, remaps them again to a virtual address, so the kernel can access them natively
<clever>
but /dev/mem deals with arm physical
<srk>
makes sense
<srk>
otherwise the i/o registers are compatible between variants?
<clever>
mostly
<clever>
some hw blocks like ST_ appear unchanged over every model
<clever>
some like the I2C controllers got multiplied, and the rpi4 has more of them
<clever>
the power management (PM_) seem to function in a completely different on the rpi4
<srk>
that's fine if it's still the same IP
<clever>
some like the arm control block, reserved bits start having a purpose, when 64bit comes along
<srk>
there's no way to compare these via header files I guess
<clever>
we only have the headers for the rpi1, and the current linux source
<srk>
yeah, with some guesswork we can RE the rest
<srk>
good that you can at least dump what's the orig fw sets
<srk>
s/what's/what
<clever>
srk: some things like the ARM_ block, return all nulls when read from the arm side
<clever>
srk: you can only see the true value if you read it from the VPU
<srk>
protection mechanism?
<clever>
yeah
<srk>
like arm control blocks should be standard anyway
<clever>
the arm translate registers let you configure the mmu from page 5 of the pdf
<clever>
srk: ranges lets you map registers from dt back into arm physical
<srk>
cool, didn't know there's devicetree spec!
<clever>
srk: dma-ranges lets you translate arm physical back into bus addresses, for the purposes of telling a device to perform dma
<clever>
srk: the rpi4 also has 4 or 5 different address spaces, and the pci controller lives in a different one
<clever>
srk: so the pci area, has its own unique dma-ranges, so you translate a given physical differently, when telling pci to dma
<clever>
srk: as for what uptime.c did, the rpi has a 64bit free-running timer, ST_CLO and ST_CHI give you the lower and upper 32bits of it
<viric>
damn it the K120 also does the sampling thing.
<viric>
Maybe it's the OS?
<clever>
srk: ST_C0, ST_C1, ST_C2, and ST_C3 are 4 compare registers, that will fire an irq when the lower 32bits match, and the rpi1 needed that as it was the only source of timers
<viric>
I don't know the USB HID thing enough, but it has to be very weird if it only allows 6 keys at once
<clever>
srk: rpi2 added proper arm timers into the mix
<srk>
like systick?
<srk>
viric: it's the reason why there's no full NKRO on linux except for PS/2
<srk>
on windows it's doable with special drivers iirc
<viric>
I've used NKRO keyboards in both very well
<viric>
all worked fine
<srk>
but for which N :)
<viric>
all I managed to press
<viric>
A Sharkoon SKiller 5 or similar name, I used
<srk>
yeah, looks like linux driver shouldn't be limited either
drakonis has joined #nixos-chat
<viric>
But I don't care about that now
<viric>
I care about why my keyboard doesn't know in what order I pressed the keys if I press them fast
<viric>
and how could I prove I type them in this or that order :)
<viric>
- the laptop keyboard looks like working fine, but that's PS2
Synthetica has joined #nixos-chat
<ar>
<viric> I don't know the USB HID thing enough, but it has to be very weird if it only allows 6 keys at once
<ar>
viric: that's true only for the compatibility/basic mode
<ar>
viric: which keyboards default to because of macos
<ar>
(because iirc even non-ancient uefi knows how to deal with modern hid)
<viric>
ar: ok, it makes sense.
<viric>
so my fight is against the matrices and the sampling frequency
<viric>
And manufacturers OF COURSE wouldn't report any of that
<viric>
so I don't know what keyboard to buy to shut up my complaining
<srk>
viric: what's the microncontroller inside it?
<viric>
srk: I've no idea.
<srk>
you can try something that runs qmk
<srk>
find a screwdriver and break that warranty void sign
<viric>
srk: I may still return the keyboard
<viric>
I don't want a mechanical keyboard but I want good sampling rate + 2KRO with shift pressed.
<viric>
(crying to the sky)
<clever>
viric: modifier keys like shift/alt/ctrl are often an exception to the rollover, and have a dedicated bit field
<viric>
clever: I have not found a single keyboard where that is true
<viric>
yet I've seen that claim in websites
<clever>
viric: have you played with libusb much?
Church- has quit [Ping timeout: 240 seconds]
<viric>
clever: a bit. I wrote a usermode driver for a device
<viric>
(a temperature logger)
<joepie91>
viric: is there a configuration tool for your keyboard?
<viric>
I could write it understanding 10% of what I was doing
<clever>
viric: ive used libusb to talk to my wireless headset before, it does report button presses over usb hid
<viric>
it worked.
<joepie91>
I had a very similar issue with my new keyboard, until I realized that I could increase the sample rate from the config tool
<joepie91>
and it works fine now
<viric>
joepie91: I don't think there is
<viric>
cherry stream 3.0
<clever>
viric: you could use that to dump the raw HID packets, and see how much room it has, and what keys do what
<viric>
I can't press R+T+shift at once
<clever>
ouch
<viric>
I mean it doesn't get that. I don't need the usb thing to find out about that
<clever>
zxqw ctrl windows alt shift, turns into zxq
<cransom>
something also about how keyboard manufacturers cheap out as well by tuning which keys rollover well. wasd and surrounding keys get some love, and modifiers + zxcv for the common windows shortcuts (on qwerty)
<clever>
yeah, if i swap w for another key, i can get more
<clever>
for some combinations, it sanely ignores the new press (limit in reporting not detection?)
<clever>
for others, it drops other held keys (limit in detection?)
<srk>
I'm going to desing and build one too soon^tm, gonna run haskell generated firmware
<srk>
don't have USB stack yet
<wildtrees>
haskell generated firmware!? something like ivory?
<clever>
wildtrees: one crazy plan i have, is to run haskell as the firmware
<clever>
not generating firmware, but being the firmware
<gchristensen>
O.o
<wildtrees>
you are gonna something like ghc as firmware?? what about gc pauses and gc size, how big is the device you are gonna run? I have heard of unikernels that use haskell
<gchristensen>
you'll need to do neat tricks to make the SoC let you allocate 1T of vmem
<wildtrees>
ha :)
<gchristensen>
;)
<clever>
gchristensen: that 1tb of ram, is only a performance hack, done on 64bit systems
<clever>
haskell doesnt do it on 32bit systems
<gchristensen>
aye, it was a cheap joke
<clever>
wildtrees: the current rtos (threadx) has the ability to defrag its heap
<clever>
wildtrees: and the copy collector in ghc, is basically defragging the heap each time it collects
<clever>
that is what led to this idea :P
<clever>
wildtrees: and i have read the bootstrap code in halvm (haskell under xen), so i know how to make it work, i just dont know how to compile it for the arch (haskell to llvm to vc4)
<wildtrees>
I mean its a cool idea, only problems I have had with haskell is mostly occasional gc pauses for games, and serializing and deseriliazing large amounts of binary data is kinda of slow
<wildtrees>
vc4?
<clever>
videocore4, the gpu on the rpi
<__monty__>
A keyboard firmware running on a GPU? o.O
<clever>
__monty__: haskell on a gpu, not keyboard on a gpu
<srk>
wildtrees: exactly ivory, and tower :)
<clever>
__monty__: though, you could have the gpu dealing with a keyboard matrix
<__monty__>
Oh, I thought you wanted to run it as a keyboard firmware.
<clever>
its more then just a gpu
<wildtrees>
something haskell like on a gpu, reminds me of futhark, haven't look into it much
<clever>
the VPU on the rpi, is just a dual-core processor, that can run any normal code (c/c++ is what i currently use)
<clever>
it also has a 16 wide ALU, shared between both cores, which can fetch data from a 64x64 matrix of registers
<clever>
this code will fill a c array with 16 ints, load all 16 ints into the matrix, multiply all 16 by a single constant, then copy them back out to a c array, and print
<clever>
it can operate on a max of 1024 elements in a batch
drakonis has quit [Read error: Connection reset by peer]
<cransom>
'who wrote this crap.' <git blame> 'crap. i did.'
<gchristensen>
haha
Peetz0r has joined #nixos-chat
psyanticy has quit [Quit: Connection closed for inactivity]
<viric>
clever: hitting a character makes it release shift? that's crazy
<viric>
clever: the problem is not "up to N letters". The problem is the minimum that can be pressed together.
<clever>
viric: depending on which keys i hit, shift returns when i release the "too many" one, but sometimes it doesnt
<clever>
it would take too long to test every single pair of keys
<clever>
oh, but i have noticed that windows is also a problem
<clever>
ive been using screen on linux for years, and the hotkeys have become muscle memory
<clever>
it i'm in putty on windows, i type too fast, and it drops half the keystrokes
<viric>
is it worse on windows? how can it be?
<joepie91>
clever: ha
<joepie91>
cransom: ha *
<joepie91>
sorry clever :P
<clever>
i dont know what windows is doing, but its worse :P
<viric>
In the logitech K120, if I drop two fingers straight over KO (caring to press K first), it types ok.
<viric>
I'm amazed at this
<viric>
The USB HID thing takes
<viric>
The USB HID thing takes up to 6 key states per message.
<viric>
(probably more after the 'boot keyboard protocol' thing)
<viric>
But imagine that a message reports that o+k have been just pressed.
<viric>
Is it possible? I hope not but feels like so.
<cransom>
is that keyboard supposed to have a better reputation? i don't see much info on it other than it's $17 at amazon.
<viric>
:)
<viric>
I started at the Logitech K120 and I was happy with it. Comfortable. Until I realized that some things that end up typed wrong were not my fault!
<viric>
Then I guess I got crazy at finding a keyboard that works.
<viric>
I went for more expensive keyboards and all are worse, with more important problems than the K120
<viric>
And somehow this "keyboard world" takes the direction towards mechanical keyboards with long key travel and noise. And I don't want any of that.
<viric>
The keyboard with more keys rollover + short travel + high sampling rate is that of my cheap laptop.
<viric>
The characteristics I care most are not advertised by any manufacturer: sampling rate, 2KRO with modifiers apart, short key travel, weak presses but quick return, etc.
<viric>
So it's an adventure to find a keyboard.
<viric>
With XEV I see that when I press two keys short enough in time, the appear with same timestamp