Is low persistence possible on dk1?

[Fredz]

It seems possible to flash the backlight on Android phones (see this tweet) and PWM modulation frequency can be adjusted on Windows for some Intel GPUs. So I guess it may be possible to manage strobed backlighting in pure software on PC, not sure which systems/GPUs could be supported though.

The /sys/class/backlight/ directory does exist on my Linux machine but it's empty, I'll try with the Rift connected to see if it does change anything.

Another (less ideal) solution would be to enable/disable brightness at the right time if no control of the backlight is possible. The screen can be turned black in this way but with the backlight still working at its current level, not ideal but still closer to black than whatever would be displayed with normal brightness.

On Linux brightness can be controlled with xrandr --output LVDS1 --brightness [0.0|1.0] on the command line, but I guess it can be also done programmaticaly by writing to some registers.

Some more info on backlight control on Linux : https://wiki.archlinux.org/index.php/Backlight

Some code in the Nouveau driver on Linux (NVIDIA GPUs) for backlight control (when the battery is low to limit the backlight intensity for example) :
http://cgit.freedesktop.org/nouveau/lin ... t/pwm_bl.c
http://cgit.freedesktop.org/nouveau/lin ... neric_bl.c

[geekmaster]

I suspect that the Rift DK1 control box switches are read and debounced by firmware, in which case the backlight brightness is under firmware control. If somebody wants to decompile the firmware for the Rift DK1 (IDA Pro?), it may be possible to control the backlight with a firmware patch. Perhaps a custom send_feature_report to pulse the backlight with a potential jitter of 1 msec (not a problem considering that the top and bottom of the screen are not normally visible on a DK1). The firmware is not encrypted, as can be seen with "strings" on a firmware image...

[Hannibalj2]

Wearing shutter-glasses with the Rift? Hmm...

Laugh Out Loud! (LOL)

[Fredz]

Thanks for the pointers geekmaster, but I still think it may be possible to access the backlight without modifying the firmware. And I hope so since that looks quite complicated. I've read that some manufacturers of LVDS controller boards even intentionaly obsfucate their code. May not be the case for all of them though.

So back to software control of the backlight.

Some months ago NVIDIA did release some documentation about their GPUs (yeah, everything happens... ), specifically documentation about the Device Control Block ("DCB") layout in the VBIOS.

In this documentation there is this paragraph about the Power and Backlight Control field of the Device Specific Information of the DCB. :

This field describes the control method for the power and backlight of the panel. Currently defined values are:
0 = External. This is used to define panels where we don’t have direct control over the power or backlight. For example, this value is used for most TMDS panels.
1 = Scripts. Used for most LVDS panels.
2 = VBIOS callbacks to the SBIOS.

Since the Rift DK1 uses a LVDS panel I suppose it falls in case 1, so it may be possible that the backlight can be controlled directly from the PC in software, contrary to case 0 it seems. I think case 0 must be for monitors and TVs for which control of the backlight doesn't make particular sense, as opposed to LVDS panels that seem to be used mostly in laptops, and for which backlight control is important since it has a direct incidence on power management.

So now it's only a matter of plugging the Rift and reading this field to see if the backlight can be controlled in this way.

Then it would probably be necessary to connect specific GPIOs to Pulse Width Modulated (PWM) signals to control the backlight power as indicated in the GPIO Assignment Table section and as illustrated in these patches : pwm-backlight: Add GPIO and power supply support.

This lists all the GPIO pins related to backlight control in the NVIDIA documentation :

