linux-fbdev-users Mailing List for Linux Frame Buffer Device Development

On Friday 29 October 2004 18:11, Ladislav Michl wrote:
> On Fri, Oct 29, 2004 at 08:05:07AM +0800, Antonino A. Daplas wrote:
> > However, it took a lot of pain to separate fbcon from fbdev, and making
> > struct fbcon_ops visible to the fbdev driver is tantamount to reversing
> > everything that was done. So, no, struct fbcon_ops needs to be invisible
> > from the drivers.
>
> Ah, well... Newport can live with that easily, but it's pain for MGras
> (SGI Octane graphics option). You need to setup very complicated DMA to
> support copy area.
>
> > And fb_fillrect|copyarea|imageblit will have to stay, although you are
> > correct that the above functions are just a subset of tileblitting:-).
>
> Now code looks like:
> fbcon_putcs => fbcon_ops->putcs => info->fbops->fb_imageblit
> fbcon_bmove => fbcon_ops->bmove => info->fbops->fb_copyarea
> fbcon_clear => fbcon_ops->clear => info->fbops->fb_filrect
How about:
fbcon_putcs => fbcon_ops->putcs => info->tileops->tileblit
fbcon_bmove => fbcon_ops->bmove => info->tileops->tilemove
fbcon_clear =>fbcon_ops->clear => info->tileops->tilefill
The functions in fbcon_ops and tileops are very, very similar.
>
> So there are four possibilities for MGras:
> 1) Implement console driver (like newport_con.c). That has clear
> disadvantage of no mode switching API and will cause troubles with
> adding DRM.
> 2) Implement copyarea in fb driver. That's very compicated (two DMA
> transfers - 24bit and 1bit) and slower than invalidating area (that
> is single 1bit DMA transfer) for bmove. (SGI Octane pages are there:
> http://helios.et.put.poznan.pl/~sskowron/ip30/)
Within fbcon, it is possible to have an unimplemented bmove. If the driver uses
redraw, or pan_redraw as a scrolling method, fbcon_bmove will never be
called. However, fbcon_bmove is required by the upper console layer (vt.c)
as a function necessary when inserting or deleting characters. So it's 
unavoidable to implement bmove, whether using tilemove, or bitmove.
> 3) Hook fb_con operations from driver. You don't like it.
Why not use info->tileops?
 
> 4) Add option to fbcon which will implement bmove by redrawing affected
> area rather than copying rectangle.
We already have number 4. See drivers/video/console/fbcon.c:fbcon_redraw_move.
>
> > > Also having flag for supported font widths would be
> > > nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> > > width efectively (zpattern line is misused for that).
> >
> > We can do this, by adding a field that says that the driver can only do
> > blits if source bitmap width is divisible by 8 pixels. I think vga16fb
> > needs this restriction too.
>
> Ok. I remember such flag was there.
It was present in 2.4, removed in 2.6.
Tony

On Fri, Oct 29, 2004 at 08:05:07AM +0800, Antonino A. Daplas wrote:
> However, it took a lot of pain to separate fbcon from fbdev, and making
> struct fbcon_ops visible to the fbdev driver is tantamount to reversing
> everything that was done. So, no, struct fbcon_ops needs to be invisible
> from the drivers.
Ah, well... Newport can live with that easily, but it's pain for MGras
(SGI Octane graphics option). You need to setup very complicated DMA to
support copy area.
> And fb_fillrect|copyarea|imageblit will have to stay, although you are
> correct that the above functions are just a subset of tileblitting:-).
Now code looks like:
fbcon_putcs => fbcon_ops->putcs => info->fbops->fb_imageblit
fbcon_bmove => fbcon_ops->bmove => info->fbops->fb_copyarea
fbcon_clear => fbcon_ops->clear => info->fbops->fb_filrect
So there are four possibilities for MGras:
1) Implement console driver (like newport_con.c). That has clear
 disadvantage of no mode switching API and will cause troubles with
 adding DRM.
2) Implement copyarea in fb driver. That's very compicated (two DMA
 transfers - 24bit and 1bit) and slower than invalidating area (that
 is single 1bit DMA transfer) for bmove. (SGI Octane pages are there:
 http://helios.et.put.poznan.pl/~sskowron/ip30/)
3) Hook fb_con operations from driver. You don't like it.
4) Add option to fbcon which will implement bmove by redrawing affected
 area rather than copying rectangle.
> > Also having flag for supported font widths would be
> > nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> > width efectively (zpattern line is misused for that).
> 
> We can do this, by adding a field that says that the driver can only do 
> blits if source bitmap width is divisible by 8 pixels. I think vga16fb needs
> this restriction too.
Ok. I remember such flag was there.
> Go ahead, write it. But, do not make struct fbcon_ops visible to the fbdev
> driver, use the methods in info->tileops instead and set the
> FBINFO_MISC_TILEBLITTING bit in info->flags. The end result should be the same.
I'll do. Informations provided by you are sufficient to write Newport
driver. Let's see what could be done with MGras.
	ladis

On Friday 29 October 2004 03:43, Ladislav Michl wrote:
> Hi,
>
> I've playing with idea to implement faked framebufer driver fox SGI
> Newport graphics based on REX3 engine (documentation is here:
> ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/) and fbcon changes
> accepted to 2.6.10-rc1 kicked me to write this post :-)
>
> Now stop reading and see patch below (Note: I didn't test it and even
> tried to compile. It worked with old interface and few tweaks in fbcon,
> but I do not want to spent too much time before some consensus is
> reached)... See drivers/video/console/newport_con.c for putcs
> implementation.
>
> Some video devices act as write-only command pipe. There is no memory
> you can read from, there is even no mapable memory at all.
> However they still can utilize fbdev interface to change resolution and
> for DRM and fbcon to handle fonts settings.
>
> Currently there are two bliting modes: bitblit and tileblit. Extending
> struct fbcon_ops with logo drawing op
This can be done. The logo image can be divided into tiles and fed to
fb_tileblit. But with no users yet, I haven't written any code for it. (The
potential user is matroxfb though)
> and providing way to register blit
> operations to fb driver itself would allow fb_fillrect, fb_copyarea,
> fb_imageblit and fb_cursor become optional, making wider range of
> hardware happy.
That was one of the goals, in order for matroxfb to support a framebuffer in
text mode, the tileblitting extension was added.
However, it took a lot of pain to separate fbcon from fbdev, and making
struct fbcon_ops visible to the fbdev driver is tantamount to reversing
everything that was done. So, no, struct fbcon_ops needs to be invisible
from the drivers.
And fb_fillrect|copyarea|imageblit will have to stay, although you are
correct that the above functions are just a subset of tileblitting:-).
> Also having flag for supported font widths would be
> nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> width efectively (zpattern line is misused for that).
We can do this, by adding a field that says that the driver can only do 
blits if source bitmap width is divisible by 8 pixels. I think vga16fb needs
this restriction too.
> These
> modifications would make supporting SGI graphics options easier,
> providing way to change resolution in defined way.
>
Go ahead, write it. But, do not make struct fbcon_ops visible to the fbdev
driver, use the methods in info->tileops instead and set the
FBINFO_MISC_TILEBLITTING bit in info->flags. The end result should be the same.
Tony

