Re: kernel: matrox fb - missing files, doesn't compile

Re: kernel: matrox fb - missing files, doesn't compile

[Petr Vandrovec]

On 13 Dec 02 at 1:13, Ariel wrote:
> Kernel 2.5.51.
> 
> I tried copying the fbcon*.h files from 2.2.19 kernel, but that didn't
> help much.

Either go for 2.5.50, or you'll have to wait several weeks. After looking
at current kernel interface it looks like that I'll have to write
matroxcon to get at least same level of functionality which was
available before, and it will definitely take weeks, or maybe months.

Current interface just supports only cfb, and only very bad for my needs.
And because of matroxfb supports also other modes (such as native text
mode, or loading font into accelerator), bye-bye. For now I recommend you 
either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
call fb_sync when using font width which is not multiple of 8, and that 
with fonts greater than 16*16 pixels (I believe that such fonts are still 
supported...) it will corrupt memory...

You can also try to use complete drivers/video, include/video, plus
some of drivers/char and include/linux from 2.5.50... You should be
able to get working system that way too.
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Antonino Daplas]

On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> Current interface just supports only cfb, and only very bad for my needs.
> And because of matroxfb supports also other modes (such as native text
> mode, or loading font into accelerator), bye-bye. For now I recommend you 
> either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> call fb_sync when using font width which is not multiple of 8, and that 
Can you explain why an fb_sync is needed for every character?

> with fonts greater than 16*16 pixels (I believe that such fonts are still 
> supported...) it will corrupt memory...

I agree.  To be more specific, buffer overruns will occur if (xres *
fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
resized somewhere in the fbcon layer (ideally in accel_setup(), but this
was removed).  For those concerned about this problem, you can try this
patch as a temporary measure until fbcon is fixed. It should not cause
to much slowdown:

For anyone concerned, this is a heads up:  The data in the pixmap must
be read completely by the hardware before exiting, otherwise font
corruption will occur.  If you think this will be a problem, the
function can be easily modified to do multiple buffering instead.
 
Comments?

Tony

diff -Naur linux-2.5.51/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.51/drivers/video/console/fbcon.c	2002-12-14 23:33:50.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2002-12-14 23:35:10.000000000 +0000
@@ -390,7 +390,9 @@
 	unsigned int cellsize = vc->vc_font.height * width;
 	struct fb_image image;
 	u16 c = scr_readw(s);
-	static u8 pixmap[8192];
+	static int xres = 0;
+	static int fontheight = 0;
+	static u8 *pixmap = NULL;
 	
 	image.fg_color = attr_fgcol(p, c);
 	image.bg_color = attr_bgcol(p, c);
@@ -399,9 +401,24 @@
 	image.height = vc->vc_font.height;
 	image.depth = 1;
 
-/*	pixmap = kmalloc((info->var.bits_per_pixel + 7) >> 3 *
-				vc->vc_font.height, GFP_KERNEL); 
-*/
+	/*
+	 * FIXME: This code segment has to be placed 
+	 *        somewhere else to allow freeing of 
+	 *        memory on exit and to reduce unnecessary
+	 *        processing.
+	 */
+	if (xres != info->var.xres || 
+	    fontheight != vc->vc_font.height) {
+		xres = info->var.xres;
+		fontheight = vc->vc_font.height;
+
+		if (info->fbops->fb_sync)
+			info->fbops->fb_sync(info);
+		if (pixmap != NULL)
+			kfree(pixmap);
+		pixmap = kmalloc((xres + 7)/8 *
+				 fontheight, GFP_KERNEL); 
+	}
 				
 	if (!(vc->vc_font.width & 7) && pixmap != NULL) {
 		unsigned int pitch = width * count, i, j;
@@ -432,10 +449,6 @@
 			image.dx += vc->vc_font.width;
 		}	
 	}
-	/*
-	if (pixmap);
-		kfree(pixmap);
-	*/	
 }
 
 void accel_clear_margins(struct vc_data *vc, struct display *p,






-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Petr Vandrovec]

