From: Ico D. <fb...@ze...> - 2007-11-24 21:43:37
|
Hello, I have just finished writing a framebuffer driver for a LCD display connected to our embedded system (monochrome, 128x64, GPIO driven). It's very similar to the hecubafb driver, and uses deferred IO. I've included some of the drivers properties at the end of this mail. Things works fine when displaying images by doing write()s to /dev/fb0, so this part seems to be ok. I hope some of the regulars on this list can clear up some issues I've run into when using this driver: - My next step as to redirect the linux console to this framebuffer device. I've configured the kernel for framebuffer console, and when loading the fbcon module, the message Console: switching to mono frame buffer device 16x4" appears, and cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device cat /sys/class/vtconsole/vtcon1/bind -> 1 This seems just fine to me, but however, no output appears on the display: just a blank screen. It seems that the console is doing *something*, since my driver gets triggered by the deferred IO every 200msec (blinking cursor?), problem is that the data arriving in my driver is all zeroes! So, what would I need to do to get the console working properly with my driver ? - The other question is more a userspace issue: I was hoping to use the xorg fbdev server on my dislay, but unfortunately this does not seem to support 1 bit depth displays : (EE) FBDEV(0): unsupported number of bits per pixel: 1 Is there a way to make X work on 1-bit fb devices, or am I out of luck here ? Thank you, Ico #define DPY_W 128 #define DPY_H 64 static struct fb_fix_screeninfo mbarcfb_fix __devinitdata = { .id = "mbarcfb", .type = FB_TYPE_PACKED_PIXELS, .visual = FB_VISUAL_MONO01, .xpanstep = 0, .ypanstep = 0, .ywrapstep = 0, .accel = FB_ACCEL_NONE, }; static struct fb_var_screeninfo mbarcfb_var __devinitdata = { .xres = DPY_W, .yres = DPY_H, .xres_virtual = DPY_W, .yres_virtual = DPY_H, .bits_per_pixel = 1, .nonstd = 1, }; -- :wq ^X^Cy^K^X^C^C^C^C |
From: Ico D. <fb...@ze...> - 2007-11-24 22:14:59
|
(Sorry for replying to my own post this soon) * On 2007-11-24 Ico Doornekamp <fb...@ze...> wrote : > It's very similar to the hecubafb driver, and uses deferred IO. Anyway, it is *supposed* to use deferred IO, but I suspect this is where my problem is. If I understand right, the fb_defio code should handle the mmap()ing of the framebuffer device for me, and run my callback whenever a write occured to the fb memory. I guess something is not right here, since the callback never gets to run when doing mmap() from userspace, or when using the fbcon module. Is the deferred IO code currently known to work properly ? Thanks again, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Jaya K. <jay...@gm...> - 2007-11-24 22:49:54
|
On Nov 24, 2007 5:14 PM, Ico Doornekamp <fb...@ze...> wrote: > Is the deferred IO code currently known to work properly ? > The deferred IO code does not work properly at the moment. The symptom is that only the first write to the framebuffer is detected. I have a patch to fix this which I've tested to work on 2.6.22.10. You can cherrypick the fb_defio.c changes from the following post. http://marc.info/?l=linux-fbdev-devel&m=119412505902140&w=2 Best regards, jaya |
From: Ico D. <fb...@ze...> - 2007-11-25 09:05:43
|
* On 2007-11-24 Jaya Kumar <jay...@gm...> wrote : > On Nov 24, 2007 5:14 PM, Ico Doornekamp <fb...@ze...> wrote: > > Is the deferred IO code currently known to work properly ? > > > > The deferred IO code does not work properly at the moment. The symptom > is that only the first write to the framebuffer is detected. I have a > patch to fix this which I've tested to work on 2.6.22.10. You can > cherrypick the fb_defio.c changes from the following post. > > http://marc.info/?l=linux-fbdev-devel&m=119412505902140&w=2 This seems to fix my mmap problem, although the first mmap access yields a kernel warning: WARNING: at fs/buffer.c:696 __set_page_dirty() [<c01622f8>] __set_page_dirty+0xb8/0xf0 [<c0134169>] set_page_dirty+0x29/0x50 [<c0134d5b>] set_page_dirty_balance+0xb/0x40 [<c0139470>] __do_fault+0x160/0x340 [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 In spite of the warning, mmaping now works fine. Still no output from the virtual console though. Thank you, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Jaya K. <jay...@gm...> - 2007-11-25 10:48:07
|
On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > This seems to fix my mmap problem, although the first mmap > access yields a kernel warning: > > WARNING: at fs/buffer.c:696 __set_page_dirty() > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > [<c0134169>] set_page_dirty+0x29/0x50 > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > [<c0139470>] __do_fault+0x160/0x340 > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe it's a recent change. Just curious, which kernel are you using and on which arch? Thanks, jaya |
From: Ico D. <fb...@ze...> - 2007-11-25 10:54:09
|
* On 2007-11-25 Jaya Kumar <jay...@gm...> wrote : > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > This seems to fix my mmap problem, although the first mmap > > access yields a kernel warning: > > > > WARNING: at fs/buffer.c:696 __set_page_dirty() > > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > > [<c0134169>] set_page_dirty+0x29/0x50 > > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > > [<c0139470>] __do_fault+0x160/0x340 > > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe > it's a recent change. Just curious, which kernel are you using and on > which arch? I'm running 2.6.23.8 on i386. I can post the driver code if this would be of any help. Unfortunalely I'm not very familiar with the lowlevel paging and memory handling, so this is a though one for me to debug myself. -- :wq ^X^Cy^K^X^C^C^C^C |
From: Jaya K. <jay...@gm...> - 2007-11-25 11:12:28
|
On Nov 25, 2007 5:53 AM, Ico Doornekamp <fb...@ze...> wrote: > > I'm running 2.6.23.8 on i386. I can post the driver code if this would > be of any help. > Yes, I think it'll help. I'll try to upgrade to top of tree as well. Thanks, jaya |
From: Ico D. <fb...@ze...> - 2007-11-25 11:22:01
|
> On Nov 25, 2007 5:53 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > I'm running 2.6.23.8 on i386. I can post the driver code if this would > > be of any help. > > > > Yes, I think it'll help. I'll try to upgrade to top of tree as well. The driver uses on-chip GPIO for communication with the LCD, which is handled by the v86sxgpio_* functions. mbarcfb_dpy_update() does a complete screen update; the layout of the LCD is different from the fbdev, so the 'transpose' function is doing some logic to find the proper pixels. This code is still far from optimal. The code needs some cleanup and #defines for magic numbers here and there, but the general idea should be clear. write() and mmap() from userspace both work fine at this moment, I'm still working on getting the console to display. Ico /* * linux/drivers/video/mbarcfb.c -- FB driver for mbarc display * * Copyright (C) 2007, Ico Doornekamp * Based on the Hecuba driver * * 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/module.h> #include <linux/kernel.h> #include <linux/errno.h> #include <linux/string.h> #include <linux/mm.h> #include <linux/slab.h> #include <linux/vmalloc.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/fb.h> #include <linux/init.h> #include <linux/platform_device.h> #include <linux/list.h> #include <asm/uaccess.h> #include <linux/v86sxgpio.h> #define DPY_W 128 #define DPY_H 64 struct mbarcfb_par { struct v86sxgpio *gpio_data; struct v86sxgpio *gpio_ctrl; int ctrl_bits; struct fb_info *info; }; static struct fb_fix_screeninfo mbarcfb_fix __devinitdata = { .id = "mbarcfb", .type = FB_TYPE_PACKED_PIXELS, .visual = FB_VISUAL_MONO01, .xpanstep = 0, .ypanstep = 0, .ywrapstep = 0, .accel = FB_ACCEL_NONE, }; static struct fb_var_screeninfo mbarcfb_var __devinitdata = { .xres = DPY_W, .yres = DPY_H, .xres_virtual = DPY_W, .yres_virtual = DPY_H, .bits_per_pixel = 1, .nonstd = 1, }; static DECLARE_WAIT_QUEUE_HEAD(mbarcfb_waitq); static struct platform_device *mbarcfb_device; #define DI_INSTR 0 #define DI_DATA 1 #define RW_WRITE 0 #define RW_READ 1 #define BIT_DI (1<<0) #define BIT_RW (1<<1) #define BIT_EN (1<<2) #define BIT_CS1 (1<<3) #define BIT_CS2 (1<<4) #define BIT_RST (1<<5) static void mbarc_set(struct mbarcfb_par *par, int mask, int val) { if(val) { par->ctrl_bits |= mask; } else { par->ctrl_bits &= ~mask; } v86sxgpio_set(par->gpio_ctrl, par->ctrl_bits); } static void mbarc_send(struct mbarcfb_par *par, int di, int val) { mbarc_set(par, BIT_DI, di); mbarc_set(par, BIT_RW, RW_WRITE); v86sxgpio_set(par->gpio_data, val); mbarc_set(par, BIT_EN, 1); mbarc_set(par, BIT_EN, 0); } static int __devinit mbarc_init_control(struct mbarcfb_par *par) { mbarc_set(par, BIT_RST, 0); mbarc_set(par, BIT_RST, 1); mbarc_send(par, DI_DATA, 0xff); mbarc_send(par, DI_DATA, 0xff); mbarc_send(par, DI_DATA, 0xff); mbarc_send(par, DI_INSTR, 0xe2); return 0; } u8 transpose(u8 *src, unsigned x, unsigned y) { u8 b; int i; u8 mask; unsigned offset; mask = 1 << ( 7 - (x%8)); b = 0; for(i=0; i<8; i++) { offset = (x + (y+i)*DPY_W) / 8; if( src[offset] & mask ) b |= (1<<i); } return b; } /* main mbarcfb functions */ static void mbarcfb_dpy_update(struct mbarcfb_par *par) { unsigned char *buf = (unsigned char __force *)par->info->screen_base; unsigned c, x, cx, y; u8 *p; u8 b; p = buf; for(c=0; c<2; c++) { mbarc_set(par, BIT_CS1, c==0); mbarc_set(par, BIT_CS2, c==1); for(y=0; y<64; y+=8) { mbarc_send(par, DI_INSTR, 0x40); mbarc_send(par, DI_INSTR, 0xb8 + y/8); mbarc_send(par, DI_INSTR, 0xc0); /* display start line */ for(cx=0; cx<64; cx++) { x = cx + c*64; b = transpose(buf, x, y); mbarc_send(par, DI_DATA, b); mbarc_send(par, DI_INSTR, 0x3f); /* wtf! */ } } } for(c=0; c<2; c++) { mbarc_set(par, BIT_CS1, c==0); mbarc_set(par, BIT_CS2, c==1); mbarc_send(par, DI_INSTR, 0x3f); /* wtf! */ } } /* this is called back from the deferred io workqueue */ static void mbarcfb_dpy_deferred_io(struct fb_info *info, struct list_head *pagelist) { mbarcfb_dpy_update(info->par); } static void mbarcfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect) { struct mbarcfb_par *par = info->par; sys_fillrect(info, rect); mbarcfb_dpy_update(par); } static void mbarcfb_copyarea(struct fb_info *info, const struct fb_copyarea *area) { struct mbarcfb_par *par = info->par; sys_copyarea(info, area); mbarcfb_dpy_update(par); } static void mbarcfb_imageblit(struct fb_info *info, const struct fb_image *image) { struct mbarcfb_par *par = info->par; sys_imageblit(info, image); mbarcfb_dpy_update(par); } /* * this is the slow path from userspace. they can seek and write to * the fb. it's inefficient to do anything less than a full screen draw */ static ssize_t mbarcfb_write(struct fb_info *info, const char __user *buf, size_t count, loff_t *ppos) { unsigned long p; int err=-EINVAL; struct mbarcfb_par *par; unsigned int xres; unsigned int fbmemlength; p = *ppos; par = info->par; xres = info->var.xres; fbmemlength = (xres * info->var.yres)/8; if (p > fbmemlength) return -ENOSPC; err = 0; if ((count + p) > fbmemlength) { count = fbmemlength - p; err = -ENOSPC; } if (count) { char *base_addr; base_addr = (char __force *)info->screen_base; count -= copy_from_user(base_addr + p, buf, count); *ppos += count; err = -EFAULT; } mbarcfb_dpy_update(par); if (count) return count; return err; } static struct fb_ops mbarcfb_ops = { .owner = THIS_MODULE, .fb_read = fb_sys_read, .fb_write = mbarcfb_write, .fb_fillrect = mbarcfb_fillrect, .fb_copyarea = mbarcfb_copyarea, .fb_imageblit = mbarcfb_imageblit, }; static struct fb_deferred_io mbarcfb_defio = { .delay = HZ / 5, .deferred_io = mbarcfb_dpy_deferred_io, }; static int __devinit mbarcfb_probe(struct platform_device *dev) { struct fb_info *info; int retval = -ENOMEM; int videomemorysize; unsigned char *videomemory; struct mbarcfb_par *par; videomemorysize = (DPY_W*DPY_H)/8; if (!(videomemory = vmalloc(videomemorysize))) return retval; memset(videomemory, 0, videomemorysize); info = framebuffer_alloc(sizeof(struct mbarcfb_par), &dev->dev); if (!info) goto err; info->screen_base = (char __iomem *) videomemory; info->fbops = &mbarcfb_ops; info->var = mbarcfb_var; info->fix = mbarcfb_fix; info->fix.smem_len = videomemorysize; par = info->par; par->info = info; par->gpio_ctrl = v86sxgpio_request("mbarcfb-ctrl", 0, 0, 6); if(!par->gpio_ctrl) { printk(KERN_WARNING "cant get ctrl gpio\n"); goto err1; } v86sxgpio_ddr(par->gpio_ctrl, 0x3f); par->ctrl_bits = 0; par->gpio_data = v86sxgpio_request("mbarcfb-data", 1, 0, 8); if(!par->gpio_data) { printk(KERN_WARNING "cant get data gpio\n"); goto err2; } v86sxgpio_ddr(par->gpio_data, 0xff); info->flags = FBINFO_FLAG_DEFAULT; info->fbdefio = &mbarcfb_defio; fb_deferred_io_init(info); retval = register_framebuffer(info); if (retval < 0) goto err3; platform_set_drvdata(dev, info); printk(KERN_INFO "fb%d: Mbarc frame buffer device, using %dK of video memory\n", info->node, videomemorysize >> 10); /* this inits the dpy */ mbarc_init_control(par); return 0; err3: v86sxgpio_release(par->gpio_data); err2: v86sxgpio_release(par->gpio_ctrl); err1: framebuffer_release(info); err: vfree(videomemory); return retval; } static int __devexit mbarcfb_remove(struct platform_device *dev) { struct fb_info *info = platform_get_drvdata(dev); struct mbarcfb_par *par; if (info) { fb_deferred_io_cleanup(info); unregister_framebuffer(info); vfree((void __force *)info->screen_base); framebuffer_release(info); par = info->par; v86sxgpio_release(par->gpio_data); v86sxgpio_release(par->gpio_ctrl); } return 0; } static struct platform_driver mbarcfb_driver = { .probe = mbarcfb_probe, .remove = mbarcfb_remove, .driver = { .name = "mbarcfb", }, }; static int __init mbarcfb_init(void) { int ret; ret = platform_driver_register(&mbarcfb_driver); if (!ret) { mbarcfb_device = platform_device_alloc("mbarcfb", 0); if (mbarcfb_device) ret = platform_device_add(mbarcfb_device); else ret = -ENOMEM; if (ret) { platform_device_put(mbarcfb_device); platform_driver_unregister(&mbarcfb_driver); } } return ret; } static void __exit mbarcfb_exit(void) { platform_device_unregister(mbarcfb_device); platform_driver_unregister(&mbarcfb_driver); } module_init(mbarcfb_init); module_exit(mbarcfb_exit); MODULE_DESCRIPTION("fbdev driver for Mbarc board"); MODULE_AUTHOR("Ico Doornekamp"); MODULE_LICENSE("GPL"); |
From: Ico D. <fb...@ze...> - 2007-11-28 11:42:20
|
Hello Jaya, * On 2007-11-25 Jaya Kumar <jay...@gm...> wrote : > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > This seems to fix my mmap problem, although the first mmap > > access yields a kernel warning: > > > > WARNING: at fs/buffer.c:696 __set_page_dirty() > > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > > [<c0134169>] set_page_dirty+0x29/0x50 > > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > > [<c0139470>] __do_fault+0x160/0x340 > > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe > it's a recent change. Just curious, did you happen to take a look at this issue, and were you able to reproduce it ? Thank you, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Jaya K. <jay...@gm...> - 2007-11-28 13:00:56
|
On Nov 28, 2007 6:40 AM, Ico Doornekamp <fb...@ze...> wrote: > * On 2007-11-25 Jaya Kumar <jay...@gm...> wrote : > > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > > > This seems to fix my mmap problem, although the first mmap > > > access yields a kernel warning: > > > > > > WARNING: at fs/buffer.c:696 __set_page_dirty() > > > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > > > [<c0134169>] set_page_dirty+0x29/0x50 > > > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > > > [<c0139470>] __do_fault+0x160/0x340 > > > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > > > > > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe > > it's a recent change. > > Just curious, did you happen to take a look at this issue, and were you > able to reproduce it ? > I haven't looked at it yet. Thanks, jaya |
From: Jaya K. <jay...@gm...> - 2007-11-28 13:11:09
|
On Nov 28, 2007 8:00 AM, Jaya Kumar <jay...@gm...> wrote: > On Nov 28, 2007 6:40 AM, Ico Doornekamp <fb...@ze...> wrote: > > * On 2007-11-25 Jaya Kumar <jay...@gm...> wrote : > > > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > > > > > This seems to fix my mmap problem, although the first mmap > > > > access yields a kernel warning: > > > > > > > > WARNING: at fs/buffer.c:696 __set_page_dirty() > > > > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > > > > [<c0134169>] set_page_dirty+0x29/0x50 > > > > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > > > > [<c0139470>] __do_fault+0x160/0x340 > > > > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > > > > > > > > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe > > > it's a recent change. > > > > Just curious, did you happen to take a look at this issue, and were you > > able to reproduce it ? > > > > I haven't looked at it yet. > I'm regretably tied up. Please feel free to look at it too of course. Thanks, jaya |
From: Ico D. <fb...@pr...> - 2007-11-28 13:21:21
|
* On 2007-11-28 Jaya Kumar <jay...@gm...> wrote : > On Nov 28, 2007 8:00 AM, Jaya Kumar <jay...@gm...> wrote: > > On Nov 28, 2007 6:40 AM, Ico Doornekamp <fb...@ze...> wrote: > > > * On 2007-11-25 Jaya Kumar <jay...@gm...> wrote : > > > > On Nov 25, 2007 4:05 AM, Ico Doornekamp <fb...@ze...> wrote: > > > > > > > > > > This seems to fix my mmap problem, although the first mmap > > > > > access yields a kernel warning: > > > > > > > > > > WARNING: at fs/buffer.c:696 __set_page_dirty() > > > > > [<c01622f8>] __set_page_dirty+0xb8/0xf0 > > > > > [<c0134169>] set_page_dirty+0x29/0x50 > > > > > [<c0134d5b>] set_page_dirty_balance+0xb/0x40 > > > > > [<c0139470>] __do_fault+0x160/0x340 > > > > > [<c013a9d3>] handle_mm_fault+0xd3/0x3d0 > > > > > > > > > > > > > Odd. I don't see the same warning. I am still on 2.6.22.10 so maybe > > > > it's a recent change. > > > > > > Just curious, did you happen to take a look at this issue, and were you > > > able to reproduce it ? > > > > > > > I haven't looked at it yet. > > > > I'm regretably tied up. Please feel free to look at it too of course. Yes, of course, I was about to, so that's why I asked. Thank you, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Geert U. <ge...@li...> - 2007-11-25 08:49:38
|
On Sat, 24 Nov 2007, Ico Doornekamp wrote: > I have just finished writing a framebuffer driver for a LCD display > connected to our embedded system (monochrome, 128x64, GPIO driven). > It's very similar to the hecubafb driver, and uses deferred IO. I've > included some of the drivers properties at the end of this mail. Things > works fine when displaying images by doing write()s to /dev/fb0, so this > part seems to be ok. > > I hope some of the regulars on this list can clear up some issues > I've run into when using this driver: > > - My next step as to redirect the linux console to this framebuffer > device. I've configured the kernel for framebuffer console, and when > loading the fbcon module, the message > > Console: switching to mono frame buffer device 16x4" > > appears, and > > cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device > cat /sys/class/vtconsole/vtcon1/bind -> 1 > > This seems just fine to me, but however, no output appears on the > display: just a blank screen. > > It seems that the console is doing *something*, since my driver gets > triggered by the deferred IO every 200msec (blinking cursor?), problem > is that the data arriving in my driver is all zeroes! Fbcon writes to the memory at fb_info.screen_base. > - The other question is more a userspace issue: I was hoping to use the > xorg fbdev server on my dislay, but unfortunately this does not seem > to support 1 bit depth displays : > > (EE) FBDEV(0): unsupported number of bits per pixel: 1 > > Is there a way to make X work on 1-bit fb devices, or am I out of luck > here ? The old XF86_FBDev (from XFree86 3.x) definitely works with monochrome. I expect (but never tried) KDrive also to support it. It's a pity many frame buffer organizations were dropped in Xorg. 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 |
From: Ico D. <fb...@ze...> - 2007-11-25 10:52:06
|
* On 2007-11-25 Geert Uytterhoeven <ge...@li...> wrote : > On Sat, 24 Nov 2007, Ico Doornekamp wrote: > > I have just finished writing a framebuffer driver for a LCD display > > connected to our embedded system (monochrome, 128x64, GPIO driven). > > It's very similar to the hecubafb driver, and uses deferred IO. I've > > included some of the drivers properties at the end of this mail. Things > > works fine when displaying images by doing write()s to /dev/fb0, so this > > part seems to be ok. > > > > I hope some of the regulars on this list can clear up some issues > > I've run into when using this driver: > > > > - My next step as to redirect the linux console to this framebuffer > > device. I've configured the kernel for framebuffer console, and when > > loading the fbcon module, the message > > > > Console: switching to mono frame buffer device 16x4" > > > > appears, and > > > > cat /sys/class/vtconsole/vtcon1/name -> (M) frame buffer device > > cat /sys/class/vtconsole/vtcon1/bind -> 1 > > > > This seems just fine to me, but however, no output appears on the > > display: just a blank screen. > > > > It seems that the console is doing *something*, since my driver gets > > triggered by the deferred IO every 200msec (blinking cursor?), problem > > is that the data arriving in my driver is all zeroes! > > Fbcon writes to the memory at fb_info.screen_base. That is what I expected. I'll have to do a bit more debugging here then. > > - The other question is more a userspace issue: I was hoping to use the > > xorg fbdev server on my dislay, but unfortunately this does not seem > > to support 1 bit depth displays : > > > > (EE) FBDEV(0): unsupported number of bits per pixel: 1 > > > > Is there a way to make X work on 1-bit fb devices, or am I out of luck > > here ? > > The old XF86_FBDev (from XFree86 3.x) definitely works with monochrome. > I expect (but never tried) KDrive also to support it. > > It's a pity many frame buffer organizations were dropped in Xorg. It is, yes. I'll give Kdrive a try, or as an alternative I can make my framebuffer 8-bit greycale instead of monochrome, with a simple threshold. I'll be using simple monochrome apps with some text only, so that will probably be sufficient. Thanks, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Ico D. <ic...@pr...> - 2007-11-24 22:09:29
|
(Sorry for replying to my own post so soon) * On 2007-11-24 Ico Doornekamp <fb...@ze...> wrote : > It's very similar to the hecubafb driver, and uses deferred IO. Anyway, it is *supposed* to use deferred IO, but I suspect this is where my problem is. If I understand right, the fb_defio code should handle the mmap()ing of the framebuffer device for me, and run my callback whenever a write occured to the fb memory. I guess something is not right here, since the callback never gets to run when doing mmap() from userspace, or when using the fbcon module. Is the deferred IO code currently known to work properly ? Thanks again, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Ico D. <fb...@ze...> - 2007-11-25 12:52:00
|
* On 2007-11-25 Ico Doornekamp <fb...@ze...> wrote : > > > > Fbcon writes to the memory at fb_info.screen_base. > > That is what I expected. I'll have to do a bit more debugging here then. It seems that my driver did not fill the line_length member of fb_fix_screeninfo, and no gets was copied by fbcon when this is missing. I filled in this field, but now BUG: unable to handle kernel paging request at virtual address c882a800 [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb] [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor] [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit] [<c01c5c53>] vsnprintf+0x303/0x690 happens. Back to do some more debugging. Thanks for your time, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Ico D. <fb...@ze...> - 2007-11-25 13:32:38
|
* On 2007-11-25 Ico Doornekamp <fb...@ze...> wrote : > * On 2007-11-25 Ico Doornekamp <fb...@ze...> wrote : > > > > Fbcon writes to the memory at fb_info.screen_base. > > > > That is what I expected. I'll have to do a bit more debugging here then. > > It seems that my driver did not fill the line_length member of > fb_fix_screeninfo, and no gets was copied by fbcon when this is missing. > > I filled in this field, but now > > BUG: unable to handle kernel paging request at virtual address c882a800 > > [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb] > [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor] > [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit] > [<c01c5c53>] vsnprintf+0x303/0x690 > > happens. Back to do some more debugging. Ok, one more reply to myself: all problems seem to be solved now - I changed my driver to support 8-bit pseudocolor instead of 1-bit mono, and suddenly both the console and X are working just fine. It seems that the MONO01 visual is just not well supported in various other parts interacting with the framebuffer code. The only issue remaining is the kernel warning I posted in an earlier mail (__set_page_dirty), which I understood Jaya was already trying to reproduce on his system. Thank you both for your time and answers, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Geert U. <ge...@li...> - 2007-11-25 22:17:52
|
On Sun, 25 Nov 2007, Ico Doornekamp wrote: > * On 2007-11-25 Ico Doornekamp <fb...@ze...> wrote : > > * On 2007-11-25 Ico Doornekamp <fb...@ze...> wrote : > > > > Fbcon writes to the memory at fb_info.screen_base. > > > That is what I expected. I'll have to do a bit more debugging here then. > > > > It seems that my driver did not fill the line_length member of > > fb_fix_screeninfo, and no gets was copied by fbcon when this is missing. > > > > I filled in this field, but now > > > > BUG: unable to handle kernel paging request at virtual address c882a800 > > > > [<c882450c>] mbarcfb_imageblit+0xc/0x20 [mbarcfb] > > [<c881315d>] soft_cursor+0x15d/0x1bc [softcursor] > > [<c8817b38>] bit_cursor+0x338/0x5a8 [bitblit] > > [<c01c5c53>] vsnprintf+0x303/0x690 > > > > happens. Back to do some more debugging. > > Ok, one more reply to myself: all problems seem to be solved now - I Good! > changed my driver to support 8-bit pseudocolor instead of 1-bit mono, > and suddenly both the console and X are working just fine. It seems that > the MONO01 visual is just not well supported in various other parts > interacting with the framebuffer code. That's strange. Monochrome is known to work on Amiga. Last one I tried was 2.6.24-rcX. 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 |