It is not *that* bad. If nothing has changed, the driver only pays the
cost of a 1024 bytes memcmp. Even more, there are no current users for
anything other than a PC, so I think we shouldn't overdesign at this point.
> - All accesses to the device depend on the previous behaviour whereas
> write(), read() syscall could be synchrone and easier to use for
> fast writing of image sets. Actually the refresh stuff is really
> needed only if you mmap the device. And it seems not really used
> for now since it was broken on your last patch.
That is not entirely true. If a user-space application misbehaves and
starts writing faster than what can actually be seen, not having a fixed
refresh rate means that your CPU will be *very* busy writing garbage
that the user won't be able to see.
A fixed refresh rate is a maximum CPU usage tunable that prevents
applications (that are not aware that this is an external slow device)
to write more than what they should.
This can be improved, however.
We could have the concept of a "dirty" buffer. Any write or nopage call
would set the dirty flag and set a timer to refresh the display in one
refresh period from now.
When doing the actual refresh, the "dirty" flag would be cleared and the
buffer unmapped.
In this case, if nothing was ever written to the display, the CPU usage
would be _zero_ (as it should), and it would work nicely with dynticks
and such.