On Sun, Dec 15, 2002 at 05:30:43AM +0500, Antonino Daplas wrote:
> On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > Current interface just supports only cfb, and only very bad for my needs.
> > And because of matroxfb supports also other modes (such as native text
> > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > call fb_sync when using font width which is not multiple of 8, and that 
> Can you explain why an fb_sync is needed for every character?

It is not needed after every character. But I thought that it will be called
before we return to userspace... And I want to rely on fb_sync
because of hardware setup to change fg_color and bg_color is very costly.

In my tests I'm not able to get accelerated code running faster than
at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
two PCI writes could speed it a bit... It will not get on par, but better than
nothing.
 
> > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > supported...) it will corrupt memory...
> 
> I agree.  To be more specific, buffer overruns will occur if (xres *
> fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> was removed).  For those concerned about this problem, you can try this
> patch as a temporary measure until fbcon is fixed. It should not cause
> to much slowdown:

But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
if I remember fork() problems with allocating stack with order=1 correctly,
it is not best idea under the sun. But using physically non-continuous
area is probably even worse idea.

> For anyone concerned, this is a heads up:  The data in the pixmap must
> be read completely by the hardware before exiting, otherwise font
> corruption will occur.  If you think this will be a problem, the
> function can be easily modified to do multiple buffering instead.

What if I'll decide to paint characters through busmastering? Then
I need font data in buffers allocated by pci_alloc_consistent...
In the past it was not a win to use busmastering, but now, when
upper layers might prepare images much larger than 8x16, it may be 
worth of rechecking that...
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Antonino Daplas]

On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> On Sun, Dec 15, 2002 at 05:30:43AM +0500, Antonino Daplas wrote:
> > On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > > Current interface just supports only cfb, and only very bad for my needs.
> > > And because of matroxfb supports also other modes (such as native text
> > > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > > call fb_sync when using font width which is not multiple of 8, and that 
> > Can you explain why an fb_sync is needed for every character?
> 
> It is not needed after every character. But I thought that it will be called
> before we return to userspace... And I want to rely on fb_sync
> because of hardware setup to change fg_color and bg_color is very costly.
> 
I see. 

> In my tests I'm not able to get accelerated code running faster than
> at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
> two PCI writes could speed it a bit... It will not get on par, but better than
> nothing.
>  
> > > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > > supported...) it will corrupt memory...
> > 
> > I agree.  To be more specific, buffer overruns will occur if (xres *
> > fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> > resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> > was removed).  For those concerned about this problem, you can try this
> > patch as a temporary measure until fbcon is fixed. It should not cause
> > to much slowdown:
> 
> But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
> if I remember fork() problems with allocating stack with order=1 correctly,
> it is not best idea under the sun. But using physically non-continuous
> area is probably even worse idea.
You mean the multiple buffering?  Sorry, I did not mean classic
multi-buffering, just a single buffer with size at least 2x that
required.  Then the buffer will just be "walked" by adjusting the buffer
offset.  Once the offset reaches the end of the buffer, we just call
fb_sync() then reset the offset to 0.

> 
> > For anyone concerned, this is a heads up:  The data in the pixmap must
> > be read completely by the hardware before exiting, otherwise font
> > corruption will occur.  If you think this will be a problem, the
> > function can be easily modified to do multiple buffering instead.
> 
> What if I'll decide to paint characters through busmastering? Then
> I need font data in buffers allocated by pci_alloc_consistent...
> In the past it was not a win to use busmastering, but now, when
> upper layers might prepare images much larger than 8x16, it may be 
> worth of rechecking that...

True, using kmalloc() to cache a good-sized pixmap is probably not the
best idea in all cases (in my case, it is best when the pixmap is in
graphics memory). I submitted a proposal before that allows more
flexibility: it will let the drivers decide on how it wants the buffers
allocated, the size of the buffer, specific alignment requirements, or
if it even actually needs one. Other driver-specific needs can probably
be added if necessary.

