What would be the benefit of this in $CURRENT_YEAR?

PS/2 has lower latency than USB

This & it was reliable.

I have a keyboard that uses ps/2. It's nice and I get an extra USB port because of it but it has the problem in that every few months the cable falls out and I have to reboot my computer to make the keyboard work again. This is because ps/2 doesn't support hot swapping. I guess that's just the trade off you make by using it.

So, when are you going back to cuckchan? Or any other site?

I just bought brand new motherboards with a brand new chipset and it still has these fucking ports.
I assumed it's because chinks and shit countries are still using these.

i wasn't aware of this.
superuser.com/questions/16893/do-usb-or-ps-2-keyboards-respond-faster

this also says usb has a limit of 6 key keys that can be down at any one time, while ps/2 has no limit. usb keyboards that want to detect more than 6 keys down at a time have to play games and pretend to be multiple keyboards.

It largely depends on how the USB is handled. Modern USB 3 is over PCIe IIRC and has a direct path to the CPU eliminating such latencies

wait, really? I guess u mean original playstation? cause the PS2 (the console), PS3, and PS4 don't use these.

*giggles*

really? I heard it won't detect it if you try to plug it in while the computer is on, but I didn't know it could brick your system!
scary

meanie!

oh cool! That sounds like a really nice advantage, as does

t-they don't like me over there! ;_;

Attached: pic.jpg (466x432, 40.07K)

My keyboard has the superior DIN-5 connector. Have to use adaptors these days.

Attached: 1512129934457.jpg (1268x1280, 276.51K)

should be good for vr then

youtube.com/watch?v=lHLpKzUxjGk

USB relies on polling to interact with its connected devices and answer their requests.
PS/2 on the other hand has a dedicated interrupt that gains almost immediate attention from the CPU when you press any key; it raises a high priority interrupt flag on CPU (IRQ1), only behind the system timer (IRQ0).

Then lurk more until I can't tell.

furfags out

they use chad interrupts instead of faggot virgin polling, you shouldn't even have to ask this question.

5-pin DIN is superior in every way

Attached: owo.jpg (1024x832, 51.1K)

Rather than using fucking USB it generates interrupts. It's the patrician way to input text and cursor commands.

For me, using PS/2 is a pain in the ass. I use it because I have a "dinosaur" keyboard, an IBM MODEL M. I love this keyboard but it is a little obnoxious to use an active converter if I want to use this keyboard in conjunction with a laptop that isn't from 2002.

No keyboard or mouse would use USB3, at least not any non-RGB gaymer models desperate for a gimmick.
I'd be surprised if some aren't still using USB1 chipsets.
`lsusb -v` and check bcdUSB

Still using my Extended II via ADB/USB adapter

Note that while nearly all older PS/2 interfaces and devices aren't hotplug safe, many newer ones actually are. Another problem is that even if it's safe to hotplug, the software might not recognize a hotplugged device.

Newer USB standards don't just increase speed, but offer other changes that are helpful even in slower modes. That said, yeah, I very much doubt anybody will make ultra-low-latency USB3 gaymur keyboards.

Attached: ADB-Stecker.jpg (500x380, 13.28K)

thanks doc

Attached: dd.jpg (500x282, 18.8K)

it's 10x cooler than vinyl, OP

>superuser.com/questions/16893/do-usb-or-ps-2-keyboards-respond-faster

Don't get usgayed. 1/10th to 1/16th the lag sounds pretty comfy anons

USB has to be polled, PS/2 sends an interrupt command directly to the CPU.
I don't think it's possible to be faster than PS/2

anything would be cooler than vinyl
because vinyl is useless crap with shit objective audio quality (only placebophiles will tell you they hear muh analog purity etc, which is obviously bullshit if you start doing any real comparison with the scientific methodology)

it can be made arbitrarily close to make the difference disappear in measurement noise.
500Hz polling for mice is pretty common btw.

reported

is the port faster or the keyboard itself?
I have a PS/2 mouse/key to USB. Do thinkpads have PS/2?

burtonsys.com/ps2_chapweske.htm
don't know how reliable but this seems reliable enough.
device generates the clock speed
clock speed must be 10 - 16.7 kHz.
8 bits of useful data per cycle
max speed
16.7*1000*8 = 133600b/s = 16700B/s = 16.7kB/s

