it's asasasasasasasasasasasasasasasasasasasasasas*, you're just not pressing them at the same time
*pressed with a $12 rubber dome keyboard (windows 7)
Really? I can't be asasased right now to boot into Win7 and try stuff out, but that sounds like a Win7 HID bug :-/
saaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
assssssssssssssssssssssssssssssssssss
assssssssssssssssssssssssssssssssss
asasasasasasasasasasasasasasasasasasasasasas
Lol.
I can't get alternating keys to happen Filco on win7
I can't get alternating keys to happen Filco on win7
Tkl Leopold for me, ps/2. What's better and why? How can we change that? And why isn't it standard for all keyboards? lol
how can we get alternate keys??
so it isn't normal and not supposed to be "asasasas". my Leopold does (as all keyboard i've ever tried) "asssss"
A USB keyboard sends the current state of all keys (ignoring the 6KRO limitation, it's not relevant to this) in each packet it sends to the host.thank you, finally a constructive input on the subject. so there isn't anything wrong with my Leopold doing "sdddddddddddd", whether pluggued via USB or PS/2.
So the host can get a packet with no keys pressed, and the next can have two (or more) pressed.
Then, yes, it's the OS doing the key repeat. I don't think it's part of the HID spec, so I guess there's no real documentation on how it should behave. Clearly though, the intention is to act like a PS/2 keyboard, and repeat the last key pressed.
I'd call it a bug, however minor and irrelevant. The OS has already made a (completely arbitrary) choice of which key to present first, so that choice should also be applied to the key repeat. (After all, PS/2 keyboards make that choice internally, and stick with it for the repeat).
Teensy doesn't do anything - it's all down to the software. My converter has an output queue, mainly to support playing back macros, which means that it will only output one change at a time (except for modifiers, it can change all of them at once in macros). Anyway, different USB keyboards may behave differently in this regard.
thank you, finally a constructive input on the subject. so there isn't anything wrong with my Leopold doing "sdddddddddddd", whether pluggued via USB or PS/2.
I just think that most of the time, when typing and pressing two keys, it would be more useful to get alternate keys (or there is no reason to press 2 keys at the same time). still, ingame, you can press 2 keys and it will alternate (well, both keys remain activated). but not when typing in Windows (the 2 keys are probably still activated but Windows just take the last stroke for some reason).
And it's not easy to replicate if you look at my posts.
So anyway the McRip effect means that it's not a big deal. And it's not easy to replicate if you look at my posts.finally found the right paragraph in that whole thread. wow.
So anyway the McRip effect means that it's not a big deal. And it's not easy to replicate if you look at my posts.finally figured out what you were saying after reading the whole thread (just stopped after the first video the first time I saw your thread because tl:dr). that might be my English too, I'm French Canadian and just trying to improve it. in the long run if I keep on posting some threads and answering others on those forums, I will get better ;p
A USB keyboard sends the current state of all keys (ignoring the 6KRO limitation, it's not relevant to this) in each packet it sends to the host.
So the host can get a packet with no keys pressed, and the next can have two (or more) pressed.
Then, yes, it's the OS doing the key repeat. I don't think it's part of the HID spec, so I guess there's no real documentation on how it should behave. Clearly though, the intention is to act like a PS/2 keyboard, and repeat the last key pressed.
I'd call it a bug, however minor and irrelevant. The OS has already made a (completely arbitrary) choice of which key to present first, so that choice should also be applied to the key repeat. (After all, PS/2 keyboards make that choice internally, and stick with it for the repeat).
Teensy doesn't do anything - it's all down to the software. My converter has an output queue, mainly to support playing back macros, which means that it will only output one change at a time (except for modifiers, it can change all of them at once in macros). Anyway, different USB keyboards may behave differently in this regard.
I wonder if Soarer has figured out yet that KEYBOARD SCIENCE requires experimentation!
Notice that I think the scan sequence and/or matrix location makes a difference here Soarer.
A and H are obviously scanned with different horizontal/vertical grids. I BELIEVE the Filco controller goes Left to Right.
...
If you are impressed with my KEYBOARD SCIENCE skills...
Quote from: SoarerAs an idiot savant, you've mentioned key debounce. Yet you have no idea just how relevant that is!!
fuuuuuuuuuuuuuuuuuuuu
ufffffffffffff
fufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufufu
Gimme some specifics here.....Not able to replicate on my Filco. And KEYBOARD SCIENCE requires confirmation of results.
Well, no. Science involves examining ALL possibilities, not simply espousing the first that appears plausible.
I'll grant you that your theory seems plausible. But only for 6KRO keyboards, or those using a similar HID report layout. NKRO over USB uses a bit per key, and the bit positions are fixed in the report, so matrix scan order will make no difference to the bit positions. Anyway, for 6KRO boot mode...
We know that one packet has no keys, and the next has two (or more) keys. That's a given for this behaviour to be at all feasible.
The HID specification [1] states that there is no defined order that the keys have to conform to. It's even legal to have gaps, e.g. slots 2 and 5 could be used from the 6 to send two codes.
We don't know how the OS examines each packet, i.e. what order it will present the events it finds there. It's a fair assumption that it reads the 6 key slots from beginning to end. But still, one should caution that it is an assumption at this point.
We don't know how each keyboard chooses to fill the packet. Some might well fill it starting from the beginning in matrix-scan order. Others could just as easily do something completely different - it's all down to the software.
As an idiot savant, you've mentioned key debounce. Yet you have no idea just how relevant that is!!
I think there are 2 separate issue here. 1: what exactly is the keyboard spitting out, 2: how is the OS interpreting it. 1 should be easy to test. USB sniffer should be able to read what's being outputted by the keyboard. May be that'll help better decipher the behavior of the controller. I think we need to figure that out before testing behavior of the OS.
I do agree this is McRip effect territory. Unless you're soarer and other people who have written firmware for controllers, it has almost zero tangible effect on computing.
PS, I am the idiot who mentioned debounce. Just how relevant is it?
My view on the "effect" is that it's stuff that only wacky enthusiasts care about. like 88tooth ratchets vs 84tooth. I think bar fights have started from those talks ;o
Debouncing in batch was one of my guesses about the behavior. The other is how often the controller actually poll the matrix, since it could be different than the USB reporting rate.
Bull**** is a bad word.
Theis sososososososososososososososososososososososososososososososososososososososososososososososososososososososososososososososososososososo
much friendlier.
I get asasasasasasasasasasasasasasasasasas with this keyboard using WinXP:
(Attachment) 42852[/ATTACH]
On my Ducky, I get asssssssssssssssssssssssss on Win7. Both use USB, the Dell has 2KRO and the Ducky has NKRO. I wonder, if I use a PS/2 adapter on the Ducky, would Windows interpret the packets differently (actually behave according to PS/2 spec)?
See. I can't do M F.
If impressed with my keyboard scanning experiments and observations...
Filco scanning is too slow to pick up the small delay between the 2 keys I guess.
No quirk in my firmware.
With a credit card at a very slight angle:
left to right
wertywertywertywertywertywertywertywertywertywertywertywertywertywertywertywertywerty
right to left
ytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrewytrew
I can't believe Wellington 1869 used to obsess about this stuff so much. Reminds me of KL obsessing over me and posting every time I post.
ripster says...QuoteOriginally Posted by ripster (http://geekhack.org/showthread.php?p=542263)
I can't believe Wellington 1869 used to obsess about this stuff so much. Reminds me of KL obsessing over me and posting every time I post.
our records show...Show Image(http://geekhack.org/attachment.php?attachmentid=43583&d=1331502764)
oops!
science works.Small 'S' now?
Lol...ripster was just kidding. We're friends now!
See my subforum for more info =)
I'm using hasu's firmware so I can't say exactly what is the rate. I'll try to look at the code later to see if I can figure it out.