linux-kernel - Re: staging: udlfb -- staging version does not work, external does

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Apr 2010 17:44:29 -0700
From:	Bernie Thompson <bernie@...gable.com>
To:	Pavel Machek <pavel@....cz>
Cc:	roberto@...it.it, gregkh@...e.de, Cyril Hrubis <metan@....cz>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: staging: udlfb -- staging version does not work, external does

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/