Hi,
I've playing with idea to implement faked framebufer driver fox SGI
Newport graphics based on REX3 engine (documentation is here: 
ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/) and fbcon changes
accepted to 2.6.10-rc1 kicked me to write this post :-)
Now stop reading and see patch below (Note: I didn't test it and even
tried to compile. It worked with old interface and few tweaks in fbcon,
but I do not want to spent too much time before some consensus is
reached)... See drivers/video/console/newport_con.c for putcs
implementation.
Some video devices act as write-only command pipe. There is no memory
you can read from, there is even no mapable memory at all.
However they still can utilize fbdev interface to change resolution and
for DRM and fbcon to handle fonts settings.
Currently there are two bliting modes: bitblit and tileblit. Extending
struct fbcon_ops with logo drawing op and providing way to register blit
operations to fb driver itself would allow fb_fillrect, fb_copyarea,
fb_imageblit and fb_cursor become optional, making wider range of
hardware happy. Also having flag for supported font widths would be
nice, because REX3 cannot handle drawing 1bpp images other that 8*x
width efectively (zpattern line is misused for that). These
modifications would make supporting SGI graphics options easier,
providing way to change resolution in defined way.
Comments and ideas are more that welcome.
Thanks,
	ladis
Index: drivers/video/Kconfig
===================================================================
RCS file: /home/cvs/linux/drivers/video/Kconfig,v
retrieving revision 1.29
diff -u -r1.29 Kconfig
--- drivers/video/Kconfig	25 Oct 2004 20:44:39 -0000	1.29
+++ drivers/video/Kconfig	28 Oct 2004 17:43:00 -0000
@@ -373,6 +373,14 @@
 	help
 	 SGI Visual Workstation support for framebuffer graphics.
 
+config FB_NEWPORT
+	bool "SGI Newport"
+	depends on FB && SGI_IP22
+	help
+	 This is the fake frame buffer device driver for SGI Newport
+	 graphics. Since Newport has no mapable video memory, this driver
+	 is good only to run console on the top.
+
 config FB_GBE
 	bool "SGI Graphics Backend frame buffer support"
 	depends on FB && (SGI_IP32 || X86_VISWS)
Index: drivers/video/Makefile
===================================================================
RCS file: /home/cvs/linux/drivers/video/Makefile,v
retrieving revision 1.84
diff -u -r1.84 Makefile
--- drivers/video/Makefile	12 Oct 2004 01:45:47 -0000	1.84
+++ drivers/video/Makefile	28 Oct 2004 17:43:01 -0000
@@ -90,7 +90,7 @@
 obj-$(CONFIG_FB_MAXINE)		 += maxinefb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_TX3912)		 += tx3912fb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_AU1100)		 += au1100fb.o fbgen.o
-
+obj-$(CONFIG_FB_NEWPORT)	 += newportfb.o
 
 # Platform or fallback drivers go here
 obj-$(CONFIG_FB_VESA) += vesafb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
Index: drivers/video/console/fbcon.c
===================================================================
RCS file: /home/cvs/linux/drivers/video/console/fbcon.c,v
retrieving revision 1.20
diff -u -r1.20 fbcon.c
--- drivers/video/console/fbcon.c	25 Oct 2004 20:44:39 -0000	1.20
+++ drivers/video/console/fbcon.c	28 Oct 2004 17:43:31 -0000
@@ -456,6 +456,7 @@
 	}
 }
 
+#if 0
 #ifdef CONFIG_FB_TILEBLITTING
 static void set_blitting_type(struct vc_data *vc, struct fb_info *info,
 			 struct display *p)
@@ -477,6 +478,14 @@
 	fbcon_set_bitops(ops);
 }
 #endif /* CONFIG_MISC_TILEBLITTING */
+#endif
+static void set_blitting_type(struct vc_data *vc, struct fb_info *info,
+			 struct display *p)
+{
+	struct fbcon_ops *ops = (struct fbcon_ops *) info->fbcon_par;
+
+	newport_set_bitops(ops);
+}
 
 /**
 *	set_con2fb_map - map console to frame buffer device
Binary files /dev/zero and drivers/video/newportfb.c differ
--- /dev/null	2004年10月28日 12:38:40.000000000 +0200
+++ drivers/video/newportfb.c	2004年10月28日 14:14:13.000000000 +0200
@@ -0,0 +1,534 @@
+/*
+ * SGI Newport XL fake framebuffer driver
+ *
+ * Derived from drivers/video/console/newport_con.c
+ *
+ * Copyright (C) 2004 Ladislav Michl <la...@li...>
+ * 
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+
+#include <video/newport.h>
+
+extern unsigned long sgi_gfxaddr;
+
+/* default mode */
+static struct fb_var_screeninfo default_var_high __initdata = {
+	/* 1280x1024, 8bpp */
+	.xres		= 1280,
+	.yres		= 1024,
+	.xres_virtual	= 1280,
+	.yres_virtual	= 1024,
+	.xoffset	= 0,
+	.yoffset	= 0,
+	.bits_per_pixel	= 8,
+	.grayscale	= 0,
+	.red		= { 0, 8, 0 },
+	.green		= { 0, 8, 0 },
+	.blue		= { 0, 8, 0 },
+	.transp		= { 0, 0, 0 },
+	.nonstd		= 0,
+	.activate	= 0,
+	.height		= -1,
+	.width		= -1,
+	.accel_flags	= 0,
+	.pixclock	= 9353,
+	.left_margin	= 20,
+	.right_margin	= 30,
+	.upper_margin	= 37,
+	.lower_margin	= 3,
+	.hsync_len	= 20,
+	.vsync_len	= 3,
+	.sync		= 0,
+	.vmode		= FB_VMODE_NONINTERLACED
+};
+
+static struct fb_videomode default_mode_high __initdata = {
+	/* 1280x1024, 8bpp */
+	.xres		= 1280,
+	.yres		= 1024,
+	.pixclock	= 9353,
+	.left_margin	= 20,
+	.right_margin	= 30,
+	.upper_margin	= 37,
+	.lower_margin	= 3,
+	.hsync_len	= 20,
+	.vsync_len	= 3,
+	.vmode		= FB_VMODE_NONINTERLACED,
+};
+
+struct fb_videomode *default_mode = &default_mode_high;
+struct fb_var_screeninfo *default_var = &default_var_high;
+
+struct newportfb_par {
+	struct newport_regs *npregs;
+	struct fb_var_screeninfo var;
+	int valid;
+};
+
+static unsigned int pseudo_palette[256];
+
+static int newportfb_blank(int blank, struct fb_info *info)
+{
+	unsigned short treg;
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+
+	/* 0 unblank, 1 blank, 2 no vsync, 3 no hsync, 4 off */
+	switch (blank) {
+	case 0:		/* unblank */
+		treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+		newport_vc2_set(npregs, VC2_IREG_CONTROL,
+				(treg | VC2_CTRL_EDISP));
+		break;
+
+	case 1:		/* blank */
+		treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+		newport_vc2_set(npregs, VC2_IREG_CONTROL,
+				(treg & ~(VC2_CTRL_EDISP)));
+		break;
+
+	default:
+		/* Nothing */
+		break;
+	}
+	return 0;
+}
+
+/*
+ * Set the hardware according to 'par'.
+ */
+static int newportfb_set_par(struct fb_info *info)
+{
+	return 0;
+}
+
+static void newportfb_encode_fix(struct fb_fix_screeninfo *fix,
+				 struct fb_var_screeninfo *var)
+{
+	memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+	strcpy(fix->id, "SGI Newport");
+	fix->smem_start = 0;
+	fix->smem_len = 0;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->type_aux = 0;
+	fix->accel = FB_ACCEL_NONE;
+	switch (var->bits_per_pixel) {
+	case 8:
+		fix->visual = FB_VISUAL_PSEUDOCOLOR;
+		break;
+	default:
+		fix->visual = FB_VISUAL_TRUECOLOR;
+		break;
+	}
+	fix->ywrapstep = 0;
+	fix->xpanstep = 0;
+	fix->ypanstep = 0;
+	fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+	fix->mmio_start = sgi_gfxaddr;
+	fix->mmio_len = sizeof(struct newport_regs);
+}
+
+/*
+ * Check video mode validity, eventually modify var to best match.
+ */
+static int newportfb_check_var(struct fb_var_screeninfo *var,
+			 struct fb_info *info)
+{
+	return 0;
+}
+
+void newport_reset(struct newport_regs *npregs)
+{
+	unsigned short treg;
+	int i;
+
+	newport_wait(npregs);
+	treg = newport_vc2_get(npregs, VC2_IREG_CONTROL);
+	newport_vc2_set(npregs, VC2_IREG_CONTROL,
+			(treg | VC2_CTRL_EVIDEO));
+
+	treg = newport_vc2_get(npregs, VC2_IREG_CENTRY);
+	newport_vc2_set(npregs, VC2_IREG_RADDR, treg);
+	npregs->set.dcbmode = (NPORT_DMODE_AVC2 | VC2_REGADDR_RAM |
+			 NPORT_DMODE_W2 | VC2_PROTOCOL);
+	for (i = 0; i < 128; i++) {
+		newport_bfwait(npregs);
+		if (i == 92 || i == 94)
+			npregs->set.dcbdata0.byshort.s1 = 0xff00;
+		else
+			npregs->set.dcbdata0.byshort.s1 = 0x0000;
+	}
+
+	/* turn off popup plane */
+	npregs->set.dcbmode = (DCB_XMAP0 | R_DCB_XMAP9_PROTOCOL |
+			 XM9_CRS_CONFIG | NPORT_DMODE_W1);
+	npregs->set.dcbdata0.bybytes.b3 &= ~XM9_PUPMODE;
+	npregs->set.dcbmode = (DCB_XMAP1 | R_DCB_XMAP9_PROTOCOL |
+			 XM9_CRS_CONFIG | NPORT_DMODE_W1);
+	npregs->set.dcbdata0.bybytes.b3 &= ~XM9_PUPMODE;
+
+	npregs->cset.topscan = 0x3ff;
+	npregs->cset.xywin = (4096 << 16) | 4096;
+}
+
+static inline void newport_fillrect(struct newport_regs *npregs,
+				 int x1, int y1, int x2, int y2, int ci)
+{
+	newport_wait(npregs);
+	npregs->set.wrmask = 0xffffffff;
+	npregs->set.drawmode0 = (NPORT_DMODE0_DRAW | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_DOSETUP | NPORT_DMODE0_STOPX |
+				 NPORT_DMODE0_STOPY);
+	npregs->set.colori = ci;
+	npregs->set.xystarti = (x1 << 16) | y1;
+	npregs->go.xyendi = (x2 << 16) | y2;
+}
+
+static inline void newport_copyrect(struct newport_regs *npregs,
+				 int x1, int y1, int x2, int y2,
+				 int w, int h)
+{
+	newport_wait(npregs);
+	npregs->set.drawmode0 = (NPORT_DMODE0_S2S | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_DOSETUP | NPORT_DMODE0_STOPX |
+				 NPORT_DMODE0_STOPY);
+	npregs->set.xystarti = (x1 << 16) | y1;
+	npregs->set.xyendi = (x2 << 16) | y2;
+	npregs->go.xymove = ((w - x1) << 16) | (h - y1);
+}
+
+/* 
+ * Draw 8 pixel width 1bpp image (character) 
+ */
+static void newport_imageblit_1bpp_8(struct newport_regs *npregs,
+				 unsigned char *src, int x, int y,
+				 int h, int fg, int bg)
+{
+	int x2 = x + 8 - 1;
+	int y2 = y + h - 1;
+
+	/* Fill backgroung */
+	newport_fillrect(npregs, x, y, x2, y2, bg);
+
+	/* Set the color and drawing mode. */
+	newport_wait(npregs);
+	npregs->set.colori = fg;
+	npregs->set.drawmode0 = (NPORT_DMODE0_DRAW | NPORT_DMODE0_BLOCK |
+				 NPORT_DMODE0_STOPX | NPORT_DMODE0_ZPENAB |
+				 NPORT_DMODE0_L32);
+	/* Set coordinates for bitmap operation. */
+	npregs->set.xystarti = (x << 16) | y;
+	npregs->set.xyendi = (x2 << 16) | y2;
+	newport_wait(npregs);
+
+	/* Go, baby, go... */
+	while (h--)
+		npregs->go.zpattern = *src++ << 24;
+
+}
+static void newport_imageblit_8bpp(struct newport_regs *npregs,
+				 unsigned char *src, int x, int y,
+				 int w, int h)
+{
+	int x2, y2, dx, dy;
+	uint32_t *img = (uint32_t *) src;
+
+	newport_wait(npregs);
+
+	npregs->set.drawmode1 = DM1_RGBPLANES | 
+				NPORT_DMODE1_CCLT | 
+				NPORT_DMODE1_CCEQ | 
+				NPORT_DMODE1_CCGT | 
+				NPORT_DMODE1_LOSRC |
+				NPORT_DMODE1_DD8 | 
+				NPORT_DMODE1_HD8 | 
+				NPORT_DMODE1_RWPCKD;
+
+	npregs->set.drawmode0 = NPORT_DMODE0_DRAW | 
+				NPORT_DMODE0_BLOCK | 
+				NPORT_DMODE0_CHOST;
+	x2 = x + w;
+	y2 = y + h;
+	npregs->set.xystarti = (x << 16) | y;
+	npregs->set.xyendi = ((x2 - 1) << 16) | (y2 - 1);
+
+	for (dy = y; dy < y2; dy++) {
+		for (dx = x; dx < x2; dx += 4) {
+			npregs->go.hostrw0 = *img;
+			img++;
+		}
+	}
+}
+
+static int newportfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			 unsigned blue, unsigned transp,
+			 struct fb_info *p)
+{
+	struct newportfb_par *par = p->par;
+	struct newport_regs *npregs = par->npregs;
+
+	newport_cmap_setaddr(npregs, regno);
+	newport_cmap_setrgb(npregs, red, green, blue);
+
+	return 0;
+}
+
+static void newportfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
+{
+}
+
+static void newportfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
+{
+}
+
+static void newportfb_imageblit(struct fb_info *p, const struct fb_image *image)
+{
+}
+
+/* 
+ * Newport has no mapable memory
+ */
+static ssize_t newportfb_read(struct file *file, char __user *buf,
+			 size_t count, loff_t *ppos)
+{
+	return -EINVAL;
+}
+
+static ssize_t newportfb_write(struct file *file, const char __user *buf,
+			 size_t count, loff_t *ppos)
+{
+	return -EINVAL;
+}
+
+static int newportfb_mmap(struct fb_info *info, struct file *file,
+			 struct vm_area_struct *vma)
+{
+	return -EINVAL;
+}
+
+static void newport_op_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+			 int sx, int dy, int dx, int height, int width)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+	int x1 = sx << 3;
+	int y1 = sy * vc->vc_font.height;
+	int x2 = dx << 3;
+	int y2 = dy * vc->vc_font.height;
+	int w = width << 3;
+	int h = height * vc->vc_font.height;
+	newport_copyrect(npregs, x1, y1, x2, y2, w, h);
+}
+
+static void newport_op_clear(struct vc_data *vc, struct fb_info *info,
+			 int sy, int sx, int height, int width)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+	int x1 = sx << 3;
+	int y1 = sy * vc->vc_font.height;
+	int x2 = (sx + width) << 3;
+	int y2 = (sy + height) * vc->vc_font.height;
+	/* FIXME: Use correct background color */
+	newport_fillrect(npregs, x1, y1, x2, y2, 0);
+}
+
+static void newport_op_putcs(struct vc_data *vc, struct fb_info *info,
+			 const unsigned short *s, int count, int yy, int xx,
+			 int fg, int bg)
+{
+	struct newportfb_par *par = info->par;
+	struct newport_regs *npregs = par->npregs;
+
+}
+
+static void newport_op_clear_margins(struct vc_data *vc, struct fb_info *info,
+				 int bottom_only)
+{
+	return;
+}
+
+static void newport_op_cursor(struct vc_data *vc, struct fb_info *info,
+			 struct display *p, int mode, int fg, int bg)
+{
+}
+
+void newport_set_ops(struct vc_data *vc, struct fb_info *info,
+		 struct display *p, struct fbcon_ops *ops)
+{
+	ops->bmove = newport_op_bmove;
+	ops->clear = newport_op_clear;
+	ops->putcs = newport_op_putcs;
+	ops->clear_margins = newport_op_clear_margins;
+	ops->cursor = newport_op_cursor;
+}
+
+EXPORT_SYMBOL(newport_set_ops);
+
+static struct fb_ops newportfb_ops = {
+	.owner		= THIS_MODULE,
+	.fb_read	= newportfb_read,
+	.fb_write	= newportfb_write,
+	.fb_check_var	= newportfb_check_var,
+	.fb_set_par	= newportfb_set_par,
+	.fb_setcolreg	= newportfb_setcolreg,
+	.fb_blank	= newportfb_blank,
+	.fb_fillrect	= newportfb_fillrect,
+	.fb_copyarea	= newportfb_copyarea,
+	.fb_imageblit	= newportfb_imageblit,
+	.fb_cursor	= newportfb_cursor,
+	.fb_mmap	= newportfb_mmap,
+};
+
+int __init newportfb_setup(char *options)
+{
+	return 0;
+}
+
+#define TESTVAL 0xdeadbeef
+#define XSTI_TO_FXSTART(val) (((val) & 0xffff) << 11)
+
+static int __init newportfb_probe(struct device *dev)
+{
+	int ret;
+	struct fb_info *info;
+	struct newportfb_par *par;
+	struct newport_regs *npregs;
+	struct platform_device *p_dev = to_platform_device(dev);
+
+	if (!sgi_gfxaddr)
+		return -ENODEV;
+
+	info = framebuffer_alloc(sizeof(struct newportfb_par), &p_dev->dev);
+	if (!info)
+		return -ENOMEM;
+
+	if (!request_mem_region(sgi_gfxaddr, sizeof(struct newport_regs),
+				"Newport")) {
+		printk(KERN_ERR "newportfb: couldn't reserve mmio region\n");
+		ret = -EBUSY;
+		goto out_free_fbinfo;
+	}
+
+	npregs = (struct newport_regs*)
+		 ioremap(sgi_gfxaddr, sizeof(struct newport_regs));
+	if (!npregs) {
+		printk(KERN_ERR "newportfb: couldn't map mmio region\n");
+		ret = -ENXIO;
+		goto out_release_mem_region;
+	}
+
+	npregs->cset.config = NPORT_CFG_GD0;
+	if (newport_wait(npregs)) {
+		ret = -ENODEV;
+		goto out_unmap;
+	}
+
+	npregs->set.xstarti = TESTVAL;
+	if (npregs->set._xstart.word != XSTI_TO_FXSTART(TESTVAL)) {
+		ret = -ENODEV;
+		goto out_unmap;
+	}
+
+	newport_reset(npregs);
+/*
+	newport_get_revisions();
+	newport_get_screensize();
+*/
+	par = info->par;
+	par->npregs = npregs;
+
+	info->currcon = -1;
+	info->fbops = &newportfb_ops;
+	info->pseudo_palette = pseudo_palette;
+	info->flags = FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
+		 FBINFO_HWACCEL_IMAGEBLIT;
+	fb_alloc_cmap(&info->cmap, 256, 0);
+
+	/* turn on default video mode */
+//	if (fb_find_mode(&par->var, info, NULL, NULL, 0,
+//			 default_mode, 8) == 0)
+		par->var = *default_var;
+	info->var = par->var;
+	newportfb_check_var(&par->var, info);
+	newportfb_encode_fix(&info->fix, &info->var);
+
+	if (register_framebuffer(info) < 0) {
+		ret = -ENXIO;
+		printk(KERN_ERR "newportfb: couldn't register framebuffer\n");
+		goto out_unmap;
+	}
+
+	dev_set_drvdata(&p_dev->dev, info);
+
+	return 0;
+
+out_unmap:
+	iounmap((void *)npregs);
+out_release_mem_region:
+	release_mem_region(sgi_gfxaddr, sizeof(struct newport_regs));
+out_free_fbinfo:
+	framebuffer_release(info);
+	return ret;
+}
+
+static int newportfb_remove(struct device* dev)
+{
+	struct platform_device *p_dev = to_platform_device(dev);
+	struct fb_info *info = dev_get_drvdata(&p_dev->dev);
+	struct newportfb_par *par = info->par;
+
+	unregister_framebuffer(info);
+	framebuffer_release(info);
+	iounmap((void *)par->npregs);
+	release_mem_region(sgi_gfxaddr, sizeof(struct newport_regs));
+
+	return 0;
+}
+
+static struct device_driver newportfb_driver = {
+	.name = "newportfb",
+	.bus = &platform_bus_type,
+	.probe = newportfb_probe,
+	.remove = newportfb_remove,
+};
+
+static struct platform_device newportfb_device = {
+	.name = "newportfb",
+};
+
+int __init newportfb_init(void)
+{
+	int ret = driver_register(&newportfb_driver);
+	if (!ret) {
+		ret = platform_device_register(&newportfb_device);
+		if (ret)
+			driver_unregister(&newportfb_driver);
+	}
+	return ret;
+}
+
+void __exit newportfb_exit(void)
+{
+	 driver_unregister(&newportfb_driver);
+}
+
+module_init(newportfb_init);
+module_exit(newportfb_exit);
+
+MODULE_AUTHOR("Ladislav Michl <la...@li...>");
+MODULE_DESCRIPTION("Newport fake framebuffer");
+MODULE_LICENSE("GPL");