However, the change is a bit more invasive and complex and thus probably
did not hold very well with the maintainers.  So I submitted a patch
that is simpler but less flexible.  In my case, I have to do an extra
copy of the pixmap contents to graphics memory or directly to the
graphics pipeline depending on the size/alignment and proceed from
there.  It's not the best solution, but definitely better than doing one
imageblit/character.

I really don't have a say on any of this... I just submit patches, you
have to ask James or Geert about these.

Tony



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Geert Uytterhoeven]

On 15 Dec 2002, Antonino Daplas wrote:
> On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> > What if I'll decide to paint characters through busmastering? Then
> > I need font data in buffers allocated by pci_alloc_consistent...
> > In the past it was not a win to use busmastering, but now, when
> > upper layers might prepare images much larger than 8x16, it may be 
> > worth of rechecking that...
> 
> True, using kmalloc() to cache a good-sized pixmap is probably not the
> best idea in all cases (in my case, it is best when the pixmap is in
> graphics memory). I submitted a proposal before that allows more
> flexibility: it will let the drivers decide on how it wants the buffers
> allocated, the size of the buffer, specific alignment requirements, or
> if it even actually needs one. Other driver-specific needs can probably
> be added if necessary.

Add address/size fields in fb_info to let the driver tell it already allocated
a suitable buffer? If those are NULL, fbcon can fall back to its own buffer
(e.g. static and fixed 8 kiB buffer).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Antonino Daplas]

On Sun, 2002-12-22 at 16:44, Geert Uytterhoeven wrote:
> On 15 Dec 2002, Antonino Daplas wrote:
> > On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> > > What if I'll decide to paint characters through busmastering? Then
> > > I need font data in buffers allocated by pci_alloc_consistent...
> > > In the past it was not a win to use busmastering, but now, when
> > > upper layers might prepare images much larger than 8x16, it may be 
> > > worth of rechecking that...
> > 
> > True, using kmalloc() to cache a good-sized pixmap is probably not the
> > best idea in all cases (in my case, it is best when the pixmap is in
> > graphics memory). I submitted a proposal before that allows more
> > flexibility: it will let the drivers decide on how it wants the buffers
> > allocated, the size of the buffer, specific alignment requirements, or
> > if it even actually needs one. Other driver-specific needs can probably
> > be added if necessary.
> 
> Add address/size fields in fb_info to let the driver tell it already allocated
> a suitable buffer? If those are NULL, fbcon can fall back to its own buffer
> (e.g. static and fixed 8 kiB buffer).
> 

How about the following?

Drivers can choose to fill up the fb_pixmap structure for
device-specific buffer requirements:


#define FB_PIXMAP_SYSMEM    0
#define FB_PIXMAP_IOMEM     1

struct fb_pixmap {
	__u32 loc;              /* location of buffer */
	__u8  *addr;            /* address of buffer */
	__u32 size;             /* size of buffer */
	__u32 align;            /* byte alignment per scanline */
};

Drivers can allocate the buffer in system memory (FB_PIXMAP_SYSMEM) or
io/graphics memory (FB_PIXMAP_IOMEM) and specify the alignment of each
line of pixels.  Otherwise, accel_putcs will default to using the
statically allocated buffer with a 1-byte alignment per scanline.

Attached is a patch against 2.5.52. Other changes:  

call fb_sync() if framebuffer memory is to be accessed (cfb_* drawing
functions, fb_read and fb_write).

Tony

