David Eger wrote:
> If the patch looks good to you (James, Geert, BenH), I'd like to
> forward it on to Linus followed by the individual driver updates
> (that'll take a little longer -- I need to revise how drivers do
> things like remember noaccel, etc. and update them).
You are aware of the fact that some of the fb drivers have maintainers.
aren't you?
How about properly documenting what you actually do and let the driver
maintainer handle the implementation?
General question (not to you only): How about considering the 2.6 series
as "stable" as everybody else does and keep it to fixing bugs instead of
change the driver API the Xth time?
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Thomas Winischhofer eloquently put:
David Eger wrote:
> If the patch looks good to you (James, Geert, BenH), I'd like to
> forward it on to Linus followed by the individual driver updates
> (that'll take a little longer -- I need to revise how drivers do
> things like remember noaccel, etc. and update them).
How about properly documenting what you actually do and let the driver
maintainer handle the implementation?
see the update to skeletonfb.c
General question (not to you only): How about considering the 2.6 series
as "stable" as everybody else does and keep it to fixing bugs instead of
change the driver API the Xth time?
If you want to handle the fix for sisfb, please do, I'll skip over that one ;-)
It's all part of fixing bugs ;-) When my "accelerated" fb driver is still
super-slow, i consider that a bug. And it's a bug of the framebuffer
subsystem, not really of the drivers. Your lovely
SiS310SubsequentScreenToScreenCopy() and friends (do I smell xfree86 code here?
;-) ) would probably work great if they were ever called. Currently, they're
not :-P
The patch (a later version mailed to lkml against mainline) fixes an issue
discussed in a large thread previously. The Linux 2.6 fbdriver/kernel
interface is opaque as to what hardware acceleration a video card *actually*
provides. There are a bunch of entry-points, but they're often done by
software. This patch fixes the framebuffer interface so that fbcon (currently
the only app that really lives on top of the fb subsystem) can sanely choose
its method of rendering.
-dte
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
On Friday 28 May 2004 11:38, David Eger wrote:
Thomas Winischhofer eloquently put:
quoted
David Eger wrote:
It's all part of fixing bugs ;-) When my "accelerated" fb driver is still
super-slow, i consider that a bug. And it's a bug of the framebuffer
subsystem, not really of the drivers. Your lovely
There is also another cause for the slowdown. Although 2.6 fbcon is slightly
faster than 2.4 fbcon (not considering other variables such as panning), the
speed can be increased further more (around 30-50%).
This is mainly due to the use of sys_inbuf and sys_outbuf, which are used a
lot, for transferring data from the pixmap when creating the monochrome
bitmap (for use by xxx_imageblit). I guess we just need to use standard
memcopy (or similar), possibly inlined, if the pixmap is in system RAM, and
only use sys_inbuf and sys_outbuf when the pixmap is in video/DMA/etc memory.
Tony
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click