Yes you can make it close insofar as input latency but the CPU can still decide to ignore the USB input, unlike PS/2.

by faster it means the latency is lower because ps/2 generates an interrupt on the cpu, while the host has to poll a usb device

Oh. I should find a laptop with PS/2 then. Isn't laptop's keyboard also the same since it's not
USB?

Unless you're running your programs on bare, OS-less metal (or under DOS, which is effectively the same thing), the keypress still has to bubble through the OS driver stack to the running application. Typically, this means the interrupt will simply save the new state somewhere, which is then polled by higher layers whenever the app is ready to receive input. You lose most of the advantage this way.

Patrician taste, user.

I would actually love a kb with an integrated USB3 hub.

No latency, detects more keys at once, uses less power, no drivers needed.

Laptop keyboards are usually connected over a PS/2 port, though a lot are using a USB-like interface nowadays.

CPU can decide to ignore anything if the software instructs it so.
bullshit argument tbh.

Non-maskable interrupts also?

#triggered

time to take a few guesses to my own question
why was ps/2 depreciated
ps/2 peripherals were depreciated due to
A. port design that is easy to break and twist due to lonely pins
B. relatively large for a connector with few contacts
C. bulky
D. not able to be used for non-peripherals
but I still don't understand why they didn't remain popular for >muh esports, since ps/2 connector on high end peripherals were manufactured at some point

It looks like some people are building specialist USB3 HID devices. These seem to be meant for industrial controls, although I have no clue why they went with USB3 in this specific case - the provided software seems to just behave like a normal USB keyboard.
xkeys.com/xkeys/xk3swi.php
I also noticed a few folks with broken English looking for information on setting up hardware for this mode. USB3 keyboards are coming...

They can't have macros, and le gaming laptops usually didn't have a pair of PS/2 connectors, and they seldom have even a single one anymore.

My keyboard came with a USB to PS/2 adapter, would it be worth it to use it?

So no RGBs.

So no proprietary keys.

First actual good reason.

it still won't magically know what to do.
and then it's up to software to choose.
I can write a trivial program that will ignore every other keypress, for example.

web.archive.org/web/20060323160257/http://www.cvtinc.com/products/keyboards/stellar.htm

they belong to the software side
macros in peripherals are 100% cancer

i seriously doubt most people are going to be able to perceive the difference between 2ms and 30ms for a keypress.
your also going to gain ms in that adapter.

another point, forgetting the monitor's actual response time, a 60hz refresh rate is 16ms. if the keyboard response is under the refresh rate it's especially not going to make any difference. though gaymers claim to notice a difference between 60fps and 120fps on a monitor that only displays 60fps.

Not necessarily, there is latency in e.g the computer too.

the latency adds up, there are many possible causes of more latency, and when it crosses a certain threshold, you will just suck balls at gaming because of poor reaction time and incoherence of your own motions (lack of proper visual feedback)

Is there a good way to measure input latency without having a high speed camera?

120 FPS is not high speed but it's present in almost every smartphone.
that leaves you with ~8.33ms of error for single measurement.
depending on your goal, that may be sufficient.
BUT, even if it isn't, you may retry and average.
the measurement error will be random and will mostly cancel out.

I have always heard this meme about PS/2 allowing unlimited simultaneous keypresses but that doesn't seem to be the case for me. It seems like after 5 or 6, any more will depend on the specific key I'm pressing. Although I'm not sure when you'd ever need to press more than 3 or 4 at once anyway.

I do use a PS/2 keyboard but I think it doesn't really matter unless you have a specific need for it.

considering it's a USB device it should be trivial to get around that limitation with a driver.
the benefit that I see here is because of the interrupt if the cpu is under heavy load and not polling the usb as often as it should be, then the keyboard should still go through.

but I use a 144Hz monitor for coding. The difference between 2 and 30 milliseconds is huge. Regular people can definitely feel a difference.

What are you, a keyboard virtuoso?
I use 10ms buffers with jack for midi controllers and never feel any lag until 20 ms.
30ms < 1000ms/60hz.
Why does Zig Forums hate throughput?

that's the best part

Doesn't the keyboard itself need to support >6 keys as well? So you'd need a keyboard that supports it with a PS/2 connector. Or am I wrong? I don't know a whole lot on the subject, because I've not played a lot of PC-only games that require many keys pressed simultaneously.

I use the PS/2 port for my Model M

Attached: bird.png (4000x3000 637.77 KB, 4.28M)

Attached: neat.jpg (500x491, 27.59K)

Attached: The Simpsons Marge gets mad [Clip] - YouTube.webm (640x360, 1.12M)

I love u! ^.^

Cool desktop

Attached: d4ba8c7a1ececbc50fc466608017665d.jpg (564x758, 54.12K)

there is a great virgin/chad meme of this

wow tech is full of larpers isn't it?
PS2 polls around 125Hz to 200Hz at best, USB can go to 1Khz+. So no, its not faster. It *may* have had a perceived advantage of being tied directly to an interrupt but in reality there doesn't seem to be any real world plus to this.

ps/2 can handle unlimited key presses at the same time, but usb can only handle 4.

usb also has to share bandwidth with other usb devices so its slower than ps/2 because it's waiting its turn.

You may be right. The keyboard itself is PS/2 though, I'm not using an adapter or anything. But it may be a limitation in my device rather than in the connector itself.

For everyone asking about simultaneous keypresses, what you want is NKRO (N-Key RollOver), which while it can be implemented easier on PS/2, is also possible over USB with workarounds (usually, as said, by pretending to be multiple keyboards). See here for a full overview of the subject:
deskthority.net/wiki/Rollover,_blocking_and_ghosting#n-key_rollover

you have some evidence to back that up or are you just going to be a nigger?

Simultaneous inputs of 104 keys any and all combinations of key presses registered with 100% accuracy.
USB can do 6 at a time then stops taking inputs.

Didn't specify it, but I referred to mice.

for NKRO, yes

excessive throughput is wasted electricity and bloat

Do PS/2 Mice have the same advantages as keyboards? And is it worth it to use one of those cheap adapters?

great.

30ms probably _is_ a problem.

LCDs are now in the 1-4ms range, according to sites like TFT Central

It's not so simple. On a CRT with vsync, the top left pixel has 0ms latency and the bottom right has approximately 16ms. An LCD is exactly the same except you now have pixel response time as well as display input latency added to this.

Input latency is strictly _added_ to end-to-end latency.

I just started timing this recently. It becomes impossible to aim consistently in an FPS when vsync of any type (double buffered, triple buffered (OpenGL), FIFO vsync (also called "triple buffered" by D3D)) is enabled in any game (aside from maybe beam racing, but i doubt any modern TPS/FPS has this). Double buffered vsync normally adds around 16 to input latency (it cannot add more, but it can add less for example if the game does some heavy computation before input in each frame), and this already makes the lag unbearable from my experience. Contrary to 99% of retards on the internet, vsync doesn't add input lag "because it locks the framerate" - locking the framerate to 60 on 60HZ feels much better (and looks much worse) than 60HZ vsync.

Again:

