Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Antonino D. <ad...@po...> - 2002-11-01 22:24:21
|
On Sat, 2002-11-02 at 05:23, Sven Luther wrote: > On Sat, Nov 02, 2002 at 04:29:32AM +0800, Antonino Daplas wrote: > > It's an irritating bug in the new kernel configurator. Try make -k if > > it complains about the QT libs. > > Ok, it worked some, but debian's kernel-package command did not like it, > o well, i will have to build it by hand until it is fixed. > > BTW, in the old pm3fb driver (which i did not write) a pm3fb_info > structure contained the driver local stuff. I suppose, from reading > skeletonfb.c, that it is now in the xxx_par (that is pm3fb_par) that > private driver info will be found ? > Yes, you can stuff all your driver private data in info->par. (fb_info can be stuffed in pci_device during pci_probe, I think). > Also, since pm3fb_par is placed in include/video/pm3.h, this data will > be shared with other entities, like the drm module for example. > Yes, but it's optional. > ... > > Mmm, it does not compile :(((( > > drivers/video/console/vgacon.c: In function `vgacon_adjust_height': > drivers/video/console/vgacon.c:890: `i' undeclared (first use in this function) > drivers/video/console/vgacon.c:890: (Each undeclared identifier is reported only once > drivers/video/console/vgacon.c:890: for each function it appears in.) > make[3]: *** [drivers/video/console/vgacon.o] Erreur 1 > > O, well, i think i will wait another week or so that the new stuff has > stabilized a bit more before continuing working on this. > Just declare 'int i' and it should work. Tony |
|
From: Antonino D. <ad...@po...> - 2002-11-01 20:42:00
|
On Sat, 2002-11-02 at 04:22, Sven Luther wrote: [...] > > > > Well, yes, i was going to donwload the BK tree, but james was speaking > > > about a 2.5.45 diff, which was finally not the right one. > > > > > I downloaded the patch 12 hours ago and actually ported a driver to > > that. So unless James changed it again, it should be the right one. > > Mmm, yes, it was my fault. > > BTW, is there something with the new kernel configuration process or > something ? I get this error when trying to configure the kernel : > > $ make oldconfig > * > * Unable to find the QT installation. Please make sure that the > * QT development package is correctly installed and the QTDIR > * environment variable is set to the correct location. > * > make[1]: *** [scripts/kconfig/.tmp_qtcheck] Erreur 1 > make: *** [scripts/kconfig/conf] Erreur 2 > > Is this something pulled in from james diff, or is it no more possible > to configure the kernel with plain text console anymore ? > It's an irritating bug in the new kernel configurator. Try make -k if it complains about the QT libs. |
|
From: Antonino D. <ad...@po...> - 2002-11-01 20:08:39
|
On Sat, 2002-11-02 at 03:52, Sven Luther wrote: [...] > > > Ok, i did copy the cfb_ functions to the driver, it works better (the > > > box does not hang anymore), the console apprently works (the cursor > > > blinks in the right place, and it could type stuff, switch VT and > > > shutdown the box) but there is nothing else written. > > > > > > BTW, what is the difference between the full cursor and the underline > > > one ? > > The block cursor most probably comes from fbcon's software cursor, the > > underline is probably your hardware's? > > Mmm, maybe the other way around ? i get block cursor with the old > accelerated pm3fb, and since i did enter no acceleration whatsoever yet > in the new driver, i don't believe it can be using the hardware cursor. > The fbcon software cursor is always a block cursor, well at least before the latest patch James posted. The newest patch should give you an underline cursor by default. > > > Anyway, here are the two Oops : > > > > > > > > [...] > > > I don't believe the result of running ksymoops on these are valid, i > > > will have to reboot in the 2.5.44 kernel for it. > > > > > > > If you did not define fb_set_var at all, then info->disp.dispsw must > > > > point to valid console drawing hooks before you register the > > > > framebuffer. (Actually, all fields in struct display must be valid > > > > before you register the framebuffer) > > > > > > Mmm, still need to check those. > > > > > > > Your oops tracing points to fbcon_cursor as the culprit. If > > > > dispsw->cursor is NULL, then you must have a valid dispsw->revc. > > > > > > There where two oops, the first in fbcon_setup, and the second in > > > fbcon_cursor, i think i will be looking in the first oops first. > > > > > Might as well try to port your driver using the latest fbdev patch > > posted by James, hopefully, this is the last major change. This should > > give you less things to worry about. > > Well, yes, i was going to donwload the BK tree, but james was speaking > about a 2.5.45 diff, which was finally not the right one. > I downloaded the patch 12 hours ago and actually ported a driver to that. So unless James changed it again, it should be the right one. Tony |
|
From: Sven L. <lu...@dp...> - 2002-11-01 19:52:25
|
On Sat, Nov 02, 2002 at 03:42:14AM +0800, Antonino Daplas wrote: > On Fri, 2002-11-01 at 18:52, Sven Luther wrote: > > On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote: > > > Running ksymoops on that might help. The source can be found at > > > ftp.kernel.org. > > > > Ok, got it from the debian package :))) > > > > Erm, i am no more running the same kernel, so i specified the -o and the > > -m options, but it looks at the wrong /proc/ksyms, should i save the > > /proc/ksyms of kernel before/after insmodding the pm3fb module ? > > > Save the symbols after the insmod. Ok, > > Ok, i did copy the cfb_ functions to the driver, it works better (the > > box does not hang anymore), the console apprently works (the cursor > > blinks in the right place, and it could type stuff, switch VT and > > shutdown the box) but there is nothing else written. > > > > BTW, what is the difference between the full cursor and the underline > > one ? > The block cursor most probably comes from fbcon's software cursor, the > underline is probably your hardware's? Mmm, maybe the other way around ? i get block cursor with the old accelerated pm3fb, and since i did enter no acceleration whatsoever yet in the new driver, i don't believe it can be using the hardware cursor. > > Anyway, here are the two Oops : > > > > > [...] > > I don't believe the result of running ksymoops on these are valid, i > > will have to reboot in the 2.5.44 kernel for it. > > > > > If you did not define fb_set_var at all, then info->disp.dispsw must > > > point to valid console drawing hooks before you register the > > > framebuffer. (Actually, all fields in struct display must be valid > > > before you register the framebuffer) > > > > Mmm, still need to check those. > > > > > Your oops tracing points to fbcon_cursor as the culprit. If > > > dispsw->cursor is NULL, then you must have a valid dispsw->revc. > > > > There where two oops, the first in fbcon_setup, and the second in > > fbcon_cursor, i think i will be looking in the first oops first. > > > Might as well try to port your driver using the latest fbdev patch > posted by James, hopefully, this is the last major change. This should > give you less things to worry about. Well, yes, i was going to donwload the BK tree, but james was speaking about a 2.5.45 diff, which was finally not the right one. Will do that nextly. Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2002-11-01 19:43:48
|
On Fri, 2002-11-01 at 18:52, Sven Luther wrote: > On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote: > > Running ksymoops on that might help. The source can be found at > > ftp.kernel.org. > > Ok, got it from the debian package :))) > > Erm, i am no more running the same kernel, so i specified the -o and the > -m options, but it looks at the wrong /proc/ksyms, should i save the > /proc/ksyms of kernel before/after insmodding the pm3fb module ? > Save the symbols after the insmod. [..] > > Ok, i did copy the cfb_ functions to the driver, it works better (the > box does not hang anymore), the console apprently works (the cursor > blinks in the right place, and it could type stuff, switch VT and > shutdown the box) but there is nothing else written. > > BTW, what is the difference between the full cursor and the underline > one ? The block cursor most probably comes from fbcon's software cursor, the underline is probably your hardware's? > > Anyway, here are the two Oops : > > [...] > I don't believe the result of running ksymoops on these are valid, i > will have to reboot in the 2.5.44 kernel for it. > > > If you did not define fb_set_var at all, then info->disp.dispsw must > > point to valid console drawing hooks before you register the > > framebuffer. (Actually, all fields in struct display must be valid > > before you register the framebuffer) > > Mmm, still need to check those. > > > Your oops tracing points to fbcon_cursor as the culprit. If > > dispsw->cursor is NULL, then you must have a valid dispsw->revc. > > There where two oops, the first in fbcon_setup, and the second in > fbcon_cursor, i think i will be looking in the first oops first. > Might as well try to port your driver using the latest fbdev patch posted by James, hopefully, this is the last major change. This should give you less things to worry about. Tony |
|
From: Antonino D. <ad...@po...> - 2002-11-01 19:43:14
|
On Fri, 2002-11-01 at 05:03, James Simmons wrote: > > Sorry about not producing a regular diff. The final changes really did a > number on the framebuffer console code in fbcon.c so I had some massive > work to do. I still have a massive amount of cleaning up to do. Also a lot > of drivers stil haven't been ported. > > So here is the regular diff against 2.5.45 > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > James, I tried the patch, and it does produce a cleaner and smaller driver. Overall, I like it. Some observations: 1. Without the fb_set_var() hook, switching from X messes up the console. I would guess this will be addressed by the console? 2. Console panning/wrapping does not work. updatevar includes a check "if (con == info->currcon)", and my guess is info->currcon is obsoleted so the check always fails. 3. fbdev can be loaded without taking over the console. After running an fb-based application, exiting fbdev messes up the vga console (actually hangs the system). Should the fbdev driver provide the capability to restore the VGA state then, ie at info->fb_release? 4. The initial font loaded is 8x8. It seems that 8x16 fonts are limited for the SGI console console only. Any reason why? 5. The cfb_* drawing functions still behave erratically, especially in emacs. Geert has made some versions that work correctly for me. This was discussed in a thread sometimes ago. Some of the above problems may be from the driver side (ie. #3). Tony Attached is a diff that will allow the logo to be drawn at 8-bpp pseudocolor: diff -Naur linux-2.4.45-fbdev/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c --- linux-2.4.45-fbdev/drivers/video/console/fbcon.c Fri Nov 1 19:19:13 2002 +++ linux/drivers/video/console/fbcon.c Fri Nov 1 19:20:00 2002 @@ -2281,12 +2281,12 @@ } saved_palette = info->pseudo_palette; info->pseudo_palette = palette; - image.width = LOGO_W; - image.height = LOGO_H; - image.depth = depth; - image.data = logo; - image.dy = 0; } + image.width = LOGO_W; + image.height = LOGO_H; + image.depth = depth; + image.data = logo; + image.dy = 0; #endif for (x = 0; x < num_online_cpus() * (LOGO_W + 8) && |
|
From: Sven L. <lu...@dp...> - 2002-11-01 18:43:56
|
On Fri, Nov 01, 2002 at 09:35:06AM -0800, James Simmons wrote: > > > If you did not define fb_set_var at all, then info->disp.dispsw must > > point to valid console drawing hooks before you register the > > framebuffer. (Actually, all fields in struct display must be valid > > before you register the framebuffer) > > The next set of change should help reduce these problems of missing > pointers as we move to the new api. > > > > So, does the cfb_xxx generic accel stuff get linked correctly when > > > building as modules or am i missing something ? > > > > You're correct, the neofb line in the Makefile is for static building > > only. The cfb_xxx will not compile as modules, yet. If your driver has > > its own Makefile, just add cfb_xxx.o objects to directly link to them. > > In the next set of changes the cfb* files should be able to be built as > modules!!!! The ones in the patches you failed to send or the one thereafter ? BTW, do you think the latest set of changes will be in 2.4.46 or something such ? Friendly, Sven Luther |
|
From: James S. <jsi...@in...> - 2002-11-01 18:08:27
|
> If you did not define fb_set_var at all, then info->disp.dispsw must > point to valid console drawing hooks before you register the > framebuffer. (Actually, all fields in struct display must be valid > before you register the framebuffer) The next set of change should help reduce these problems of missing pointers as we move to the new api. > > So, does the cfb_xxx generic accel stuff get linked correctly when > > building as modules or am i missing something ? > > You're correct, the neofb line in the Makefile is for static building > only. The cfb_xxx will not compile as modules, yet. If your driver has > its own Makefile, just add cfb_xxx.o objects to directly link to them. In the next set of changes the cfb* files should be able to be built as modules!!!! |
|
From: James S. <jsi...@in...> - 2002-11-01 16:47:12
|
> On Wed, Oct 30, 2002 at 01:56:38PM -0800, James Simmons wrote: > > I doubt this code will go into 2.5.X but it is avaiable for anyone to play > > with it. > > Why? I don't want to live another release with the old, crappy console, > and you've been working on this during almost all of 2.4 now.. Give my console diff a try. http://phoenix.infradead.org/~jsimmons/console.diff.gz Its against 2.5.45. It has 3 bugs I know of. 1) Switch back to X messes up the screen. 2) I had to disable the beeper. I have to think of a proper solution to that problem with Vojtech. 3) Software suspend is broken because the console has moved from the global int currcons to private struct vc_data to represent a VC. BTW what was the author of that code trying to do any ways? |
|
From: James S. <jsi...@in...> - 2002-11-01 16:18:56
|
> > Sorry about not producing a regular diff. The final changes really did a > > number on the framebuffer console code in fbcon.c so I had some massive > > work to do. I still have a massive amount of cleaning up to do. Also a lot > > of drivers stil haven't been ported. > > > > So here is the regular diff against 2.5.45 > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > Doesn't apply, seems to be a diff against 2.5.2. Hm??? I will give it a try. |
|
From: James S. <jsi...@in...> - 2002-11-01 16:17:51
|
Hi!
Looking at the last bits of the fbdev changes I have question. Currently
I have in fbgen.c:
int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
{
int xoffset = var->xoffset;
int yoffset = var->yoffset;
int err;
if (xoffset < 0 || yoffset < 0 ||
xoffset + info->var.xres > info->var.xres_virtual ||
yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
if (info->fbops->fb_pan_display) {
if ((err = info->fbops->fb_pan_display(var, info)))
return err;
else
return -EINVAL;
}
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
if (var->vmode & FB_VMODE_YWRAP)
info->var.vmode |= FB_VMODE_YWRAP;
else
info->var.vmode &= ~FB_VMODE_YWRAP;
return 0;
}
Now what I was wondering are these test standard enough that we coudl call
this instead of info->fb_ops->fb_pan_display. Several drivers have this
test so it would me more code reduction.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@us...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: Petr B. <pa...@pa...> - 2002-11-01 15:06:57
|
Dear diary, on Thu, Oct 31, 2002 at 12:32:18AM CET, I got a letter, where Skip Ford <ski...@ve...> told me, that... > James Simmons wrote: > > > > bk://linuxconsole.bkbits.net > > > > BTW I will make patches avaiable as soon as 2.5.45 comes out. > > Don't even bother posting to the list without a patch. Saying you want > testers and not providing a patch is just rediculous. As far as I understand it, he just provided you a status report so that you could see what's going on etc (especially relevant around the Oct-31 deadline), and he fullfiled his promise and sent the patches as soon as 2.5.45 came out, didn't he? So what's wrong? -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . This host is a black hole at HTTP wavelengths. GETs go in, and nothing comes out, not even Hawking radiation. -- Graaagh the Mighty on rec.games.roguelike.angband . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ |
|
From: Sven L. <lu...@dp...> - 2002-11-01 10:53:00
|
On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote: > Running ksymoops on that might help. The source can be found at > ftp.kernel.org. Ok, got it from the debian package :))) Erm, i am no more running the same kernel, so i specified the -o and the -m options, but it looks at the wrong /proc/ksyms, should i save the /proc/ksyms of kernel before/after insmodding the pm3fb module ? > If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and > fb_fillrect in info->fbops must not be null. Otherwise, you'll always > get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with > fbcon_dummy, which is totally safe but will not show anything at all. > This is all assuming you use gen_set_var. Ok, i did copy the cfb_ functions to the driver, it works better (the box does not hang anymore), the console apprently works (the cursor blinks in the right place, and it could type stuff, switch VT and shutdown the box) but there is nothing else written. BTW, what is the difference between the full cursor and the underline one ? Anyway, here are the two Oops : Nov 1 11:16:10 iliana kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Nov 1 11:16:10 iliana kernel: printing eip: Nov 1 11:16:10 iliana kernel: c023a5a5 Nov 1 11:16:10 iliana kernel: *pde = 00000000 Nov 1 11:16:10 iliana kernel: Oops: 0000 Nov 1 11:16:10 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx Nov 1 11:16:10 iliana kernel: CPU: 0 Nov 1 11:16:10 iliana kernel: EIP: 0060:[fbcon_setup+677/2368] Not tainted Nov 1 11:16:10 iliana kernel: EFLAGS: 00010212 Nov 1 11:16:10 iliana kernel: eax: 00000080 ebx: 00000008 ecx: 00000007 edx: 00000000 Nov 1 11:16:10 iliana kernel: esi: 0000003f edi: c042d37c ebp: c1143240 esp: c3cfbdbc Nov 1 11:16:10 iliana kernel: ds: 0068 es: 0068 ss: 0068 Nov 1 11:16:10 iliana kernel: Process modprobe (pid: 561, threadinfo=c3cfa000 task=c5aeacc0) Nov 1 11:16:10 iliana kernel: Stack: c7941000 c7941294 c042d37c c1143240 00003389 000033af 00000004 00003386 Nov 1 11:16:10 iliana kernel: c00beea0 00000001 00000100 00000000 c03dfeaf 00000000 c1143240 c7941000 Nov 1 11:16:10 iliana kernel: c042d280 c023a1f7 00000000 00000000 00000000 00000000 00000000 c04156c0 Nov 1 11:16:10 iliana kernel: Call Trace: [fbcon_init+151/192] [visual_init+138/224] [take_over_console+170/400] [register_framebuffer+353/432] [<c887b6f1>] [<c887b123>] [<c887b9e8>] [pci_device_probe+65/96] [<c887b980>] [<c887b9e8>] [<c887b9e8>] [<c887b9c0>] [bus_match+52/96] [driver_attach+64/128] [<c887b9e8>] [<c887b9e8>] [bus_add_driver+87/128] [<c887b9e8>] [<c887b9e8>] [<c887a066>] [driver_register+50/80] [<c887b9e8>] [pci_register_driver+54/80] [<c887b9e8>] [<c887b287>] [<c887b9c0>] [sys_init_module+1309/1536] [<c887a060>] [syscall_call+7/11] Nov 1 11:16:10 iliana kernel: Code: 85 42 24 75 1c 53 68 00 41 33 c0 e8 4b f0 ed ff 8b 74 24 48 And : Nov 1 11:16:30 iliana kernel: <1>Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel NULL pointer dereference at virtual address 00000018 Nov 1 11:16:30 iliana kernel: printing eip: Nov 1 11:16:30 iliana kernel: c023b00c Nov 1 11:16:30 iliana kernel: *pde = 00000000 Nov 1 11:16:30 iliana kernel: Oops: 0000 Nov 1 11:16:30 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx Nov 1 11:16:30 iliana kernel: CPU: 0 Nov 1 11:16:30 iliana kernel: EIP: 0060:[fbcon_cursor+108/480] Not tainted Nov 1 11:16:30 iliana kernel: EFLAGS: 00010246 Nov 1 11:16:30 iliana kernel: eax: 00000000 ebx: 00000000 ecx: 00000000 edx: c1143240 Nov 1 11:16:30 iliana kernel: esi: c042d280 edi: 00000002 ebp: 00000018 esp: c7fb1d78 Nov 1 11:16:30 iliana kernel: ds: 0068 es: 0068 ss: 0068 Nov 1 11:16:30 iliana kernel: Process events/0 (pid: 3, threadinfo=c7fb0000 task=c7fbccc0) Nov 1 11:16:30 iliana kernel: Stack: 00000000 c04156c0 00000000 0000000e c01f21f8 c1143240 00000002 00000000 Nov 1 11:16:30 iliana kernel: c04156c0 c01f5435 00000000 c039efa0 c03e0387 00003887 000038ba c795e040 Nov 1 11:16:30 iliana kernel: 00000000 c5a69e5c 00000000 c0119439 c039efa0 c03e0387 00000033 000038ba Nov 1 11:16:30 iliana kernel: Call Trace: [hide_cursor+120/128] [vt_console_print+165/736] [__call_console_drivers+57/80] [_call_console_drivers+87/96] [call_console_drivers+217/224] [release_console_sem+77/192] [printk+303/352] [do_page_fault+618/1076] [do_page_fault+0/1076] [run_timer_tasklet+231/304] [delayed_work_timer_fn+0/96] [tasklet_hi_action+61/112] [do_softirq+90/176] [do_IRQ+240/272] [apic_timer_interrupt+26/32] [error_code+45/56] [fbcon_switch+335/448] [redraw_screen+224/336] [complete_change_console+43/192] [change_console+137/144] [console_callback+58/176] [worker_thread+482/720] [worker_thread+0/720] [console_callback+0/176] [default_wake_function+0/64] [default_wake_function+0/64] [kernel_thread_helper+5/16] Nov 1 11:16:30 iliana kernel: Code: 83 7b 18 00 74 4e 8b 54 24 14 8b 8e cc 00 00 00 0f b7 42 2c I don't believe the result of running ksymoops on these are valid, i will have to reboot in the 2.5.44 kernel for it. > If you did not define fb_set_var at all, then info->disp.dispsw must > point to valid console drawing hooks before you register the > framebuffer. (Actually, all fields in struct display must be valid > before you register the framebuffer) Mmm, still need to check those. > Your oops tracing points to fbcon_cursor as the culprit. If > dispsw->cursor is NULL, then you must have a valid dispsw->revc. There where two oops, the first in fbcon_setup, and the second in fbcon_cursor, i think i will be looking in the first oops first. Anyway, thanks for your help. Friendly, Sven Luther |
|
From: Sven L. <lu...@dp...> - 2002-11-01 09:05:57
|
On Thu, Oct 31, 2002 at 01:03:54PM -0800, James Simmons wrote: > > Sorry about not producing a regular diff. The final changes really did a > number on the framebuffer console code in fbcon.c so I had some massive > work to do. I still have a massive amount of cleaning up to do. Also a lot > of drivers stil haven't been ported. > > So here is the regular diff against 2.5.45 > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Doesn't apply, seems to be a diff against 2.5.2. Friendly, Sven Luther |
|
From: James S. <jsi...@in...> - 2002-11-01 00:45:56
|
> > 3) Multi-desktop systems. Already done this. The current code in BK > > doesn't support this just yet as I have a few bug to beat out for > > single headed systems. It will take about one more week to get this > > ready. > > this is something i know several people are interested in. and it > does not touch core code to add, does it? > > This is my personal-favorit-must-go-in-above-all-else-feature. Just the VT console code. It does effect the console display drivers tho. |
|
From: James S. <jsi...@in...> - 2002-11-01 00:44:48
|
> On Wed, Oct 30, 2002 at 01:56:38PM -0800, James Simmons wrote: > > I doubt this code will go into 2.5.X but it is avaiable for anyone to play > > with it. > > Why? I don't want to live another release with the old, crappy console, > and you've been working on this during almost all of 2.4 now.. Okay. Here is the new console system. The patch is against 2.5.45. Please note only vgacon has been fixed to work with this new api. http://phoenix.infradead.org/~jsimmons/console.diff.gz Via BK bk://linuxconsole.bkbits.net/stable Diff stats: arch/alpha/kernel/setup.c | 13 arch/arm/kernel/setup.c | 9 arch/i386/kernel/setup.c | 8 arch/i386/vmlinux.lds.s | 109 arch/ia64/kernel/setup.c | 16 arch/m68k/amiga/config.c | 4 arch/m68k/apollo/config.c | 3 arch/m68k/atari/config.c | 5 arch/m68k/hp300/config.c | 4 arch/m68k/mac/config.c | 5 arch/m68k/q40/config.c | 3 arch/m68k/sun3/config.c | 4 arch/m68k/sun3x/config.c | 3 arch/mips/ddb5476/setup.c | 5 arch/mips/dec/setup.c | 5 arch/mips/ite-boards/generic/it8172_setup.c | 7 arch/mips/jazz/setup.c | 4 arch/mips/philips/nino/setup.c | 7 arch/mips/sgi/kernel/setup.c | 6 arch/mips/sni/setup.c | 4 arch/mips64/kernel/ioctl32.c | 3 arch/mips64/sgi-ip22/ip22-setup.c | 5 arch/mips64/sgi-ip32/ip32-setup.c | 6 arch/parisc/kernel/setup.c | 8 arch/ppc/amiga/config.c | 3 arch/ppc/kernel/ppc4xx_setup.c | 7 arch/ppc/platforms/chrp_setup.c | 8 arch/ppc/platforms/k2_setup.c | 6 arch/ppc/platforms/lopec_setup.c | 4 arch/ppc/platforms/mcpn765_setup.c | 6 arch/ppc/platforms/menf1_setup.c | 6 arch/ppc/platforms/mvme5100_setup.c | 6 arch/ppc/platforms/pcore_setup.c | 6 arch/ppc/platforms/pmac_setup.c | 5 arch/ppc/platforms/pplus_setup.c | 4 arch/ppc/platforms/prep_setup.c | 4 arch/ppc/platforms/prpmc750_setup.c | 6 arch/ppc/platforms/prpmc800_setup.c | 6 arch/ppc/platforms/sandpoint_setup.c | 5 arch/ppc/platforms/spruce_setup.c | 6 arch/ppc64/kernel/chrp_setup.c | 5 arch/ppc64/kernel/ioctl32.c | 73 arch/sh/kernel/setup.c | 8 arch/sparc/kernel/setup.c | 5 arch/sparc64/kernel/ioctl32.c | 37 arch/um/kernel/um_arch.c | 2 arch/x86_64/kernel/setup.c | 10 drivers/char/Kconfig | 5 drivers/char/console_macros.h | 166 - drivers/char/consolemap.c | 152 - drivers/char/decvte.c | 2065 ++++++++++++++++++ drivers/char/keyboard.c | 327 +- drivers/char/misc.c | 3 drivers/char/n_tty.c | 12 drivers/char/selection.c | 83 drivers/char/sysrq.c | 17 drivers/char/tty_io.c | 48 drivers/char/vc_screen.c | 124 - drivers/char/vt.c | 3178 ++++++++-------------------- drivers/char/vt_ioctl.c | 1020 +++++--- drivers/video/dummycon.c | 1 drivers/video/mdacon.c | 3 drivers/video/newport_con.c | 1 drivers/video/promcon.c | 13 drivers/video/sticon.c | 1 drivers/video/vgacon.c | 162 - include/linux/console.h | 60 include/linux/console_struct.h | 110 include/linux/consolemap.h | 6 include/linux/kbd_kern.h | 96 include/linux/selection.h | 32 include/linux/tty.h | 19 include/linux/vt_kern.h | 350 ++- include/video/fbcon.h | 2 74 files changed, 4752 insertions(+), 3778 deletions(-) |
|
From: James S. <jsi...@in...> - 2002-10-31 23:50:59
|
> > Sorry about not producing a regular diff. The final changes really did a > > number on the framebuffer console code in fbcon.c so I had some massive > > work to do. I still have a massive amount of cleaning up to do. Also a lot > > of drivers stil haven't been ported. > > > > So here is the regular diff against 2.5.45 > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > > > James, > > The diff you posted is still not the right one. Ug. Try it again. |
|
From: Antonino D. <ad...@po...> - 2002-10-31 21:48:06
|
On Fri, 2002-11-01 at 05:03, James Simmons wrote: > > Sorry about not producing a regular diff. The final changes really did a > number on the framebuffer console code in fbcon.c so I had some massive > work to do. I still have a massive amount of cleaning up to do. Also a lot > of drivers stil haven't been ported. > > So here is the regular diff against 2.5.45 > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > James, The diff you posted is still not the right one. Tony |
|
From: Antonino D. <ad...@po...> - 2002-10-31 21:21:32
|
On Fri, 2002-11-01 at 05:44, James Simmons wrote: > > > On Thu, 2002-10-31 at 12:02, alain volmat wrote: > > > > > > What about adding fb_write / fb_read function in the > > > framebuffer (device dependant) driver. The same way as > > > for fb_mmap. I saw that at the beginning of fb_mmap in > > > fbmem.c, there is a test to see if the device driver > > > contains its own fb_mmap function, if so the device > > > driver fb_mmap will be used instead of the "generic" > > > fb_mmap. What about doing the same thing for fb_write > > > / fb_read. > > > > > I've seen a post by James sometimes ago about adding fb_write and > > fb_read to info->fbops. > > Correct. The next set of fbdev changes will include this plus I added > fb_sync!!! Iknow this will make you happy:-) > Indeed :-), not just me, but others too, I guess. Selective hardware syncs will maximize the graphics instruction pipeline. Tony |
|
From: Sottek, M. J <mat...@in...> - 2002-10-31 21:18:41
|
>:-( Even with providing your own mmap function you still couldn't get it >to work. Is that a question? I did make it work. It worked just fine however when a client accesses a bank via the mmap you have to fault in that bank and _unmap_ the other bank from the client's mmap. This isn't something the kernel lets you do from a module (for good reason). The problem is that when one instruction accesses two banks at the same time there is no possible way to have both banks present and the fault handler would get stuck trying to satisfy the impossible. It doesn't happen in normal aligned accesses (I had XFree running on it) but it is a timebomb waiting to go off so I stopped pursuing it. -Matt |
|
From: James S. <jsi...@in...> - 2002-10-31 20:54:59
|
> The short answer to your problem is that, sadly, much of the 2.4 > framebuffer is badly implemented, allowing device independent code to > directly access device memory etc. Some of this is cleaned up for 2.5, but > as I've not looked at it lately I'm not sure how much. Here are some > pointers as to what is required for 2.4. > > #1 The Boot penguin code directly accesses your video memory. If you have > banked memory this will likely fall off the end of a pointer and oops the > kernel or worse. Fixed in 2.5.X. You use the image drawing function to draw the penguin. > #2 Read/Write Access video memory directly. I had added a read/write > handler to the fb_ops to hook these out and switch banks. > Read/write are also incorrect if your pitch != width. Fixed. I have hooks now. I didn't notice the pitch != width problem. Give me time to fix up a patch, unless someone bets me to the punch. > #3 Memory map can't be done. I had coded up a working version that would > map a single back and page fault in the banks as necessary. This worked > but would get hung up on unaligned accesses where one instruction accessed > two memory banks at the same time. So memory map isn't possible. :-( Even with providing your own mmap function you still couldn't get it to work. |
|
From: James S. <jsi...@in...> - 2002-10-31 20:51:12
|
> On Thu, 2002-10-31 at 12:02, alain volmat wrote: > > > > What about adding fb_write / fb_read function in the > > framebuffer (device dependant) driver. The same way as > > for fb_mmap. I saw that at the beginning of fb_mmap in > > fbmem.c, there is a test to see if the device driver > > contains its own fb_mmap function, if so the device > > driver fb_mmap will be used instead of the "generic" > > fb_mmap. What about doing the same thing for fb_write > > / fb_read. > > > I've seen a post by James sometimes ago about adding fb_write and > fb_read to info->fbops. Correct. The next set of fbdev changes will include this plus I added fb_sync!!! Iknow this will make you happy:-) |
|
From: James S. <jsi...@in...> - 2002-10-31 20:10:51
|
Sorry about not producing a regular diff. The final changes really did a number on the framebuffer console code in fbcon.c so I had some massive work to do. I still have a massive amount of cleaning up to do. Also a lot of drivers stil haven't been ported. So here is the regular diff against 2.5.45 http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz diffstat: CREDITS | 10 Documentation/DocBook/kernel-api.tmpl | 4 MAINTAINERS | 7 arch/alpha/Kconfig | 31 arch/arm/Kconfig | 21 arch/i386/Kconfig | 55 arch/ia64/Kconfig | 25 arch/m68k/Kconfig | 7 arch/mips/Kconfig | 62 arch/mips64/Kconfig | 23 arch/parisc/Kconfig | 19 arch/ppc/Kconfig | 22 arch/ppc64/Kconfig | 7 arch/sh/Kconfig | 55 arch/sparc/Kconfig | 16 arch/sparc64/Kconfig | 11 arch/x86_64/Kconfig | 55 drivers/Makefile | 3 drivers/char/consolemap.c | 1 drivers/char/keyboard.c | 1 drivers/char/selection.c | 1 drivers/char/tty_io.c | 7 drivers/char/vc_screen.c | 1 drivers/char/vt.c | 181 drivers/char/vt_ioctl.c | 58 drivers/video/Kconfig | 338 - drivers/video/Makefile | 45 drivers/video/S3triofb.c | 2 drivers/video/amifb.c | 2 drivers/video/anakinfb.c | 18 drivers/video/atafb.c | 2 drivers/video/aty/atyfb_base.c | 111 drivers/video/aty/mach64_ct.c | 2 drivers/video/aty/mach64_cursor.c | 2 drivers/video/aty/mach64_gx.c | 2 drivers/video/aty128fb.c | 3165 +++++++--------- drivers/video/cfbcopyarea.c | 485 ++ drivers/video/cfbfillrect.c | 107 drivers/video/cfbimgblt.c | 335 + drivers/video/chipsfb.c | 2 drivers/video/clps711xfb.c | 16 drivers/video/console/Kconfig | 277 + drivers/video/console/Makefile | 52 drivers/video/console/dummycon.c | 73 drivers/video/console/fbcon-accel.c | 330 + drivers/video/console/fbcon-accel.h | 34 drivers/video/console/fbcon-afb.c | 448 ++ drivers/video/console/fbcon-afb.h | 32 drivers/video/console/fbcon-hga.c | 253 + drivers/video/console/fbcon-ilbm.c | 296 + drivers/video/console/fbcon-ilbm.h | 32 drivers/video/console/fbcon-iplan2p2.c | 476 ++ drivers/video/console/fbcon-iplan2p2.h | 32 drivers/video/console/fbcon-iplan2p4.c | 497 ++ drivers/video/console/fbcon-iplan2p4.h | 32 drivers/video/console/fbcon-iplan2p8.c | 534 ++ drivers/video/console/fbcon-iplan2p8.h | 32 drivers/video/console/fbcon-sti.c | 289 + drivers/video/console/fbcon.c | 2476 +++++++++++++ drivers/video/console/fbcon.h | 188 drivers/video/console/font.h | 53 drivers/video/console/font_6x11.c | 3351 +++++++++++++++++ drivers/video/console/font_8x16.c | 4631 ++++++++++++++++++++++++ drivers/video/console/font_8x8.c | 2583 +++++++++++++ drivers/video/console/font_acorn_8x8.c | 277 + drivers/video/console/font_mini_4x6.c | 2158 +++++++++++ drivers/video/console/font_pearl_8x8.c | 2587 +++++++++++++ drivers/video/console/font_sun12x22.c | 6220 +++++++++++++++++++++++++++++++++ drivers/video/console/font_sun8x16.c | 275 + drivers/video/console/fonts.c | 135 drivers/video/console/mdacon.c | 631 +++ drivers/video/console/newport_con.c | 745 +++ drivers/video/console/prom.uni | 11 drivers/video/console/promcon.c | 605 +++ drivers/video/console/sti.h | 289 + drivers/video/console/sticon.c | 214 + drivers/video/console/sticore.c | 601 +++ drivers/video/console/vgacon.c | 1066 +++++ drivers/video/controlfb.c | 2 drivers/video/cyberfb.c | 2 drivers/video/dnfb.c | 18 drivers/video/dummycon.c | 74 drivers/video/epson1355fb.c | 2 drivers/video/fbcmap.c | 92 drivers/video/fbcon-accel.c | 188 drivers/video/fbcon-accel.h | 34 drivers/video/fbcon-afb.c | 448 -- drivers/video/fbcon-cfb16.c | 319 - drivers/video/fbcon-cfb2.c | 225 - drivers/video/fbcon-cfb24.c | 333 - drivers/video/fbcon-cfb32.c | 305 - drivers/video/fbcon-cfb4.c | 229 - drivers/video/fbcon-cfb8.c | 294 - drivers/video/fbcon-hga.c | 253 - drivers/video/fbcon-ilbm.c | 296 - drivers/video/fbcon-iplan2p2.c | 476 -- drivers/video/fbcon-iplan2p4.c | 497 -- drivers/video/fbcon-iplan2p8.c | 534 -- drivers/video/fbcon-mfb.c | 217 - drivers/video/fbcon-sti.c | 337 - drivers/video/fbcon-vga-planes.c | 387 -- drivers/video/fbcon.c | 2509 ------------- drivers/video/fbgen.c | 313 - drivers/video/fbmem.c | 100 drivers/video/fm2fb.c | 17 drivers/video/font_6x11.c | 3351 ----------------- drivers/video/font_8x16.c | 4631 ------------------------ drivers/video/font_8x8.c | 2583 ------------- drivers/video/font_acorn_8x8.c | 277 - drivers/video/font_mini_4x6.c | 2158 ----------- drivers/video/font_pearl_8x8.c | 2587 ------------- drivers/video/font_sun12x22.c | 6220 --------------------------------- drivers/video/font_sun8x16.c | 275 - drivers/video/fonts.c | 135 drivers/video/g364fb.c | 32 drivers/video/hgafb.c | 228 - drivers/video/hitfb.c | 17 drivers/video/hpfb.c | 16 drivers/video/igafb.c | 2 drivers/video/imsttfb.c | 3 drivers/video/macfb.c | 22 drivers/video/macmodes.c | 3 drivers/video/macmodes.h | 70 drivers/video/matrox/i2c-matroxfb.c | 2 drivers/video/matrox/matroxfb_base.c | 4 drivers/video/matrox/matroxfb_crtc2.c | 4 drivers/video/maxinefb.c | 15 drivers/video/mdacon.c | 632 --- drivers/video/modedb.c | 7 drivers/video/neofb.c | 28 drivers/video/newport_con.c | 746 --- drivers/video/offb.c | 23 drivers/video/platinumfb.c | 2 drivers/video/pm2fb.c | 2 drivers/video/pm3fb.c | 2 drivers/video/pmag-ba-fb.c | 15 drivers/video/pmagb-b-fb.c | 15 drivers/video/prom.uni | 11 drivers/video/promcon.c | 606 --- drivers/video/pvr2fb.c | 4 drivers/video/q40fb.c | 16 drivers/video/retz3fb.c | 2 drivers/video/sa1100fb.c | 2 drivers/video/sbusfb.c | 2 drivers/video/sgivwfb.c | 24 drivers/video/sis/Makefile | 2 drivers/video/sis/sis_accel.c | 495 ++ drivers/video/sis/sis_main.c | 2 drivers/video/skeletonfb.c | 28 drivers/video/sstfb.c | 2 drivers/video/sti-bmode.h | 287 - drivers/video/sti.h | 289 - drivers/video/sticon-bmode.c | 895 ---- drivers/video/sticon.c | 215 - drivers/video/sticore.c | 601 --- drivers/video/sticore.h | 407 ++ drivers/video/stifb.c | 1403 ++++++- drivers/video/sun3fb.c | 2 drivers/video/tdfxfb.c | 377 -- drivers/video/tgafb.c | 2 drivers/video/tridentfb.c | 2 drivers/video/tx3912fb.c | 16 drivers/video/valkyriefb.c | 2 drivers/video/vesafb.c | 24 drivers/video/vfb.c | 36 drivers/video/vga16fb.c | 1192 ++++-- drivers/video/vgacon.c | 1055 ----- drivers/video/virgefb.c | 2 include/linux/console.h | 1 include/linux/fb.h | 201 - include/linux/sisfb.h | 58 include/linux/vt_kern.h | 8 include/video/fbcon-afb.h | 32 include/video/fbcon-cfb16.h | 34 include/video/fbcon-cfb2.h | 32 include/video/fbcon-cfb24.h | 34 include/video/fbcon-cfb32.h | 34 include/video/fbcon-cfb4.h | 32 include/video/fbcon-cfb8.h | 34 include/video/fbcon-hga.h | 32 include/video/fbcon-ilbm.h | 32 include/video/fbcon-iplan2p2.h | 32 include/video/fbcon-iplan2p4.h | 32 include/video/fbcon-iplan2p8.h | 32 include/video/fbcon-mac.h | 32 include/video/fbcon-mfb.h | 32 include/video/fbcon-vga-planes.h | 37 include/video/fbcon-vga.h | 32 include/video/fbcon.h | 795 ---- include/video/font.h | 53 include/video/macmodes.h | 70 191 files changed, 38960 insertions(+), 41494 deletions(-) BK bk://fbdev.bkbits.net/fbdev-2.5 Go test it out. Just note several drivers haven't been ported yet. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Sven L. <lu...@dp...> - 2002-10-31 11:31:41
|
On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote: > On Thu, 2002-10-31 at 16:10, Sven Luther wrote: > > On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote: > [...] > > > > I already solutioned this problem. > > > > BTW, i don't understand how the tdfxfb does not have this problem, as it > > is from there that i tried to sole this. > > > > The problem was that i did : > > > > /* Find the mmio register area */ > > pm3_fix.mmio_start = pci_resource_start(pdev, 0); > > pm3_fix.mmio_len = pci_resource_len(pdev, 0); > > > > And later : > > > > if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ... > > > > Changing this to : > > > > if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ... > > > > Solved the problem, so it seems that the pci_resource_ functions can be > > called only one time. Is this true ? > > > Strange. pci_resource_* are just macros, so they should be usable as > long as the pci_dev pointer is valid. Yes, thought so also, but then i may have been another problem, will look into this more tomorrow. > > Now, i seem to have everything fine, but it still hangs in > > register_framebuffer, a bit of searching has it that it is when > > register_framebuffer calls take_over_console. I didn't have time for > > looking into it more yesterday. > > > > Still the screen is black, and i see a small (underscore) blinking > > cursor at the bottom left of the screen. The machine was dead though : > > > > Oct 30 23:15:53 iliana kernel: printing eip: > > Oct 30 23:15:53 iliana kernel: c023affc > > Oct 30 23:15:53 iliana kernel: Oops: 0000 > > Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx > > Oct 30 23:15:53 iliana kernel: CPU: 0 > > Oct 30 23:15:53 iliana kernel: EIP: 0060:[fbcon_cursor+108/480] Not tainted > > Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246 > > Oct 30 23:15:53 iliana kernel: eax: 00000000 ebx: 00000000 ecx: 00000000 edx: c1143240 > > Oct 30 23:15:53 iliana kernel: esi: c042d280 edi: 00000002 ebp: 00000018 esp: c4dcbc10 > > Oct 30 23:15:53 iliana kernel: ds: 0068 es: 0068 ss: 0068 > > Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040) > > Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000 > > Oct 30 23:15:53 iliana kernel: c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30 > > Oct 30 23:15:53 iliana kernel: 00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf > > > Running ksymoops on that might help. The source can be found at > ftp.kernel.org. Yes, ... (altoug i do old style debuging (with printk) takes more time, but work also. > If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and > fb_fillrect in info->fbops must not be null. Otherwise, you'll always > get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with > fbcon_dummy, which is totally safe but will not show anything at all. Mmm, ok, > This is all assuming you use gen_set_var. Yes, i use this one. > If you did not define fb_set_var at all, then info->disp.dispsw must > point to valid console drawing hooks before you register the > framebuffer. (Actually, all fields in struct display must be valid > before you register the framebuffer) > > Your oops tracing points to fbcon_cursor as the culprit. If > dispsw->cursor is NULL, then you must have a valid dispsw->revc. Ok, but will look more at it, tomorrow. > > How, well, maybe i should wait for the new patches from James to be > > accepted into the linus tree. > > > > Notice, maybe this is due to me not having defined yet any of the > > check_var, set_par, blank, ... functions, but my idea, for the howto > > afterward, was to write first the most minimal working fbdev. > > > > BTW, should i work on james BK tree directly ? Is there an howto on how > > to do that ? Or could it be possible to get a patch against 2.5.44 ? > > > Try Documentation/BK-usage. You will need a very fat pipe, then for a > start, > > bk clone bk://fbdev.bkbits.net/fbdev-2.5 Ok, ... i have ADSL 512K, i suppose it will have to be enough, anyway, the other solution would be to just be patient, isn't it ? > > when i try to use the cfb_xxx functions, it does not work. i copied the > > neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx > > objects, but it does not work. When loading the cfbxxx.o object files as > > modules, insmod complains about lack of version in them, so i guess they > > are not modules. Still, they don't get linked with the pm3fb.o (and > > neither with the neofb.o when i tried it), and when loading pm3fb.o, i > > get a message about missing symbols cfb_xxx. > > > > So, does the cfb_xxx generic accel stuff get linked correctly when > > building as modules or am i missing something ? > > > You're correct, the neofb line in the Makefile is for static building > only. The cfb_xxx will not compile as modules, yet. If your driver has > its own Makefile, just add cfb_xxx.o objects to directly link to them. It is just one file, i think i will just copy the cfb_xxx functions into my file for now, it should work as well, anyway, i plan to add my own accel functions later on. Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2002-10-31 11:08:26
|
On Thu, 2002-10-31 at 16:10, Sven Luther wrote: > On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote: [...] > > I already solutioned this problem. > > BTW, i don't understand how the tdfxfb does not have this problem, as it > is from there that i tried to sole this. > > The problem was that i did : > > /* Find the mmio register area */ > pm3_fix.mmio_start = pci_resource_start(pdev, 0); > pm3_fix.mmio_len = pci_resource_len(pdev, 0); > > And later : > > if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ... > > Changing this to : > > if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ... > > Solved the problem, so it seems that the pci_resource_ functions can be > called only one time. Is this true ? > Strange. pci_resource_* are just macros, so they should be usable as long as the pci_dev pointer is valid. > Now, i seem to have everything fine, but it still hangs in > register_framebuffer, a bit of searching has it that it is when > register_framebuffer calls take_over_console. I didn't have time for > looking into it more yesterday. > > Still the screen is black, and i see a small (underscore) blinking > cursor at the bottom left of the screen. The machine was dead though : > > Oct 30 23:15:53 iliana kernel: printing eip: > Oct 30 23:15:53 iliana kernel: c023affc > Oct 30 23:15:53 iliana kernel: Oops: 0000 > Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx > Oct 30 23:15:53 iliana kernel: CPU: 0 > Oct 30 23:15:53 iliana kernel: EIP: 0060:[fbcon_cursor+108/480] Not tainted > Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246 > Oct 30 23:15:53 iliana kernel: eax: 00000000 ebx: 00000000 ecx: 00000000 edx: c1143240 > Oct 30 23:15:53 iliana kernel: esi: c042d280 edi: 00000002 ebp: 00000018 esp: c4dcbc10 > Oct 30 23:15:53 iliana kernel: ds: 0068 es: 0068 ss: 0068 > Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040) > Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000 > Oct 30 23:15:53 iliana kernel: c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30 > Oct 30 23:15:53 iliana kernel: 00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf > Running ksymoops on that might help. The source can be found at ftp.kernel.org. If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and fb_fillrect in info->fbops must not be null. Otherwise, you'll always get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with fbcon_dummy, which is totally safe but will not show anything at all. This is all assuming you use gen_set_var. If you did not define fb_set_var at all, then info->disp.dispsw must point to valid console drawing hooks before you register the framebuffer. (Actually, all fields in struct display must be valid before you register the framebuffer) Your oops tracing points to fbcon_cursor as the culprit. If dispsw->cursor is NULL, then you must have a valid dispsw->revc. > How, well, maybe i should wait for the new patches from James to be > accepted into the linus tree. > > Notice, maybe this is due to me not having defined yet any of the > check_var, set_par, blank, ... functions, but my idea, for the howto > afterward, was to write first the most minimal working fbdev. > > BTW, should i work on james BK tree directly ? Is there an howto on how > to do that ? Or could it be possible to get a patch against 2.5.44 ? > Try Documentation/BK-usage. You will need a very fat pipe, then for a start, bk clone bk://fbdev.bkbits.net/fbdev-2.5 > > when i try to use the cfb_xxx functions, it does not work. i copied the > neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx > objects, but it does not work. When loading the cfbxxx.o object files as > modules, insmod complains about lack of version in them, so i guess they > are not modules. Still, they don't get linked with the pm3fb.o (and > neither with the neofb.o when i tried it), and when loading pm3fb.o, i > get a message about missing symbols cfb_xxx. > > So, does the cfb_xxx generic accel stuff get linked correctly when > building as modules or am i missing something ? > You're correct, the neofb line in the Makefile is for static building only. The cfb_xxx will not compile as modules, yet. If your driver has its own Makefile, just add cfb_xxx.o objects to directly link to them. Tony |
754 messages has been excluded from this view by a project administrator.