• 0 = LCD0 backlight: Backlight control. LCD0 corresponds to the LCD0 defined in the LCD ID field in the Connector Table.
  138 = LCD1 backlight: Backlight control. LCD1 corresponds to the LCD1 defined in LCD ID field in Connector Table.
  144 = LCD2 backlight: Backlight control. LCD2 corresponds to the LCD2 defined in LCD ID field in Connector Table.
  150 = LCD3 backlight: Backlight control. LCD3 corresponds to the LCD3 defined in LCD ID field in Connector Table.
  156 = LCD4 backlight: Backlight control. LCD4 corresponds to the LCD4 defined in LCD ID field in Connector Table.
  162 = LCD5 backlight: Backlight control. LCD5 corresponds to the LCD5 defined in LCD ID field in Connector Table.
  168 = LCD6 backlight: Backlight control. LCD6 corresponds to the LCD6 defined in LCD ID field in Connector Table.
  174 = LCD7 backlight: Backlight control. LCD7 corresponds to the LCD7 defined in LCD ID field in Connector Table.

I guess similar information must be available for Intel and AMD/ATI hardware, so now it's only a matter of implementing that I guess. I don't even know where to start, but I'll have a try at it.

TL;DR : backlight may be controlled in software on NVIDIA GPUs, steps to follow :
1) read the Power and Backlight Control field of the DCB to confirm this for the Rift DK1 panel
2) connect a GPIO to PWM signals to control the backlight
3) control the backlight with the right timing (~15ms after vsync, <=3ms duration)
4) prof... hem, low-persistence LCD for VR...

[rupy]

Just wanted to let you know that you can if you run the game at >300 FPS you will "emulate" persistence in software and this works because the 60 frames you get are more "recent" than if you vertical and FPS sync!!!

This is important!!! All VR apps/games so far have made me sick because of slow rendering. So persistence is a huge thing, and I suspect that the new screen will only fix this issue if you have a really high FPS which causes problems for mutiplayer because you usually sync FPS to get all clients at the same speed!!!

A little off topic but how can you sync speeds without synching framerate for multiplayer? I don't think synching the physics at 60 FPS will help, suspect my brain will detect it and make me sick.

Last option is capping the game at 300 FPS and setting requirements really high!

[MSat]

Just wanted to let you know that you can if you run the game at >300 FPS you will "emulate" persistence in software and this works because the 60 frames you get are more "recent" than if you vertical and FPS sync!!!

This is important!!! All VR apps/games so far have made me sick because of slow rendering. So persistence is a huge thing, and I suspect that the new screen will only fix this issue if you have a really high FPS which causes problems for mutiplayer because you usually sync FPS to get all clients at the same speed!!!

A little off topic but how can you sync speeds without synching framerate for multiplayer? I don't think synching the physics at 60 FPS will help, suspect my brain will detect it and make me sick.

Last option is capping the game at 300 FPS and setting requirements really high!

It doesn't work like that because the panel can only operate at whatever refresh rate it's set to (typically 60hz, and never much higher than that).

[Fredz]

Just wanted to let you know that you can if you run the game at >300 FPS you will "emulate" persistence in software and this works because the 60 frames you get are more "recent" than if you vertical and FPS sync

You don't emulate low-persistence with an higher FPS, you reduce the time between the last sensor reading and the presentation of the pixels to the user. This does reduce latency (~13ms less compared to 60fps) which is probably why you experience less simulator sickness this way.

Low-persistence is used to reduce the motion blur produced by sample & hold displays, what Michael Abrash calls judder. It's corrected by illuminating the display for a small duration (1~2.5ms) instead of the full duration of the frame (16.7ms at 60Hz).

[rupy]

Just wanted to let you know that you can if you run the game at >300 FPS you will "emulate" persistence in software and this works because the 60 frames you get are more "recent" than if you vertical and FPS sync

You don't emulate low-persistence with an higher FPS, you reduce the time between the last sensor reading and the presentation of the pixels to the user. This does reduce latency (~13ms less compared to 60fps) which is probably why you experience less simulator sickness this way.

Low-persistence is used to reduce the motion blur produced by sample & hold displays, what Michael Abrash calls judder. It's corrected by illuminating the display for a small duration (1~2.5ms) instead of the full duration of the frame (16.7ms at 60Hz).

Thanks for explaining why! You wouldn't believe the difference it makes, I suspect it will be even more important with the OLED...