> That being said, it is still desirable to try to achieve a somewhat
> accurate tick in the simulator if we can do it without making the simulator
> code non-portable. Currently it runs 10 times too fast, on the system I run
> on, so all the places in the rockbox code that check on an elapsed time by
> doing "TIME_AFTER(current_tick, xxx)" are off by a factor of 10.

Yeah, that's a pretty big difference.

> When I change the increment value in x11_sleep form 5 to 'tics', then
> current_tick runs about 3 times too fast (because of the problem that I
> discussed earlier where multiple threads can be in a sleep call and all
> will be incrementing current_tick).
>
> The best quick fix seems to be to change the increment value in x11_sleep
> from 5 to 1. This works fairly well because no matter what rockbox is
> doing, there is always a thread doing constant calls to
> button_get_w_timeout which does multiple calls of sleep(1) to do its
> timeout.

Right, that would be a quick somewhat working way. But what about doing it
like this: we add an extra thread that only updates a global max_tick
variable every second (or so), and then the x11_sleep() makes sure to never
increase the 'current_tick' to a value that is larger than to the max_tick
value. Then we'll get a tick counter that moves EXACTLY as it should in
average over many seconds. Ok, it won't be moving with a constant rate, but I
don't think that'll be a problem...

Oh, and when max_tick is set, it must also make sure that current_tick is no
less than (max_tick - HZ). In fact, it could be set to max_tick - HZ, as it
shouldn't be larger either! :-)