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: James S. <jsi...@in...> - 2003-03-18 17:22:22
|
Applied.
On Tue, 18 Mar 2003, Geert Uytterhoeven wrote:
>
> If a colormap contains no transparency information, fb_set_cmap() calls
> fb_setcolreg() with trans = 0. This causes all CLUT entries to be fully
> transparent on hardware that does have transparency information in the CLUT
> registers.
>
> The following patch solves this problem by changing the default transparency
> from 0 (full transparent) to 0xffff (full opaque).
>
> The patch applies to both 2.4.20 and 2.5.65.
>
> --- linux/drivers/video/fbcmap.c.orig Mon Mar 5 09:29:30 2001
> +++ linux/drivers/video/fbcmap.c Mon Mar 17 17:39:59 2003
> @@ -271,7 +271,7 @@
> hred = *red;
> hgreen = *green;
> hblue = *blue;
> - htransp = transp ? *transp : 0;
> + htransp = transp ? *transp : 0xffff;
> } else {
> get_user(hred, red);
> get_user(hgreen, green);
> @@ -279,7 +279,7 @@
> if (transp)
> get_user(htransp, transp);
> else
> - htransp = 0;
> + htransp = 0xffff;
> }
> red++;
> green++;
>
> 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: James S. <jsi...@in...> - 2003-03-18 17:18:17
|
Linus, please do a bk pull http://fbdev.bkbits.net/fbdev-2.5 This will update the following files: Documentation/fb/clgenfb.txt | 89 drivers/video/aty128fb.c | 2353 ----- drivers/video/clgenfb.c | 3546 ------- drivers/video/clgenfb.h | 122 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/sis/325vtbl.h | 2335 ----- drivers/video/sis/sisfb.h | 153 drivers/video/sstfb.h | 355 include/asm-alpha/linux_logo.h | 27 include/asm-arm/linux_logo.h | 19 include/asm-i386/linux_logo.h | 27 include/asm-ia64/linux_logo.h | 28 include/asm-m68k/linux_logo.h | 924 -- include/asm-m68knommu/linux_logo.h | 13 include/asm-mips/linux_logo.h | 43 include/asm-mips/linux_logo_dec.h | 907 - include/asm-mips/linux_logo_sgi.h | 919 -- include/asm-mips64/linux_logo.h | 919 -- include/asm-parisc/linux_logo.h | 1438 --- include/asm-ppc64/linux_logo.h | 26 include/asm-sh/linux_logo.h | 1418 --- include/asm-sparc/linux_logo.h | 934 -- include/asm-sparc64/linux_logo.h | 934 -- include/asm-um/linux_logo.h | 6 include/asm-x86_64/linux_logo.h | 29 include/linux/sisfb.h | 169 Documentation/fb/cirrusfb.txt | 97 Documentation/fb/matroxfb.txt | 12 Documentation/fb/pvr2fb.txt | 2 Documentation/fb/sa1100fb.txt | 2 Documentation/fb/tgafb.txt | 2 Documentation/fb/vesafb.txt | 4 MAINTAINERS | 6 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 | 10 drivers/char/vt_ioctl.c | 13 drivers/video/Kconfig | 43 drivers/video/Makefile | 28 drivers/video/aty/Makefile | 2 drivers/video/aty/aty128fb.c | 2362 +++++ drivers/video/aty/atyfb.h | 133 drivers/video/aty/atyfb_base.c | 2124 ++-- drivers/video/aty/mach64_accel.c | 51 drivers/video/aty/mach64_ct.c | 846 + drivers/video/aty/mach64_cursor.c | 4 drivers/video/aty/mach64_gx.c | 18 drivers/video/aty/xlinit.c | 367 drivers/video/aty128fb.c | 162 drivers/video/cfbcopyarea.c | 218 drivers/video/cfbfillrect.c | 12 drivers/video/cfbimgblt.c | 255 drivers/video/cg6.c | 8 drivers/video/cirrusfb.c | 3546 +++++++ drivers/video/console/Kconfig | 65 drivers/video/console/fbcon.c | 1935 +--- drivers/video/console/fbcon.h | 48 drivers/video/console/newport_con.c | 69 drivers/video/console/vgacon.c | 884 - drivers/video/dnfb.c | 9 drivers/video/fbmem.c | 518 - drivers/video/fbmon.c | 10 drivers/video/ffb.c | 12 drivers/video/hgafb.c | 15 drivers/video/hitfb.c | 2 drivers/video/hpfb.c | 2 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/imsttfb.c | 1616 +-- drivers/video/logo/Kconfig | 75 drivers/video/logo/Makefile | 27 drivers/video/logo/clut_vga16.ppm | 20 drivers/video/logo/logo.c | 100 drivers/video/logo/logo_dec_clut224.ppm | 1604 +++ drivers/video/logo/logo_linux_clut224.ppm | 1604 +++ drivers/video/logo/logo_linux_mono.pbm | 203 drivers/video/logo/logo_linux_vga16.ppm | 1604 +++ drivers/video/logo/logo_mac_clut224.ppm | 1604 +++ drivers/video/logo/logo_parisc_clut224.ppm | 1604 +++ drivers/video/logo/logo_sgi_clut224.ppm | 1604 +++ drivers/video/logo/logo_sun_clut224.ppm | 1604 +++ drivers/video/logo/logo_superh_clut224.ppm | 1604 +++ drivers/video/logo/logo_superh_mono.pbm | 203 drivers/video/logo/logo_superh_vga16.ppm | 1604 +++ drivers/video/maxinefb.c | 2 drivers/video/modedb.c | 8 drivers/video/neofb.c | 113 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/q40fb.c | 1 drivers/video/radeonfb.c | 1 drivers/video/riva/fbdev.c | 405 drivers/video/riva/nv_driver.c | 156 drivers/video/riva/rivafb.h | 2 drivers/video/sgivwfb.c | 192 drivers/video/sis/300vtbl.h | 1555 ++- drivers/video/sis/310vtbl.h | 3373 +++++-- drivers/video/sis/init.c | 6345 ++++++++----- drivers/video/sis/init.h | 310 drivers/video/sis/init301.c |13192 ++++++++++++++++++----------- drivers/video/sis/init301.h | 529 - drivers/video/sis/initdef.h | 114 drivers/video/sis/oem300.h | 468 - drivers/video/sis/oem310.h | 239 drivers/video/sis/osdef.h | 13 drivers/video/sis/sis.h | 10 drivers/video/sis/sis_accel.c | 176 drivers/video/sis/sis_accel.h | 513 + drivers/video/sis/sis_main.c | 4743 ++++++---- drivers/video/sis/sis_main.h | 686 - drivers/video/sis/vgatypes.h | 26 drivers/video/sis/vstruct.h | 687 - drivers/video/skeletonfb.c | 6 drivers/video/softcursor.c | 180 drivers/video/sstfb.c | 16 drivers/video/tdfxfb.c | 31 drivers/video/tgafb.c | 18 drivers/video/tridentfb.c | 4 drivers/video/vga16fb.c | 145 include/linux/console_struct.h | 24 include/linux/fb.h | 53 include/linux/linux_logo.h | 1435 --- include/linux/vt_kern.h | 5 include/video/cirrus.h | 122 include/video/mach64.h | 75 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/sisfb.h | 191 include/video/sstfb.h | 355 include/video/vga.h | 23 scripts/Makefile | 4 scripts/pnmtologo |binary scripts/pnmtologo.c | 523 + 146 files changed, 51055 insertions(+), 38065 deletions(-) through these ChangeSets: <jsimmons@kozmo.(none)> (03/03/17 1.960) [FBCON]More optimizations. Removed moving struct display around. <jsi...@ma...> (03/03/15 1.955) [SIS FBDEV] Added Maintiner for SIS fbdev driver. [FBDEV] Updates to drivers ported to new api. <jsimmons@kozmo.(none)> (03/03/14 1.952) [FBCON] Cursor handling clean up. I nuked several static variables. <jsimmons@kozmo.(none)> (03/03/12 1.951) [FBCON] Killing off more cursor fields in struct display. Use what is in struct vc_data. <jsimmons@kozmo.(none)> (03/03/11 1.950) [CONSOLE] Nuked a few gloabl variables. Now that the console system supports different sized screens these gloabl variables are a bad idea. <jsimmons@kozmo.(none)> (03/03/10 1.947) [FBDEV] Menu cleanups. Added in depenedency needed. More cleanup in fbcon layer. <jsi...@ma...> (03/03/10 1.946) [FBDEV] Standardized using xxfb for setup strings. [FBDEV] Added proper syncing in pixmap code. [FBMON] Place limits on the DCLK clock. <jsimmons@kozmo.(none)> (03/03/09 1.943) [FBDEV] Enhanced data buffer management for drawing very large images. <jsi...@ma...> (03/03/07 1.936.1.10) [SIS FBDEV] More sisfb driver updates. [FBCON] Many fixes dealing with reszing the screen. <jsi...@ma...> (03/03/06 1.936.1.7) [SIS FBDEV] Make it compile as a module. <jsi...@ma...> (03/03/05 1.936.1.5) [TWIN TURBO FBDEV] Ported over to new api. <jsi...@ma...> (03/03/05 1.936.1.4) [FBCON] Help clear margins for modes where the resolution does quite fit the console size. <jsi...@ma...> (03/03/05 1.936.1.3) [FBDEV] Updates for the SIS fbdev driver to the new api. Removed poll. We wil use signals in the future instead. <jsi...@ma...> (03/03/03 1.936) [FBDEV] Accelerated functions pass in const structs. [ATY128 FBDEV] Gcc compile issue fixes. <jsi...@ma...> (03/03/03 1.935) [GENRIC ACCEL] Megred David Millers changes with my own. [FBCON] Small scrolling fix. <jsi...@ma...> (03/02/28 1.931) [FRAMEBUFFER]: cfbcopyarea accesses fb without using FB_{READ,WRITE}L. <jsi...@ma...> (03/02/27 1.929) [ATY FBDEV] Rage XL cards can now be booted with needed the BIOS :-) [FBCON] Moving to use ring buffers and DMA cards. <jsimmons@kozmo.(none)> (03/02/26 1.926) [ATY128 FBDEV] Moved aty128fb to aty/ and a few minor changes so aty128fb.c compiles with the newest compiler standards. <jsimmons@kozmo.(none)> (03/02/26 1.925) [FBCON] More struct display cleanup. Also killed off static buffer for accel_putcs. <jsi...@ma...> (03/02/24 1.923) [FBDEV] Minor fixes for logo code. [FBCON] More optimizations for drawing a string of characters. [VGACON] Using more code from video/vga.h. [VGA] Changes membase to unsigned long to support 64 bit platforms. <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.54.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.54.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.54.1) [GENERIC ACCELERATION] Fixed the generic image drawing function tfor 64 bit machines. [RIVA FBDEV] The cursor and imageblit functions have been fixed. As usually a normal diff is avaiable at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz It is against 2.5.65. Thank you. |
|
From: Jon S. <jon...@ya...> - 2003-03-18 17:08:02
|
Here is a description of how to control the shadow write protect for a SIS chipset. It is done by writing to PCI config space. There is a slim chance that this is a standard procedure. http://www.missl.cs.umd.edu/Projects/sebos/winint/index1.html When you copied to 8000 ot 9000, did you copy the ROM or the image at C000? I compared a dump of C000 to the ROM and they don't match. ATI may have overlaid some code during the init procedure. So I guess we are stuck with a user space daemon. Athlon-64 and IA64 will require the entire VM86 emulator. Last I checked the scitech emulator (ver8) han't implemented all of the instructions needed to run the ATI ROMs so it will need some work. How do the Transmeta tools work? Could we turn the ROMs into a C program and compile them again? Or use something like use an emulator to capture the reset sequence and then compile it for protected mode. I tried a couple of reverse engineering tools on the ROMs but I didn't get very far. I don't have access to the ATI Radeon documentation so it is hard for me to tell what is going on. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Geert U. <ge...@li...> - 2003-03-18 14:36:09
|
If a colormap contains no transparency information, fb_set_cmap() calls
fb_setcolreg() with trans = 0. This causes all CLUT entries to be fully
transparent on hardware that does have transparency information in the CLUT
registers.
The following patch solves this problem by changing the default transparency
from 0 (full transparent) to 0xffff (full opaque).
The patch applies to both 2.4.20 and 2.5.65.
--- linux/drivers/video/fbcmap.c.orig Mon Mar 5 09:29:30 2001
+++ linux/drivers/video/fbcmap.c Mon Mar 17 17:39:59 2003
@@ -271,7 +271,7 @@
hred = *red;
hgreen = *green;
hblue = *blue;
- htransp = transp ? *transp : 0;
+ htransp = transp ? *transp : 0xffff;
} else {
get_user(hred, red);
get_user(hgreen, green);
@@ -279,7 +279,7 @@
if (transp)
get_user(htransp, transp);
else
- htransp = 0;
+ htransp = 0xffff;
}
red++;
green++;
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: Antonino D. <ad...@po...> - 2003-03-18 10:03:39
|
On Tue, 2003-03-18 at 07:41, Jon Smirl wrote: > The C000 must be a PCI restriction, it was not there > during ISA days. It's not. It's IBM defining that VGA ROM should be at segment C000. > Plan A: how is C000:0 protected; does the chipset > hardware do it or is it done via the descriptor > tables? Descriptor tables can be fixed but there is > probably no general solution to chipset protection. > This is most probably chipset specific. > On the other hand, we may be lucky and the PCI spec > has specified a standard way for enabling write > protect. Could there be a BIOS INT xx function for > this? > If writable shadow ROM is to be supported, this has to be a specific implementation by the BIOS vendor. The standard (well, at least by Phoenix), does not define any BIOS service to do this. > Plan B is to copy the ROM to something like 8000 or > 9000. But the question there is, are VBIOS ROMs still > written to run position independent give the PCI C000 > requirement? It won't run. I already tried it. > > Plan C is go into VM86 mode during early boot and > remap the memory. That means go to protected mode first, then vm86, since vm86 can only be entered in protected mode. Personally, this is too much work. > > Plan D would be to get enough info to write the code > in protected mode. That's one plan. Emulate real-mode x86 while in real-mode/protected mode. However, x86emu requires a bunch of functions to parse and execute the opcodes. > > Are there more ways to do this? I've thought of 2 more things. The first is similar to Unreal Mode or Voodoo mode. This mode was employed by DOS game developers before the advent of protected mode DOS. They initialize the GDT to have a segment limit of 4G, go to protected mode, then immediately switch back to real mode. Upon return to real mode, they now have a segment:offset of 16:32 instead of 16:16. This is real mode with a 4 Gigabyte address limit. The variant of what I'm thinking is to do the same thing, but instead of adjusting the segment limit, adjust the base address of the GDT by an offset of 1 MB. Copy the memory contents from 0 - 1 MB and place them at 1 - 2 MB. Then, go to protected mode and back to real mode. Hopefully, if this works, I can now have an address space that starts at 0x100000 (1MB) but would still appear to everyone as starting at 0 effectively bypassing BIOS protection of expansion segments. I'm not sure if the above will work though, but should be easy enough to experiment on. But if anyone knows that it won't work, let me know. The other one is proposed by Kendall. Let's just have a userspace daemon that does all BIOS requests. The second is easy to implement since we already have the tools. Also, you can literally request for BIOS services anytime. Plus, it can even run on non-x86 using an emulator. The first may not work at all, and even if it does, will run only once. Also, it has to be coded in assembly and though I've done a lot of assembly before, it takes too long to code. But it does have the advantage of initializing adapters before the kernel loads, so we can have multiple framebuffers loaded at boot time. I'm still weighing which I should look first into. The second seems to be more useful, the first is much more interesting. What do you think? Tony |
|
From: Geert U. <ge...@li...> - 2003-03-18 09:09:01
|
On Mon, 17 Mar 2003, Jon Smirl wrote:
> Plan B is to copy the ROM to something like 8000 or
> 9000. But the question there is, are VBIOS ROMs still
> written to run position independent give the PCI C000
> requirement?
Probably. Some drivers are even compressed, since they don't fit in the ROM.
So they have to be decompressed elsewhere.
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: Marijn K. <ma...@gm...> - 2003-03-18 01:03:48
|
> I don't have a clue what could cause this problem... Perhaps anybody else > has any ideas? Hmmz, It looks like nobody has anuyy ideas what I could be doing wrong? I don't have any ideas... Marijn Kruisselbrink |
|
From: Jon S. <jon...@ya...> - 2003-03-18 00:00:53
|
This describes a BIOS INT for controlling the write protect on the shadow RAM. http://216.239.33.100/search?q=cache:ekBz42QrBngC:www.digital-logic.de/support/download/Treiber/misc/pcchip/c%26t/INT1F.TXT+shadow+BIOS+write+protect+int&hl=en&ie=UTF-8 Unsure if this is a standard BIOS feature. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Jon S. <jon...@ya...> - 2003-03-17 23:41:44
|
The C000 must be a PCI restriction, it was not there during ISA days. Plan A: how is C000:0 protected; does the chipset hardware do it or is it done via the descriptor tables? Descriptor tables can be fixed but there is probably no general solution to chipset protection. On the other hand, we may be lucky and the PCI spec has specified a standard way for enabling write protect. Could there be a BIOS INT xx function for this? Plan B is to copy the ROM to something like 8000 or 9000. But the question there is, are VBIOS ROMs still written to run position independent give the PCI C000 requirement? Plan C is go into VM86 mode during early boot and remap the memory. Plan D would be to get enough info to write the code in protected mode. Are there more ways to do this? I'll go poke around in google and see what I can come up with. Let me know if you come up with anything. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Antonino D. <ad...@po...> - 2003-03-17 22:33:26
|
On Tue, 2003-03-18 at 06:02, Jon Smirl wrote:
> The VBIOS should be position independent code and it
> will run at any 64K boundary. The PC bus spec simply
> says the video BIOS defaults to C000, it is not a
> requirement that it be located there. For example if
> you look at the aty128fb driver's find ROM routine
> your will notice that it is searching a broad address
> space for the ROM.
>
> I'm still not convinced that the memory at C000 is
> really hardware write protected, I think it is just
> RAM with a copy of the ROM in it. For example if I
> turn off BIOS shadowing my system will not boot. When
> debugging this I spent some time tracing into the ATI
> ROM and I was pretty sure that they are dependent on
> begin copied into RAM before begin run.
The PC-compatible specific set of steps for the system POST code
when handling each expansion ROM are:
1. Map and enable the expansion ROM to an unoccupied area of the
memory address space.
2. Find the proper image in the ROM and copy it from ROM into the
compatibility area of RAM (typically 0C0000h to 0DFFFFhh) using the
number of bytes specified by Initialization Size.
3. Disable the Expansion ROM Base Address register.
4. Leave the RAM area writable and call the INIT function.
5. Use the byte at offset 02h (which may have been modified) to
determine how much memory is used at runtime.
Before system boot, the POST code must make the RAM area containing
expansion ROM code read-only.
POST code must handle VGA devices with expansion ROMs in a special
way. The VGA device's expansion BIOS must be copied to 0C0000h.
VGA devices can be identified by examining the Class Code field in
the device's Configuration Space.
-- pg. 210 PCI Local Bus Specification Revision 2.2 December 18, 1998
>
> Do you have a DOS floppy around? Just boot into DOS,
> start debug and see if you can change C000:0.
Yes, it's unchangeable.
Tony
|
|
From: Jon S. <jon...@ya...> - 2003-03-17 22:02:16
|
The VBIOS should be position independent code and it will run at any 64K boundary. The PC bus spec simply says the video BIOS defaults to C000, it is not a requirement that it be located there. For example if you look at the aty128fb driver's find ROM routine your will notice that it is searching a broad address space for the ROM. I'm still not convinced that the memory at C000 is really hardware write protected, I think it is just RAM with a copy of the ROM in it. For example if I turn off BIOS shadowing my system will not boot. When debugging this I spent some time tracing into the ATI ROM and I was pretty sure that they are dependent on begin copied into RAM before begin run. Do you have a DOS floppy around? Just boot into DOS, start debug and see if you can change C000:0. If C000:0 is hardware write protected, there is nothing stopping the ROM from begin copied into 8000:0 or 9000:0 or whatever where there is guaranteed RAM. We would just need to temporarily get the kernel out of the way. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Antonino D. <ad...@po...> - 2003-03-17 21:42:28
|
On Tue, 2003-03-18 at 03:33, Jon Smirl wrote: > --- Antonino Daplas <ad...@po...> wrote: > > You're talking about other device's expansion ROM's. > > VGA ROM's, > > especially for the x86, are an exception and has to > > be always mapped at > > c000:0000. > > Reboot and add pci=rom (case sensitive) to your kernel > parameters. That will show you where the video ROMs > are really located. > > My x86 PC's boot video ROM is located at dd000000 not > C00000. C00000 is only a copy of the ROM in RAM. That's not the problem. I can easily grab a copy of the ROM through extended memory copy, but it cannot just run anywhere. The VBIOS code (as with other BIOS code) must run in real mode (address below 1MB) and VBIOS can only run when at C000:0000 (C000:0000 is in real-mode segmented addressing, it is C0000 when translated to a linear address). Check the definition of DEFAULT_V_BIOS in the code you sent me. > How is this write protection being achieved? Is it > done via manipulation of the processor descriptor > tables; if so just undo it. Possibly through some BIOS specific thing. Usually the BIOS places it somewhere where it cannot be reached, even by the OS. Tony |
|
From: Antonino D. <ad...@po...> - 2003-03-17 21:42:28
|
On Tue, 2003-03-18 at 02:22, Kendall Bennett wrote: > The other option is to use the x86emu BIOS emulator project. Then you > don't need to do any of this stuff and instead can warm boot all the > graphics controllers using the BIOS from the card (see the sample > 'warmboot' program included in the source code archives). The code is > presently 32-bit specific I believe, so you would have two choices for > running this from real mode - port the code to a 16-bit C compiler or > port it to run in 32-bit real mode. I assume you are probably thinking of > during the boot phase of GRUB or LILO, so at that point you will have > full control and should be able to execute 32-bit real mode code. You may Interesting, an x86 emulator while in real mode... This is probably worth a try. Thanks. Tony |
|
From: Jon S. <jon...@ya...> - 2003-03-17 19:33:39
|
--- Antonino Daplas <ad...@po...> wrote:
> You're talking about other device's expansion ROM's.
> VGA ROM's,
> especially for the x86, are an exception and has to
> be always mapped at
> c000:0000.
Reboot and add pci=rom (case sensitive) to your kernel
parameters. That will show you where the video ROMs
are really located.
My x86 PC's boot video ROM is located at dd000000 not
C00000. C00000 is only a copy of the ROM in RAM.
01:00.0 VGA compatible controller: ATI Technologies
Inc Radeon R250 If [Radeon 9
000] (rev 01) (prog-if 00 [VGA])
Subsystem: C.P. Technology Co. Ltd: Unknown
device 2039
Flags: stepping, 66Mhz, medium devsel, IRQ 5
Memory at d0000000 (32-bit, prefetchable)
[disabled] [size=64M]
I/O ports at c000 [disabled] [size=256]
Memory at de000000 (32-bit, non-prefetchable)
[disabled] [size=64K]
Expansion ROM at dd000000 [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
The ROM on my other video card is located here:
00:0b.0 VGA compatible controller: ATI Technologies
Inc Rage 128 PD/PRO TMDS (pr
og-if 00 [VGA])
Subsystem: ATI Technologies Inc Rage 128 AIW
Flags: bus master, stepping, medium devsel,
latency 32, IRQ 10
Memory at d8000000 (32-bit, prefetchable)
[size=64M]
I/O ports at e400 [size=256]
Memory at df000000 (32-bit, non-prefetchable)
[size=16K]
Expansion ROM at 20060000 [size=128K]
Capabilities: [5c] Power Management version 2
> Remember, ROM's are supposed to be read-only, so
> even if they are
> shadowed, the BIOS write protects it.
How is this write protection being achieved? Is it
done via manipulation of the processor descriptor
tables; if so just undo it.
=====
Jon Smirl
jon...@ya...
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
|
|
From: Kendall B. <Ken...@sc...> - 2003-03-17 18:22:37
|
Geert Uytterhoeven <ge...@li...> wrote: > > Download from: > > http://www.cs.helsinki.fi/u/amlaukka/vesafb/ > > Since the code used to be at a university webserver, you may want > to ask the sysadmin team of cs.helsinki.fi whether they have a > backup. Good point. Do you have an email contact there or should I just email them at postmaster or something? I will go dig around and see if I can find a contact. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ |
|
From: Kendall B. <Ken...@sc...> - 2003-03-17 18:22:37
|
Antonino Daplas <ad...@po...> wrote: > > A long time ago in early 2000, Aki M Laukkanen was a guy working on a > > VESA framebuffer console daemon for Linux. This driver was structured as > > a as a user land daemon that the kernel vesafb console driver would call > > back into once the system was up, allowing the userland VESA driver to > > use the vm86() service to change modes, program the palette and other > > useful things that can't be done by the basic VESA driver that uses a > > mode set previously by LILO or GRUB. > > That is a very neat project :-) It can also be expanded to > something not just the VESA driver will use, but as a general > interface whenever the BIOS services are to be needed. Yes, it could. It also doesn't need to be used just for VESA/BIOS services, but could be used to implement real mode fbconsole drivers using existing driver modules from XFree86 if desired. > BTW: I want to initialize multiple VGA adapters during the early > boot sequence. The machine will be in real mode, so there's no > such thing as copy-on-write. I'm pretty sure it's not possible, > but do you know of a way to disable the BIOS write protection of > the C000:0000 segment? I don't think it is possible to do this because the BIOS is in ROM on the graphics card. If the system BIOS is shadowing it (quite likely) then it would be possible, but you would need to know how to disable the write protection in the system chipset which is probably different for each motherboard. The other option is to use the x86emu BIOS emulator project. Then you don't need to do any of this stuff and instead can warm boot all the graphics controllers using the BIOS from the card (see the sample 'warmboot' program included in the source code archives). The code is presently 32-bit specific I believe, so you would have two choices for running this from real mode - port the code to a 16-bit C compiler or port it to run in 32-bit real mode. I assume you are probably thinking of during the boot phase of GRUB or LILO, so at that point you will have full control and should be able to execute 32-bit real mode code. You may even be able to put the machine into protected mode and run the code as 32-bit protected mode code also if needed (but you would need to then write your own protected mode kernel). The BIOS emulator code is available from: ftp://ftp.scitechsoft.com/devel/x86emu I think... Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ |
|
From: Geert U. <ge...@li...> - 2003-03-17 14:49:26
|
On 17 Mar 2003, Antonino Daplas wrote:
> On Mon, 2003-03-17 at 21:47, Geert Uytterhoeven wrote:
> > BTW, I just realized there's no need to distinguish between monochrome copy and
> > monochrome-to-color expansion. The monochrome logo code just has to write the
> > correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
> > bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).
> >
>
> I remember mentioning this to you before, and you said that there might
> be rare cases that fgcolor can be equal to bgcolor. However, using -1
> instead for bg_color/fg_color may work, at least for the current setup
> and only for monochrome, (except perhaps 32-bit monochrome, if there is
> such a thing)
No, you wanted to distinguish between monochrome expansion and color copy by
setting fb_image.[fb]gcolor to -1.
> I still prefer splitting fb_imageblit() into two though, and still keep
> image->depth for logo drawing only, to allow for future expansion.
OK.
> > > Do we still use the LUT?
> >
> > Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there
>
> Yes. Which also means logo drawing will also work for quirky drivers,
> and the upper layer will be finally totally independent of the low level
> drivers.
>
> > are enough number of colors). But since imageblit is done for the logo only,
> > doing the transform from LUT index to pixel value in imageblit is OK, I think.
> >
>
> Yes, I also prefer referring to the LUT whatever the format even for
> character drawing. I don't expect any noticeable performance penalty
> except for logo drawing. The way it's currently done is because,
> looking at all drivers, not one fills up the pseudo_palette when bpp <=
> 8.
There are some, that have RGB332 truecolor.
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: Antonino D. <ad...@po...> - 2003-03-17 14:28:11
|
On Mon, 2003-03-17 at 21:47, Geert Uytterhoeven wrote: > > IMHO always using an image depth of 8 is fine. That's a nice trade off between > genericity and easy access of image data. > > Except for monochrome, there I prefer a depth of 1, since doing 1->8 and 8->1 > in a row is a bit too wasteful. > An exception to the rule :-) Well, I guess if it will significantly benefit monochrome drivers... > BTW, I just realized there's no need to distinguish between monochrome copy and > monochrome-to-color expansion. The monochrome logo code just has to write the > correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of > bits = var.bits_per_pixel, so it works for 8-bit monochrome, too). > I remember mentioning this to you before, and you said that there might be rare cases that fgcolor can be equal to bgcolor. However, using -1 instead for bg_color/fg_color may work, at least for the current setup and only for monochrome, (except perhaps 32-bit monochrome, if there is such a thing) I still prefer splitting fb_imageblit() into two though, and still keep image->depth for logo drawing only, to allow for future expansion. . > > Do we still use the LUT? > > Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there Yes. Which also means logo drawing will also work for quirky drivers, and the upper layer will be finally totally independent of the low level drivers. > are enough number of colors). But since imageblit is done for the logo only, > doing the transform from LUT index to pixel value in imageblit is OK, I think. > Yes, I also prefer referring to the LUT whatever the format even for character drawing. I don't expect any noticeable performance penalty except for logo drawing. The way it's currently done is because, looking at all drivers, not one fills up the pseudo_palette when bpp <= 8. Tony |
|
From: Geert U. <ge...@li...> - 2003-03-17 13:50:06
|
On 17 Mar 2003, Antonino Daplas wrote:
> On Mon, 2003-03-17 at 20:25, Petr Vandrovec wrote:
> > On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> > >
> > > That depends... How do we draw the monochrome penguin? Using image->depth is 1
> > > or 8? The latter (current method) is slower, since we need to expand the
> > > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> > > driver afterwards.
> >
> > As far as I can see, it gets monochromatic logo and converts it to
> > 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
> > converts it back to 1bpp.
>
> Yes. That's the sacrifice for simplicity and consistency, low color
> depths sacrifice on speed, high color depth sacrifice on color range.
> The real beneficiary is 8-bit pseudo-pixel.
Indeed.
> Of course, there's always a choice:
>
> 1. allow support for non-monochrome expansion/reduction in
> cfb_imageblit(), ie input data is 4bpp and framebuffer format is 16 bpp,
> directcolor.
>
> 2. prepare all logo so image->depth matches framebuffer depth. This
> will require that fb_prepare_logo() has additional code to pack
> image->data properly
This moves code from the low-level driver to the high-level, and thus reduces
code duplication.
The disadvantage is that the conversion may be a waste of work, if the
resulting image data is not in the same format as the hardware uses (e.g. for
bitplanes).
> 3. Just add conditionals like:
>
> if depth == 1
> logo->data == logo_bw
> else if depth == 4
> logo->data == logo_4
> else if depth == 8
> logo->data == logo_8
> else
> prepare_logo_to_match_fb_depth
Don't forget about other depths. And the number of logo colors does not depend
on the color depth only, for visuals different from pseudocolor.
> For #2 and #3, what do we do when var->bits_per_pixel > 8? Do we still
> use image->depth=8?
IMHO always using an image depth of 8 is fine. That's a nice trade off between
genericity and easy access of image data.
Except for monochrome, there I prefer a depth of 1, since doing 1->8 and 8->1
in a row is a bit too wasteful.
BTW, I just realized there's no need to distinguish between monochrome copy and
monochrome-to-color expansion. The monochrome logo code just has to write the
correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).
> Do we still use the LUT?
Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there
are enough number of colors). But since imageblit is done for the logo only,
doing the transform from LUT index to pixel value in imageblit is OK, I think.
> 4. Go back to the 2.4 way of drawing the logo, let the upper layer do
> everything, and just directly memcopy the data to the framebuffer.
Ugh... This is much worse, since the logo drawing code has to know about all
possible frame buffer formats. In the current scheme, this is nicely hidden in
imageblit.
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: Antonino D. <ad...@po...> - 2003-03-17 13:05:39
|
On Mon, 2003-03-17 at 20:25, Petr Vandrovec wrote: > On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote: > > > > That depends... How do we draw the monochrome penguin? Using image->depth is 1 > > or 8? The latter (current method) is slower, since we need to expand the > > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev > > driver afterwards. > > As far as I can see, it gets monochromatic logo and converts it to > 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit > converts it back to 1bpp. > Yes. That's the sacrifice for simplicity and consistency, low color depths sacrifice on speed, high color depth sacrifice on color range. The real beneficiary is 8-bit pseudo-pixel. Of course, there's always a choice: 1. allow support for non-monochrome expansion/reduction in cfb_imageblit(), ie input data is 4bpp and framebuffer format is 16 bpp, directcolor. 2. prepare all logo so image->depth matches framebuffer depth. This will require that fb_prepare_logo() has additional code to pack image->data properly 3. Just add conditionals like: if depth == 1 logo->data == logo_bw else if depth == 4 logo->data == logo_4 else if depth == 8 logo->data == logo_8 else prepare_logo_to_match_fb_depth For #2 and #3, what do we do when var->bits_per_pixel > 8? Do we still use image->depth=8? Do we still use the LUT? 4. Go back to the 2.4 way of drawing the logo, let the upper layer do everything, and just directly memcopy the data to the framebuffer. > > And perhaps we may want to draw 32-bit ARGB images later? > > > > So I see the following possible valid values for image->depth: > > - 8 (logo with up to 256 colors and LUT) > > - optional 1 (monochrome logo, if we don't want to expand?) > > - optional 32 (ARGB image, dithering left to the driver?) > > I still do not understand 'if we don't want to expand'. This forces too > much knowledge on upper layer, as far as I can tell. I agree. Tony |
|
From: Antonino D. <ad...@po...> - 2003-03-17 13:05:34
|
On Mon, 2003-03-17 at 20:18, Geert Uytterhoeven wrote: > On 17 Mar 2003, Antonino Daplas wrote: > > On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote: > > > On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote: > > > > On 17 Mar 2003, Antonino Daplas wrote: > > > > > As Geert said, it's not just trivial, but logical to split fb_imageblit > > > > > into two. > > > > > > > > So, are we gonna split it? This will also make hardware acceleration support > > > > more clean. E.g. most sbus drivers do color expansion in hardware, and fall > > > > back to cfb_imageblit() for the logo. > > > > It's up to James, though I vote for it. And I don't think any driver > > has accelerated versions of fb_imageblit for the logo, since any > > performance gained is probably minimal and it will involve too much work > > for something that's going to be done only once. > > Wait until someone wants 256-color fonts ;-) When we do get that to that point, the entire interface will be revamped. Imagine passing 128 bytes to draw a single character. This is where Tile Blitting comes in. Tony |
|
From: Geert U. <ge...@li...> - 2003-03-17 12:42:51
|
On Mon, 17 Mar 2003, Petr Vandrovec wrote:
> On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> > That depends... How do we draw the monochrome penguin? Using image->depth is 1
> > or 8? The latter (current method) is slower, since we need to expand the
> > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> > driver afterwards.
>
> As far as I can see, it gets monochromatic logo and converts it to
> 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
> converts it back to 1bpp.
Yes, that's what I wrote above (current method).
> > And perhaps we may want to draw 32-bit ARGB images later?
> >
> > So I see the following possible valid values for image->depth:
> > - 8 (logo with up to 256 colors and LUT)
> > - optional 1 (monochrome logo, if we don't want to expand?)
> > - optional 32 (ARGB image, dithering left to the driver?)
>
> I still do not understand 'if we don't want to expand'. This forces too
> much knowledge on upper layer, as far as I can tell.
Color expansion => use fb_image.fg_color if bit == 1,
use fb_image.bg_color if bit == 0
No expansion => look up color in fb_image.cmap.
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: Petr V. <VAN...@vc...> - 2003-03-17 12:26:06
|
On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
>
> That depends... How do we draw the monochrome penguin? Using image->depth is 1
> or 8? The latter (current method) is slower, since we need to expand the
> monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> driver afterwards.
As far as I can see, it gets monochromatic logo and converts it to
8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
converts it back to 1bpp.
> And perhaps we may want to draw 32-bit ARGB images later?
>
> So I see the following possible valid values for image->depth:
> - 8 (logo with up to 256 colors and LUT)
> - optional 1 (monochrome logo, if we don't want to expand?)
> - optional 32 (ARGB image, dithering left to the driver?)
I still do not understand 'if we don't want to expand'. This forces too
much knowledge on upper layer, as far as I can tell.
Petr Vandrovec
|
|
From: Geert U. <ge...@li...> - 2003-03-17 12:20:04
|
On 17 Mar 2003, Antonino Daplas wrote:
> On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote:
> > On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
> > > On 17 Mar 2003, Antonino Daplas wrote:
> > > > As Geert said, it's not just trivial, but logical to split fb_imageblit
> > > > into two.
> > >
> > > So, are we gonna split it? This will also make hardware acceleration support
> > > more clean. E.g. most sbus drivers do color expansion in hardware, and fall
> > > back to cfb_imageblit() for the logo.
>
> It's up to James, though I vote for it. And I don't think any driver
> has accelerated versions of fb_imageblit for the logo, since any
> performance gained is probably minimal and it will involve too much work
> for something that's going to be done only once.
Wait until someone wants 256-color fonts ;-)
> > > > > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> > > > > while if depth != 0, then palette is in info->pseudo_palette ?
> > > >
> > > > Yes. You can also say that if image->depth != var->bits_per_pixel, do
> > > > color expansion or reduction, whatever the case may be.
> > >
> > > Hmmm... Note that image->depth can be larger than 8, while the image data is
> > > still 8-bit. This is an inconsistency.
>
> I was thinking that if image->depth=8 and var->bits_per_pixel=4, then
> the driver is in danger of going out of bounds when referring to the
> pseudo_palette. But I forgot that the fb_show_logo() takes care of
> avoiding that :-) And yes, current usage of image->depth is pretty
> inconsistent and basically useless.
>
> > image->depth for logo must change to 8. Or remove depth completely after
> > splitting imageblit to paintchar & paintlogo, as currently depth is
> > useless anyway: target format is defined by framebuffer layout, not
> > by image->depth, and source format is hardwired to the code.
>
> You're correct. If it's going to be split, image->depth becomes
> redundant.
That depends... How do we draw the monochrome penguin? Using image->depth is 1
or 8? The latter (current method) is slower, since we need to expand the
monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
driver afterwards.
And perhaps we may want to draw 32-bit ARGB images later?
So I see the following possible valid values for image->depth:
- 8 (logo with up to 256 colors and LUT)
- optional 1 (monochrome logo, if we don't want to expand?)
- optional 32 (ARGB image, dithering left to the driver?)
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: Antonino D. <ad...@po...> - 2003-03-17 12:10:46
|
On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote: > On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote: > > On 17 Mar 2003, Antonino Daplas wrote: > > > As Geert said, it's not just trivial, but logical to split fb_imageblit > > > into two. > > > > So, are we gonna split it? This will also make hardware acceleration support > > more clean. E.g. most sbus drivers do color expansion in hardware, and fall > > back to cfb_imageblit() for the logo. > > It's up to James, though I vote for it. And I don't think any driver has accelerated versions of fb_imageblit for the logo, since any performance gained is probably minimal and it will involve too much work for something that's going to be done only once. > > > > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol, > > > > while if depth != 0, then palette is in info->pseudo_palette ? > > > > > > Yes. You can also say that if image->depth != var->bits_per_pixel, do > > > color expansion or reduction, whatever the case may be. > > > > Hmmm... Note that image->depth can be larger than 8, while the image data is > > still 8-bit. This is an inconsistency. I was thinking that if image->depth=8 and var->bits_per_pixel=4, then the driver is in danger of going out of bounds when referring to the pseudo_palette. But I forgot that the fb_show_logo() takes care of avoiding that :-) And yes, current usage of image->depth is pretty inconsistent and basically useless. > > image->depth for logo must change to 8. Or remove depth completely after > splitting imageblit to paintchar & paintlogo, as currently depth is > useless anyway: target format is defined by framebuffer layout, not > by image->depth, and source format is hardwired to the code. You're correct. If it's going to be split, image->depth becomes redundant. Tony |
754 messages has been excluded from this view by a project administrator.
