Supporting virtual reality displays in Linux

Posted Mar 9, 2018 15:44 UTC (Fri) by excors (subscriber, #95769)
Parent article: Supporting virtual reality displays in Linux

> Those displays have an inertial measurement unit (IMU) for position and orientation tracking and a display with some optics.

Not really relevant to the article but I feel like mentioning it anyway: Good VR headsets don't just rely on the IMU for tracking. Vive requires you to put two 'lighthouse' boxes in high corners of your room, which emit IR pulses and beams that sweep across the room horizontally and vertically. Multiple IR sensors on the headset record the times when the beams reach them. The timing differences between each sensor, combined with the fixed position of each sensor relative to the headset, and some initial calibration, let you determine the absolute position and orientation of the headset. If I remember correctly they say it's accurate to about 1mm at a range of up to 5m, and it updates at 60Hz, which seems pretty decent.

> the one-frame latency introduced by using an LCD display evidently interferes with optimal game playing.

Hmm, I'm not sure about the "evidently" - I think a lot of competitive gamers' hardware choices are based more on superstition than evidence.

Supporting virtual reality displays in Linux

Posted Mar 9, 2018 19:48 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

> Hmm, I'm not sure about the "evidently" - I think a lot of competitive gamers' hardware choices are based more on superstition than evidence.

While I do tend to agree in general, not all games run at 60 Hz. A one-frame delay may be (more realistically) noticeable on a 24 Hz or maybe even a 30 Hz game.

Supporting virtual reality displays in Linux

Posted Mar 9, 2018 22:20 UTC (Fri) by excors (subscriber, #95769) [Link] (1 responses)

I assume the delay of an LCD is going to depend on the monitor's refresh rate, not the game's framerate, so just get a standard 144Hz gaming monitor and it'll be negligible (and perhaps even better than a 60Hz CRT).

Supporting virtual reality displays in Linux

Posted Mar 12, 2018 19:43 UTC (Mon) by hkario (subscriber, #94864) [Link]

the issue is with input-lag, not refresh rate (yes, they are similar, but they are different issues)

Supporting virtual reality displays in Linux

Posted Mar 9, 2018 22:27 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

Valid point, though AFAIK another reason CRTs are popular in that demographic is that they can usually go well above 60Hz - even the original Doom was designed for a 70Hz monitor.

Supporting virtual reality displays in Linux

Posted Mar 9, 2018 22:53 UTC (Fri) by zlynx (guest, #2285) [Link] (1 responses)

There's a lot of superstition about CRTs out there these days too. Too many people have never used one and those that did have nostalgia.

For one thing, if a CRT wasn't designed for 75 Hz refresh, its phosphors will have too much persistence and it'll smear. On the other hand, with too short persistence and too low a refresh it'll give you a headache from flicker.

And there's the "infinite resolution" myth. Nope. Display masks and dot pitch set very firm limits on where and how many pixels a CRT has.

And the "one frame delay" of LCD and the "super low latency" of CRT thing relies on using the CRT with no vertical sync. Which yes, some gamers did, but it was and still is ugly. And anyway, it only really applied to LCDs with a VGA connection where it had to process the analog signal into pixels. Most LCD gaming displays will set pixels as they come in over DP or HDMI. There really isn't a processing delay at all.

Supporting virtual reality displays in Linux

Posted Mar 10, 2018 18:38 UTC (Sat) by jem (subscriber, #24231) [Link]

>And there's the "infinite resolution" myth. Nope. Display masks and dot pitch set very firm limits on where and how many pixels a CRT has.

In theory, a color CRT has an uninterrupted phosphor layer just like a monochrome tube. In a color tube the phospor layer alternates between red, green and blue areas, which limits the resolution of the color component. The chrominance resolution is not limited by dot size: the signal can vary within a color dot, limited by the sharpness of the electron beamand the bandwidth of the video signal.

In practice, the dots have borders which affect picure quality, and the vertical resolution is of course limited by the discrete scan lines.