On Thursday 28 October 2004 03:28, Elimar Riesebieter wrote:
> On 2004年10月27日 the mental interface of
>
> Antonino A. Daplas told:
> > On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
>
> White cursor is back :-))
Great.
> Bootlogo isn't shown?
Can you try choosing the l6 color logo in the kernel kconfig. Or you can
try this patch instead. Let me know which one or if both works.
Tony
diff -Nru a/drivers/video/aty/radeon_monitor.c b/drivers/video/aty/radeon_monitor.c
--- a/drivers/video/aty/radeon_monitor.c	2004年10月27日 14:58:07 +08:00
+++ b/drivers/video/aty/radeon_monitor.c	2004年10月28日 06:04:32 +08:00
@@ -12,9 +12,9 @@
 	.xres_virtual	= 640,
 	.yres_virtual	= 480,
 	.bits_per_pixel = 8,
-	.red		= { 0, 6, 0 },
-	.green		= { 0, 6, 0 },
-	.blue		= { 0, 6, 0 },
+	.red		= { 0, 8, 0 },
+	.green		= { 0, 8, 0 },
+	.blue		= { 0, 8, 0 },
 	.activate	= FB_ACTIVATE_NOW,
 	.height		= -1,
 	.width		= -1,

On 2004年10月27日 the mental interface of
Antonino A. Daplas told:
> On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > --- a/drivers/video/console/fbcon.c 2004年10月26日 23:49:13 +08:00
> > > +++ b/drivers/video/console/fbcon.c 2004年10月27日 08:17:19 +08:00
> > > @@ -1012,7 +1012,9 @@
> > >
> > > static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > > {
> > > - fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > > + unsigned short chr =3D c;
> >
> > I think that you must use scr_write(c, &chr) to get it right.
>=20
> Indeed. Thanks.
White cursor is back :-))
Bootlogo isn't shown?
Ciao
Elimar
--=20
 Never make anything simple and efficient when a way=20
 can be found to make it complex and wonderful ;-)

On Wed, Oct 27, 2004 at 09:09:43AM +0800, Antonino A. Daplas wrote:
> On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> > On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > > --- a/drivers/video/console/fbcon.c 2004年10月26日 23:49:13 +08:00
> > > +++ b/drivers/video/console/fbcon.c 2004年10月27日 08:17:19 +08:00
> > > @@ -1012,7 +1012,9 @@
> > >
> > > static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > > {
> > > - fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > > + unsigned short chr = c;
> >
> > I think that you must use scr_write(c, &chr) to get it right.
> 
> Indeed. Thanks.
Cool. Works here on rivafb!
 -- Guido

On Wednesday 27 October 2004 08:40, Petr Vandrovec wrote:
> On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> > --- a/drivers/video/console/fbcon.c 2004年10月26日 23:49:13 +08:00
> > +++ b/drivers/video/console/fbcon.c 2004年10月27日 08:17:19 +08:00
> > @@ -1012,7 +1012,9 @@
> >
> > static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > {
> > - fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> > + unsigned short chr = c;
>
> I think that you must use scr_write(c, &chr) to get it right.
Indeed. Thanks.
Tony
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	2004年10月26日 23:49:13 +08:00
+++ b/drivers/video/console/fbcon.c	2004年10月27日 09:07:57 +08:00
@@ -1012,7 +1012,10 @@
 
 static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
 {
-	fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
+	unsigned short chr;
+
+	scr_writew(c, &chr);
+	fbcon_putcs(vc, &chr, 1, ypos, xpos);
 }
 
 static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)

On 27 Oct 04 at 8:24, Antonino A. Daplas wrote:
> --- a/drivers/video/console/fbcon.c 2004年10月26日 23:49:13 +08:00
> +++ b/drivers/video/console/fbcon.c 2004年10月27日 08:17:19 +08:00
> @@ -1012,7 +1012,9 @@
> 
> static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> {
> - fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
> + unsigned short chr = c;
I think that you must use scr_write(c, &chr) to get it right.
 Petr Vandrovec
 
> +
> + fbcon_putcs(vc, &chr, 1, ypos, xpos);
> }
> 
> static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
> 
> 

On Wednesday 27 October 2004 01:13, Elimar Riesebieter wrote:
> On 2004年10月26日 the mental interface of
>
> Antonino A. Daplas told:
> > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > On 2004年10月25日 the mental interface of
> > >
> > > Antonino A. Daplas told:
> > > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > > Any hints to get back a white mousecursor and a shown bootlogo as
> > > > > in 2.6.8?
> > > >
> > > > See my other mail for the mousecursor.
> >
> > Can you try booting with video=radeonfb:noaccel?
>
> No changes :(
>
I suspect as much. I think fbcon_putc might have an endian bug. Can you try
this patch?
Tony
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	2004年10月26日 23:49:13 +08:00
+++ b/drivers/video/console/fbcon.c	2004年10月27日 08:17:19 +08:00
@@ -1012,7 +1012,9 @@
 
 static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
 {
-	fbcon_putcs(vc, (const unsigned short *) &c, 1, ypos, xpos);
+	unsigned short chr = c;
+
+	fbcon_putcs(vc, &chr, 1, ypos, xpos);
 }
 
 static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)

On 2004年10月26日 the mental interface of
Antonino A. Daplas told:
> On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > On 2004年10月25日 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > Hi all,
> > > >
> > > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at bootti=
me.
> > > > The mousecursor is black colored on vt's and can be used as a brush=
 to
> > > > darken the screen.
> > > >
> > > > $ /usr/sbin/fbset
> > > > mode "1280x854-60"
> > > > # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > > > geometry 1280 854 1280 854 8
> > > > timings 12529 128 16 8 1 112 3
> > > > rgba 8/0,8/0,8/0,0/0
> > > > endmode
> > > >
> > > > $ cat /proc/fb
> > > > 0 ATI Radeon NP
> > > >
> > > > The bootlogo isn`t shown.
> > > >
> > > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > > fine.
> > > >
> > > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > > 2.6.8?
> > >
> > > See my other mail for the mousecursor.
> >
>=20
> Can you try booting with video=3Dradeonfb:noaccel?
No changes :(
$ dmesg | grep radeon
Kernel command line: root=3D/dev/hda5 ro video=3Dradeonfb:noaccel=20
radeonfb: Invalid ROM signature 303 should be 0xaa55
radeonfb: Retreived PLL infos from Open Firmware
radeonfb: Reference=3D27.00 MHz (RefDiv=3D12) Memory=3D200.00 Mhz, System=
=3D300.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type LCD found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
radeonfb: Power Management enabled for Mobility chipsets
radeonfb: ATI Radeon NP SDR SGRAM 64 MB
Elimar
--=20
 Planung:
 Ersatz des Zufalls durch den Irrtum.
 -unknown-

On Tue, 2004年10月26日 at 10:36, Geert Uytterhoeven wrote:
> On 2004年10月26日, Antonino A. Daplas wrote:
> > On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> > > On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > > > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > > > On 2004年10月25日 the mental interface of
> > > > Can you try booting with video=radeonfb:noaccel?
> > >
> > > I'm not sure if this has already been mentionend outside of the debian-ppc
> > > list: this also happens with at least rivafb and offb too.
> > 
> > This is the first time I knew about this problem. Note that gpm
> > predominantly uses the TIOCLINUX ioctl which mainly manipulates the
> > screen_buffer. 
> > 
> > So each time the mouse is moved, gpm sends an ioctl that complements or
> > reverses the attributes of the character underneath the mouse cursor, then
> > it sends a putc command (telling the console to repaint the character). It does
> > not use the fbcon cursor API.
> > 
> > In all drivers I tested in the i386, gpm seems towork correctly.
> > 
> > I can't really much help in this area except for someone with a PPC machine
> > to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
> > selection code in drivers/char/selection.c.
> 
> Just a guess: has anyone recently introduced an endianness-bug somewhere in the
> selection code?
The other common problem is that "char" is unsigned by
default on PowerPC.
**sigh** None of this is necessary. I've used PowerPC in
little-endian mode before, and it works great. Having a
motherboard that does a 64-bit byte swap is helpful for
PCI IO, but certainly not required. On a Mac, you'd simply
need to anti-munge the IO addresses in addition to the
byte swapping that's already done for PCI IO. Also, the
page table entry code needs to order the bits differently,
and loading the MSR may require an extra instruction.

On 2004年10月26日, Antonino A. Daplas wrote:
> On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> > On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > > On 2004年10月25日 the mental interface of
> > > Can you try booting with video=radeonfb:noaccel?
> >
> > I'm not sure if this has already been mentionend outside of the debian-ppc
> > list: this also happens with at least rivafb and offb too.
> 
> This is the first time I knew about this problem. Note that gpm
> predominantly uses the TIOCLINUX ioctl which mainly manipulates the
> screen_buffer. 
> 
> So each time the mouse is moved, gpm sends an ioctl that complements or
> reverses the attributes of the character underneath the mouse cursor, then
> it sends a putc command (telling the console to repaint the character). It does
> not use the fbcon cursor API.
> 
> In all drivers I tested in the i386, gpm seems towork correctly.
> 
> I can't really much help in this area except for someone with a PPC machine
> to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
> selection code in drivers/char/selection.c.
Just a guess: has anyone recently introduced an endianness-bug somewhere in the
selection code?
Gr{oetje,eeting}s,
						Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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

On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > On 2004年10月25日 the mental interface of
> > Can you try booting with video=radeonfb:noaccel?
>
> I'm not sure if this has already been mentionend outside of the debian-ppc
> list: this also happens with at least rivafb and offb too.
This is the first time I knew about this problem. Note that gpm
predominantly uses the TIOCLINUX ioctl which mainly manipulates the
screen_buffer. 
So each time the mouse is moved, gpm sends an ioctl that complements or
reverses the attributes of the character underneath the mouse cursor, then
it sends a putc command (telling the console to repaint the character). It does
not use the fbcon cursor API.
In all drivers I tested in the i386, gpm seems towork correctly.
I can't really much help in this area except for someone with a PPC machine
to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
selection code in drivers/char/selection.c.
Tony
 

On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > On 2004年10月25日 the mental interface of
> >
> > Antonino A. Daplas told:
> > > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > > Hi all,
> > > >
> > > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime.
> > > > The mousecursor is black colored on vt's and can be used as a brush to
> > > > darken the screen.
> > > >
> > > > $ /usr/sbin/fbset
> > > > mode "1280x854-60"
> > > > # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > > > geometry 1280 854 1280 854 8
> > > > timings 12529 128 16 8 1 112 3
> > > > rgba 8/0,8/0,8/0,0/0
> > > > endmode
> > > >
> > > > $ cat /proc/fb
> > > > 0 ATI Radeon NP
> > > >
> > > > The bootlogo isn`t shown.
> > > >
> > > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > > fine.
> > > >
> > > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > > 2.6.8?
> > >
> > > See my other mail for the mousecursor.
> >
> 
> Can you try booting with video=radeonfb:noaccel?
I'm not sure if this has already been mentionend outside of the debian-ppc
list: this also happens with at least rivafb and offb too.
 -- Guido

On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> On 2004年10月25日 the mental interface of
>
> Antonino A. Daplas told:
> > On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > > Hi all,
> > >
> > > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime.
> > > The mousecursor is black colored on vt's and can be used as a brush to
> > > darken the screen.
> > >
> > > $ /usr/sbin/fbset
> > > mode "1280x854-60"
> > > # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > > geometry 1280 854 1280 854 8
> > > timings 12529 128 16 8 1 112 3
> > > rgba 8/0,8/0,8/0,0/0
> > > endmode
> > >
> > > $ cat /proc/fb
> > > 0 ATI Radeon NP
> > >
> > > The bootlogo isn`t shown.
> > >
> > > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > > fine.
> > >
> > > Any hints to get back a white mousecursor and a shown bootlogo as in
> > > 2.6.8?
> >
> > See my other mail for the mousecursor.
>
Can you try booting with video=radeonfb:noaccel?
Tony

On 2004年10月25日 the mental interface of
Antonino A. Daplas told:
> On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> > Hi all,
> >
> > I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. =
The
> > mousecursor is black colored on vt's and can be used as a brush to
> > darken the screen.
> >
> > $ /usr/sbin/fbset
> > mode "1280x854-60"
> > # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> > geometry 1280 854 1280 854 8
> > timings 12529 128 16 8 1 112 3
> > rgba 8/0,8/0,8/0,0/0
> > endmode
> >
> > $ cat /proc/fb
> > 0 ATI Radeon NP
> >
> > The bootlogo isn`t shown.
> >
> > The same kernel on a i386 box with radeonfb (Radeon 9000) works
> > fine.
> >
> > Any hints to get back a white mousecursor and a shown bootlogo as in
> > 2.6.8?
>=20
> See my other mail for the mousecursor.
Can't find the mail?
> As for the bootlogo, is there a space alloted for the logo, or does your
> console start at the very top? can you send the pertinent parts of your
> config?
CONFIG_FB=3Dy
CONFIG_FB_MODE_HELPERS=3Dy
[...]
CONFIG_FB_RADEON=3Dy
CONFIG_FB_RADEON_I2C=3Dy
[...]
CONFIG_DUMMY_CONSOLE=3Dy
CONFIG_FRAMEBUFFER_CONSOLE=3Dy
# Logo configuration
#
CONFIG_LOGO=3Dy
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=3Dy
Ciao
Elimar
--=20
 You cannot propel yourself forward by
 patting yourself on the back.

On Mon, 2004年10月25日 at 13:34, Antonino A. Daplas wrote:
> On Monday 25 October 2004 16:34, Laurence Abbott wrote:
> > I'm not totally sure how I work with multiple framebuffer devices: my
> > AGP card gives me two: /dev/fb/0 which works as I'd expect, and
> > /dev/fb/2, which I think may be TV-out, or something, but this one is
> > only VGA16. The ct65550 one appears as /dev/fb/1
> 
> Doing a cat /proc/fb should tell you what drivers are loaded. What kernel
> version are you using?
This is a 2.6.8 kernel. Yes, /proc/fb does give the numbers I said
above. I also have a /proc/fb0 directory with a couple of files in it
(cannot check at the moment) but no /proc/fb1 or /proc/fb2 (could be
related to vesafb-tng?).
> > I'm currently using the vesafb-tng driver (as part of Gentoo) and think
> > that this may be causing some of my problems! If I use:
> >
> > % fbset -fb /dev/fb/1
> >
> > It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
> > Fair enough. If I try to change the depth on that framebuffer, it
> > corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
> 
> Normal behavior is not to affect /dev/fb0 if the command is explicit
> to /dev/fb1. So there is a bug somewhere. (however, this may happen
> if you have 2 drivers for the same physical device, say vga16fb and
> a driver specific driver)
I will try without compiling support for VGA16 so the second FB on my
AGP card is ignored (hopefully!).
> > with the standard vesafb driver tonight to see if that works any better.
> >
> > In the framebuffer HOWTO, it says that you can only run fbset from teh
> > framebuffer itself. Is this the case? Surely that is the whole point of
> > the -fb switch!
> 
> No, you can run fbset anywhere, even within xterm, if you have the guts.
> If there is no -fb, it defaults to /dev/fb0.
This is what I was hoping...
> > Is there a simple command which can be used to restore a framebuffer
> > back to a sane state, rather than having to reboot?
> 
> There are a few drivers that can restore the hardware state, but the answer
> is generally no. You can try to have > 1 video cards, load each of their
> drivers. If your console becomes corrupt, you can use con2fbmap to
> move your console to the known working driver.
I have some more testing to do now...
Thanks,
Laz

On Monday 25 October 2004 16:34, Laurence Abbott wrote:
> On Sun, 2004年10月24日 at 11:23, Antonino A. Daplas wrote:
> > On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> > > What is the current status of the driver for the Chips and Technologies
> > > 65550 chipset? I can only find mentions of it from a couple of years
> > > back with regard to a new version of the driver (links to that driver
> > > no longer work).
> >
> > There is a chipsfb driver in 2.6 which looks like is properly coded.
>
> Well, to get chipsfb.c to compile on ix86 architecture, I had to remove
> the dependency on PPC in /usr/src/linux/driver/video/Kconfig, and then
> compilation barfed at line 414:
>
> p->screen_base = __ioremap(addr, 0x200000, _PAGE_NO_CACHE);
>
> because _PAGE_NO_CACHE is only defined for PPC. Looking through fbmem.c
> for the same symbol, I found that for some architectures other than
> ix86:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
>
> and for ix86:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
>
> Changing _PAGE_NO_CACHE for _PAGE_PCD in chipsfb.c allowed it co compile
> cleanly (not too sure how legitimate this fix is but it seemed to work
> as a quick bodge!).
>
> > > I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> > > graphics card based on the CT65550 chip, and I'm hoping to get this
> > > working as a basic framebuffer device.
> > >
> > > I believe the current driver only works on PPC architecture but with a
> > > bit of tweaking, I managed to compile the chipsfb module on the ix86
> > > machine containing the card.
> > >
> > > Is this ever likely to work?! Is it likely to work with the VESA
> > > driver?
> >
> > Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
> > ct65550 does have the 2.0 version.
>
> After much more fiddling about (and discovering that the connection to
> the monitor is a bit dodgy), I have got a picture on the monitor
> attached to the ct65550 using the above fix to chipsfb.c. However, this
> is only really with X and the chips driver rather than a proper frame
> buffer driver.
>
> I'm not totally sure how I work with multiple framebuffer devices: my
> AGP card gives me two: /dev/fb/0 which works as I'd expect, and
> /dev/fb/2, which I think may be TV-out, or something, but this one is
> only VGA16. The ct65550 one appears as /dev/fb/1.
>
Doing a cat /proc/fb should tell you what drivers are loaded. What kernel
version are you using?
> I'm currently using the vesafb-tng driver (as part of Gentoo) and think
> that this may be causing some of my problems! If I use:
>
> % fbset -fb /dev/fb/1
>
> It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
> Fair enough. If I try to change the depth on that framebuffer, it
> corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
Normal behavior is not to affect /dev/fb0 if the command is explicit
to /dev/fb1. So there is a bug somewhere. (however, this may happen
if you have 2 drivers for the same physical device, say vga16fb and
a driver specific driver)
> with the standard vesafb driver tonight to see if that works any better.
>
> In the framebuffer HOWTO, it says that you can only run fbset from teh
> framebuffer itself. Is this the case? Surely that is the whole point of
> the -fb switch!
No, you can run fbset anywhere, even within xterm, if you have the guts.
If there is no -fb, it defaults to /dev/fb0.
>
> Is there a simple command which can be used to restore a framebuffer
> back to a sane state, rather than having to reboot?
There are a few drivers that can restore the hardware state, but the answer
is generally no. You can try to have > 1 video cards, load each of their
drivers. If your console becomes corrupt, you can use con2fbmap to
move your console to the known working driver.
Tony

On Sun, 2004年10月24日 at 11:23, Antonino A. Daplas wrote:
> On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> > What is the current status of the driver for the Chips and Technologies
> > 65550 chipset? I can only find mentions of it from a couple of years
> > back with regard to a new version of the driver (links to that driver no
> > longer work).
> 
> There is a chipsfb driver in 2.6 which looks like is properly coded.
Well, to get chipsfb.c to compile on ix86 architecture, I had to remove
the dependency on PPC in /usr/src/linux/driver/video/Kconfig, and then
compilation barfed at line 414:
 p->screen_base = __ioremap(addr, 0x200000, _PAGE_NO_CACHE);
because _PAGE_NO_CACHE is only defined for PPC. Looking through fbmem.c
for the same symbol, I found that for some architectures other than
ix86:
pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
and for ix86:
pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
Changing _PAGE_NO_CACHE for _PAGE_PCD in chipsfb.c allowed it co compile
cleanly (not too sure how legitimate this fix is but it seemed to work
as a quick bodge!).
> > I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> > graphics card based on the CT65550 chip, and I'm hoping to get this
> > working as a basic framebuffer device.
> >
> > I believe the current driver only works on PPC architecture but with a
> > bit of tweaking, I managed to compile the chipsfb module on the ix86
> > machine containing the card.
> >
> > Is this ever likely to work?! Is it likely to work with the VESA driver?
> 
> Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
> ct65550 does have the 2.0 version.
After much more fiddling about (and discovering that the connection to
the monitor is a bit dodgy), I have got a picture on the monitor
attached to the ct65550 using the above fix to chipsfb.c. However, this
is only really with X and the chips driver rather than a proper frame
buffer driver.
I'm not totally sure how I work with multiple framebuffer devices: my
AGP card gives me two: /dev/fb/0 which works as I'd expect, and
/dev/fb/2, which I think may be TV-out, or something, but this one is
only VGA16. The ct65550 one appears as /dev/fb/1.
I'm currently using the vesafb-tng driver (as part of Gentoo) and think
that this may be causing some of my problems! If I use:
% fbset -fb /dev/fb/1
It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
Fair enough. If I try to change the depth on that framebuffer, it
corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
with the standard vesafb driver tonight to see if that works any better.
In the framebuffer HOWTO, it says that you can only run fbset from teh
framebuffer itself. Is this the case? Surely that is the whole point of
the -fb switch!
Is there a simple command which can be used to restore a framebuffer
back to a sane state, rather than having to reboot?
Cheers,
Laz

On Sunday 24 October 2004 17:25, Elimar Riesebieter wrote:
> Hi all,
>
> I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. The
> mousecursor is black colored on vt's and can be used as a brush to
> darken the screen.
>
> $ /usr/sbin/fbset
> mode "1280x854-60"
> # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
> geometry 1280 854 1280 854 8
> timings 12529 128 16 8 1 112 3
> rgba 8/0,8/0,8/0,0/0
> endmode
>
> $ cat /proc/fb
> 0 ATI Radeon NP
>
> The bootlogo isn`t shown.
>
> The same kernel on a i386 box with radeonfb (Radeon 9000) works
> fine.
>
> Any hints to get back a white mousecursor and a shown bootlogo as in
> 2.6.8?
See my other mail for the mousecursor.
As for the bootlogo, is there a space alloted for the logo, or does your
console start at the very top? can you send the pertinent parts of your
config?
Tony

On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> Hi,
>
> What is the current status of the driver for the Chips and Technologies
> 65550 chipset? I can only find mentions of it from a couple of years
> back with regard to a new version of the driver (links to that driver no
> longer work).
There is a chipsfb driver in 2.6 which looks like is properly coded.
>
> I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> graphics card based on the CT65550 chip, and I'm hoping to get this
> working as a basic framebuffer device.
>
> I believe the current driver only works on PPC architecture but with a
> bit of tweaking, I managed to compile the chipsfb module on the ix86
> machine containing the card.
>
> Is this ever likely to work?! Is it likely to work with the VESA driver?
Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
ct65550 does have the 2.0 version.
> At present, I cannot even see the card with lspci, although I'm not
> convinced that it is seated correctly: have yet to check on that.
That's the first thing you need to do, make sure that the device
is detected first. Then try vesafb.
Tony

Hi all,
I am running 2.6.10-rc1 on my Apple AlBG4. gpm is started at boottime. The
mousecursor is black colored on vt's and can be used as a brush to
darken the screen.
$ /usr/sbin/fbset
mode "1280x854-60"
 # D: 79.815 MHz, H: 51.963 kHz, V: 60.003 Hz
 geometry 1280 854 1280 854 8
 timings 12529 128 16 8 1 112 3
 rgba 8/0,8/0,8/0,0/0
endmode
$ cat /proc/fb
0 ATI Radeon NP
The bootlogo isn`t shown.
The same kernel on a i386 box with radeonfb (Radeon 9000) works
fine.
Any hints to get back a white mousecursor and a shown bootlogo as in
2.6.8?
Thx
Elimar
--=20
 The path to source is always uphill!
 -unknown-

Hi,
What is the current status of the driver for the Chips and Technologies
65550 chipset? I can only find mentions of it from a couple of years
back with regard to a new version of the driver (links to that driver no
longer work).
I have recently acquired a Keycorp K57 LCD monitor with a dedicated
graphics card based on the CT65550 chip, and I'm hoping to get this
working as a basic framebuffer device.
I believe the current driver only works on PPC architecture but with a
bit of tweaking, I managed to compile the chipsfb module on the ix86
machine containing the card.
Is this ever likely to work?! Is it likely to work with the VESA driver?
At present, I cannot even see the card with lspci, although I'm not
convinced that it is seated correctly: have yet to check on that.
Cheers,
Laz

On 21 Oct 04 at 14:28, Andreas Burmester wrote:
> As a bridge between my G450 and arcade machine, I have a JPAC
> (http://www.ultimarc.com/jpac.html), which verifies the resolution and
> amplifies the video signal. The JPAC has 3 LEDs indicating the input
> resolution, 31khz, 25khz and 15khz.
> 
> I have specified two fbmodes, one 15khz and one 31khz.
> 
> mode "15khz"
> # D: 5.544 MHz, H: 15.750 kHz, V: 60.115 Hz
> geometry 256 240 256 480 16
> timings 180375 32 32 16 3 32 3
> accel false
> endmode
> 
> The problem is when I set the 15khz mode on fb0 (connected to the
> JPAC) non of the LEDs is on. If I set the 31khz mode on fb0, the 31khz
> LED is on. Could it be possible that the fbset indicates 15khz, but is
> not actually outputting it?
Are you sure you do not want 'laced true' and normal VGA resolution with
525 lines? Just take your 31kHz resolution, multiply pixclock by 2 and
set laced to true.
 
> Another thing, is that I set much flexible resolutions on fb0 then
> fb1, how come is that? ie. I can't set the 15khz mode on fb1.
Which resolution you cannot set? fb1 is more restrictive on line
length (must be multiple of 128 or something like that) and supports
only 16/32 bpp. And it does not support interlaced picture for RGB
output.
 Petr Vandrovec