It's absolutely a zoning issue. The Texas legislature is literally overriding large cities to force them to allow smaller lot sizes. Most of Dallas, for example, is R-7.5, which drives up cost because land is expensive and it requires you to dedicate a lot of it to your yard (max 45% coverage). Only a few areas, like some PDs in old east Dallas, have been rezoned to allow the smaller lots, though you seem to believe its all of Dallas city limits.
NHTSA has a 25-year rule that allows a car old than 25 years to be imported without those considerations. You can definitely import them legally in Texas. I find it funny that we disallow these new smaller trucks, but we allow folks to jack up the suspension on an already large American truck 24 inches, install a grille guard, and it's still considered legal.
They are also huge offenders! At least in Los Angeles.
A pet project of @FilmThePoliceLA is filming & posting videos of cops’ personal vehicles with illegal modifications. He calls them out directly if he sees them, they never have any reasonable response.
Flipper has no mechanism to read a magstripe, so no, I don't think so. But it's possible to clone all kinds of other things. I cloned my SO's old building key (Mifare 1k classic) so she wouldn't need to "buzz" me up.
Our awper ran out of bullets the other week forgetting the magazine change lol. Definitely changes the round dynamics as he can't hold the same and has to be more judicious.
There are two "scan" rates: the rate at whitch keyboard matrix is scanned by whatever electronics is inside keyboard (that is probably independent of the outside interface) and the rate at which the interface is able to process input events, which for PS/2 means faster that the keyboard can produce them (as keyboard is essentially bus master on the AT/PS2 keyboard "bus") and for USB means as fast as the *HCI pools keyboard for interrupt events (old Apple's ADB works the same way and is in fact to some extent inspiration for USB <3.0 and Firewire "one big bus" high level model).
Edit: then there is third approach: simple keyboard/input devices with serial interfaces, where host provided clock is used to both clock the interface and keyboard scan logic. In essence the whole keyboard then looks like one big shift register. Keyboards that works this way includes original Macintosh, most Wyse and DEC terminals and MIT/LMI/Symbolics Lisp machines (and probably pre-sun4 Suns, sun4 and later have rs232-derived ionterface), also this is the way how controllers for Nintendo consoles before Wii work (IIRC Nintendo calls that "EXI bus") and how PlayStation 1/2 controllers work. IMHO this is to some extent where the idea behind SPI comes from.
Most importantly it removes the penalty of using a 1000hz scanning input which can have an adverse affect on the cpu whilst providing a better (yet insignificant) result.
I've gotten a FTDI down to 2 ms RTT, so if done right (using isochronous transfer) you can get USB down to 1 or max 2 ms. Looking at the latencies quoted here and in the article it's certainly not the problem.
Notice that just getting a thread scheduled every 2 ms is already impossible for Windows, certainly one running a game. You'll get a bunch of outliers within the second. So even if you got your keyboard down to 5 ms, great, but you are not running an operating system that can reliably do something within that timespan!
>So even if you got your keyboard down to 5 ms, great, but you are not running an operating system that can reliably do something within that timespan!
Maybe I'm not understanding, but that doesn't seem correct.
Most people (gamers) are running mice at 500/1000Hz polling rates and you can easily verify the movement made in each 1-2ms update. (And it is most definitely a noticeable difference going from a standard 125Hz rate to even 500Hz.)
Don't confuse throughout and latency. The mouse may be measuring and sending data every 1-2ms, but that doesn't say anything about the latency before the data is handled.
This is also a pretty important point: most monitors refresh at 60hz anyway even if your game seems to be measuring much higher framerates, so there's a worst case floor of ~17s on just visuals lagging behind input because you're waiting for the next screen refresh anyway.
The mouse measuring data every 1-2ms will increase the quality of the motion tracking, but it won't necessarily help you with latency unless the data gets to the game fast and the game handles the data quickly.
True, though these days 144Hz monitors are everywhere (Personally I used a CRT until LCDs were capable of 120Hz, not sure I could ever go back to 60), makes a big difference I think when down to a 7ms window. Using a mouse at 125 on a modern screen feels really janky.
I'm unaware of any pro gamer (or streamer) that's using PS/2, and that's about as serious a gamer as you get. Most are using a late model mechanical keyboard connected via USB, often with lots of RGB just because.
I think the only PS/2 holdouts you'll find are the old Korean Starcraft players that are still using a Qsenn DT-35.
PS/2 supports lots of RGB, I'm using one, because using the USB costs CPU where as the PS/2 does not, and PS/2 gives NKRO and lower latency, however insignificant they are.
It's entirely a preference based thing, the most relevant factor would be whether or not you need to hot swap it.
Pro gamers are paid to use whatever their sponsors want them to use.
And if their new fancy keyboard is good enough not to negatively affect their game, I don't see why they would turn down the money.
That's tangential though. Whether or not you have skipped frames, G-Sync/FreeSync tend to reduce input lag, because the panel's refresh events will be timed such that they're closer, on average, to the times when new frames become available.
Most competitive players will have their own configs for competitive play etc. I have tournament/LAN configs, online play configs, and my video settings mostly stay the same. All tuned for lowest latency and highest visibility.
Pro gamers in highly competitive, reaction-based games (such as most first-person shooters) usually disable it, yeah.
And I'm not an expert in this either, but I'm pretty sure double buffering is the norm, whether you use V-Sync or not.
One buffer in which your graphics card works on frames (I'll call this "graphics card buffer") and then a buffer into which finished frames are moved, so that your screen can read them out in peace (I'll call this "pre-screen buffer").
There's also "triple buffering", which introduces another one of those graphics card buffers, so that when a finished frame is being transferred from that first graphics card buffer to the pre-screen buffer, then your graphics card doesn't have to wait for that transfer to finish and can instead start working in the second graphics card buffer right away. (And then it transfers frames from those graphics card buffers in alternating fashion.)
So, the delay that V-Sync introduces is not that. What V-Sync does, is that instead of transferring finished frames from the graphics card buffer(s) into the pre-screen buffer as soon as the frame is finished, it waits with the transfer until your screen has finished with reading out the previous frame.
If you don't wait (have V-Sync disabled), your screen will read out some part of the previous frame and then read out the rest from the new frame. On the screen, you'll see this break between previous and new frame as screen tearing.
So, assuming your screen can display 120 frames per second and your graphics card happens to finish 120 frames in a second, then V-Sync will not introduce a delay. It'll wait once with transferring the first frame, but then they'll be in sync and no further delay should occur.
However, if your graphics card is able to calculate 240 frames per second (and your screen still does 120 frames per second), then with V-Sync, the graphics card buffer will be transferred into the pre-screen buffer only 120 times per second, making the graphics card slow down to 120 frames per second as well.
Without V-Sync, the graphics card buffer will be transferred 240 times per second, regardless of how often your screen can read it out from the pre-screen buffer. This means a frame will get loaded into the pre-screen buffer as your screen is reading it out. As a result, you'll get screen tearing and one half of your screen will be from the new frame, with a 1/240 s = 4.167 ms delay, the other half is still from the previous frame with a 2/240 s = 1/120 s = 8.33 ms delay.
So, a few numbers:
120 FPS with 120 Hz screen = 8.33 ms delay.
240 FPS with 240 Hz screen = 4.167 ms delay.
240 FPS with 120 Hz screen = ½8.33 ms + ½4.167 ms = 6.25 ms delay on average.
480 FPS with 120 Hz screen = ¼(1/480) + ¼(1/360) + ¼(1/240) + ¼(1/120) = 4.34 ms delay on average.
960 FPS with 120 Hz screen = 2.83 ms delay on average.
960 FPS with 240 Hz screen = 2.17 ms delay on average.
Most mechanical PS2 keyboards are a diode cascade.
You pressing the key triggers a wave of electricity cross the keyboard which is converted into the PS2 waveform, and pumped out at the same rate of the incoming clock waveform.
OLD PS2 keyboards don't generally have internal digital micro-controllers, they're effectively analog, the logic they do contain is blindly simple. This is why some struggle with N-Key Rollover.
---
OFC this is if you are using an -old- PS2 keyboard. I'm still using an 80's IBM Model M and above it roughly how it works.
This is absolutely untrue for any PS/2 keyboard, as well as for most pre-PS/2 PC keyboards (incuding AT and XT keyboards). All keyboards have always had a microcontroller in them which is responsible for scanning the key matrix and sending output over the serial link. (In PS/2, it's also responsible for reading input to change the state of keyboard LEDs.) There is nothing analog about them whatsoever.
Here is a set of pictures of an IBM Model M, for instance. The microcontroller is clearly visible in the ceramic DIP40 package.
PS/2 and AT are also bidirectional protocols for controlling the LEDs, key repeat, and various other commands that at a minimum requires some sort of digital state machine to manage the interface.
- I cannot find about "diode cascades" having anything to do keyboards. The closest is the usual diode matrix to deal with simultaneous key presses.
- The PS/2 interface involves sending scan codes, parity bits, and start and stop bits. How exactly does a "wave of electricity" get converted into a PS/2 waveform without some digital electronics?
- All the old schematics for mechanical keyboards I could find were the usual matrix scan. Even a textbook from the 1970s.
Anyway, reference please. I'd find it very interesting to see how such a thing would work.
