Hi Pavel,
Thanks again for reporting this.
Because neither X nor fbcon uses the char read/write path, this broke
a while ago and it didn't get noticed. I even highlighted this case
when trying to enumerate the different fbdev access models
(http://plugable.com/2010/01/30/linux-kernel-framebuffer-rendering-apis/
), yet still botched it.
But this is definitely something that should work, as it's a nice way
to drop a test image to hardware when perf doesn't matter.
A patch which restores the functionality is here:
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h=cd5e3761bb6b0132ba72d4...
Will get it cleaned up and moving downstream. Any feedback is welcome.
On fbcon -- sorry its con2fbmap, not fbset, to look for how to assign
a console to a framebuffer. fbcon uses blit and copy operations, so it
doesn't hit the paths you're seeing problems on.
On defio -- it would be great to get experienced help with the
problems we've been having there. Defio is essential for standard
mmap clients (xf86-video-fbdev, kdrive, or fbi, etc.) when we have a
system memory framebuffer like this -- timer-based updates aren't
practical, as there's just too much data involved here, so the system
load is unacceptable if we're entirely ignorant of what pixels are
changing. Defio's page-fault-based dirty detection is a nice
compromise.
Testing defio to recreate the problems is easy, just use any of the
standard fbdev clients mentioned above. Defio is enabled by default
in 2.6.34 as it stands. Defio can also be enabled/disabled with a
switch in the code.
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h=38e6da578178f439e6613d...
to see example of switching it.
We don't have enough eyes on these problems, because most people are
using udlfb with the custom X server written to it, which doesn't hit
any of these issues.
Again, any feedback, suggestions, or udlfb patches (direct to the
staging tree or here) are very welcome.
Thanks,
Bernie
http://plugable.com/
--