diff -Nuar linux-2.4.52/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.4.52/drivers/video/cfbcopyarea.c	2002-12-27 14:39:27.000000000 +0000
+++ linux/drivers/video/cfbcopyarea.c	2002-12-27 14:38:27.000000000 +0000
@@ -375,6 +375,9 @@
 	dst_idx += area->dy*next_line*8 + area->dx*p->var.bits_per_pixel;
 	src_idx += area->sy*next_line*8 + area->sx*p->var.bits_per_pixel;
 	
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
+
 	if (rev_copy) {
 		while (area->height--) {
 			dst_idx -= next_line*8;
diff -Nuar linux-2.4.52/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.4.52/drivers/video/cfbfillrect.c	2002-12-27 14:39:30.000000000 +0000
+++ linux/drivers/video/cfbfillrect.c	2002-12-27 14:38:32.000000000 +0000
@@ -397,6 +397,10 @@
 	dst_idx += rect->dy*p->fix.line_length*8+rect->dx*bpp;
 	/* FIXME For now we support 1-32 bpp only */
 	left = BITS_PER_LONG % bpp;
+
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
+
 	if (!left) {
 		u32 pat = pixel_to_pat32(p, fg);
 		void (*fill_op32)(unsigned long *dst, int dst_idx, u32 pat, u32 n) = NULL;
diff -Nuar linux-2.4.52/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.4.52/drivers/video/cfbimgblt.c	2002-12-27 14:39:23.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2002-12-27 14:38:22.000000000 +0000
@@ -322,6 +322,9 @@
 	bitstart &= ~(bpl - 1);
 	dst1 = p->screen_base + bitstart;
 
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
+
 	if (image->depth == 1) {
 		if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 		    p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
diff -Nuar linux-2.4.52/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.4.52/drivers/video/console/fbcon.c	2002-12-27 14:39:13.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2002-12-27 14:38:09.000000000 +0000
@@ -378,16 +378,26 @@
 	info->fbops->fb_fillrect(info, &region);
 }	
 
+static inline void syswriteb(u8 val, u8 *addr)
+{
+	*addr = val;
+}
+
+static inline void iowriteb(u8 val, u8 *addr) 
+{
+	fb_writeb(val, addr);
+}
+
 void accel_putcs(struct vc_data *vc, struct display *p,
 			const unsigned short *s, int count, int yy, int xx)
 {
+	static char pixmap[8192];
 	struct fb_info *info = p->fb_info;
 	unsigned short charmask = p->charmask;
 	unsigned int width = ((vc->vc_font.width + 7)/8);
 	unsigned int cellsize = vc->vc_font.height * width;
 	struct fb_image image;
 	u16 c = scr_readw(s);
-	static u8 pixmap[8192];
 	
 	image.fg_color = attr_fgcol(p, c);
 	image.bg_color = attr_bgcol(p, c);
@@ -396,30 +406,60 @@
 	image.height = vc->vc_font.height;
 	image.depth = 1;
 
-/*	pixmap = kmalloc((info->var.bits_per_pixel + 7) >> 3 *
-				vc->vc_font.height, GFP_KERNEL); 
-*/
-				
-	if (!(vc->vc_font.width & 7) && pixmap != NULL) {
-		unsigned int pitch = width * count, i, j;
+	if (!(vc->vc_font.width & 7)) {
+		unsigned int pitch, i, j;
 		char *src, *dst, *dst0;
+		void (*write_op)(u8 val, u8 *addr) = syswriteb;
+
+		if (info->pixmap.addr != NULL) {
+			unsigned int align = (info->pixmap.align) ?
+				info->pixmap.align - 1 : 0;
+
+			pitch = (width * count + align) & ~(align);
+			if (pitch * vc->vc_font.height > info->pixmap.size)
+				/* 
+				 * FIXME: do multiple blit's instead
+				 *        of exiting
+				 */
+				return;
+
+			dst0 = info->pixmap.addr;
+			image.data = info->pixmap.addr;
+			switch (info->pixmap.loc) {
+			case FB_PIXMAP_IOMEM:
+				write_op = iowriteb;
+				break;
+			case FB_PIXMAP_SYSMEM:
+			default:
+				write_op = syswriteb;
+				break;
+			}
+		}
+		else {
+			pitch = width * count;
+			dst0 = pixmap;
+			image.data = pixmap;
+			if (pitch * vc->vc_font.height > 8192) 
+				/* 
+				 * FIXME: do multiple blit's instead
+				 *        of exiting
+				 */
+				return;
+		}
 
-		dst0 = pixmap;
 		image.width = vc->vc_font.width * count;
-		image.data = pixmap;
 		while (count--) {
 			src = p->fontdata + (scr_readw(s++) & charmask) * cellsize;
 			dst = dst0;
 			for (i = image.height; i--; ) {
 				for (j = 0; j < width; j++) 
-					dst[j] = *src++;
+					write_op(*src++, dst + j);
 				dst += pitch;
 			}
 			dst0 += width;
 		}
 		info->fbops->fb_imageblit(info, &image);
-		if (info->fbops->fb_sync)
-			info->fbops->fb_sync(info);
+		
 	} else {
 		image.width = vc->vc_font.width;
 		while (count--) {
@@ -429,10 +469,6 @@
 			image.dx += vc->vc_font.width;
 		}	
 	}
-	/*
-	if (pixmap);
-		kfree(pixmap);
-	*/	
 }
 
 void accel_clear_margins(struct vc_data *vc, struct display *p,
diff -Nuar linux-2.4.52/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.4.52/drivers/video/fbmem.c	2002-12-27 14:39:19.000000000 +0000
+++ linux/drivers/video/fbmem.c	2002-12-27 14:41:30.000000000 +0000
@@ -392,6 +392,9 @@
 	if (!info || ! info->screen_base)
 		return -ENODEV;
 
+	if (info->fbops->fb_sync)
+		info->fbops->fb_sync(info);
+
 	if (info->fbops->fb_read)
 		return info->fbops->fb_read(file, buf, count, ppos);
 	
@@ -425,6 +428,9 @@
 	if (!info || !info->screen_base)
 		return -ENODEV;
 
+	if (info->fbops->fb_sync)
+		info->fbops->fb_sync(info);
+
 	if (info->fbops->fb_write)
 		return info->fbops->fb_write(file, buf, count, ppos);
 	
diff -Nuar linux-2.4.52/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.4.52/include/linux/fb.h	2002-12-27 14:39:43.000000000 +0000
+++ linux/include/linux/fb.h	2002-12-27 14:41:31.000000000 +0000
@@ -294,6 +294,16 @@
 	struct fb_cmap cmap;	/* color map info */
 };
 
+#define FB_PIXMAP_SYSMEM    0
+#define FB_PIXMAP_IOMEM     1
+
+struct fb_pixmap {
+	__u32 loc;              /* location of buffer */
+	__u8  *addr;            /* address of buffer */
+	__u32 size;             /* size of buffer */
+	__u32 align;            /* byte alignment per scanline */
+};
+
 /*
  * hardware cursor control
  */
@@ -386,6 +396,7 @@
    struct fb_monspecs monspecs;         /* Current Monitor specs */
    struct fb_cursor cursor;		/* Current cursor */	
    struct fb_cmap cmap;                 /* Current cmap */
+   struct fb_pixmap pixmap;             /* Current pixmap */
    struct fb_ops *fbops;
    char *screen_base;                   /* Virtual address */
    struct vc_data *display_fg;		/* Console visible on this display */




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: kernel: matrox fb - missing files, doesn't compile

[Geert Uytterhoeven]

On 15 Dec 2002, Antonino Daplas wrote:
> On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > Current interface just supports only cfb, and only very bad for my needs.
> > And because of matroxfb supports also other modes (such as native text
> > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > call fb_sync when using font width which is not multiple of 8, and that 
> Can you explain why an fb_sync is needed for every character?
> 
> > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > supported...) it will corrupt memory...
> 
> I agree.  To be more specific, buffer overruns will occur if (xres *
> fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> was removed).  For those concerned about this problem, you can try this
> patch as a temporary measure until fbcon is fixed. It should not cause
> to much slowdown:

What about making putcs() check for overflows? I.e. large putcs() will just be
split in multiple image blit calls.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/