Again, it's not so simple. At 120FPS on 60HZ, you will usually see one half of frame A and half of frame B, and the tear between the two frames will move around depending on how far off your timer is from the monitor's clock (it's always off, even on high resolution timers).

Now what I want to test is whether 60FPS on 60HZ is as good as 120FPS on 60HZ. The main issue with this is that if your game is locked to 60HZ, the tear will noticably move up and down the screen (as the framerate fluctuates and didn't have a true 60HZ period equal to the monitor in the first place). I feel like this makes it harder to aim in many cases. But I think even increasing the framerate a tiny bit (61FPS for example) on 60HZ already remedies this because the tear moves so fast that it becomes negligable (aside from the game still looking like shit as it always will without vsync). So far I have been unable to tell the difference between 120FPS at 60HZ and 65FPS or so at 60HZ.

Having a framerate _less_ than the refresh rate is certainly bad though, because it causes stutter and increased motion blur. On that topic, 120HZ screens have half the motion blur of 60HZ (one of the only true advantages of 120HZ). Pixel response time has not been a significant cause of motion blur for LCDs for a long time now - instead it's mainly caused by the fact that the LCD displays one image for a period of time before showing the next (as opposed to CRT which shows any part of the image for a tiny amount of time (

wait, I thought you're talking about display latency, but both display latency and pixel response time are said to be this low now.

For me I always assumed it was because USB is so versatile and you could plug fucking anything into those ports, and because USB ports are so commonly manufactured, at some point it probably became cheaper to just use those.

It's damned easy to code for.

Attached: m.png (512x964, 9.61K)

also in quake 3 it is somewhat common to always look slightly below normal, unless you specifically expect some this happening above you.
as without vsync you will get the upper parts of screen earlier than the lower parts, this will again improve your reaction time.
(it combines naturally with some aspects of the correct usage of rocket launcher too)

fucked up while editing
replace with

Shit, I somehow messed up with deletion password.
Here's normal version of my text, mods please kill my previous 2 replies and I promise to be a good boy and not to do this shit again.

Not sure if it depends on a game but I can tell difference between that in all flavors of Quake 3 that I played, and also between 120 FPS and 200+ FPS at 60Hz too.
The difference is in the average display latency (and I'm very sensitive to visual latency) and the tearing looks uglier with less FPS, and also it has super ugly spots when FPS is close to being a multiple of the refresh rate or even refresh rate/2 (60, 90, 120, 180)
In Quake 3 latency basically trumps everything else, if you need to improve your game you need to make the latency as low as possible.
In many other fast games it is going to be the same (unless the game uses some retarded this to always force some minimal latency so that improving further from somewhere is intentionally made impossible, but I won't play that shit, it's the same level of retardation as locking the FPS to 30)
also in quake 3 it is somewhat common to always look slightly below normal, unless you specifically expect some this happening above you.
as without vsync you will get the upper parts of screen earlier than the lower parts, this will again improve your reaction time.
(it combines naturally with some aspects of the correct usage of rocket launcher too)

That's some sexy Bit bashing

I wouldn't strictly call that motion blur, as compared with the "sample-and-hold" artifacts you mention later, better terms are "ghosting" or "smearing".

As for LCDs, the official ratings for pixel response are as fantastically insane as their ratings for contrast ratio or viewing angle. Here's some lab photos of what is supposedly a "1ms GtG" panel, displaying over 5 frames of visible ghosting even with carefully tuned overdrive:
pcmonitors.info/reviews/asus-vg248qe/#Responsiveness
The only solution to this problem will be with a transition to OLED (or basically anything other than LCD), clearing the way not only to 120Hz displays that actually work, but to displays that approach the 1kHz barrier.

Isn't the correct approach exactly the opposite, capping 1-3 FPS lower than display framerate to substitute for v-sync without lag, in games that can't use 0-flip queue triple-buffering?

The primary advantage of 120Hz, regardless of blur, lag, ghosting, or stutter, is that your eye gets twice as much data from the game every second.

Isn't Quake 3's default physics tied to framerate in some subtly fucked up way?
openarena.wikia.com/wiki/Game_physics

in any reasonable tournament port, such as CPMA, no, they aren't.
it's now all about latency.

I think any mouse you find that has a PS/2 plug will have a DPI rate too low to be beneficial overall.

static void kbd_int_handler(void){ static uint16_t kbd_recv; uint32_t data; data = gpio_port_read(GPIOB) & GPIO9; kbd_recv >>= 1; kbd_recv |= data; if (kbd_recv & 1) { kbd_recv >>= 1; char c; if ((c = ps2_key_parse((uint8_t)kbd_recv))) { keyq[keyq_head++] = c; keyq_head &= (KBDQUEUE - 1); } kbd_recv = 0; }}

less branching version :^)

Yeah if it hovers in one spot its very distracting. But I still see the artifacts even far from a multiple of refresh rate at say 320FPS on 60Hz.

But assuming there's some refresh rate that's optimal for humans it may make sense to lock it there. The one big problem with variable refresh rate which pretty much every modern game uses is interpolation of player posistions. I wouldn't be surprised if it turned out in the future that it's better to lock to some constant framerate=tickrate=refreshrate (120Hz? 240Hz?) and remove interpolation.

m8, you're explaining how it is with vsync. the screen will look like this (but with a constant added to all lag values - for example 16.66ms with 60Hz double buffering or 0ms with beam racing):

0ms1ms2ms3ms4ms5ms6ms7ms8ms9ms10ms11ms12ms13ms14ms15ms16ms

Without vsync: Without a real close frame period to the monitor's refresh period, the tear will be a completely new random position every frame. But with an equal period the tear will start in a random position and will be in roughly the same position the entire game, so it can be the exact same thing as the above diagram, or it can be like this:

10ms11ms12ms13ms14ms15ms16ms0ms1ms2ms3ms4ms5ms6ms7ms8ms9ms

or like this

6ms7ms8ms9ms10ms11ms12ms13ms14ms15ms16ms0ms1ms2ms3ms4ms5ms

the official rating are exaggerated, they're almost always multiple ms lower than the results testers post
careful, pcmonitors guy doesn't know what he's talking about (the only English sites I've come across that seem to be not full of shit are Display Corner and TFT Central). I'll quote some of his misconceptions from [pcmonitors.info/articles/factors-affecting-pc-monitor-responsiveness/]:
No, LCD (ignoring display input lag) and CRT both in fact respond immediately regardless of refresh rate, because (ignoring VBI), it's always updating part of the screen. At 120FPS on 60Hz (ignoring vsync phase) each half of the screen has between 1-8ms of lag.
>pcmonitors.info/wp-content/uploads/2013/11/Sampling-comparison.png
No, the "dark phase" (which is completely irrelevant) is the VBI which is only ~1ms out of 16.67 at most. This is actually a big difference.
No, LCDs do not instantly display the frame and do nothing for 15ms, they do the exact same thing as CRT (ignoring added lag values here and there) but pixels stay the same until the beam comes by and updates them.
After rereading this article I'm not sure if he actually thinks stuff works this way or is trying to simplify it, but it's hugely misleading.
That's also not how it works oy vey.
Scanning would be like a CRT (no LCDs do this), strobing is not, since CRTs do not strobe since they scan out the image slowly over the period of 16.66ms-VBI.
Yeah but now you can actually see more stuff than blobs moving around your screen in an FPS because there's no motion blur. Except this is still slightly wrong, because when a frame is shown twice that can lead to reintroducing smearing or similar bad effects.

Also, PixPerAnn pictures aren't super meaningful aside from proving that pixel response time is less than 1 full frame (if they were 1 frame or longer you'd see two ghosts instead of just one). also camera shutter speed probably comes into play
But yes, as I said, response times to seem pretty low these days, but that still doesn't help much because of "sample-and-hold".

Do you know about strobe reduction black lights? They solve the problem as well. In order to do them properly the backlight should always be off except for a small period of time during the vertical blanking interval (right before displaying the next frame). They can introduce some input delay but at a high enough framerate that shouldn't be an issue. I'd assume this acceptable framerate with motion blur reduction is far less than 1kHz.

I'm not sure what you're saying. Capping the framerate without vsync will always introduce tearing. Capping below the refresh rate means some parts of the screen will show the same frame twice.
Are you talking about using the Direct3D with the prerender queue set to 0, or are you talking about OpenGL tripper buffering? The former sounds like lag and/or tearing. The latter has issues with stutter and requires massive refresh rates to reduce your input latency.

Yes, assuming that actually makes a perceptable difference. As I said it would reduce "sample-and-hold" smear by half which is a huge effect, but I'm not sure whether there's other big benefits. I've never tried 120Hz yet aside from the CRT days but I didn't pay much attention. At the very least very fast motion would be less likeky to be ruined by only beeing able to see an object for one frame as it crosses the screen.

It's virtually the same identical shit.

Attached: 9940624300_1429377724.png (606x606, 157.63K)

enjoy your bloat

Clear the shit from your eyes m8.

no man should be honest about a din that mini

this is in practice bullshit for LCD as they change pixels at the same time. it's gonna be all 16 ms.
or otherwise how would you explain the higher latency with vsync?
any kind of vsync adds so much to the average latency it's making quake 3 unplayable.

these are more mild.
of course you'll see some tearing, what I meant is that when the tearing is consistently in one position of the screen or moves slowly across (this is what happens near multiples) then it's nuts.