Screen Refresh

Screen Refresh

[Lucas Correia Villa Real]

Hi,

I'm writing a device driver for a monochrome LCD display managed by a 
controller that will be plugged into the CPU through a SPI, that is, I cannot 
directly memory-map it's address, since the communication will be done via 
a serial interface.

I've seen good chunks of code tonight (fbcon.c, fbmem.c and fbcon_mfb.c), but 
an unique question still remains: I didn't see anywhere *how* the buffer is 
updated to the video card. As far I could see on others drivers that I've 
read, they are doing that by memory mapping the video card's memory, and 
hence any write done into the buffer will be automagically reflected on the 
screen.

On my case I probably won't be able to memory map it's video memory. So, is 
there a way to get notified (at driver level) when some write is going to 
happen? Or should I just install a timer and use some kind of 
double-buffering scheme to verify if changes happened?

Many thanks in advance,
Lucas


-------------------------------------------------------
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

Re: Screen Refresh

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Wed, 2004-05-05 10:47:00 -0300, Lucas Correia Villa Real <lucasvr@gobolinux.org>
wrote in message <200405051047.00127.lucasvr@gobolinux.org>:
> I'm writing a device driver for a monochrome LCD display managed by a 
> controller that will be plugged into the CPU through a SPI, that is, I cannot 
> directly memory-map it's address, since the communication will be done via 
> a serial interface.

So I see two ways.

	If you only want to be able to output text, then you'd register
as a console device. You'll then get write accesses, which you can then
promote to real hardware.

	If you really want to provide a graphical display, you'll need
something like two buffers (one the kernel writes to, probably a 2nd one
to store the "current" image to only send down the changed pixels).
That'll come along with some timed function - not nice, but may work.

In theory, you'd try to not actually provide a framebuffer (memory), but
to simply give pointers to all those accelerated functions. If you've
got enough luck, you'll only see these functions called, so that you can
do graphics with merely no overhead of polling the whole memory...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Screen Refresh

[Lucas Correia Villa Real]

On Wednesday 05 May 2004 11:02, Jan-Benedict Glaw wrote:
> On Wed, 2004-05-05 10:47:00 -0300, Lucas Correia Villa Real
> <lucasvr@gobolinux.org>
>
> wrote in message <200405051047.00127.lucasvr@gobolinux.org>:
> > I'm writing a device driver for a monochrome LCD display managed by a
> > controller that will be plugged into the CPU through a SPI, that is, I
> > cannot directly memory-map it's address, since the communication will be
> > done via a serial interface.
>
> So I see two ways.
>
> 	If you only want to be able to output text, then you'd register
> as a console device. You'll then get write accesses, which you can then
> promote to real hardware.
>
> 	If you really want to provide a graphical display, you'll need
> something like two buffers (one the kernel writes to, probably a 2nd one
> to store the "current" image to only send down the changed pixels).
> That'll come along with some timed function - not nice, but may work.
>
> In theory, you'd try to not actually provide a framebuffer (memory), but
> to simply give pointers to all those accelerated functions. If you've
> got enough luck, you'll only see these functions called, so that you can
> do graphics with merely no overhead of polling the whole memory...

Hmm, that's a good idea! I'll need to have graphical display, so I think I'll 
start by writing a first release using this double buffering technique, and 
later try to play with accelerated functions.

Thanks for the help!
Lucas


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

[ PATCH-LINK ] fb accel capabilities - take 2

[David Eger]

I've taken Geert's suggestion and put the framebuffer capabilities flags 
in fbinfo.flags as follows:

 /* FBIF = FB_Info.Flags */
 #define FBIF_MODULE		0x0001	/* Low-level driver is a module */
 #define FBIF_HWACCEL_DISABLED	0x0002

 /* hints */
 #define FBIF_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
 #define FBIF_READS_FAST		0x0080 /* soft-copy faster than rendering */

 /* hardware supported ops */
 #define FBIF_HWACCEL_NONE	0x0000
 #define FBIF_HWACCEL_COPYAREA	0x0100
 #define FBIF_HWACCEL_FILLRECT	0x0200
 #define FBIF_HWACCEL_ROTATE	0x0400
 #define FBIF_HWACCEL_IMAGEBLIT	0x0800
 #define FBIF_HWACCEL_XPAN	0x1000
 #define FBIF_HWACCEL_YPAN	0x2000
 #define FBIF_HWACCEL_YWRAP	0x4000

The patch is very large (40 kilobytes), but 27 of those kilobytes are just 
the work of running 's/FBINFO_FLAG_DEFAULT/FBIF_DEFAULT/g'.  I've posted the
patch at http://www.yak.net/random/fbdev-patches/accel-cap-take2

The files there are:

rev-1.1415.radeonfb-copyarea-corruption-fix.patch
	This is in the mainline kernel, but not yet applied to benh's tree ;)

rev-1.1416.james-console-init-cleanup.patch
	James's patch, modified to apply against benh's tree.

rev-1.1417.fb-accel-capabilities.patch
	Baseline patch to make framebuffer/fbcon interaction more sane by 
	basing the fbcon heuristics on capabilities advertized by underlying 
	framebuffer via the fb_info.flags field.

	This patch updates fbcon, fb.h, and skeletonfb.c.
	It also does a 's/FBINFO_FLAG_DEFAULT/FBIF_DEFAULT/g' on the fb drivers 
	to let them compile.  
	It does *not* yet update the drivers themselves.  They should compile 
	and work, but their hinting is not correct yet, meaning most fb drivers
	will be slow until I set the flags to the right hinting driver-by-driver.

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).

-dte


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click