fbdev: platforming metronomefb and am200epd
Subsystems (2)
PATCH 1/2 fbdev: platforming metronomefb and am200epd
Hi Tony, Geert, Andrew, fbdev,
This patchset has 2 patches. They are are in order to split metronomefb and hecubafb into platform independent (platform drivers) and platform specific (platform devices) drivers which are am200epd (arm) and n411 (x86). The improvement over the last time I posted this is that I've now added module refcount handling in the platform drivers and so module loading/unloading works.
I would be grateful for any feedback on this.
Thanks,
jaya
This patch splits metronomefb into the platform independent metronomefb and the platform dependent am200epd. It also includes some comment cleanup and a bugfix for the use of cfb_* functions instead of sys_* functions. The Kconfig and Makefile changes include the changes needed for hecubafb and n411.
---
Documentation/fb/metronomefb.txt | 16 - drivers/video/Kconfig | 33 ++-- drivers/video/Makefile | 2 drivers/video/am200epd.c | 295 +++++++++++++++++++++++++++++++++++ drivers/video/hecubafb.c | 302 +++++++++--------------------------- drivers/video/metronomefb.c | 320 ++++++--------------------------------- drivers/video/n411.c | 202 ++++++++++++++++++++++++ include/video/hecubafb.h | 51 ++++++ include/video/metronomefb.h | 62 +++++++ 9 files changed, 767 insertions(+), 516 deletions(-)
Documentation/fb/metronomefb.txt +7 -9
@@ -1,7 +1,7 @@ Metronomefb ----------- Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> -Last revised: Nov 20, 2007 +Last revised: Mar 10, 2008 Metronomefb is a driver for the Metronome display controller. The controller is from E-Ink Corporation. It is intended to be used to drive the E-Ink
@@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html . Metronome is interfaced to the host CPU through the AMLCD interface. The host CPU generates the control information and the image in a framebuffer which is then delivered to the AMLCD interface by a host specific method. -Currently, that's implemented for the PXA's LCDC controller. The display and -error status are each pulled through individual GPIOs. +The display and error status are each pulled through individual GPIOs. -Metronomefb was written for the PXA255/gumstix/lyre combination and -therefore currently has board set specific code in it. If other boards based on -other architectures are available, then the host specific code can be separated -and abstracted out. +Metronomefb is platform independent and depends on a board specific driver +to do all physical IO work. Currently, an example is implemented for the +PXA board used in the AM-200 EPD devkit. This example is am200epd.c Metronomefb requires waveform information which is delivered via the AMLCD interface to the metronome controller. The waveform information is expected to be delivered from userspace via the firmware class interface. The waveform file can be compressed as long as your udev or hotplug script is aware of the need -to uncompress it before delivering it. metronomefb will ask for waveform.wbf -which would typically go into /lib/firmware/waveform.wbf depending on your +to uncompress it before delivering it. metronomefb will ask for metronome.wbf +which would typically go into /lib/firmware/metronome.wbf depending on your udev/hotplug setup. I have only tested with a single waveform file which was originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for. Caution should be exercised when manipulating the waveform as there may be
drivers/video/Kconfig +20 -13
@@ -149,6 +149,16 @@ config FB_DEFERRED_IO depends on FB default y +config FB_METRONOME + tristate + depends on FB + depends on FB_DEFERRED_IO + +config FB_HECUBA + tristate + depends on FB + depends on FB_DEFERRED_IO + config FB_SVGALIB tristate depends on FB
@@ -674,20 +684,18 @@ config FB_IMAC help This is the frame buffer device driver for the Intel-based Macintosh -config FB_HECUBA - tristate "Hecuba board support" +config FB_N411 + tristate "N411 Apollo/Hecuba devkit support" depends on FB && X86 && MMU select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS select FB_DEFERRED_IO + select FB_HECUBA help - This enables support for the Hecuba board. This driver was tested - with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO - interface (8 bit data, 4 bit control). If you anticipate using - this driver, say Y or M; otherwise say N. You must specify the - GPIO IO address to be used for setting control and data. + This enables support for the Apollo display controller in its + Hecuba form using the n411 devkit. config FB_HGA tristate "Hercules mono graphics support"
@@ -1893,19 +1901,18 @@ config FB_XILINX framebuffer. ML300 carries a 640*480 LCD display on the board, ML403 uses a standard DB15 VGA connector. -config FB_METRONOME - tristate "Metronome display controller support" +config FB_AM200EPD + tristate "AM-200 E-Ink EPD devkit support" depends on FB && ARCH_PXA && MMU select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS select FB_DEFERRED_IO + select FB_METRONOME help - This enables support for the Metronome display controller. Tested - with an E-Ink 800x600 display and Gumstix Connex through an AMLCD - interface. Please read <file:Documentation/fb/metronomefb.txt> - for more information. + This enables support for the Metronome display controller used on + the E-Ink AM-200 EPD devkit. config FB_VIRTUAL tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
drivers/video/Makefile +2 -0
@@ -29,6 +29,7 @@ obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o # Hardware specific drivers go first obj-$(CONFIG_FB_AMIGA) += amifb.o c2p.o +obj-$(CONFIG_FB_AM200EPD) += am200epd.o obj-$(CONFIG_FB_ARC) += arcfb.o obj-$(CONFIG_FB_CLPS711X) += clps711xfb.o obj-$(CONFIG_FB_CYBER2000) += cyber2000fb.o
@@ -47,6 +48,7 @@ obj-$(CONFIG_FB_SAVAGE) += savage/ obj-$(CONFIG_FB_GEODE) += geode/ obj-$(CONFIG_FB_MBX) += mbx/ obj-$(CONFIG_FB_NEOMAGIC) += neofb.o +obj-$(CONFIG_FB_N411) += n411.o obj-$(CONFIG_FB_3DFX) += tdfxfb.o obj-$(CONFIG_FB_CONTROL) += controlfb.o obj-$(CONFIG_FB_PLATINUM) += platinumfb.o
drivers/video/am200epd.c new file +295 -0
295 lines not on this page · raw message
drivers/video/metronomefb.c +50 -270
515 lines not on this page · raw message
include/video/metronomefb.h new file +62 -0
62 lines not on this page · raw message
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
PATCH 2/2 fbdev: platforming hecubafb and n411
This patch splits hecubafb into the platform independent hecubafb and the platform dependent n411. It also includes some comment cleanup and a bugfix for hecubafb_write which would return an incorrect error value for framebuffer writes.
---
drivers/video/hecubafb.c +78 -224
@@ -1,5 +1,5 @@/* -* linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller +* linux/drivers/video/hecubafb.c -- FB driver for Hecuba/Apollo controller * * Copyright (C) 2006, Jaya Kumar * This work was sponsored by CIS(M) Sdn Bhd
@@ -17,18 +17,13 @@* values. There are other commands that the display is capable of, * beyond the 5 used here but they are more complex. * -* This driver is written to be used with the Hecuba display controller -* board, and tested with the EInk 800x600 display in 1 bit mode. -* The interface between Hecuba and the host is TTL based GPIO. The -* GPIO requirements are 8 writable data lines and 6 lines for control. -* Only 4 of the controls are actually used here but 6 for future use. -* The driver requires the IO addresses for data and control GPIO at -* load time. It is also possible to use this display with a standard -* PC parallel port. +* This driver is written to be used with the Hecuba display architecture. +* The actual display chip is called Apollo and the interface electronics +* it needs is called Hecuba. * -* General notes: -* - User must set hecubafb_enable=1 to enable it -* - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR +* It is intended to be architecture independent. A board specific driver +* must be used to perform all the physical IO interactions. An example +* is provided as n411.c * */
@@ -47,34 +42,12 @@#include <linux/list.h> #include <linux/uaccess.h> -/* Apollo controller specific defines */ -#define APOLLO_START_NEW_IMG 0xA0 -#define APOLLO_STOP_IMG_DATA 0xA1 -#define APOLLO_DISPLAY_IMG 0xA2 -#define APOLLO_ERASE_DISPLAY 0xA3 -#define APOLLO_INIT_DISPLAY 0xA4 - -/* Hecuba interface specific defines */ -/* WUP is inverted, CD is inverted, DS is inverted */ -#define HCB_NWUP_BIT 0x01 -#define HCB_NDS_BIT 0x02 -#define HCB_RW_BIT 0x04 -#define HCB_NCD_BIT 0x08 -#define HCB_ACK_BIT 0x80 +#include <video/hecubafb.h> /* Display specific information */ #define DPY_W 600#define DPY_H 800 -struct hecubafb_par { -unsigned long dio_addr; -unsigned long cio_addr; -unsigned long c2io_addr; -unsigned char ctl; -struct fb_info *info; -unsigned int irq; -}; -static struct fb_fix_screeninfo hecubafb_fix__devinitdata = { .id ="hecubafb" , .type =FB_TYPE_PACKED_PIXELS ,
@@ -82,6 +55,7 @@ static struct fb_fix_screeninfo hecubafb_fix __devinitdata = { .xpanstep = 0, .ypanstep = 0, .ywrapstep = 0, + .line_length = DPY_W, .accel = FB_ACCEL_NONE, };
@@ -94,136 +68,51 @@ static struct fb_var_screeninfo hecubafb_var __devinitdata = { .nonstd = 1, }; -static unsigned long dio_addr; -static unsigned long cio_addr; -static unsigned long c2io_addr; -static unsigned long splashval; -static unsigned int nosplash; -static unsigned int hecubafb_enable; -static unsigned int irq; - -static DECLARE_WAIT_QUEUE_HEAD (hecubafb_waitq); - -static void hcb_set_ctl (struct hecubafb_par *par) -{ -outb (par->ctl, par->cio_addr); -} - -static unsigned char hcb_get_ctl (struct hecubafb_par *par) -{ -return inb (par->c2io_addr); -} - -static void hcb_set_data (struct hecubafb_par *par,unsigned char value) -{ -outb (value, par->dio_addr); -} - -static int __devinit apollo_init_control (struct hecubafb_par *par) -{ -unsigned char ctl; -/* for init, we want the following setup to be set: -WUP = lo -ACK = hi -DS = hi -RW = hi -CD = lo -*/ - -/* write WUP to lo, DS to hi, RW to hi, CD to lo */ - par->ctl =HCB_NWUP_BIT |HCB_RW_BIT |HCB_NCD_BIT ; - par->ctl &= ~HCB_NDS_BIT ; -hcb_set_ctl (par); - -/* check ACK is not lo */ - ctl =hcb_get_ctl (par); -if ((ctl &HCB_ACK_BIT )) { -printk (KERN_ERR "Fail because ACK is already low\n" ); -return -ENXIO ; - } - -return 0 ; -} - -static void hcb_wait_for_ack (struct hecubafb_par *par) -{ - -int timeout; -unsigned char ctl; - - timeout=500 ; -do { - ctl =hcb_get_ctl (par); -if ((ctl &HCB_ACK_BIT )) -return ; -udelay (1 ); - }while (timeout--); -printk (KERN_ERR "timed out waiting for ack\n" ); -} - -static void hcb_wait_for_ack_clear (struct hecubafb_par *par) -{ - -int timeout; -unsigned char ctl; - - timeout=500 ; -do { - ctl =hcb_get_ctl (par); -if (!(ctl &HCB_ACK_BIT )) -return ; -udelay (1 ); - }while (timeout--); -printk (KERN_ERR "timed out waiting for clear\n" ); -} +/* main hecubafb functions */ static void apollo_send_data (struct hecubafb_par *par,unsigned char data) {/* set data */ -hcb_set_data (par, data); + par->board->set_data (par, data);/* set DS low */ - par->ctl |=HCB_NDS_BIT ; -hcb_set_ctl (par); + par->board->set_ctl (par,HCB_DS_BIT ,0 ); -hcb_wait_for_ack (par); +/* wait for ack */ + par->board->wait_for_ack (par,0 );/* set DS hi */ - par->ctl &= ~(HCB_NDS_BIT ); -hcb_set_ctl (par); + par->board->set_ctl (par,HCB_DS_BIT ,1 ); -hcb_wait_for_ack_clear (par); +/* wait for ack to clear */ + par->board->wait_for_ack (par,1 ); }static void apollo_send_command (struct hecubafb_par *par,unsigned char data) {/* command so set CD to high */ - par->ctl &= ~(HCB_NCD_BIT ); -hcb_set_ctl (par); + par->board->set_ctl (par,HCB_CD_BIT ,1 );/* actually strobe with command */ apollo_send_data (par, data);/* clear CD back to low */ - par->ctl |= (HCB_NCD_BIT ); -hcb_set_ctl (par); + par->board->set_ctl (par,HCB_CD_BIT ,0 ); } -/* main hecubafb functions */ -static void hecubafb_dpy_update (struct hecubafb_par *par) {int i;unsigned char *buf = (unsigned char __force *)par->info->screen_base; -apollo_send_command (par,0xA0 ); +apollo_send_command (par,APOLLO_START_NEW_IMG );for (i=0 ; i < (DPY_W *DPY_H /8 ); i++) {apollo_send_data (par, *(buf++)); } -apollo_send_command (par,0xA1 ); -apollo_send_command (par,0xA2 ); +apollo_send_command (par,APOLLO_STOP_IMG_DATA ); +apollo_send_command (par,APOLLO_DISPLAY_IMG ); }/* this is called back from the deferred io workqueue */
@@ -270,41 +159,43 @@ static void hecubafb_imageblit(struct fb_info *info,static ssize_t hecubafb_write (struct fb_info *info,const char __user *buf,size_t count,loff_t *ppos) { -unsigned long p; -int err=-EINVAL ; -struct hecubafb_par *par; -unsigned int xres; -unsigned int fbmemlength; +struct hecubafb_par *par = info->par; +unsigned long p = *ppos; +void *dst; +int err =0 ; +unsigned long total_size; - p = *ppos; - par = info->par; - xres = info->var.xres; - fbmemlength = (xres * info->var.yres)/8 ; +if (info->state !=FBINFO_STATE_RUNNING ) +return -EPERM ; -if (p > fbmemlength) -return -ENOSPC ; + total_size = info->fix.smem_len; - err =0 ; -if ((count + p) > fbmemlength) { - count = fbmemlength - p; - err = -ENOSPC ; +if (p > total_size) +return -EFBIG ; + +if (count > total_size) { + err = -EFBIG ; + count = total_size; } -if (count) { -char *base_addr; +if (count + p > total_size) { +if (!err) + err = -ENOSPC ; - base_addr = (char __force *)info->screen_base; - count -=copy_from_user (base_addr + p, buf, count); - *ppos += count; - err = -EFAULT ; + count = total_size - p; } -hecubafb_dpy_update (par); + dst = (void __force *) (info->screen_base + p); + +if (copy_from_user (dst, buf, count)) + err = -EFAULT ; -if (count) -return count; +if (!err) + *ppos += count; -return err; +hecubafb_dpy_update (par); + +return (err) ? err : count; }static struct fb_ops hecubafb_ops = {
@@ -324,11 +215,21 @@ static struct fb_deferred_io hecubafb_defio = {static int __devinit hecubafb_probe (struct platform_device *dev) {struct fb_info *info; +struct hecuba_board *board;int retval = -ENOMEM ;int videomemorysize;unsigned char *videomemory;struct hecubafb_par *par; +/* pick up board specific routines */ + board = dev->dev.platform_data; +if (!board) +return -EINVAL ; + +/* try to count device specific driver, if can't, platform recalls */ +if (!try_module_get (board->owner)) +return -ENODEV ; + videomemorysize = (DPY_W *DPY_H )/8 ;if (!(videomemory =vmalloc (videomemorysize)))
@@ -338,9 +239,9 @@ static int __devinit hecubafb_probe(struct platform_device *dev) info =framebuffer_alloc (sizeof (struct hecubafb_par ), &dev->dev);if (!info) - goto err; + goto err_fballoc; - info->screen_base = (char __iomem *) videomemory; + info->screen_base = (char __force __iomem *)videomemory; info->fbops = &hecubafb_ops; info->var = hecubafb_var;
@@ -348,14 +249,10 @@ static int __devinit hecubafb_probe(struct platform_device *dev) info->fix.smem_len = videomemorysize; par = info->par; par->info = info; + par->board = board; + par->send_command = apollo_send_command; + par->send_data = apollo_send_data; -if (!dio_addr || !cio_addr || !c2io_addr) { -printk (KERN_WARNING "no IO addresses supplied\n" ); - goto err1; - } - par->dio_addr = dio_addr; - par->cio_addr = cio_addr; - par->c2io_addr = c2io_addr; info->flags =FBINFO_FLAG_DEFAULT ; info->fbdefio = &hecubafb_defio;
@@ -363,7 +260,7 @@ static int __devinit hecubafb_probe(struct platform_device *dev) retval =register_framebuffer (info);if (retval <0 ) - goto err1; + goto err_fbreg;platform_set_drvdata (dev, info); printk(KERN_INFO
@@ -371,25 +268,16 @@ static int __devinit hecubafb_probe(struct platform_device *dev) info->node, videomemorysize >> 10);/* this inits the dpy */ -apollo_init_control (par); - -apollo_send_command (par,APOLLO_INIT_DISPLAY ); -apollo_send_data (par,0x81 ); - -/* have to wait while display resets */ -udelay (1000 ); - -/* if we were told to splash the screen, we just clear it */ -if (!nosplash) { -apollo_send_command (par,APOLLO_ERASE_DISPLAY ); -apollo_send_data (par, splashval); - } + retval = par->board->init (par); +if (retval <0 ) + goto err_fbreg;return 0 ; -err1: +err_fbreg:framebuffer_release (info); -err: +err_fballoc:vfree (videomemory); +module_put (board->owner);return retval; }
@@ -398,9 +286,13 @@ static int __devexit hecubafb_remove(struct platform_device *dev)struct fb_info *info =platform_get_drvdata (dev);if (info) { +struct hecubafb_par *par = info->par;fb_deferred_io_cleanup (info);unregister_framebuffer (info);vfree ((void __force *)info->screen_base); +if (par->board->remove) + par->board->remove (par); +module_put (par->board->owner);framebuffer_release (info); }return 0 ;
@@ -410,62 +302,24 @@ static struct platform_driver hecubafb_driver = { .probe = hecubafb_probe, .remove = hecubafb_remove, .driver = { + .owner = THIS_MODULE, .name = "hecubafb", }, }; -static struct platform_device *hecubafb_device; -static int __init hecubafb_init (void ) { -int ret; - -if (!hecubafb_enable) { -printk (KERN_ERR "Use hecubafb_enable to enable the device\n" ); -return -ENXIO ; - } - - ret =platform_driver_register (&hecubafb_driver); -if (!ret) { - hecubafb_device =platform_device_alloc ("hecubafb" ,0 ); -if (hecubafb_device) - ret =platform_device_add (hecubafb_device); -else - ret = -ENOMEM ; - -if (ret) { -platform_device_put (hecubafb_device); -platform_driver_unregister (&hecubafb_driver); - } - } -return ret; - +return platform_driver_register (&hecubafb_driver); } static void __exit hecubafb_exit(void) { -platform_device_unregister (hecubafb_device);platform_driver_unregister (&hecubafb_driver); } -module_param (nosplash, uint,0 ); -MODULE_PARM_DESC (nosplash,"Disable doing the splash screen" ); -module_param (hecubafb_enable, uint,0 ); -MODULE_PARM_DESC (hecubafb_enable,"Enable communication with Hecuba board" ); -module_param (dio_addr, ulong,0 ); -MODULE_PARM_DESC (dio_addr,"IO address for data, eg: 0x480" ); -module_param (cio_addr, ulong,0 ); -MODULE_PARM_DESC (cio_addr,"IO address for control, eg: 0x400" ); -module_param (c2io_addr, ulong,0 ); -MODULE_PARM_DESC (c2io_addr,"IO address for secondary control, eg: 0x408" ); -module_param (splashval, ulong,0 ); -MODULE_PARM_DESC (splashval,"Splash pattern: 0x00 is black, 0x01 is white" ); -module_param (irq, uint,0 ); -MODULE_PARM_DESC (irq,"IRQ for the Hecuba board" ); -module_init (hecubafb_init);module_exit (hecubafb_exit); -MODULE_DESCRIPTION ("fbdev driver for Hecuba board" ); +MODULE_DESCRIPTION ("fbdev driver for Hecuba/Apollo controller" );MODULE_AUTHOR ("Jaya Kumar" );MODULE_LICENSE ("GPL" );
drivers/video/n411.c new file +202 -0
202 lines not on this page · raw message
include/video/hecubafb.h new file +51 -0
51 lines not on this page · raw message
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Quoted 11 lines · On Thu, 03 Apr 2008 01:19:08 -0400 Jaya Kumar <[email protected]> wrote:
Hi Tony, Geert, Andrew, fbdev,
This patchset has 2 patches. They are are in order to split metronomefb and hecubafb into platform independent (platform drivers) and platform specific (platform devices) drivers which are am200epd (arm) and n411 (x86). The improvement over the last time I posted this is that I've now added module refcount handling in the platform drivers and so module loading/unloading works.
I would be grateful for any feedback on this.
Quoted 9 lines
Thanks,
jayaThis patch splits metronomefb into the platform independent metronomefb and the platform dependent am200epd. It also includes some comment cleanup and a bugfix for the use of cfb_* functions instead of sys_* functions. The
KconfigandMakefilechanges include the changes needed for hecubafb and n411.
argh.
Please don't mix huge code-motion changes into the same patch with bugfixes!
a) we want to be able to look at and review that bugfix in isolation
b) what happens if someone (eg a distro) is shipping 2.6.23 and wants to backport your bugfix?
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Quoted 24 lines · Andrew Morton
Quoted 11 lines · On Thu, 03 Apr 2008 01:19:08 -0400 Jaya Kumar <[email protected]> wrote:
Hi Tony, Geert, Andrew, fbdev,
This patchset has 2 patches. They are are in order to split metronomefb and hecubafb into platform independent (platform drivers) and platform specific (platform devices) drivers which are am200epd (arm) and n411 (x86). The improvement over the last time I posted this is that I've now added module refcount handling in the platform drivers and so module loading/unloading works.
I would be grateful for any feedback on this.
Quoted 9 lines
Thanks,
jayaThis patch splits metronomefb into the platform independent metronomefb and the platform dependent am200epd. It also includes some comment cleanup and a bugfix for the use of cfb_* functions instead of sys_* functions. The
KconfigandMakefilechanges include the changes needed for hecubafb and n411.
Quoted 5 lines
argh.
Please don't mix huge code-motion changes into the same patch with bugfixes!
a) we want to be able to look at and review that bugfix in isolation
Ok. I guess I need to figure out how to do this. I will do a separate patch that only fixes the bug and then patches on top of that to platformize.
Quoted 4 lines
b) what happens if someone (eg a distro) is shipping 2.6.23 and wants to backport your bugfix?
My thinking in doing this as one set was practicality. But I agree with the principle behind splitting the patches and so will do so.
Thanks,
jaya
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Quoted 8 lines · On Thu, 3 Apr 2008 20:58:53 -0400 "Jaya Kumar" <[email protected]> wrote:
Quoted 4 lines
Please don't mix huge code-motion changes into the same patch with bugfixes!
a) we want to be able to look at and review that bugfix in isolation
Ok. I guess I need to figure out how to do this. I will do a separate patch that only fixes the bug and then patches on top of that to platformize.
yes please, that's the best order in which to make the changes.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace