staging: udlfb -- staging version does not work, external does
in [Kernel]
|
Prev: hid: add suspend/resume hooks for hid drivers
Next: Lockup inside of stop_machine() during modprobe aes (was Re: Another AR5008 hang)
From: Pavel Machek on 11 Apr 2010 13:40 Hi! > >> I don't think redirects like that will work. �The fbcon module loads > >> against one fb, and can only be switch with utilities like > >> "fbset" I tried playing with fbset, but it seems to only set videomodes. Ideally, I'd like to send kernel consoles to /dev/fb1, but that does not seem possible. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bernie Thompson on 12 Apr 2010 20:50
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=cd5e3761bb6b0132ba72d45b26ff55d22c9d727b 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=38e6da578178f439e6613d27fa946c0107394420 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |