From: Mika Pruikkonen <mpruikko@cc.hut.fi>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: directfb-dev@directfb.org
Subject: Crude savagefb driver for 2.6 kernels
Date: Thu, 17 Jun 2004 05:31:27 +0300 [thread overview]
Message-ID: <20040617023127.GD41088@cc.hut.fi> (raw)
Hi,
You can find a crude patch for S3 Savage framebuffers in:
http://www.hut.fi/~mpruikko/savagefb/patch-2.6.7-savagefb
It's based on the 2.4 savagefb driver found in the directfb project's
cvs tree, with minor resyncing to the X driver. I really have no clue
about video driver programming, nor actually about kernel hacking
either, but I wanted to be able to do acpi suspend and have the
framebuffer work after the resume too, so here's the result. :)
I use this on an IBM Thinkpad T23, which has a S3 SuperSavage IXC and
a 1024x768 lcd screen, and the driver hasn't been tested on anything
else, so it will very probably not work without tweaking on most
savages.
Features: screen corruption during mode switching, interesting text
scroll effects, refreshingly unusual console color scheme at 16bpp,
hard-coded boot resolution 1024x768@8bpp, warranty void if you're
trying to use other resolutions than 1024x768. And I wouldn't try
compiling it as a module.
I also noticed that the driver was noticeably slower than vesafb (e.g.
using mplayer with fbdev/fbdev2, text scrolling, etc). Following patch
(incremental) hard-codes some timing registers to values which were in
use when using vesafb (with vga=792):
http://www.hut.fi/~mpruikko/savagefb/patch-2.6.7-savagefb-hardcoded-timing
With this patch the performance seems comparable to vesafb. I have
no idea how to fix this in general, though. I converted the timing
calculation functions to use non-floating-point arithmetic, but I think
they should produce the same results as in the directfb driver. Also, I
remember reading that someone complained about worse-than-vesafb
performance in the directfb driver too. Any ideas?
I hope someone can find this useful and/or maybe even get it to work,
and I would welcome patches for the known "features" (or unknown ones),
or much-needed cleanup.. best of all would of course be, if someone
who actually knew what he was doing would produce a proper driver to
be included in the kernel. :)
Regards,
mp
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
reply other threads:[~2004-06-17 2:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040617023127.GD41088@cc.hut.fi \
--to=mpruikko@cc.hut.fi \
--cc=directfb-dev@directfb.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).