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...> - 2003-02-20 22:00:15
|
On Fri, 2003-02-21 at 03:58, James Simmons wrote: > > > I was for five weeks in U.S., so I did not do anything with > > matroxfb during that time. I plan to use fillrect and copyrect > > from generic code > > I have ported the accelerated functions to the new api. What is left is to > deal with the loadfont and putcs issue which I'm working on the code right > now. > > > (although it means unnecessary multiply on > > generic side, and division in matroxfb, > > ???? > > > but well, if we gave > > up on reasonable speed for fbdev long ago...). > > This is not true. Several benchmarks have shown a large performance > improvement in 2.5.X. > 2.5.x might be a bit slower with bpp8 but at higher color depths is significantly faster. And this is done with a single generic color exapnd function that replaces the entire fbcon-cfb*.c in 2.4. And it will theoretically still draw correctly whatever the condition is (any bpp from 1-32, unaligned origin, pitch, width, etc). Drivers with accelerated color expansion, if done correctly, _should_ perform better whatever the color depth. However, using fonts with widths not divisible by 8 will be several folds slower. This should be helped if we add some form of tile/texture blitting support to fbdev. Note: I cannot test with 12x22 fonts in 2.4 because some/most drivers do not support it. Tony no accel scrollmode: yredraw font: 8x16 visual: packed pixels time cat /usr/src/linux/MAINTAINERS linux-2.4.20 bpp8 ---- real 0m2.499s user 0m0.000s sys 0m2.500s bpp16 ----- real 0m8.324s user 0m0.000s sys 0m8.320s bpp24 ----- real 0m12.364s user 0m0.000s sys 0m12.370s bpp32 ----- real 0m16.274s user 0m0.000s sys 0m16.280s linux-2.5.62 bpp8 ---- real 0m2.557s user 0m0.003s sys 0m2.553s bpp16 ----- real 0m4.051s user 0m0.002s sys 0m4.050s bpp24 ----- real 0m9.520s user 0m0.000s sys 0m9.520s bpp32 ----- real 0m7.496s user 0m0.002s sys 0m7.494s |
|
From: James S. <jsi...@in...> - 2003-02-20 19:59:42
|
> I was for five weeks in U.S., so I did not do anything with > matroxfb during that time. I plan to use fillrect and copyrect > from generic code I have ported the accelerated functions to the new api. What is left is to deal with the loadfont and putcs issue which I'm working on the code right now. > (although it means unnecessary multiply on > generic side, and division in matroxfb, ???? > but well, if we gave > up on reasonable speed for fbdev long ago...). This is not true. Several benchmarks have shown a large performance improvement in 2.5.X. > But I simply > want loadfont and putcs hooks for character painting. And if > fbdev maintainer does not want to give me them, well, then > matroxfb and fbdev are not compatible. Working on it. I starting with Tony's tileblit patch but I plan to expand it even more i.e texture maps to draw fonts. > (3) persuade me that I want to write matroxcon and forget about fbcon at all, or This is the best solution. > Besides that with that strange additional copy in accel_putcs > I get much slower output than with 2.4.x... and although I Again not true. |
|
From: Petr V. <van...@vc...> - 2003-02-20 18:29:54
|
On Thu, Feb 20, 2003 at 03:02:01PM +0000, Dave Jones wrote: > On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote: > > > New updates to the fbdev layer. You can grab the diff from > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > James, > Whats the current status with matroxfb ? Its been broken > for months now, and hasn't seen any progress wrt getting it > back on its feet. > > I understand Petr had some concerns with the new API, but > *something* needs to be done to get this back up and running. > > I'd understand if this was a neglected hardly-used-by-anyone > driver, but there's an awful lot of matrox cards out there. > > This was first reported broken way back in 2.5.53, but I believe > was broken even longer before that. Since 2.5.51, when rewrite came in... You can get patch which reverts most of James's work at ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.59.gz. I was for five weeks in U.S., so I did not do anything with matroxfb during that time. I plan to use fillrect and copyrect from generic code (although it means unnecessary multiply on generic side, and division in matroxfb, but well, if we gave up on reasonable speed for fbdev long ago...). But I simply want loadfont and putcs hooks for character painting. And if fbdev maintainer does not want to give me them, well, then matroxfb and fbdev are not compatible. I refuse to remove features from matroxfb driver, and textmode support is one of current features (needed and required to be able to run VMware on fullscreen - and as main part of my job happens in VMware...). So there is couple of choices: (1) new maintainer, or (2) remove matroxfb from kernel, or (3) persuade me that I want to write matroxcon and forget about fbcon at all, or (4) something else I do not know about. Besides that with that strange additional copy in accel_putcs I get much slower output than with 2.4.x... and although I understand that for 2.6.x we'll all have faster computers than we had for 2.4.x, I still think that speed should be primary concern, and code extensibility and readability secondary. But well, I told it dozens of time, so why I bother. I do not want to end up as Larry. Petr Vandrovec van...@vc... |
|
From: Ivan K. <in...@ju...> - 2003-02-20 15:11:35
|
On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote: > <jsi...@ma...> (03/02/19 1.913.1.1) ... > using standard macros for vgacon.c. Unfortunately, this makes vgacon on non-legacy platforms where the I/O port address doesn't fit in unsigned short almost unfixable. :-( Ivan. |
|
From: James S. <jsi...@in...> - 2003-02-20 15:08:51
|
> James, > Whats the current status with matroxfb ? Its been broken > for months now, and hasn't seen any progress wrt getting it > back on its feet. > > I understand Petr had some concerns with the new API, but > *something* needs to be done to get this back up and runn I have a newer driver but its not finished. The last month I have focused on finding work instead. |
|
From: Dave J. <da...@co...> - 2003-02-20 14:50:40
|
On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote: > New updates to the fbdev layer. You can grab the diff from > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz James, Whats the current status with matroxfb ? Its been broken for months now, and hasn't seen any progress wrt getting it back on its feet. I understand Petr had some concerns with the new API, but *something* needs to be done to get this back up and running. I'd understand if this was a neglected hardly-used-by-anyone driver, but there's an awful lot of matrox cards out there. This was first reported broken way back in 2.5.53, but I believe was broken even longer before that. Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs |
|
From: James S. <jsi...@in...> - 2003-02-20 01:24:08
|
> James Simmons wrote: > > New updates to the fbdev layer. You can grab the diff from > > > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > > > or do a pull > > > > bk pull http://gkernel.bkbits.net/fbdev-2.5 > > > You need to fix your script... Oops. Sorry folks. I meant http://fbdev.bkbits.net/fbdev-2.5 |
|
From: Jeff G. <jg...@po...> - 2003-02-20 01:18:43
|
James Simmons wrote: > New updates to the fbdev layer. You can grab the diff from > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > or do a pull > > bk pull http://gkernel.bkbits.net/fbdev-2.5 You need to fix your script... I do not think you posted your BK repo at "gkernel" ;-) Jeff |
|
From: James S. <jsi...@in...> - 2003-02-20 01:10:43
|
New updates to the fbdev layer. You can grab the diff from http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz or do a pull bk pull http://gkernel.bkbits.net/fbdev-2.5 This will update the following files: drivers/video/maxinefb.h | 37 drivers/video/pm2fb.h | 218 --- drivers/video/pm3fb.h | 1284 -------------------- drivers/video/pmag-ba-fb.h | 24 drivers/video/pmagb-b-fb.h | 32 drivers/video/sstfb.h | 355 ----- arch/mips64/Kconfig | 4 arch/ppc/syslib/prom.c | 3 arch/ppc/syslib/prom_init.c | 28 arch/ppc64/kernel/prom.c | 27 drivers/char/vt.c | 8 drivers/video/Kconfig | 17 drivers/video/Makefile | 3 drivers/video/aty/atyfb.h | 86 - drivers/video/aty/atyfb_base.c | 1804 ++++++++++++++--------------- drivers/video/aty/mach64_accel.c | 51 drivers/video/aty/mach64_ct.c | 356 +++-- drivers/video/aty/mach64_cursor.c | 4 drivers/video/aty/mach64_gx.c | 18 drivers/video/aty128fb.c | 162 +- drivers/video/cfbcopyarea.c | 42 drivers/video/cfbfillrect.c | 12 drivers/video/cfbimgblt.c | 100 - drivers/video/console/fbcon.c | 333 ----- drivers/video/console/fbcon.h | 3 drivers/video/console/newport_con.c | 69 - drivers/video/console/vgacon.c | 673 +++++----- drivers/video/fbmem.c | 306 ++-- drivers/video/fbmon.c | 3 drivers/video/hgafb.c | 9 drivers/video/i810/i810.h | 9 drivers/video/i810/i810_accel.c | 150 +- drivers/video/i810/i810_main.c | 486 ++----- drivers/video/i810/i810_main.h | 14 drivers/video/logo/Kconfig | 67 + drivers/video/logo/Makefile | 27 drivers/video/logo/logo.c | 100 + drivers/video/logo/logo_dec_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_linux_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_linux_mono.pbm | 202 +++ drivers/video/logo/logo_linux_vga16.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_mac_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_parisc_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_sgi_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_sun_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_superh_clut224.ppm | 1603 +++++++++++++++++++++++++ drivers/video/logo/logo_superh_mono.pbm | 202 +++ drivers/video/logo/logo_superh_vga16.ppm | 1603 +++++++++++++++++++++++++ drivers/video/maxinefb.c | 2 drivers/video/modedb.c | 8 drivers/video/neofb.c | 81 - drivers/video/pm2fb.c | 2 drivers/video/pm3fb.c | 3 drivers/video/pmag-ba-fb.c | 2 drivers/video/pmagb-b-fb.c | 2 drivers/video/radeonfb.c | 1 drivers/video/riva/fbdev.c | 323 ++--- drivers/video/riva/nv_driver.c | 156 ++ drivers/video/riva/rivafb.h | 2 drivers/video/sgivwfb.c | 192 ++- drivers/video/skeletonfb.c | 6 drivers/video/sstfb.c | 14 drivers/video/tdfxfb.c | 6 drivers/video/tgafb.c | 2 drivers/video/tridentfb.c | 2 drivers/video/vga16fb.c | 127 +- include/linux/fb.h | 19 include/linux/linux_logo.h | 1435 ----------------------- include/video/mach64.h | 61 include/video/maxinefb.h | 37 include/video/pm3fb.h | 1284 ++++++++++++++++++++ include/video/pmag-ba-fb.h | 24 include/video/pmagb-b-fb.h | 32 include/video/sgivw.h | 40 include/video/sstfb.h | 355 +++++ include/video/vga.h | 16 scripts/Makefile | 4 scripts/pnmtologo |binary scripts/pnmtologo.c | 498 ++++++++ 79 files changed, 20264 insertions(+), 6227 deletions(-) through these ChangeSets: <jsi...@ma...> (03/02/19 1.913.1.3) [FBDEEV] Need to add support to build pnmtologo. <jsi...@ma...> (03/02/19 1.913.1.1) Removed obsolete functions in fbcon.c and re-enabled mapping console(s) to a framebuffer device. A few compile fixes for rivafb and using standard macros for vgacon.c. <jsi...@ma...> (03/02/16 1.913) [FBDEV] Data in struct fb_image is now const. [FBDEV] Updates to the logo code. We seperated it into two functions. [I810 FBDEV] Updates to the driver. PCI hooks for PCI supsend and resume to save the AGP GART mapping during power saving. [ATY 128] Add proper support for two graphics cards. Also added support for two more models of the Rage 128. [SGIVW FBDEV] Updates for the SGI Visual Workstation framebuffer. <jsi...@ma...> (03/02/13 1.910) [LOGO] New better logo code. [FBDEV] Moved a few more header files. <jsi...@ma...> (03/02/11 1.909) [FBCON] Removal of useless code. <jsi...@ma...> (03/02/11 1.906) [ATY FBDEV] Reversed mobilty patches. They busted every other card. <jsi...@ma...> (03/02/09 1.900) [ATY FBDEV] Updates to support Rage Mobility Chipstes. <jsi...@ma...> (03/01/30 1.899) [RIVA FBDEV] SUpprot Directcolor mode. Needed for some cards. <jsimmons@kozmo.(none)> (03/01/28 1.897) [NEOMAGIC FBDEV] Fix to work with no 21xx versions of the chip. <jsi...@ma...> (03/01/28 1.889.52.3) [RADEON FBDEV] Add cursor support. Now the cursor is back. [RIVA FBDEV] Added support for interlace mode and are now using TRUECOLOR instead of DIRECTCOLOR. Setting the graphics card in DIRECTCOLOR confusses the X server. <jsi...@ma...> (03/01/26 1.889.52.2) Accel rountines pass in constant data into each function. The reason being was some of the code in the upper layers depended on the data being passed to the low level function not be altered because the upper layers was altering the data themselves. Pan display fix for fbcon.c. p->vrow needed to be updated. PPC build fix for fbmon.c I810 fbdev updates. <jsi...@ma...> (03/01/17 1.889.52.1) [GENERIC ACCELERATION] Fixed the generic image drawing function tfor 64 bit machines. [RIVA FBDEV] The cursor and imageblit functions have been fixed. |
|
From: Ani J. <aj...@un...> - 2003-02-19 19:06:45
|
Marcello and Linus will recieve an update in the next week or so.
ani
On Wed, 19 Feb 2003, Hanno [ISO-8859-15] B=F6ck wrote:
> Hi,
>
> I own a Sony Vaio with a Radeon Mobility M6 LY.
>
> The Situation with radeonfb at the moment is not very good for me.
> 1. I need a fix that has been around for ages, but not added to the main
> kernel (see patch below).
> 2. There seem to be two updates for the radeonfb in kernel 2.4 floating
> arount. One from Ani Joshi which was part of the ac-kernel, but has
> recently been dropped. So it's not likely that it will become part of
> the main kernel. This Update works for me.
> Another one from the mplayer-team, which doesn't work for me at all,
> even if I add the fix below.
>
> By the way, the 2.5-version of the radeonfb also doesn't work at all for
> me, even if I add the fix below and change the constant-names to the
> ones used in 2.5.
>
> I would really like to have a working radeonfb. Is there currently any
> work done on this? Can we at least send the fix below to marcello and
> ask him to integrate this soon?
>
>
>
> --- radeonfb.c.orig=09Thu May 9 16:51:26 2002
> +++ radeonfb.c=09Thu May 9 16:48:46 2002
> @@ -877,6 +877,14 @@
> =09/* mem size is bits [28:0], mask off the rest */
> =09rinfo->video_ram =3D tmp & CONFIG_MEMSIZE_MASK;
>
> +=09/* According to XFree86 4.2.0, some production M6's return 0
> +=09 for 8MB. */
> +=09if (rinfo->video_ram =3D=3D 0 &&
> +=09 (pdev->device =3D=3D PCI_DEVICE_ID_RADEON_LY ||
> +=09 pdev->device =3D=3D PCI_DEVICE_ID_RADEON_LZ)) {
> +=09 rinfo->video_ram =3D 8192 * 1024;
> +=09 }
> +
> =09/* ram type */
> =09tmp =3D INREG(MEM_SDRAM_MODE_REG);
> =09switch ((MEM_CFG_TYPE & tmp) >> 30) {
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>
|
|
From: Hanno <ha...@gm...> - 2003-02-19 12:00:28
|
Hi,
I own a Sony Vaio with a Radeon Mobility M6 LY.
The Situation with radeonfb at the moment is not very good for me.
1. I need a fix that has been around for ages, but not added to the main
kernel (see patch below).
2. There seem to be two updates for the radeonfb in kernel 2.4 floating
arount. One from Ani Joshi which was part of the ac-kernel, but has
recently been dropped. So it's not likely that it will become part of
the main kernel. This Update works for me.
Another one from the mplayer-team, which doesn't work for me at all,
even if I add the fix below.
By the way, the 2.5-version of the radeonfb also doesn't work at all for
me, even if I add the fix below and change the constant-names to the
ones used in 2.5.
I would really like to have a working radeonfb. Is there currently any
work done on this? Can we at least send the fix below to marcello and
ask him to integrate this soon?
--- radeonfb.c.orig Thu May 9 16:51:26 2002
+++ radeonfb.c Thu May 9 16:48:46 2002
@@ -877,6 +877,14 @@
/* mem size is bits [28:0], mask off the rest */
rinfo->video_ram = tmp & CONFIG_MEMSIZE_MASK;
+ /* According to XFree86 4.2.0, some production M6's return 0
+ for 8MB. */
+ if (rinfo->video_ram == 0 &&
+ (pdev->device == PCI_DEVICE_ID_RADEON_LY ||
+ pdev->device == PCI_DEVICE_ID_RADEON_LZ)) {
+ rinfo->video_ram = 8192 * 1024;
+ }
+
/* ram type */
tmp = INREG(MEM_SDRAM_MODE_REG);
switch ((MEM_CFG_TYPE & tmp) >> 30) {
|
|
From: Antonino D. <ad...@po...> - 2003-02-18 21:57:37
|
On Tue, 2003-02-18 at 03:32, John Bradford wrote: > > So how about making the logo "float" above/obscure the text (ie, > > overlay)? It's not difficult to implement since fbcon.c has "redraw" > > versions of fbcon_bmove() and fbcon_clear(). All that needs to be done > > is do a "scissors" test before an fb_imageblit(). > > On the subject of the new logo code, would it be worth making it do > something, (change colour, move, or animate), during a console bell? > Possibly, it depends on the console/input developers if they want to add something like fb_flash_logo() besides doing a kd_mksound(). Also, if you don't mind compiling in a bunch of logo images to your kernel. On a more practical note, the "scissors test" (I should have named this "exclusive clipping test") can perhaps be enabled arbitrarily by userland clients. You'll be left with a rectangular screen space that will not be touched by the console. Then a distributor can do whatever it wants with that screen estate, say an animating splash or a pop-up window, which in theory can be triggered any time. Tony |
|
From: Geert U. <ge...@li...> - 2003-02-17 22:06:41
|
On 16 Feb 2003, Antonino Daplas wrote:
> On Sun, 2003-02-16 at 14:08, Antonino Daplas wrote:
> > The attached patch (linux-2.5.61 + James' fbdev.diff) fixes the following:
> >
> > 1. compile error because of missing scripts/pmntologo.
> >
> > 2. Break up of fb_show_logo() to fb_prepare_logo()/fb_show_logo() to fix
> > weird "double drawing" or the "single draw, erase in a flash" of the
> > logo.
> >
> > 3. Fixed all drivers affected by the (image.depth == 0) is color
> > expansion.
> >
>
> Here's an incremental diff to protect logo drawing code with an
> #ifdef CONFIG_FB_LOGO
Note that it's called CONFIG_LOGO now.
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: John B. <jo...@gr...> - 2003-02-17 19:32:00
|
> So how about making the logo "float" above/obscure the text (ie, > overlay)? It's not difficult to implement since fbcon.c has "redraw" > versions of fbcon_bmove() and fbcon_clear(). All that needs to be done > is do a "scissors" test before an fb_imageblit(). On the subject of the new logo code, would it be worth making it do something, (change colour, move, or animate), during a console bell? John. |
|
From: Antonino D. <ad...@po...> - 2003-02-17 19:22:56
|
On Mon, 2003-02-17 at 18:36, Geert Uytterhoeven wrote:
> > CONFIG_LOGO_POS_X="left|center|right" # or absolute ?
> > CONFIG_LOGO_POS_Y="top|center|bottom" # like X windows +110,+200 ?
Geert,
I was wondering how to implement positioning of the logo with the
current method of displaying it (by reserving screen space of height
"logo_lines"). This is not so nice to look at when we position the logo
in the center or the bottom.
So how about making the logo "float" above/obscure the text (ie,
overlay)? It's not difficult to implement since fbcon.c has "redraw"
versions of fbcon_bmove() and fbcon_clear(). All that needs to be done
is do a "scissors" test before an fb_imageblit().
Here's a trial implementation. The logo configuration has extra options
for the "overlay method" (CONFIG_LOGO_OVERLAY) and positioning of the
logo (top, bottom, left, right, center). The logo will always stay on
top while the underlying text is scrolling.
Attached is a diff. James' latest fbdev.diff and the series of patches
I submitted must be applied first.
Tony
diff -Naur linux-2.5.61-fbdev/drivers/video/console/fbcon.c linux-2.5.61/drivers/video/console/fbcon.c
--- linux-2.5.61-fbdev/drivers/video/console/fbcon.c 2003-02-17 17:57:37.000000000 +0000
+++ linux-2.5.61/drivers/video/console/fbcon.c 2003-02-17 18:39:56.000000000 +0000
@@ -106,9 +106,25 @@
struct display fb_display[MAX_NR_CONSOLES];
char con2fb_map[MAX_NR_CONSOLES];
+static struct fb_fillrect dim_logo;
static int logo_height;
static int logo_lines;
static int logo_shown = -1;
+
+#ifdef CONFIG_LOGO_OVERLAY
+static int logo_scissors = 1;
+static inline int get_logo_height(void)
+{
+ return 0;
+}
+#else
+static int logo_scissors = 0;
+static inline int get_logo_height(void)
+{
+ return (dim_logo.height);
+}
+#endif /* CONFIG_LOGO_OVERLAY */
+
/* Software scrollback */
int fbcon_softback_size = 32768;
static unsigned long softback_buf, softback_curr;
@@ -394,6 +410,27 @@
image.height = vc->vc_font.height;
image.depth = 0;
+ if (logo_scissors) {
+ int sx1 = dim_logo.dx;
+ int sx2 = dim_logo.dx + dim_logo.width;
+ int sy1 = dim_logo.dy;
+ int sy2 = dim_logo.dy + dim_logo.height;
+
+ image.width = vc->vc_font.width;
+ while (count--) {
+ if (!(image.dx + image.width > sx1 &&
+ image.dy + image.height > sy1 &&
+ image.dx < sx2 && image.dy < sy2)) {
+ image.data = p->fontdata +
+ (scr_readw(s) & charmask) * cellsize;
+ info->fbops->fb_imageblit(info, &image);
+ }
+ image.dx += vc->vc_font.width;
+ s++;
+ }
+ return;
+ }
+
if (!(vc->vc_font.width & 7)) {
unsigned int pitch, cnt, i, j, k;
unsigned int maxcnt = FB_PIXMAPSIZE/cellsize;
@@ -563,6 +600,19 @@
cursor.dest = dest;
cursor.rop = ROP_XOR;
+ if (logo_scissors) {
+ int sx1 = dim_logo.dx;
+ int sx2 = dim_logo.dx + dim_logo.width;
+ int sy1 = dim_logo.dy;
+ int sy2 = dim_logo.dy + dim_logo.height;
+
+ if (cursor.image.dx < sx2 &&
+ cursor.image.dy < sy2 &&
+ cursor.image.dx + cursor.image.width > sx1 &&
+ cursor.image.dy + cursor.image.height > sy1)
+ return;
+ }
+
if (info->fbops->fb_cursor)
info->fbops->fb_cursor(info, &cursor);
}
@@ -945,7 +995,8 @@
int cnt;
int step;
- logo_height = fb_prepare_logo(info);
+ fb_prepare_logo(&dim_logo, info);
+ logo_height = get_logo_height();
logo_lines = (logo_height + vc->vc_font.height - 1) /
vc->vc_font.height;
q = (unsigned short *) (vc->vc_origin +
@@ -1115,6 +1166,11 @@
redraw_cursor = 1;
}
+ if (logo_scissors) {
+ fbcon_redraw_clear(vc, p, sy, sx, height, width);
+ return;
+ }
+
/* Split blits that cross physical y_wrap boundary */
y_break = p->vrows - p->yscroll;
@@ -1151,12 +1207,23 @@
redraw_cursor = 1;
}
- image.fg_color = attr_fgcol(p, c);
- image.bg_color = attr_bgcol(p, c);
image.dx = xpos * vc->vc_font.width;
image.dy = real_y(p, ypos) * vc->vc_font.height;
image.width = vc->vc_font.width;
image.height = vc->vc_font.height;
+ if (logo_scissors) {
+ int sx1 = dim_logo.dx;
+ int sx2 = dim_logo.dx + dim_logo.width;
+ int sy1 = dim_logo.dy;
+ int sy2 = dim_logo.dy + dim_logo.height;
+
+ if (image.dx < sx2 && image.dy < sy2 &&
+ image.dx + image.width > sx1 &&
+ image.dy + image.height > sy1)
+ return;
+ }
+ image.fg_color = attr_fgcol(p, c);
+ image.bg_color = attr_bgcol(p, c);
image.depth = 1;
image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
@@ -1707,8 +1774,7 @@
redraw_up:
fbcon_redraw(vc, p, t, b - t - count,
count * vc->vc_cols);
- accel_clear(vc, p, real_y(p, b - count), 0,
- count, vc->vc_cols);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
scr_memsetw((unsigned short *) (vc->vc_origin +
vc->vc_size_row *
(b - count)),
@@ -1913,6 +1979,7 @@
&& conp2->vc_bottom == conp2->vc_rows)
conp2->vc_top = 0;
logo_shown = -1;
+ logo_scissors = 0;
}
if (info)
info->var.yoffset = p->yscroll = 0;
@@ -2476,6 +2543,7 @@
logo_lines * vc->vc_cols);
}
logo_shown = -1;
+ logo_scissors = 0;
}
fbcon_cursor(vc, CM_ERASE | CM_SOFTBACK);
fbcon_redraw_softback(vc, p, lines);
diff -Naur linux-2.5.61-fbdev/drivers/video/fbmem.c linux-2.5.61/drivers/video/fbmem.c
--- linux-2.5.61-fbdev/drivers/video/fbmem.c 2003-02-17 17:57:40.000000000 +0000
+++ linux-2.5.61/drivers/video/fbmem.c 2003-02-17 18:38:50.000000000 +0000
@@ -363,15 +363,15 @@
static int ofonly __initdata = 0;
#endif
+#ifdef CONFIG_LOGO
+#include <linux/linux_logo.h>
+
static inline unsigned safe_shift(unsigned d, int n)
{
return n < 0 ? d >> -n : d << n;
}
-#ifdef CONFIG_FB_LOGO
-#include <linux/linux_logo.h>
-
-static void __init fb_set_logocmap(struct fb_info *info,
+static void fb_set_logocmap(struct fb_info *info,
const struct linux_logo *logo)
{
struct fb_cmap palette_cmap;
@@ -435,7 +435,7 @@
}
}
-static void __init fb_set_logo_directpalette(struct fb_info *info,
+static void fb_set_logo_directpalette(struct fb_info *info,
const struct linux_logo *logo,
u32 *palette)
{
@@ -520,15 +520,72 @@
int needs_truepalette;
int needs_cmapreset;
int type;
+ int dx;
+ int dy;
const struct linux_logo *logo;
} fb_logo;
-int fb_prepare_logo(struct fb_info *info)
+#ifdef CONFIG_LOGO_CENTER
+static inline int get_logo_xpos(struct fb_info *info)
{
- memset(&fb_logo, 0, sizeof(struct logo_data));
+ return ((info->var.xres - fb_logo.logo->width)/2);
+}
+#elif CONFIG_LOGO_RIGHT
+static inline int get_logo_xpos(struct fb_info *info)
+{
+ return (info->var.xres - fb_logo.logo->width);
+}
+#else
+static inline int get_logo_xpos(struct fb_info *info)
+{
+ return (0);
+}
+#endif
- fb_logo.depth = info->var.bits_per_pixel;
+#ifdef CONFIG_LOGO_MIDDLE
+static inline int get_logo_ypos(struct fb_info *info)
+{
+ return ((info->var.yres - fb_logo.logo->height)/2);
+}
+#elif CONFIG_LOGO_BOTTOM
+static inline int get_logo_ypos(struct fb_info *info)
+{
+ return (info->var.yres - fb_logo.logo->height);
+}
+#else
+static inline int get_logo_ypos(struct fb_info *info)
+{
+ return (0);
+}
+#endif
+
+#ifdef CONFIG_LOGO_OVERLAY
+static inline void draw_logo(struct fb_image *image, struct fb_info *info)
+{
+ image->dx = fb_logo.dx;
+ info->fbops->fb_imageblit(info, image);
+}
+#else
+static inline void draw_logo(struct fb_image *image, struct fb_info *info)
+{
+ int xpos = fb_logo.dx;
+ int width = fb_logo.logo->width + 8;
+ int times = num_online_cpus(), x;
+ for (x = xpos; x < times * width &&
+ x <= info->var.xres-width; x += width) {
+ image->dx = x;
+ info->fbops->fb_imageblit(info, image);
+ }
+}
+#endif /* CONFIG_LOGO_OVERLAY */
+
+void fb_prepare_logo(struct fb_fillrect *rect, struct fb_info *info)
+{
+ memset(&fb_logo, 0, sizeof(struct logo_data));
+ memset(rect, 0, sizeof(struct fb_fillrect));
+ fb_logo.depth = info->var.bits_per_pixel;
+
switch (info->fix.visual) {
case FB_VISUAL_TRUECOLOR:
if (fb_logo.depth >= 8) {
@@ -587,9 +644,14 @@
fb_logo.logo = fb_find_logo(fb_logo.type);
if (!fb_logo.logo || fb_logo.logo->height > info->var.yres) {
fb_logo.logo = NULL;
- return 0;
+ return;
}
- return fb_logo.logo->height;
+ fb_logo.dx = get_logo_xpos(info);
+ fb_logo.dy = get_logo_ypos(info);
+ rect->dx = fb_logo.dx;
+ rect->dy = fb_logo.dy;
+ rect->width = fb_logo.logo->width;
+ rect->height = fb_logo.logo->height;
}
int fb_show_logo(struct fb_info *info)
@@ -597,7 +659,6 @@
unsigned char *fb = info->screen_base, *logo_new = NULL;
u32 *palette = NULL, *saved_pseudo_palette = NULL;
struct fb_image image;
- int x;
/* Return if the frame buffer is not mapped */
if (!fb || !info->fbops->fb_imageblit ||
@@ -642,14 +703,10 @@
image.width = fb_logo.logo->width;
image.height = fb_logo.logo->height;
- image.dy = 0;
+ image.dy = fb_logo.dy;
+
+ draw_logo(&image, info);
- for (x = 0; x < num_online_cpus() * (fb_logo.logo->width + 8) &&
- x <= info->var.xres-fb_logo.logo->width; x += (fb_logo.logo->width + 8)) {
- image.dx = x;
- info->fbops->fb_imageblit(info, &image);
- }
-
if (palette != NULL)
kfree(palette);
if (saved_pseudo_palette != NULL)
@@ -659,9 +716,10 @@
return fb_logo.logo->height;
}
#else
-int fb_prepare_logo(struct fb_info *info) { return 0; }
+void fb_prepare_logo(struct fb_fillrect *rect, struct fb_info *info)
+{ return 0; }
int fb_show_logo(struct fb_info *info) { return 0; }
-#endif /* CONFIG_FB_LOGO */
+#endif /* CONFIG_LOGO */
static int fbmem_read_proc(char *buf, char **start, off_t offset,
int len, int *eof, void *private)
diff -Naur linux-2.5.61-fbdev/drivers/video/logo/Kconfig linux-2.5.61/drivers/video/logo/Kconfig
--- linux-2.5.61-fbdev/drivers/video/logo/Kconfig 2003-02-17 18:10:15.000000000 +0000
+++ linux-2.5.61/drivers/video/logo/Kconfig 2003-02-17 18:08:22.000000000 +0000
@@ -8,6 +8,47 @@
bool "Bootup logo"
depends on FB || CONFIG_SGI_NEWPORT_CONSOLE
+config LOGO_OVERLAY
+ bool "Logo Overlay"
+ depends on LOGO && FB
+ ---help---
+ If you say Y, the logo will appear to "float" over
+ the primary display, obstructing the underlying
+ text.
+
+ If unsure, say N.
+choice
+ prompt "Horizontal Position"
+ depends on LOGO_OVERLAY
+ default LOGO_LEFT
+
+config LOGO_LEFT
+ bool "Left"
+
+config LOGO_CENTER
+ bool "Center"
+
+config LOGO_RIGHT
+ bool "Right"
+
+endchoice
+
+choice
+ prompt "Vertical Position"
+ depends on LOGO_OVERLAY
+ default LOGO_TOP
+
+config LOGO_TOP
+ bool "Top"
+
+config LOGO_MIDDLE
+ bool "Center"
+
+config LOGO_BOTTOM
+ bool "Bottom"
+
+endchoice
+
config LOGO_LINUX_MONO
bool "Black and white Linux logo"
depends on LOGO
diff -Naur linux-2.5.61-fbdev/include/linux/fb.h linux-2.5.61/include/linux/fb.h
--- linux-2.5.61-fbdev/include/linux/fb.h 2003-02-17 17:57:37.000000000 +0000
+++ linux-2.5.61/include/linux/fb.h 2003-02-17 18:05:01.000000000 +0000
@@ -462,7 +462,7 @@
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
extern int unregister_framebuffer(struct fb_info *fb_info);
-extern int fb_prepare_logo(struct fb_info *fb_info);
+extern void fb_prepare_logo(struct fb_fillrect *rect, struct fb_info *fb_info);
extern int fb_show_logo(struct fb_info *fb_info);
extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
|
|
From: Antonino D. <ad...@po...> - 2003-02-17 11:33:55
|
On Sat, 2003-02-15 at 23:11, Nico Schottelius wrote: > Hello! > > I retried using atyfb with 2.5.60: > Afterloading atyfb the only thing left is the cursor. > i don't see anything else anymore..i see the cursor moving, but that's all. > btw, i am using a laptop (means lcd)... > Strange. The good news is, if you see the cursor, it means the drawing functions is working since atyfb uses soft_cursor() which uses xxxfb_imageblit (the same function to draw the characters). That is perhaps fixable. > can somebody tell me whether playing around with fbset could make things > working? > You cannot use fbset anymore to change the window size, you have to use stty cols <value> rows <value>. That implies the driver can set the video mode independently from fbset. If it doesn't, you can use something like this: fbset 640x480-60 && stty cols 80 rows 30 Tony |
|
From: Antonino D. <ad...@po...> - 2003-02-17 11:33:53
|
On Sun, 2003-02-16 at 14:08, Antonino Daplas wrote: > 3. Fixed all drivers affected by the (image.depth == 0) is color > expansion. > Sigh, missed fbcon_putc(). Tony diff -Naur linux-2.5.61-fbdev/drivers/video/console/fbcon.c linux-2.5.61/drivers/video/console/fbcon.c --- linux-2.5.61-fbdev/drivers/video/console/fbcon.c 2003-02-17 10:48:33.000000000 +0000 +++ linux-2.5.61/drivers/video/console/fbcon.c 2003-02-17 10:49:13.000000000 +0000 @@ -1157,7 +1157,7 @@ image.dy = real_y(p, ypos) * vc->vc_font.height; image.width = vc->vc_font.width; image.height = vc->vc_font.height; - image.depth = 1; + image.depth = 0; image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width; info->fbops->fb_imageblit(info, &image); |
|
From: Antonino D. <ad...@po...> - 2003-02-17 11:33:52
|
On Mon, 2003-01-20 at 16:45, Antonino Daplas wrote:
> On Mon, 2003-01-20 at 02:56, Alexander Kern wrote:
>
> Yes, that will work, only if all your console have the same window
> size. If the size of one of your console is different, then these tests
> (x_diff > vc->vc_font.width || y_diff > vc->vc_font.height) will become
> true each time you switch consoles, so you'll be back with a yres of
> 1040 instead of 1050. The best solution is for the driver to round up
> to 1050 if 1040 is not acceptable.
>
> Still, its much better than the old one :-). If you don't mind, I'll
> add a few things to your patch:
>
> a. We do not need to activate the hardware immediately if there is a
> chance of failure.
>
> b. The xres/yres returned from fb_set_var() will be acceptable as long
> as the value is within a fontwidth/fontheight. This should fix hardware
> that only has a limited set of video modes.
>
Here's an incremental patch (linux-2.5.61 + James' latest fbdev.diff)
1. adjust display->vrows unconditionally during fbcon_resize(). This
should prevent console corruption when var->yres_virtual was changed
behind the back of the console, ie using fbset.
2. call fbcon_resize() as early as possible during fbcon_switch().
Tony
diff -Naur linux-2.5.61-fbdev/drivers/video/console/fbcon.c linux-2.5.61/drivers/video/console/fbcon.c
--- linux-2.5.61-fbdev/drivers/video/console/fbcon.c 2003-02-16 21:01:01.000000000 +0000
+++ linux-2.5.61/drivers/video/console/fbcon.c 2003-02-16 22:20:31.000000000 +0000
@@ -1879,8 +1879,8 @@
DPRINTK("resize now %ix%i\n", var.xres, var.yres);
var.activate = FB_ACTIVATE_NOW;
fb_set_var(&var, info);
- p->vrows = info->var.yres_virtual/fh;
}
+ p->vrows = info->var.yres_virtual/fh;
return 0;
}
@@ -1915,6 +1915,9 @@
}
if (info)
info->var.yoffset = p->yscroll = 0;
+
+ fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
+
switch (p->scrollmode & __SCROLL_YMASK) {
case __SCROLL_YWRAP:
scrollback_phys_max = p->vrows - vc->vc_rows;
@@ -1933,7 +1936,6 @@
info->currcon = unit;
- fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
update_var(unit, info);
fbcon_set_palette(vc, color_table);
|
|
From: Geert U. <ge...@li...> - 2003-02-17 10:45:20
|
On Sat, 15 Feb 2003, Nico Schottelius wrote:
> I retried using atyfb with 2.5.60:
> Afterloading atyfb the only thing left is the cursor.
> i don't see anything else anymore..i see the cursor moving, but that's all.
> btw, i am using a laptop (means lcd)...
>
> can somebody tell me whether playing around with fbset could make things
> working?
>
> Nico
>
> lspci:
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64)
>
> dmesg:
> atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 50 Mhz MCLK
> fb0: ATY Mach64 frame buffer device on PCI
Did older versions of atyfb work on this chip? I have the same one in my Vaio,
and so far it never worked with atyfb.
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: Geert U. <ge...@li...> - 2003-02-17 10:38:36
|
On Sat, 15 Feb 2003, Nico Schottelius wrote:
> I think if the patch and the features talked about are included in the
> kernel we'll have (names are not correct)
>
> CONFIG_LOGO=y/n
> CONFIG_LOGO_XRES=128
> CONFIG_LOGO_YRES=64
> CONFIG_LOGO_BPP=8
The 3 above are stored in struct linux_logo.
> CONFIG_LOGO_PATH="" # (/usr/src/linux/.../logo/tux.pnm)
> CONFIG_LOGO_POS_X="left|center|right" # or absolute ?
> CONFIG_LOGO_POS_Y="top|center|bottom" # like X windows +110,+200 ?
> CONFIG_LOGO_BGCOL=#ef0000 # depends on bpp of framebuffer...
I prefer to store the background color in struct linux_logo as well. And it
must be a palette index, not an RGB triplet, I think.
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: Nico S. <sch...@wd...> - 2003-02-17 10:37:24
|
Hello!
I retried using atyfb with 2.5.60:
Afterloading atyfb the only thing left is the cursor.
i don't see anything else anymore..i see the cursor moving, but that's all.
btw, i am using a laptop (means lcd)...
can somebody tell me whether playing around with fbset could make things
working?
Nico
lspci:
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobilit=
y AGP 2x (rev 64)
dmesg:
atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTA=
L, 230 MHz PLL, 50 Mhz MCLK
fb0: ATY Mach64 frame buffer device on PCI
flapp:~ # fbset -fb /dev/fb/0=20
mode "640x480-60"
# D: 25.075 MHz, H: 31.343 kHz, V: 59.701 Hz
geometry 640 480 640 13075 8
timings 39881 48 16 33 10 96 2
accel true
rgba 8/0,8/0,8/0,0/0
endmode
flapp:~ # fbset -fb /dev/fb/0 -xres 1024 -yres 768
dmesg:
not enough video RAM
flapp:~ # fbset -fb /dev/fb/0 -xres 800 -yres 600
dmesg:
not enough video RAM
--=20
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt ma=
ils
to mailing list!). If you don't know what pgp is visit www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)
|
|
From: Nico S. <sch...@wd...> - 2003-02-17 10:32:21
|
[snipped out patch discussion] I think if the patch and the features talked about are included in the kernel we'll have (names are not correct) CONFIG_LOGO=3Dy/n CONFIG_LOGO_XRES=3D128 CONFIG_LOGO_YRES=3D64 CONFIG_LOGO_BPP=3D8 CONFIG_LOGO_PATH=3D"" # (/usr/src/linux/.../logo/tux.pnm) CONFIG_LOGO_POS_X=3D"left|center|right" # or absolute ? CONFIG_LOGO_POS_Y=3D"top|center|bottom" # like X windows +110,+200 ? CONFIG_LOGO_BGCOL=3D#ef0000 # depends on bpp of framebuffer...= =20 I think this would be enough for all and possible implementable for the developers..or am I wrong ? Greetings, Nico |
|
From: Antonino D. <ad...@po...> - 2003-02-17 06:32:53
|
|
From: Adrian B. <bu...@fs...> - 2003-02-16 16:51:46
|
I get the following error while compiling 2.5.61:
<-- snip -->
...
ld -m elf_i386 -r -o drivers/video/built-in.o
drivers/video/console/built-in.o drivers/video/fbmem.o
drivers/video/fbmon.o drivers/video/fbcmap.o drivers/video/modedb.o
drivers/video/softcursor.o drivers/video/aty128fb.o
drivers/video/cfbfillrect.o drivers/video/cfbcopyarea.o
drivers/video/cfbimgblt.o drivers/video/radeonfb.o drivers/video/neofb.o
drivers/video/tdfxfb.o drivers/video/tridentfb.o drivers/video/vesafb.o
drivers/video/vga16fb.o drivers/video/vgastate.o
drivers/video/riva/built-in.o drivers/video/aty/built-in.o
drivers/video/i810/built-in.o drivers/video/hgafb.o drivers/video/vfb.o
drivers/video/sstfb.o
drivers/video/hgafb.o(.init.data+0x0): multiple definition of
`linux_logo_red'
drivers/video/fbmem.o(.init.data+0x0): first defined here
drivers/video/hgafb.o(.init.data+0xbb): multiple definition of
`linux_logo_green'
drivers/video/fbmem.o(.init.data+0xbb): first defined here
drivers/video/hgafb.o(.init.data+0x176): multiple definition of
`linux_logo_blue'
drivers/video/fbmem.o(.init.data+0x176): first defined here
drivers/video/hgafb.o(.init.data+0x231): multiple definition of
`linux_logo'
drivers/video/fbmem.o(.init.data+0x231): first defined here
drivers/video/hgafb.o(.init.data+0x1b31): multiple definition of
`linux_logo_bw'
drivers/video/fbmem.o(.init.data+0x1b31): first defined here
drivers/video/hgafb.o(.init.data+0x1e51): multiple definition of
`linux_logo16'
drivers/video/fbmem.o(.init.data+0x1e51): first defined here
make[2]: *** [drivers/video/built-in.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
|
|
From: James S. <jsi...@in...> - 2003-02-16 16:41:14
|
Applied.
On 16 Feb 2003, Antonino Daplas wrote:
> On Sun, 2003-02-16 at 14:08, Antonino Daplas wrote:
> > The attached patch (linux-2.5.61 + James' fbdev.diff) fixes the following:
> >
> > 1. compile error because of missing scripts/pmntologo.
> >
> > 2. Break up of fb_show_logo() to fb_prepare_logo()/fb_show_logo() to fix
> > weird "double drawing" or the "single draw, erase in a flash" of the
> > logo.
> >
> > 3. Fixed all drivers affected by the (image.depth == 0) is color
> > expansion.
> >
>
> Here's an incremental diff to protect logo drawing code with an
> #ifdef CONFIG_FB_LOGO
>
> Tony
>
> diff -Naur linux-2.5.61-fbdev/drivers/video/fbmem.c linux-2.5.61-ad/drivers/video/fbmem.c
> --- linux-2.5.61-fbdev/drivers/video/fbmem.c 2003-02-16 11:08:40.000000000 +0000
> +++ linux-2.5.61-ad/drivers/video/fbmem.c 2003-02-16 11:08:19.000000000 +0000
> @@ -41,7 +41,6 @@
> #include <asm/pgtable.h>
>
> #include <linux/fb.h>
> -#include <linux/linux_logo.h>
>
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE
> #include "console/fbcon.h"
> @@ -369,6 +368,9 @@
> return n < 0 ? d >> -n : d << n;
> }
>
> +#ifdef CONFIG_FB_LOGO
> +#include <linux/linux_logo.h>
> +
> static void __init fb_set_logocmap(struct fb_info *info,
> const struct linux_logo *logo)
> {
> @@ -656,6 +658,10 @@
> kfree(logo_new);
> return fb_logo.logo->height;
> }
> +#else
> +int fb_prepare_logo(struct fb_info *info) { return 0; }
> +int fb_show_logo(struct fb_info *info) { return 0; }
> +#endif /* CONFIG_FB_LOGO */
>
> static int fbmem_read_proc(char *buf, char **start, off_t offset,
> int len, int *eof, void *private)
>
>
|