Implement CLOCK_MONOTONIC_RAW (linux >= 2.6.28).

It is documented as a raw hardware-based clock not subject to NTP or
incremental adjustments. With this "not as precise as CLOCK_MONOTONIC"
description in mind, map it to our CLOCK_MONOTNIC_FAST (the same
mapping as for the linux CLOCK_MONOTONIC_COARSE).

This is needed for the webcomponent of steam (chromium) and some
other steam component or game.

The linux-steam-utils port contains a LD_PRELOAD based fix for this.
There this is mapped to CLOCK_MONOTONIC.
As an untrained ear/eye (= the majority of people) is normaly not
noticing a difference of jitter in the 10-20 ms range, specially
if you don't pay attention like for example in a browser session
while watching a video stream, the mapping to CLOCK_MONOTONIC_FAST
seems more appropriate than to CLOCK_MONOTONIC.

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/compat/linux/linux_time.c b/sys/compat/linux/linux_time.c
index be38ef037a0f..f8a6d29bbdc5 100644
--- a/sys/compat/linux/linux_time.c
+++ b/sys/compat/linux/linux_time.c
@@ -212,6 +212,7 @@ linux_to_native_clockid(clockid_t *n, clockid_t l)
 		*n = CLOCK_THREAD_CPUTIME_ID;
 		break;
 	case LINUX_CLOCK_REALTIME_COARSE:
+	case LINUX_CLOCK_MONOTONIC_RAW:
 		*n = CLOCK_REALTIME_FAST;
 		break;
 	case LINUX_CLOCK_MONOTONIC_COARSE:
@@ -220,7 +221,6 @@ linux_to_native_clockid(clockid_t *n, clockid_t l)
 	case LINUX_CLOCK_BOOTTIME:
 		*n = CLOCK_UPTIME;
 		break;
-	case LINUX_CLOCK_MONOTONIC_RAW:
 	case LINUX_CLOCK_REALTIME_ALARM:
 	case LINUX_CLOCK_BOOTTIME_ALARM:
 	case LINUX_CLOCK_SGI_CYCLE: