Input Drivers Are Being Prepped For Year 2038 Safety

[phoronix]

Phoronix: Input Drivers Are Being Prepped For Year 2038 Safety

While kernel developers are busy with Spectre and Meltdown bugs right now, 20 years from now is the big "Year 2038" problem. Kernel developers are still working through the massive codebase to allow it to function past this "Unix Millenium Bug."..

http://www.phoronix.com/scan.php?page=news_item&px=Y2038-Input-Driver-Work

[M@yeulC]

Year 2106 compatibility should be more than enough

Sounds a bit familiar... Although I am reasonably confident that it won't be my problem anymore by then

[starshipeleven]

I'm unsure what is the point of having a full timestamp in an input driver anyway. You can use much shorter timestamps for input driver events, it's not like you really need to be able to tell if the input came from 20 years ago, you only need to be able to tell when the input event happened within the same day, at best.

But I'm sure I'm missing something important here.

[discordian]

Yes, whats the worst case for this? Some overflow in an input driver might mess up the mouse for a couple seconds?

(if any input driver is based on wallclock timestamps and cant handle jumps then its just broken)

[caligula]

I'm unsure what is the point of having a full timestamp in an input driver anyway. You can use much shorter timestamps for input driver events, it's not like you really need to be able to tell if the input came from 20 years ago, you only need to be able to tell when the input event happened within the same day, at best.

But I'm sure I'm missing something important here.

The y2038 systems support timestamp ranges up to 68 years.. Even shorter time span would be enough if modulo arithmetics was used. I can imagine relatively slow use cases like drag'n'drop or gamepads with buttons pressed for several seconds. Remote access via VNC might add small delays to the latencies. Even then the timespamp field has plenty of space even with milli/nanosecond precision.

[starshipeleven]

Yes, whats the worst case for this? Some overflow in an input driver might mess up the mouse for a couple seconds?

I think that such input driver will report your input event with a timestamp in the distant past (assuming it is written well enough and does not overflow). How well this will be handled by the kernel I don't know, but I suspect it would not work well if at all.

Remember the "millenium bug"? An application with that bug can't handle dates higher than 1999. Any date bigger than 1999 you pass to it will have the counter roll over itself and start counting again from 0, so for example instead of showing 2018 it would show 1918.

I have many old games with this amusing bug (reading system time on a Windows system, that itself isn't affected). Some of my high scores have a date in the early 1900 now.

[discordian]

I think that such input driver will report your input event with a timestamp in the distant past (assuming it is written well enough and does not overflow). How well this will be handled by the kernel I don't know, but I suspect it would not work well if at all.

err.. it will be in the distant past *because* of the overflow?
events that aren`t handled within a timeout will be dropped to free up the queue, there wont be any remains in the kernel.

Remember the "millenium bug"? An application with that bug can't handle dates higher than 1999. Any date bigger than 1999 you pass to it will have the counter roll over itself and start counting again from 0, so for example instead of showing 2018 it would show 1918.

Yes.
Except that we talk about input drivers, that`s rarely something that`s kept around, but forgotten fast. the produced events always are in the past, the kernel could easily detect such issues easily and I don' t thing many apps care for the timestamps... more then potentially do some mouse-smoothing.

[fqubtilfxhiq]

Realtime time stamps aren't Y2038 at present but developers of the kernel's input subsystem have been preparing input patches to make it Y2038-safe and make it safe to the year 2106. Year 2106 compatibility should be more than enough since the input developers want to eventually deprecate realtime timestamps.

So, why not deprecate realtime timestamps... now. You're not telling me it would take more than 20 years to actually do that?

"Oh, we'd better push it to 2038 quickly so we'll have more time to figure it out!"

[baka0815]

It could be that no input is possible anymore if the input system "thinks" that the input happend years ago and just drops it.