* FBdev updates. @ 2003-02-20 1:09 James Simmons 2003-02-20 1:17 ` Jeff Garzik ` (2 more replies) 0 siblings, 3 replies; 50+ messages in thread From: James Simmons @ 2003-02-20 1:09 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Linux Fbdev development list 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: <jsimmons@maxwell.earthlink.net> (03/02/19 1.913.1.3) [FBDEEV] Need to add support to build pnmtologo. <jsimmons@maxwell.earthlink.net> (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. <jsimmons@maxwell.earthlink.net> (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. <jsimmons@maxwell.earthlink.net> (03/02/13 1.910) [LOGO] New better logo code. [FBDEV] Moved a few more header files. <jsimmons@maxwell.earthlink.net> (03/02/11 1.909) [FBCON] Removal of useless code. <jsimmons@maxwell.earthlink.net> (03/02/11 1.906) [ATY FBDEV] Reversed mobilty patches. They busted every other card. <jsimmons@maxwell.earthlink.net> (03/02/09 1.900) [ATY FBDEV] Updates to support Rage Mobility Chipstes. <jsimmons@maxwell.earthlink.net> (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. <jsimmons@maxwell.earthlink.net> (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. <jsimmons@maxwell.earthlink.net> (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. <jsimmons@maxwell.earthlink.net> (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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 1:09 FBdev updates James Simmons @ 2003-02-20 1:17 ` Jeff Garzik 2003-02-20 1:22 ` James Simmons 2003-02-20 15:02 ` Dave Jones 2003-02-20 15:10 ` FBdev updates Ivan Kokshaysky 2 siblings, 1 reply; 50+ messages in thread From: Jeff Garzik @ 2003-02-20 1:17 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 1:17 ` Jeff Garzik @ 2003-02-20 1:22 ` James Simmons 0 siblings, 0 replies; 50+ messages in thread From: James Simmons @ 2003-02-20 1:22 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List, Linux Fbdev development list > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 1:09 FBdev updates James Simmons 2003-02-20 1:17 ` Jeff Garzik @ 2003-02-20 15:02 ` Dave Jones 2003-02-20 15:07 ` James Simmons 2003-02-20 18:29 ` Petr Vandrovec 2003-02-20 15:10 ` FBdev updates Ivan Kokshaysky 2 siblings, 2 replies; 50+ messages in thread From: Dave Jones @ 2003-02-20 15:02 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 15:02 ` Dave Jones @ 2003-02-20 15:07 ` James Simmons 2003-02-20 18:29 ` Petr Vandrovec 1 sibling, 0 replies; 50+ messages in thread From: James Simmons @ 2003-02-20 15:07 UTC (permalink / raw) To: Dave Jones; +Cc: Linux Kernel Mailing List, Linux Fbdev development list > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 15:02 ` Dave Jones 2003-02-20 15:07 ` James Simmons @ 2003-02-20 18:29 ` Petr Vandrovec 2003-02-20 19:03 ` Jurriaan ` (2 more replies) 1 sibling, 3 replies; 50+ messages in thread From: Petr Vandrovec @ 2003-02-20 18:29 UTC (permalink / raw) To: Dave Jones, James Simmons, Linux Kernel Mailing List, Linux Fbdev development list 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 vandrove@vc.cvut.cz ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 18:29 ` Petr Vandrovec @ 2003-02-20 19:03 ` Jurriaan 2003-02-20 19:58 ` James Simmons 2003-02-21 0:24 ` Antonino Daplas 2 siblings, 0 replies; 50+ messages in thread From: Jurriaan @ 2003-02-20 19:03 UTC (permalink / raw) To: linux-kernel From: Petr Vandrovec <vandrove@vc.cvut.cz> Date: Thu, Feb 20, 2003 at 10:29:41AM -0800 > > 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. > For the record, this patch applies cleanly against 2.5.62, and I have a very nice 1600x1200 framebuffer here right now. With the 12x22 font, that means 133x54 - one of the biggest plusses of Linux for me. Jurriaan -- Perennial nuisance Charlton Heston pops up to declare that there are "too many people on the Earth as it is" and one realizes instantly that as president of the NRA, he is doing his best to correct that. Tom Shales, The Washington Post GNU/Linux 2.5.62 SMP/ReiserFS 2x2793 bogomips load av: 0.07 0.31 0.44 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 18:29 ` Petr Vandrovec 2003-02-20 19:03 ` Jurriaan @ 2003-02-20 19:58 ` James Simmons 2003-02-20 22:00 ` [Linux-fbdev-devel] " Antonino Daplas 2003-02-21 1:45 ` David S. Miller 2003-02-21 0:24 ` Antonino Daplas 2 siblings, 2 replies; 50+ messages in thread From: James Simmons @ 2003-02-20 19:58 UTC (permalink / raw) To: Petr Vandrovec Cc: Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-20 19:58 ` James Simmons @ 2003-02-20 22:00 ` Antonino Daplas 2003-02-21 9:09 ` Geert Uytterhoeven 2003-02-21 1:45 ` David S. Miller 1 sibling, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-02-20 22:00 UTC (permalink / raw) To: James Simmons Cc: Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-20 22:00 ` [Linux-fbdev-devel] " Antonino Daplas @ 2003-02-21 9:09 ` Geert Uytterhoeven 2003-02-21 10:46 ` Antonino Daplas 0 siblings, 1 reply; 50+ messages in thread From: Geert Uytterhoeven @ 2003-02-21 9:09 UTC (permalink / raw) To: Antonino Daplas Cc: James Simmons, Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list On 21 Feb 2003, Antonino Daplas wrote: > Note: I cannot test with 12x22 fonts in 2.4 because some/most drivers do > not support it. Which specific drivers are you talking about? All drivers for popular cards support fontwidth 12 (Matrox, ATI, nVidia, 3Dfx, Permedia, VESA, ...). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-21 9:09 ` Geert Uytterhoeven @ 2003-02-21 10:46 ` Antonino Daplas 2003-02-21 11:02 ` Geert Uytterhoeven 0 siblings, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-02-21 10:46 UTC (permalink / raw) To: Geert Uytterhoeven Cc: James Simmons, Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list On Fri, 2003-02-21 at 17:09, Geert Uytterhoeven wrote: > On 21 Feb 2003, Antonino Daplas wrote: > > Note: I cannot test with 12x22 fonts in 2.4 because some/most drivers do > > not support it. > > Which specific drivers are you talking about? All drivers for popular cards > support fontwidth 12 (Matrox, ATI, nVidia, 3Dfx, Permedia, VESA, ...). > > You're absolutely correct, I'm wondering why I thought that :-) Here's a benchmark for 12x22, and it's 2x slower than 8x16, 2.4.x or 2.5.x. Still, the 2.5.x version is slower than 2.4.x. Tony no accel scrollmode: yredraw font: 12x22 visual: packed pixels time cat /usr/src/linux/MAINTAINERS linux 2.4.20 bpp8 ---- real 0m4.984s user 0m0.000s sys 0m4.940s bpp16 ----- real 0m9.188s user 0m0.000s sys 0m9.090s bpp24 ----- real 0m14.574s user 0m0.000s sys 0m14.380s bpp32 ----- real 0m18.578s user 0m0.000s sys 0m18.390s linux-2.5.62 bpp8 ---- real 0m5.247s user 0m0.001s sys 0m5.245s bpp16 ----- real 0m9.640s user 0m0.001s sys 0m9.591s bpp24 ----- real 0m15.943s user 0m0.001s sys 0m15.944s bpp32 ----- real 0m19.653s user 0m0.002s sys 0m19.651s ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-21 10:46 ` Antonino Daplas @ 2003-02-21 11:02 ` Geert Uytterhoeven 0 siblings, 0 replies; 50+ messages in thread From: Geert Uytterhoeven @ 2003-02-21 11:02 UTC (permalink / raw) To: Antonino Daplas Cc: James Simmons, Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list On 21 Feb 2003, Antonino Daplas wrote: > On Fri, 2003-02-21 at 17:09, Geert Uytterhoeven wrote: > > On 21 Feb 2003, Antonino Daplas wrote: > > > Note: I cannot test with 12x22 fonts in 2.4 because some/most drivers do > > > not support it. > > > > Which specific drivers are you talking about? All drivers for popular cards > > support fontwidth 12 (Matrox, ATI, nVidia, 3Dfx, Permedia, VESA, ...). > > > You're absolutely correct, I'm wondering why I thought that :-) Here's > a benchmark for 12x22, and it's 2x slower than 8x16, 2.4.x or 2.5.x. > Still, the 2.5.x version is slower than 2.4.x. Because accel_putcs() falls back to individual character drawing if the fontwidth is not a multiple of 8. Using one fb_imageblit() for other fontwidths too would speed this up a lot (but needs some additional coding first). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 19:58 ` James Simmons 2003-02-20 22:00 ` [Linux-fbdev-devel] " Antonino Daplas @ 2003-02-21 1:45 ` David S. Miller 2003-02-21 9:04 ` [Linux-fbdev-devel] " Geert Uytterhoeven 1 sibling, 1 reply; 50+ messages in thread From: David S. Miller @ 2003-02-21 1:45 UTC (permalink / raw) To: James Simmons Cc: Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list On Thu, 2003-02-20 at 11:58, James Simmons wrote: > > (3) persuade me that I want to write matroxcon and forget about fbcon at all, or > > This is the best solution. And then we will have sbuscon as well, thus two places where putcs() is necessary. I don't understand, but I do hope that at some point it will be realized that maybe allowing fbcon to generically handle putcs() hardware is beneficial. I can dream. :-) ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-21 1:45 ` David S. Miller @ 2003-02-21 9:04 ` Geert Uytterhoeven 0 siblings, 0 replies; 50+ messages in thread From: Geert Uytterhoeven @ 2003-02-21 9:04 UTC (permalink / raw) To: David S. Miller Cc: James Simmons, Petr Vandrovec, Dave Jones, Linux Kernel Mailing List, Linux Fbdev development list On 20 Feb 2003, David S. Miller wrote: > On Thu, 2003-02-20 at 11:58, James Simmons wrote: > > > (3) persuade me that I want to write matroxcon and forget about fbcon at all, or > > > > This is the best solution. Huh? > And then we will have sbuscon as well, thus two places where > putcs() is necessary. > > I don't understand, but I do hope that at some point it will be > realized that maybe allowing fbcon to generically handle putcs() > hardware is beneficial. > > I can dream. :-) Don't worry, tile blitting will be there (eventually)... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-20 18:29 ` Petr Vandrovec 2003-02-20 19:03 ` Jurriaan 2003-02-20 19:58 ` James Simmons @ 2003-02-21 0:24 ` Antonino Daplas 2003-03-03 20:35 ` Petr Vandrovec 2 siblings, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-02-21 0:24 UTC (permalink / raw) To: Petr Vandrovec Cc: Dave Jones, James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Fri, 2003-02-21 at 02:29, Petr Vandrovec 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 (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. Petr, I submitted the Tile Blitting patch to James some time ago, it has tilefill, tilecopy and tileblit hooks. These hooks should eliminate the "multiply in fbcon, divide in driver" bottleneck. It should result in the same behavior as you would expect in the the 2.4 API, so you can use text mode with your matroxfb driver. These same hooks will also help optimize drawing if we need to use fonts like 12x22. Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-02-21 0:24 ` Antonino Daplas @ 2003-03-03 20:35 ` Petr Vandrovec 2003-03-03 21:25 ` Geert Uytterhoeven ` (4 more replies) 0 siblings, 5 replies; 50+ messages in thread From: Petr Vandrovec @ 2003-03-03 20:35 UTC (permalink / raw) To: Antonino Daplas Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote: > On Fri, 2003-02-21 at 02:29, Petr Vandrovec 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 (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. > > Petr, > > I submitted the Tile Blitting patch to James some time ago, it has > tilefill, tilecopy and tileblit hooks. These hooks should eliminate the > "multiply in fbcon, divide in driver" bottleneck. > > It should result in the same behavior as you would expect in the the 2.4 > API, so you can use text mode with your matroxfb driver. These same > hooks will also help optimize drawing if we need to use fonts like > 12x22. Hi, while waiting on these updates I updated matroxfb a bit (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz), so that it now uses fb_* for cfb modes, and putcs/... hooks for text mode. I have still dozen of changes in fbcon.c which I have to eliminate (mainly logo painting and cursor handling - for now I still use revc method, mainly because of I did not make into it yet). But main thing is that I'd like to apologize to James - character painting is much faster for 8x16 fonts under 2.5.x than it was under 2.4.x, 8bpp unaccelerated 8x16 under 2.5.x is even faster than accelerated under 2.4.x. Algorithm for obtaining times was same as described in Documentation/fb/matroxfb.txt, with two differences: (1) hardware is G550 in P4/1.6GHz, and (2) there was 30MBps video stream feed to secondary G550 head of G550 during 2.4.19-pre6 tests, so I made 2.5.x tests twice, once with fbtv running and once without. My main concern now is 12x22 font... Accelerator setup is so costly for each separate painted character that for 8bpp accelerated version is even slower than unaccelerated one :-( (and almost twice as slow when compared with 2.4.x). And one (or two...) generic questions: why is not pseudo_palette u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? And why we do not fill this pseudo_palette with i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp pseudocolor? This allowed me to remove couple of switches and tests from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect, but I did not changed these two in my benchmarks below). Best regards, Petr Vandrovec vandrove@vc.cvut.cz NOACCEL, 8x16 2.4.19+fbtv 2.5.63+fbtv 2.5.63 8bpp 10.02 6.96 5.62 16bpp 20.05 13.25 10.62 24bpp 30.03 19.05 15.13 32bpp 45.00 25.74 20.54 ACCEL, 8x16 2.4.19+fbtv 2.5.63+fbtv 2.5.63 8bpp 7.48 3.38 3.00 16bpp 7.50 3.38 3.01 24bpp 7.53 3.56 3.53 32bpp 8.95 4.37 4.33 NOACCEL, 12x22 2.4.19+fbtv 2.5.63+fbtv 2.5.63 8bpp 11.54 13.35 10.93 16bpp 20.00 22.02 18.03 24bpp 30.03 35.83 29.53 32bpp 40.12 44.48 36.75 ACCEL, 12x22 2.4.19+fbtv 2.5.63+fbtv 2.5.63 8bpp 8.57 14.87 12.90 16bpp 8.57 14.93 12.92 24bpp 8.56 15.13 13.10 32bpp 8.56 15.52 13.76 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-03 20:35 ` Petr Vandrovec @ 2003-03-03 21:25 ` Geert Uytterhoeven 2003-03-03 21:32 ` Antonino Daplas ` (3 subsequent siblings) 4 siblings, 0 replies; 50+ messages in thread From: Geert Uytterhoeven @ 2003-03-03 21:25 UTC (permalink / raw) To: Petr Vandrovec Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Mon, 3 Mar 2003, Petr Vandrovec wrote: > My main concern now is 12x22 font... Accelerator setup > is so costly for each separate painted character that for 8bpp > accelerated version is even slower than unaccelerated one :-( > (and almost twice as slow when compared with 2.4.x). Have you already tried Antonino's patches to use one imageblit for multiple characters with (fontwidth % 8) != 0? It should help. BTW, I still have to try it with amifb. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-03 20:35 ` Petr Vandrovec 2003-03-03 21:25 ` Geert Uytterhoeven @ 2003-03-03 21:32 ` Antonino Daplas 2003-03-05 20:23 ` James Simmons 2003-03-04 21:29 ` Jurriaan ` (2 subsequent siblings) 4 siblings, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-03-03 21:32 UTC (permalink / raw) To: Petr Vandrovec Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Tue, 2003-03-04 at 04:35, Petr Vandrovec wrote: > My main concern now is 12x22 font... Accelerator setup > is so costly for each separate painted character that for 8bpp > accelerated version is even slower than unaccelerated one :-( > (and almost twice as slow when compared with 2.4.x). I submitted a patch to James, which he already applied to his tree, that addresses this problem. It conglomerates the series of bitmaps into 1, so only one fb_imageblit is necessary. It should give faster painting than the original 2.5.x code, hopefully faster than 2.4.x code, but slower than 8x16 painting because of the additional packing. > > And one (or two...) generic questions: why is not pseudo_palette > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? Yes, all drivers should treat the pseudo_palette as u32* anyway, so why not change pseudo-palette from void* to u32*? > And why we do not fill this pseudo_palette with > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp > pseudocolor? This allowed me to remove couple of switches and tests > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect, > but I did not changed these two in my benchmarks below). I also agree for a different reason. Cards with unconventional formats (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not work with the current code. Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-03 21:32 ` Antonino Daplas @ 2003-03-05 20:23 ` James Simmons 2003-03-06 1:18 ` Antonino Daplas 0 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2003-03-05 20:23 UTC (permalink / raw) To: Antonino Daplas Cc: Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list > > And one (or two...) generic questions: why is not pseudo_palette > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? > > Yes, all drivers should treat the pseudo_palette as u32* anyway, so why > not change pseudo-palette from void* to u32*? See other email. > > And why we do not fill this pseudo_palette with > > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp > > pseudocolor? This allowed me to remove couple of switches and tests > > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect, > > but I did not changed these two in my benchmarks below). > > I also agree for a different reason. Cards with unconventional formats > (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not > work with the current code. Isn't that the job of setcolreg? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-05 20:23 ` James Simmons @ 2003-03-06 1:18 ` Antonino Daplas 0 siblings, 0 replies; 50+ messages in thread From: Antonino Daplas @ 2003-03-06 1:18 UTC (permalink / raw) To: James Simmons Cc: Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list On Thu, 2003-03-06 at 04:23, James Simmons wrote: > > > > And one (or two...) generic questions: why is not pseudo_palette > > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? > > > > Yes, all drivers should treat the pseudo_palette as u32* anyway, so why > > not change pseudo-palette from void* to u32*? > > See other email. > > > > And why we do not fill this pseudo_palette with > > > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp > > > pseudocolor? This allowed me to remove couple of switches and tests > > > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect, > > > but I did not changed these two in my benchmarks below). > > > > I also agree for a different reason. Cards with unconventional formats > > (such as monochrome at 8 bpp - 0 for black , 0xff for white) will not > > work with the current code. > > Isn't that the job of setcolreg? > setcolreg does that for directcolor and truecolor modes, because they're the only ones that uses the pseudo_palette. See all driver codes, the pseudo_palette is never initialized if in pseudo_color. The purpose of the pseudo_palette is to enable to write pixels to the framebuffer without knowing the color format at all. So, if you have monochrome, then black is 0 and white is 1. But for monochrome 8bpp, black is 0 and white is 0xff. fbcon will send 0's and 1's, thus 0 and 1 will be written to the framebuffer. If the drawing functions referred to the pseudo_palette, whatever the visual format, then 0 and 0xff will be written, as it should be. Tony > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Linux-fbdev-devel mailing list > Linux-fbdev-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-03 20:35 ` Petr Vandrovec 2003-03-03 21:25 ` Geert Uytterhoeven 2003-03-03 21:32 ` Antonino Daplas @ 2003-03-04 21:29 ` Jurriaan 2003-03-04 21:46 ` Petr Vandrovec 2003-03-09 21:29 ` Petr Vandrovec 2003-03-05 20:22 ` James Simmons 2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec 4 siblings, 2 replies; 50+ messages in thread From: Jurriaan @ 2003-03-04 21:29 UTC (permalink / raw) To: Petr Vandrovec Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List, Linux Fbdev development list From: Petr Vandrovec <vandrove@vc.cvut.cz> Date: Mon, Mar 03, 2003 at 09:35:00PM +0100 > On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote: > > On Fri, 2003-02-21 at 02:29, Petr Vandrovec 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 (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. > > > > Petr, > > > > I submitted the Tile Blitting patch to James some time ago, it has > > tilefill, tilecopy and tileblit hooks. These hooks should eliminate the > > "multiply in fbcon, divide in driver" bottleneck. > > > > It should result in the same behavior as you would expect in the the 2.4 > > API, so you can use text mode with your matroxfb driver. These same > > hooks will also help optimize drawing if we need to use fonts like > > 12x22. > > Hi, > while waiting on these updates I updated matroxfb a bit > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz), > so that it now uses fb_* for cfb modes, and putcs/... hooks for > text mode. There is a regression here: I boot my kernel like this: kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1 and have the following .config: CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_AGP=y CONFIG_AGP_VIA=y CONFIG_DRM=y CONFIG_DRM_MGA=y CONFIG_RAW_DRIVER=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_PCI_CONSOLE=y CONFIG_FBCON_ADVANCED=y CONFIG_FONT_SUN12x22=y CONFIG_FONTS=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_G450=y CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=y CONFIG_FB_MATROX_MAVEN=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_ACCEL=y matroxfb: Matrox G400 (AGP) detected matroxfb: MTRR's turned on matroxfb: 1600x1200x16bpp (virtual: 1600x5241) matroxfb: framebuffer at 0xD4000000, mapped to 0xe0805000, size 33554432 Console: switching to colour frame buffer device 133x54 fb0: MATROX VGA frame buffer device pty: 256 Unix98 ptys configured Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA Apollo Pro 266T chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 64M @ 0xd0000000 [drm] Initialized mga 3.1.0 20021029 on minor 0 I see a continuous strip of alternating blocks, of sub-character size, at the extreme right end of my screen. The colors seem linked to the color of the line with the cursor in some way. After leaving XFRee, a piece of chbg's background picture is shown for a short while, then the blocks return. Kind regards, Jurriaan -- But the threat of disapproval had terrified me No more my soul will I reveal Wargasm - Chameleon GNU/Linux 2.5.63 SMP/ReiserFS 1x2793 bogomips load av: 1.18 0.46 0.17 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-04 21:29 ` Jurriaan @ 2003-03-04 21:46 ` Petr Vandrovec 2003-03-09 21:29 ` Petr Vandrovec 1 sibling, 0 replies; 50+ messages in thread From: Petr Vandrovec @ 2003-03-04 21:46 UTC (permalink / raw) To: Jurriaan Cc: Antonino Daplas, James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Tue, Mar 04, 2003 at 10:29:06PM +0100, Jurriaan wrote: > > text mode. > > There is a regression here: I boot my kernel like this: > > kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1 > > I see a continuous strip of alternating blocks, of sub-character size, > at the extreme right end of my screen. The colors seem linked to the > color of the line with the cursor in some way. > > After leaving XFRee, a piece of chbg's background picture is shown for a > short while, then the blocks return. Reproduced. Try this (untested) (it is against clean tree, so you'll get some line offsets if you had applied my matroxfb patch). Or set xres to odd value, even values do not work... Petr Vandrovec --- linux/drivers/video/console/fbcon.c 2003-03-03 18:42:37.000000000 +0100 +++ linux/drivers/video/console/fbcon.c 2003-03-04 22:44:05.000000000 +0100 @@ -456,7 +456,7 @@ region.color = attr_bgcol_ec(p, vc); region.rop = ROP_COPY; - if (rw & !bottom_only) { + if (rw && !bottom_only) { region.dx = info->var.xoffset + rs; region.dy = 0; region.width = rw; ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-04 21:29 ` Jurriaan 2003-03-04 21:46 ` Petr Vandrovec @ 2003-03-09 21:29 ` Petr Vandrovec 2003-03-09 22:27 ` Antonino Daplas 2003-03-11 15:31 ` James Simmons 1 sibling, 2 replies; 50+ messages in thread From: Petr Vandrovec @ 2003-03-09 21:29 UTC (permalink / raw) To: jsimmons Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list Hi James, I tried to use fb_cursor and I have quite a lot problems with it: (1) it uses global variables for storing last cursor value - - but there is no global hardware, so after switching from one fbdev to another you can have cursor with wrong shape, wrong color and so on... (2) callback from timer for cursor blinking may set almost any FB_CUR_* bits. But in this case fb_cursor callback may be called from interrupt context, while accelerator is busy and so on... Did I miss some synchronization? Best for me would be disabling blinking code in fbcon completely: in VGA mode cursor blinks automatically, and in graphics mode more lightweight only 'flash' callback is more appropriate for me. But then there is problem with (3) cursor_undrawn... I have no idea how is this supposed to work if fbdev provides hardware cursor... And HZ/50 delay after putcs makes orientation on screen very complicated, as there is no cursor while new characters are appearing on screen. Thanks, Petr Vandrovec vandrove@vc.cvut.cz ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-09 21:29 ` Petr Vandrovec @ 2003-03-09 22:27 ` Antonino Daplas 2003-03-09 22:54 ` Petr Vandrovec 2003-03-11 15:31 ` James Simmons 1 sibling, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-03-09 22:27 UTC (permalink / raw) To: Petr Vandrovec Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote: > Hi James, > I tried to use fb_cursor and I have quite a lot problems with > it: > (1) it uses global variables for storing last cursor value - > - but there is no global hardware, so after switching from > one fbdev to another you can have cursor with wrong shape, > wrong color and so on... > (2) callback from timer for cursor blinking may set almost any > FB_CUR_* bits. But in this case fb_cursor callback may be > called from interrupt context, while accelerator is busy > and so on... Did I miss some synchronization? Best for me > would be disabling blinking code in fbcon completely: > in VGA mode cursor blinks automatically, and in graphics mode > more lightweight only 'flash' callback is more appropriate > for me. But then there is problem with I've also noticed problems with 1 and 2, and I submitted a patch to James that allocates resources on a per device basis instead of being global and statically allocated. This includes the cursor data structures, cursor timer/vbl interrupt service, putcs buffer, and optionally the softback buffer. The last is probably not very important for the present setup but may become useful later on (ie, multiple active consoles). As for synchronization, I was meaning to ask some pointers on that. The setup currently works like this: (blink) fbcon_cursor fbcon_vbl_handler (interrupt or timer) | | ----------------------- | accel_cursor | ----------------------- | | hardware soft_cursor accel_putcs accel_putc | | | -------------- ----------------- | fb_get_buffer_offset | xxxfb_imageblit | ------------------- | | hardware software I was thinking of placing locks in accel_cursor and fb_get_buffer_offset, but I'm not sure. > (3) cursor_undrawn... I have no idea how is this supposed to work In the present cursor api, the driver just needs to draw/undraw the cursor whether by software or hardware. So the problem here is with cursors that does it's own blinking, such as text modes. > if fbdev provides hardware cursor... And HZ/50 delay after > putcs makes orientation on screen very complicated, as there > is no cursor while new characters are appearing on screen. The delay is only for the blinking. After drawing a character/stream of characters, an explicit "draw cursor" command immediately follows (I think) via fbcon_cursor. Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-09 22:27 ` Antonino Daplas @ 2003-03-09 22:54 ` Petr Vandrovec 2003-03-09 23:44 ` Antonino Daplas 0 siblings, 1 reply; 50+ messages in thread From: Petr Vandrovec @ 2003-03-09 22:54 UTC (permalink / raw) To: Antonino Daplas Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote: > On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote: > > As for synchronization, I was meaning to ask some pointers on that. The > setup currently works like this: > > (blink) > fbcon_cursor fbcon_vbl_handler (interrupt or timer) > | | > ----------------------- > | > accel_cursor > | > ----------------------- > | | > hardware soft_cursor accel_putcs accel_putc > | | | > -------------- ----------------- > | > fb_get_buffer_offset > | > xxxfb_imageblit > | > ------------------- > | | > hardware software > > > I was thinking of placing locks in accel_cursor and > fb_get_buffer_offset, but I'm not sure. Maybe just auditing code is enough: cursor_on should be zero while we are inside accel_putc/putcs (or inside any other fb function), and if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making sure that fbcon_vbl_handler is not running on other CPU while we set cursor_on = 0 should be enough. > > if fbdev provides hardware cursor... And HZ/50 delay after > > putcs makes orientation on screen very complicated, as there > > is no cursor while new characters are appearing on screen. > > The delay is only for the blinking. After drawing a character/stream of > characters, an explicit "draw cursor" command immediately follows (I > think) via fbcon_cursor. Why we schedule cursor painting at all then? While we are inside putcs, we cannot paint cursor anyway (as we are busy with painting characters at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval anyway (so you see cursor while you type characters, and not like Solaris where cursor appears after you stop typing characters) (unfortunately when I tried to verify how it behaves on secondary head of matrox (which does not have hardware cursor), I made a typo and ... Unable to handle kernel NULL pointer dereference at virtual address 00000196 printing eip: c02f9258 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0060:[<c02f9258>] Tainted: PFS EFLAGS: 00010202 EIP is at fb_open+0x28/0xf0 eax: c6ed2c30 ebx: 00000020 ecx: 00000001 edx: c04848e0 esi: 00000002 edi: 00000000 ebp: c6ed2c30 esp: c4bb3f18 ds: 007b es: 007b ss: 0068 Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940) Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4 dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30 c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830 Call Trace: [<c01669ea>] chrdev_open+0xaa/0x110 [<c01435e3>] file_ra_state_init+0x23/0x40 [<c015af91>] dentry_open+0x1d1/0x1f0 [<c015adb7>] filp_open+0x67/0x70 [<c015b26b>] sys_open+0x5b/0x90 [<c0109983>] syscall_call+0x7/0xb Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0 so I'll have to check it tomorrow on real dualhead system...) Petr Vandrovec vandrove@vc.cvut.cz ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-09 22:54 ` Petr Vandrovec @ 2003-03-09 23:44 ` Antonino Daplas 0 siblings, 0 replies; 50+ messages in thread From: Antonino Daplas @ 2003-03-09 23:44 UTC (permalink / raw) To: Petr Vandrovec Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Mon, 2003-03-10 at 06:54, Petr Vandrovec wrote: > On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote: > > On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote: > > > > As for synchronization, I was meaning to ask some pointers on that. The > > setup currently works like this: > > > > (blink) > > fbcon_cursor fbcon_vbl_handler (interrupt or timer) > > | | > > ----------------------- > > | > > accel_cursor > > | > > ----------------------- > > | | > > hardware soft_cursor accel_putcs accel_putc > > | | | > > -------------- ----------------- > > | > > fb_get_buffer_offset > > | > > xxxfb_imageblit > > | > > ------------------- > > | | > > hardware software > > > > > > I was thinking of placing locks in accel_cursor and > > fb_get_buffer_offset, but I'm not sure. > > Maybe just auditing code is enough: cursor_on should be zero while > we are inside accel_putc/putcs (or inside any other fb function), and > if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making > sure that fbcon_vbl_handler is not running on other CPU while we set > cursor_on = 0 should be enough. I think that's what happens. cursor_on is set to 0 at the beginning of fbcon_cursor(), and it remains 0 until the next fbcon_cursor() is CM_DRAW or CM_MOVE. And while cursor_on is 0, fbcon_vbl_handler just exits immediately. Yes, it's basically the code in 2.4, but instead of using revc, it uses imageblit, and instead of allowing the drivers to do the blinking, fbcon does it entirely, whether a hardware or software cursor method is installed. > > > > if fbdev provides hardware cursor... And HZ/50 delay after > > > putcs makes orientation on screen very complicated, as there > > > is no cursor while new characters are appearing on screen. > > > > The delay is only for the blinking. After drawing a character/stream of > > characters, an explicit "draw cursor" command immediately follows (I > > think) via fbcon_cursor. > > Why we schedule cursor painting at all then? While we are inside putcs, > we cannot paint cursor anyway (as we are busy with painting characters I don't think any cursor painting is done while doing putcs, if the CM_ERASE, putc/putcs, CM_DRAW/CM_MOVE sequence is followed. Note that I haven't verified if that particular sequence is followed, I just assume the console layer does. Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-09 21:29 ` Petr Vandrovec 2003-03-09 22:27 ` Antonino Daplas @ 2003-03-11 15:31 ` James Simmons 1 sibling, 0 replies; 50+ messages in thread From: James Simmons @ 2003-03-11 15:31 UTC (permalink / raw) To: Petr Vandrovec Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list > Hi James, > I tried to use fb_cursor and I have quite a lot problems with > it: I'm working on the code today. I just finished the final touchs on the pixmap buffer code. The next step is to make the pixmaps have flag for static data versus dynamic data. You can then use fastfonst with static buffer. This comes with the tile code. But first the cursor code today. P.S You can grab my latest work on the matroxfb driver at http://phoenix.infradead.org/~jsimmons/matroxfb.diff.gz ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-03 20:35 ` Petr Vandrovec ` (2 preceding siblings ...) 2003-03-04 21:29 ` Jurriaan @ 2003-03-05 20:22 ` James Simmons 2003-03-06 7:35 ` Sven Luther 2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec 4 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2003-03-05 20:22 UTC (permalink / raw) To: Petr Vandrovec Cc: Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list > Hi, > while waiting on these updates I updated matroxfb a bit > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz), > so that it now uses fb_* for cfb modes, and putcs/... hooks for > text mode. I have still dozen of changes in fbcon.c which I have > to eliminate (mainly logo painting and cursor handling - for now > I still use revc method, mainly because of I did not make into it yet). I grabbed your latest patch and started to merge it with my latest work on the matrox driver. As soon as I'm done merging my matrox changes I will send you a patch right away. > My main concern now is 12x22 font... Accelerator setup > is so costly for each separate painted character that for 8bpp > accelerated version is even slower than unaccelerated one :-( > (and almost twice as slow when compared with 2.4.x). Try the latest patch I released. > And one (or two...) generic questions: why is not pseudo_palette > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? pseudo_palette was originally designed to be a pointer to some kind of data for color register programming. For example many PPC graphics cards have a color register region. Now you could have that point to pseudo_palette. Note pseudo_palette is only visiable in fbmem.c for the logo drawing code. Personally I liek to see that hidden. > And why we do not fill this pseudo_palette with > i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp > pseudocolor? This allowed me to remove couple of switches and tests > from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect, > but I did not changed these two in my benchmarks below). ??? Does your accel engine require these kinds of values? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-05 20:22 ` James Simmons @ 2003-03-06 7:35 ` Sven Luther 2003-03-06 8:05 ` Antonino Daplas 0 siblings, 1 reply; 50+ messages in thread From: Sven Luther @ 2003-03-06 7:35 UTC (permalink / raw) To: James Simmons Cc: Petr Vandrovec, Antonino Daplas, Linux Kernel Mailing List, Linux Fbdev development list On Wed, Mar 05, 2003 at 08:22:26PM +0000, James Simmons wrote: > > > Hi, > > while waiting on these updates I updated matroxfb a bit > > (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz), > > so that it now uses fb_* for cfb modes, and putcs/... hooks for > > text mode. I have still dozen of changes in fbcon.c which I have > > to eliminate (mainly logo painting and cursor handling - for now > > I still use revc method, mainly because of I did not make into it yet). > > I grabbed your latest patch and started to merge it with my latest work on > the matrox driver. As soon as I'm done merging my matrox changes I will > send you a patch right away. > > > My main concern now is 12x22 font... Accelerator setup > > is so costly for each separate painted character that for 8bpp > > accelerated version is even slower than unaccelerated one :-( > > (and almost twice as slow when compared with 2.4.x). > > Try the latest patch I released. > > > And one (or two...) generic questions: why is not pseudo_palette > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? > > pseudo_palette was originally designed to be a pointer to some kind of > data for color register programming. For example many PPC graphics cards > have a color register region. Now you could have that point to Does this correspond to the LUT i have in my boards ? BTW, what is the point in having a pseudo_palette if you can store the colors in the onchip LUT table. Friendly, Sven Luther ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-06 7:35 ` Sven Luther @ 2003-03-06 8:05 ` Antonino Daplas 2003-03-06 8:25 ` Sven Luther 0 siblings, 1 reply; 50+ messages in thread From: Antonino Daplas @ 2003-03-06 8:05 UTC (permalink / raw) To: Sven Luther Cc: James Simmons, Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list On Thu, 2003-03-06 at 15:35, Sven Luther wrote: > > > > > And one (or two...) generic questions: why is not pseudo_palette > > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? > > > > pseudo_palette was originally designed to be a pointer to some kind of > > data for color register programming. For example many PPC graphics cards > > have a color register region. Now you could have that point to > > Does this correspond to the LUT i have in my boards ? > > BTW, what is the point in having a pseudo_palette if you can store > the colors in the onchip LUT table. > The hardware clut typically stores each color channel separately. In software terms, this is akin to struct fb_cmap. The pseudo_palette, on the other hand, is a pixel LUT, the contents of which can be directly written to the framebuffer without it ever knowing the format at all, ie it does not matter if it's RGB or YUV. This makes the upper layer independent of the low-lever driver (at least in terms of colorspace formats). Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] Re: FBdev updates. 2003-03-06 8:05 ` Antonino Daplas @ 2003-03-06 8:25 ` Sven Luther 0 siblings, 0 replies; 50+ messages in thread From: Sven Luther @ 2003-03-06 8:25 UTC (permalink / raw) To: Antonino Daplas Cc: Sven Luther, James Simmons, Petr Vandrovec, Linux Kernel Mailing List, Linux Fbdev development list On Thu, Mar 06, 2003 at 04:05:32PM +0800, Antonino Daplas wrote: > On Thu, 2003-03-06 at 15:35, Sven Luther wrote: > > > > > > > And one (or two...) generic questions: why is not pseudo_palette > > > > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ? > > > > > > pseudo_palette was originally designed to be a pointer to some kind of > > > data for color register programming. For example many PPC graphics cards > > > have a color register region. Now you could have that point to > > > > Does this correspond to the LUT i have in my boards ? > > > > BTW, what is the point in having a pseudo_palette if you can store > > the colors in the onchip LUT table. > > > > The hardware clut typically stores each color channel separately. In > software terms, this is akin to struct fb_cmap. The pseudo_palette, on > the other hand, is a pixel LUT, the contents of which can be directly > written to the framebuffer without it ever knowing the format at all, ie > it does not matter if it's RGB or YUV. This makes the upper layer > independent of the low-lever driver (at least in terms of colorspace > formats). Ok, thanks, ... Friendly, Sven Luther ^ permalink raw reply [flat|nested] 50+ messages in thread
* 2.5.66 fbdev performance (was Re: Re: FBdev updates) 2003-03-03 20:35 ` Petr Vandrovec ` (3 preceding siblings ...) 2003-03-05 20:22 ` James Simmons @ 2003-03-28 14:19 ` Petr Vandrovec 2003-03-28 18:50 ` [Linux-fbdev-devel] " Antonino Daplas 4 siblings, 1 reply; 50+ messages in thread From: Petr Vandrovec @ 2003-03-28 14:19 UTC (permalink / raw) To: Antonino Daplas Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list Hello, I see a problem with new pixmap based code... There is 25% slowdown for 8x16 8bpp videomode after upgrading from 2.5.63 to 2.5.66 :-( Setup as usual, 1024x768, 100Hz, secondary head doing nothing (i.e. no fbtv...), CPU doing nothing except running this test. P4 1.6GHz, MGA G550. Shown value is system time in seconds needed to repaint screen 1000 times (avg. from 3 tests) (you can treat it as time in milliseconds needed to repaint screen once). Although speedup for 12x22 font is very nice, it looks to me that we paid too much for it. Problem is in the new pixmap handling, especially pixbuf.output - so now instead of memcpy we call some function for copying each byte from font to temporary buffer. As you can see, "constant" portion of time, independent of color depth, increased by 1sec for unaccelerated and by 0.75sec for accelerated putcs. It is 5% to 25% slowdown (5% for 32bpp unaccelerated, 25% for 8bpp accelerated). And while we are still faster than 2.4.x, we were even better... Petr NOACCEL, 8x16 2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66 8bpp 10.02 6.96 5.62 6.62 16bpp 20.05 13.25 10.62 11.63 24bpp 30.03 19.05 15.13 16.07 32bpp 45.00 25.74 20.54 21.62 ACCEL, 8x16 2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66 8bpp 7.48 3.38 3.00 3.75 16bpp 7.50 3.38 3.01 3.76 24bpp 7.53 3.56 3.53 4.23 32bpp 8.95 4.37 4.33 5.05 NOACCEL, 12x22 2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66 8bpp 11.54 13.35 10.93 8.96 16bpp 20.00 22.02 18.03 13.61 24bpp 30.03 35.83 29.53 18.07 32bpp 40.12 44.48 36.75 23.22 ACCEL, 12x22 2.4.19+fbtv 2.5.63+fbtv 2.5.63 2.5.66 8bpp 8.57 14.87 12.90 5.72 16bpp 8.57 14.93 12.92 5.72 24bpp 8.56 15.13 13.10 6.20 32bpp 8.56 15.52 13.76 6.98 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Linux-fbdev-devel] 2.5.66 fbdev performance (was Re: Re: FBdev updates) 2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec @ 2003-03-28 18:50 ` Antonino Daplas 0 siblings, 0 replies; 50+ messages in thread From: Antonino Daplas @ 2003-03-28 18:50 UTC (permalink / raw) To: Petr Vandrovec Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Fri, 2003-03-28 at 22:19, Petr Vandrovec wrote: > > Problem is in the new pixmap handling, especially > pixbuf.output - so now instead of memcpy we > call some function for copying each byte from > font to temporary buffer. As you can see, > "constant" portion of time, independent of > color depth, increased by 1sec for unaccelerated > and by 0.75sec for accelerated putcs. > It is 5% to 25% slowdown (5% for 32bpp unaccelerated, > 25% for 8bpp accelerated). > Actually, the slowdown is caused not just by the overhead of the read/write methods, but also due to the extra work padding and aligning the bitmaps according to requirements of the hardware. This was because James wanted support for buffers located not just in system memory but also graphics/dma memory. The result is that unaccelerated imageblit will slow down while properly written accelerated imageblit will experience some speed up (not much, probably around 5%). We can: 1. partially reverse the code so it behaves similarly to 2.5.63. Support for writing to graphics/dma memory will go away. 2. split the code path: one will go to the '2.5.63' path, the other will go to the '2.5.66' path, depending on the setting of info->pixmap. 3. keep the code as is Personally, I prefer #1, but it's up to James/Geert. Tony ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBdev updates. 2003-02-20 1:09 FBdev updates James Simmons 2003-02-20 1:17 ` Jeff Garzik 2003-02-20 15:02 ` Dave Jones @ 2003-02-20 15:10 ` Ivan Kokshaysky 2 siblings, 0 replies; 50+ messages in thread From: Ivan Kokshaysky @ 2003-02-20 15:10 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote: > <jsimmons@maxwell.earthlink.net> (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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* FBDEV updates. @ 2003-08-14 19:54 James Simmons 2003-08-14 20:36 ` Otto Solares 2003-08-16 6:01 ` Sven Schnelle 0 siblings, 2 replies; 50+ messages in thread From: James Simmons @ 2003-08-14 19:54 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Linux Fbdev development list Hi folks!! Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out and tell me your results. I like to do a code drop soon. http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz bk pull http://fbdev.bkbits.net/fbdev-2.6 This will update the following files: Documentation/fb/neofb.txt | 27 MAINTAINERS | 5 drivers/char/vt_ioctl.c | 12 drivers/video/Kconfig | 100 drivers/video/Makefile | 9 drivers/video/asiliantfb.c | 619 +++ drivers/video/aty/Makefile | 1 drivers/video/cfbimgblt.c | 2 drivers/video/chipsfb.c | 4 drivers/video/console/Makefile | 29 drivers/video/console/fbcon.c | 369 - drivers/video/console/fbcon.h | 2 drivers/video/controlfb.c | 10 drivers/video/epson1355fb.c | 967 ++-- drivers/video/fbmem.c | 116 drivers/video/g364fb.c | 78 drivers/video/i810/Makefile | 7 drivers/video/imsttfb.c | 2 drivers/video/logo/Makefile | 15 drivers/video/logo/logo.c | 5 drivers/video/macfb.c | 34 drivers/video/neofb.c | 338 + drivers/video/platinumfb.c | 10 drivers/video/pvr2fb.c | 846 +--- drivers/video/riva/fbdev.c | 75 drivers/video/riva/nv_type.h | 12 drivers/video/sis/300vtbl.h | 2437 ++---------- drivers/video/sis/310vtbl.h | 2574 ++---------- drivers/video/sis/init.c | 1882 +++++---- drivers/video/sis/init.h | 2435 +++++++++++- drivers/video/sis/init301.c | 8208 +++++++++++++++++++++-------------------- drivers/video/sis/init301.h | 222 - drivers/video/sis/initdef.h | 185 drivers/video/sis/oem300.h | 502 -- drivers/video/sis/oem310.h | 88 drivers/video/sis/osdef.h | 122 drivers/video/sis/sis_accel.c | 68 drivers/video/sis/sis_accel.h | 27 drivers/video/sis/sis_main.c | 3752 ++++++++++-------- drivers/video/sis/sis_main.h | 575 +- drivers/video/sis/vgatypes.h | 81 drivers/video/sis/vstruct.h | 138 drivers/video/skeletonfb.c | 74 drivers/video/softcursor.c | 72 drivers/video/tdfxfb.c | 47 drivers/video/valkyriefb.c | 548 -- drivers/video/vesafb.c | 17 drivers/video/vgastate.c | 1 include/linux/fb.h | 88 include/linux/linux_logo.h | 4 include/linux/pci_ids.h | 11 include/video/epson1355.h | 64 include/video/neomagic.h | 261 - include/video/sisfb.h | 91 54 files changed, 14922 insertions(+), 13346 deletions(-) through these ChangeSets: <jsimmons@bohr.(none)> (03/08/11 1.1151) [NEOMAGIC FBDEV] Add going between graphics and VGA text mode. <jsimmons@host-193.int.pioneer-pra.com> (03/07/21 1.1046.1.225) [TDFX FBDEV] Fixes to make the image blitter work. Also the color handling code was fixed. <jsimmons@host-193.int.pioneer-pra.com> (03/07/15 1.1046.1.221) [FBCON] Always turn off the cursor in fbcon_cursor. The reason is that cursor might try to blink while we are reprogramming the hardware. <jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.218) [IMSTT FBDEV] Free up resources when it fails. <jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.217) [FBDEV] Makefiel cleanups. <jsimmons@host-193.int.pioneer-pra.com> (03/07/11 1.1046.1.216) [ASILIANT FBDEV] Added support for the asiliant graphics chipset. <jsimmons@host-193.int.pioneer-pra.com> (03/07/09 1.1046.1.211) [RIVA FBDEV] Support for more versions of GEFORCE 4. Also some cursor cleanup to allow it to compile. <jsimmons@host-193.int.pioneer-pra.com> (03/07/08 1.1046.1.208) [SIS FBDEV] Updates to the SiS framebuffer driver. Add support for 760 chipset, LCD scaling. <jsimmons@kozmo.(none)> (03/07/03 1.1046.1.205) [NEOMAGIC FBDEV] Fixed a nasty bug in the copyarea function. It wasn't testing for the condition when both regions have the same y coordinates but are over lapping. This casued a corrpution of data. Also started ot used the macros in vga.h. <jsimmons@kozmo.(none)> (03/06/30 1.1046.1.200) [LOGO] Display the correct logo for MIPS DEC workstations. <jsimmons@kozmo.(none)> (03/06/25 1.1046.1.194) [FBCON] Removed the crappy ROP_COPY/ROP_XOR test for flashing the cursor. Now we disable and enable the cursor timer instead. <jsimmons@kozmo.(none)> (03/06/24 1.1046.1.192) [FBDEV] Now we can use a specific hardware mapper for different hardware functionality. <jsimmons@kozmo.(none)> (03/06/23 1.1046.1.188) [VGA CORE] Added needed vmalloc header. <jsimmons@kozmo.(none)> (03/06/23 1.1046.1.185) [FBCON] When using 512 characters, the mouse pointer starts using the wrong complement_mask after a console reset. <jsimmons@kozmo.(none)> (03/06/23 1.1046.1.184) [FBDEV] Made chipsfb/controlfb/platinumfb use the xxfb kernel command line string. <jsimmons@maxwell.earthlink.net> (03/06/18 1.1046.1.180) [MAC FBDEV] Bug fixes. <jsimmons@maxwell.earthlink.net> (03/06/15 1.1046.1.176) [SIS FBDEV] More updates for the SIS driver. <jsimmons@maxwell.earthlink.net> (03/06/14 1.1046.1.174) [CONTROL/PLATINUM FBDEV] Fix to match change in fb_set_var. <jsimmons@maxwell.earthlink.net> (03/06/10 1.1046.1.170) [FBDEV] Fixed a issue with soft_cursor. It only worked with drivers with a pixmap.scan_align of 1. Now it will work with any. <jsimmons@kozmo.(none)> (03/06/07 1.1046.1.164) [SIS FBDEV] Fixed sysnc issue. <jsimmons@kozmo.(none)> (03/06/05 1.1046.1.160) [FBCON] Cleared out the struct fb_cursor we passed in. Other wise we get random data being used. <jsimmons@kozmo.(none)> (03/05/30 1.1046.1.155) [FBDEV GENERIC ACCEL] Fixed why logo was not displayed for some. <jsimmons@maxwell.earthlink.net> (03/05/24 1.1046.155.3) [VALKYRUE FBDEV] Ported to new api. <jsimmons@maxwell.earthlink.net> (03/05/23 1.1046.155.1) [FBDEV] Updates to explain the new cursor api. <jsimmons@maxwell.earthlink.net> (03/05/23 1.1046.1.142) [EPSON FRAMEBUFFER] Ported to the new api. Added support for the arm platform. <jsimmons@maxwell.earthlink.net> (03/05/15 1.1046.84.18) [SIS FBDEV] SIS Framebuffer updates. - Added preliminary and untested support for SiS660 - Added DDC support - Enhanced proprietary programming API for compatibility with X driver and upcoming SDL updates and upcoming vidix driver for mplayer - Fixes for video bridge output on various HW combinations - Fixes in TV detection - Reduced source size by removing duplicated data - Updated Kconfig descriptions <jsimmons@maxwell.earthlink.net> (03/05/14 1.1046.73.2) [PVR2 FBDEV] Port of the Dreamcast Frambuffer to the new api. <jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.19) [FBCON] set_con2fb_map wasn't testing to see the VC we where mapping to actually exist. Now it does. I add code to fbcon_cursor to reset the hotspot if it was changed by userland. <jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.17) [RIVA FBDEV] Removal of exccess variable. Kills off a few warnings. <jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.16) [VESA FBDEV] Removed the EDID code. The results where mixed. It worked for some but not for others. <jsimmons@maxwell.earthlink.net> (03/05/12 1.1046.7.15) [CONSOLE] This patch fixes the problem of not being able to set the fonts on VCs other than the first one. This also was the bug that was casuing dual head (vga and mda) to lock up. <jsimmons@kozmo.(none)> (03/05/02 1.1042.122.2) [FBDEV] Synced to kdev_t change. <jsimmons@kozmo.(none)> (03/04/22 1.1042.37.2) [FBDEV] Moved pixmap to the kernel side of the header. Will not be needed for ioctl calls at the present time. [FBCON] Lots more optimizations. <jsimmons@kozmo.(none)> (03/04/21 1.1042.37.1) [LOGO] Removed fb_ prefix. Wil be used by other drivers such as the newport driver. [G354 FBDEV] Now use the final cursor api. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 19:54 FBDEV updates James Simmons @ 2003-08-14 20:36 ` Otto Solares 2003-08-14 20:52 ` James Simmons 2003-08-14 23:16 ` Greg KH 2003-08-16 6:01 ` Sven Schnelle 1 sibling, 2 replies; 50+ messages in thread From: Otto Solares @ 2003-08-14 20:36 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list On Thu, Aug 14, 2003 at 08:54:21PM +0100, James Simmons wrote: > > Hi folks!! > > Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out > and tell me your results. I like to do a code drop soon. James: what is the current state of PM in fb drivers? does modedb is being used on 2.6 drivers? Is there an API (or lib) to use framebuffers devices without worring about differents visuals?, to quering, setting or disabling EDID support? will these drivers export sysfs entries instead of control via ioctl's? thanks for your work on fb. -solca ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 20:36 ` Otto Solares @ 2003-08-14 20:52 ` James Simmons 2003-08-15 8:40 ` Benjamin Herrenschmidt 2003-08-14 23:16 ` Greg KH 1 sibling, 1 reply; 50+ messages in thread From: James Simmons @ 2003-08-14 20:52 UTC (permalink / raw) To: Otto Solares; +Cc: Linux Kernel Mailing List, Linux Fbdev development list > what is the current state of PM in fb drivers? Experinmental patch from Ben is in the works. > does modedb is being used on 2.6 drivers? Yes. > Is there an API (or lib) to use framebuffers devices without > worring about differents visuals?, ??? > to quering, setting or > disabling EDID support? Yes. That is the fbmon.c stuff. Still needs work. > will these drivers export sysfs > entries instead of control via ioctl's? Needs to be done. I'm not familiar with sysfs so it hasn't been done. > thanks for your work on fb. Your welcome. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 20:52 ` James Simmons @ 2003-08-15 8:40 ` Benjamin Herrenschmidt 2003-08-15 22:31 ` James Simmons 0 siblings, 1 reply; 50+ messages in thread From: Benjamin Herrenschmidt @ 2003-08-15 8:40 UTC (permalink / raw) To: James Simmons Cc: Otto Solares, Linux Kernel Mailing List, Linux Fbdev development list On Thu, 2003-08-14 at 22:52, James Simmons wrote: > > what is the current state of PM in fb drivers? > > Experinmental patch from Ben is in the works. That patch actually works here and I'm more/less waiting for it to be merged so I can send you the driver updates based on it. (It's becoming rather urgent. My pending PowerMac updates that port things to the new model are causing PM to break on PowerBook laptops now because fbdev has incorrect PM and the "old style" thing isn't properly ordered). The only thing you may probably want to fix (because you know that code better than I do) are: - the "resume" callback in fbcon where I currently just refresh the foreground console, while you may actually want to refresh the one on this fb since I suppose that with mutiple heads, we may have consoles on more than one head ? - the suspend callback where you probably want to disable the cursor timer Ben. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-15 8:40 ` Benjamin Herrenschmidt @ 2003-08-15 22:31 ` James Simmons 2003-08-15 23:42 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2003-08-15 22:31 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Otto Solares, Linux Kernel Mailing List, Linux Fbdev development list > That patch actually works here and I'm more/less waiting for it > to be merged so I can send you the driver updates based on it. > (It's becoming rather urgent. My pending PowerMac updates that > port things to the new model are causing PM to break on PowerBook > laptops now because fbdev has incorrect PM and the "old style" thing > isn't properly ordered). > > The only thing you may probably want to fix (because you know > that code better than I do) are: > > - the "resume" callback in fbcon where I currently just refresh > the foreground console, while you may actually want to refresh the > one on this fb since I suppose that with mutiple heads, we may have > consoles on more than one head ? > > - the suspend callback where you probably want to disable the > cursor timer Will do. I like to also handle Video mode change. Even userland will like to know when a mode change happened. For userland a signal can be sent. This would be useful for someone in X that runs fbset in a Xterm. This hoses the X server. It would be nice if the X server would see the signal change and adapt to it. Fbset could in theory be used again to change a VC size. Yuck!!!! But it is what people want. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-15 22:31 ` James Simmons @ 2003-08-15 23:42 ` Benjamin Herrenschmidt 2003-08-16 2:40 ` Otto Solares 0 siblings, 1 reply; 50+ messages in thread From: Benjamin Herrenschmidt @ 2003-08-15 23:42 UTC (permalink / raw) To: James Simmons Cc: Otto Solares, Linux Kernel Mailing List, Linux Fbdev development list > > Will do. I like to also handle Video mode change. Even userland will like > to know when a mode change happened. For userland a signal can be sent. > This would be useful for someone in X that runs fbset in a Xterm. This > hoses the X server. It would be nice if the X server would see the signal > change and adapt to it. Fbset could in theory be used again to change a VC > size. Yuck!!!! But it is what people want. And for good reasons as we still have to deal with cases where neither the driver nor modedb knows what the monitor supports... Ben. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-15 23:42 ` Benjamin Herrenschmidt @ 2003-08-16 2:40 ` Otto Solares 0 siblings, 0 replies; 50+ messages in thread From: Otto Solares @ 2003-08-16 2:40 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Sat, Aug 16, 2003 at 01:42:32AM +0200, Benjamin Herrenschmidt wrote: > > > > > Will do. I like to also handle Video mode change. Even userland will like > > to know when a mode change happened. For userland a signal can be sent. > > This would be useful for someone in X that runs fbset in a Xterm. This > > hoses the X server. It would be nice if the X server would see the signal > > change and adapt to it. Fbset could in theory be used again to change a VC > > size. Yuck!!!! But it is what people want. > > And for good reasons as we still have to deal with cases > where neither the driver nor modedb knows what the monitor supports... It could be really cool if in sysfs be a file with video modes, something like this: 1024x768x24@80 1024x768x24@60 800x600x24@60 600x400x16@75 and other file named current_mode (or something) with the current setting, you just echo a value there and bingo, a video mode change with the desired refresh rate, is that hard? EDID and modedb can help us here. Don't you think? -solca ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 20:36 ` Otto Solares 2003-08-14 20:52 ` James Simmons @ 2003-08-14 23:16 ` Greg KH 2003-08-15 22:37 ` James Simmons 1 sibling, 1 reply; 50+ messages in thread From: Greg KH @ 2003-08-14 23:16 UTC (permalink / raw) To: Otto Solares Cc: James Simmons, Linux Kernel Mailing List, Linux Fbdev development list On Thu, Aug 14, 2003 at 02:36:58PM -0600, Otto Solares wrote: > > Is there an API (or lib) to use framebuffers devices without > worring about differents visuals?, to quering, setting or > disabling EDID support? will these drivers export sysfs > entries instead of control via ioctl's? I have some initial sysfs patches for the fb code that I've been sitting on in my trees. I was waiting for these patches to hit the mainline before bothering James and the rest of the world with them. But they don't export any of the ioctl stuff through the sysfs interface, but that would not be very hard to do at all if you want to. They just basically show the major/minor of the fb device, and point back to the proper place in the device tree where the fb device lives, which is all udev really needs right now. thanks, greg k-h ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 23:16 ` Greg KH @ 2003-08-15 22:37 ` James Simmons 2003-08-15 23:54 ` Greg KH 0 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2003-08-15 22:37 UTC (permalink / raw) To: Greg KH Cc: Otto Solares, Linux Kernel Mailing List, Linux Fbdev development list > > Is there an API (or lib) to use framebuffers devices without > > worring about differents visuals?, to quering, setting or > > disabling EDID support? will these drivers export sysfs > > entries instead of control via ioctl's? > > I have some initial sysfs patches for the fb code that I've been sitting > on in my trees. I was waiting for these patches to hit the mainline > before bothering James and the rest of the world with them. > > But they don't export any of the ioctl stuff through the sysfs > interface, but that would not be very hard to do at all if you want to. > They just basically show the major/minor of the fb device, and point > back to the proper place in the device tree where the fb device lives, > which is all udev really needs right now. Could you send me those patches :-) ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-15 22:37 ` James Simmons @ 2003-08-15 23:54 ` Greg KH 0 siblings, 0 replies; 50+ messages in thread From: Greg KH @ 2003-08-15 23:54 UTC (permalink / raw) To: James Simmons Cc: Otto Solares, Linux Kernel Mailing List, Linux Fbdev development list On Fri, Aug 15, 2003 at 11:37:21PM +0100, James Simmons wrote: > > > > Is there an API (or lib) to use framebuffers devices without > > > worring about differents visuals?, to quering, setting or > > > disabling EDID support? will these drivers export sysfs > > > entries instead of control via ioctl's? > > > > I have some initial sysfs patches for the fb code that I've been sitting > > on in my trees. I was waiting for these patches to hit the mainline > > before bothering James and the rest of the world with them. > > > > But they don't export any of the ioctl stuff through the sysfs > > interface, but that would not be very hard to do at all if you want to. > > They just basically show the major/minor of the fb device, and point > > back to the proper place in the device tree where the fb device lives, > > which is all udev really needs right now. > > Could you send me those patches :-) I'll clean them up, and port all fb drivers to them (I only did the ones that I had hardware too), and send them to you next week. Do not let them hold anything up that you can send to Linus though, they are not that important at all right now. thanks, greg k-h ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: FBDEV updates. 2003-08-14 19:54 FBDEV updates James Simmons 2003-08-14 20:36 ` Otto Solares @ 2003-08-16 6:01 ` Sven Schnelle 1 sibling, 0 replies; 50+ messages in thread From: Sven Schnelle @ 2003-08-16 6:01 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list [-- Attachment #1: Type: text/plain, Size: 7421 bytes --] Hello, James Simmons <jsimmons@infradead.org> wrote: > Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out > and tell me your results. I like to do a code drop soon. Thanks for this patch, it runs now quite nice on a RIVA TNT2. Is there any special reason why you use soft_cursor in rivafb? I changed the rivafb_cursor to the new code, maybe you have a look ;-) -------------------------------------8<---------------------------------------------------------------- diff -Naur linux-2.6.0-test3/drivers/video/riva/fbdev.c linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c --- linux-2.6.0-test3/drivers/video/riva/fbdev.c 2003-08-16 07:47:20.000000000 +0200 +++ linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c 2003-08-16 07:39:39.000000000 +0200 @@ -460,48 +460,11 @@ return (VGA_RD08(par->riva.PVIO, 0x3cc)); } -static u8 byte_rev[256] = { - 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, - 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, - 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8, - 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8, - 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4, - 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4, - 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec, - 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc, - 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2, - 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2, - 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea, - 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa, - 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6, - 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6, - 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee, - 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe, - 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1, - 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1, - 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9, - 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9, - 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5, - 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5, - 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed, - 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd, - 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3, - 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3, - 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb, - 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb, - 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7, - 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7, - 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, - 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff, -}; - -static inline void reverse_order(u32 *l) +static inline u32 reverse_order(u32 val) { - u8 *a = (u8 *)l; - *a = byte_rev[*a], a++; - *a = byte_rev[*a], a++; - *a = byte_rev[*a], a++; - *a = byte_rev[*a]; +return((val & 0x80808080) >> 7 | (val & 0x40404040) >> 5 | (val & 0x20202020) >> 3 | \ + (val & 0x10101010) >> 1 | (val & 0x08080808) << 1 | (val & 0x04040404) << 3 | \ + (val & 0x02020202) << 5 | (val & 0x01010101) << 7); } /* ------------------------------------------------------------------------- * @@ -534,13 +497,14 @@ int i, j, k = 0; u32 b, m, tmp; + for (i = 0; i < h; i++) { - b = *((u32 *)data)++; + + b = reverse_order(*((u32 *)data)++); m = *((u32 *)mask)++; - reverse_order(&b); - + for (j = 0; j < w/2; j++) { - tmp = 0; + tmp = 0; #if defined (__BIG_ENDIAN) if (m & (1 << 31)) { fg |= 1 << 15; @@ -565,7 +529,7 @@ tmp = (b & 1) ? fg : bg; b >>= 1; m >>= 1; - + if (m & 1) { fg |= 1 << 15; bg |= 1 << 15; @@ -573,10 +537,11 @@ tmp |= (b & 1) ? fg << 16 : bg << 16; b >>= 1; m >>= 1; + #endif - writel(tmp, par->riva.CURSOR + k++); - } - k += (MAX_CURS - w)/2; + writel(tmp, par->riva.CURSOR + k++); + } + k += (MAX_CURS - w)/2; } } @@ -1428,7 +1393,7 @@ const struct fb_image *image) { struct riva_par *par = (struct riva_par *) info->par; - u32 fgx = 0, bgx = 0, width, tmp; + u32 fgx = 0, bgx = 0, width; u8 *cdat = (u8 *) image->data; volatile u32 *d; int i, size; @@ -1474,23 +1439,20 @@ width = (image->width + 31)/32; size = width * image->height; + while (size >= 16) { RIVA_FIFO_FREE(par->riva, Bitmap, 16); - for (i = 0; i < 16; i++) { - tmp = *((u32 *)cdat)++; - reverse_order(&tmp); - d[i] = tmp; - } + for (i = 0; i < 16; i++) + d[i] = reverse_order(*((u32 *)cdat)++); size -= 16; - } + } + if (size) { RIVA_FIFO_FREE(par->riva, Bitmap, size); - for (i = 0; i < size; i++) { - tmp = *((u32 *) cdat)++; - reverse_order(&tmp); - d[i] = tmp; + for (i = 0; i < size; i++) + d[i] = reverse_order(*((u32 *) cdat)++); + } - } } /** @@ -1509,9 +1471,17 @@ static int rivafb_cursor(struct fb_info *info, struct fb_cursor *cursor) { struct riva_par *par = (struct riva_par *) info->par; + unsigned int scan_align = info->pixmap.scan_align - 1; + unsigned int buf_align = info->pixmap.buf_align - 1; + u8 *dst = (u8 *) info->cursor.image.data; + unsigned int i, size, pitch; u16 fg, bg; - int i; + pitch = ((info->cursor.image.width + 7) >> 3) + scan_align; + pitch &= ~scan_align; + size = pitch * info->cursor.image.height + buf_align; + size &= ~buf_align; + par->riva.ShowHideCursor(&par->riva, 0); if (cursor->set & FB_CUR_SETPOS) { @@ -1540,36 +1510,37 @@ if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP)) { u32 bg_idx = info->cursor.image.bg_color; u32 fg_idx = info->cursor.image.fg_color; - u8 *dat = (u8 *) info->cursor.image.data; - u8 *msk = (u8 *) info->cursor.mask; - u8 src[64]; - switch (info->cursor.rop) { case ROP_XOR: - for (i = 0; i < info->sprite.size; i++) - src[i] = dat[i] ^ msk[i]; + for (i = 0; i < size; i++) + dst[i] ^= info->cursor.mask[i]; break; case ROP_COPY: default: - for (i = 0; i < info->sprite.size; i++) - src[i] = dat[i] & msk[i]; + for (i = 0; i < size; i++) + dst[i] &= info->cursor.mask[i]; break; } bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) | ((info->cmap.green[bg_idx] & 0xf8) << 2) | - ((info->cmap.blue[bg_idx] & 0xf8) >> 3); + ((info->cmap.blue[bg_idx] & 0xf8) >> 3) | 0x8000; fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) | ((info->cmap.green[fg_idx] & 0xf8) << 2) | - ((info->cmap.blue[fg_idx] & 0xf8) >> 3); + ((info->cmap.blue[fg_idx] & 0xf8) >> 3) | 0x8000; par->riva.LockUnlock(&par->riva, 0); - rivafb_load_cursor_image(par, dat, msk, bg, fg, - info->cursor.image.width, + + memset_io(par->riva.CURSOR, 0, MAX_CURS * MAX_CURS*2); + + if(info->cursor.image.data) + rivafb_load_cursor_image(par, dst, info->cursor.mask, bg, fg, \ + info->cursor.image.width, \ info->cursor.image.height); - } + } + if (info->cursor.enable) par->riva.ShowHideCursor(&par->riva, 1); return 0; @@ -1602,7 +1573,7 @@ .fb_fillrect = rivafb_fillrect, .fb_copyarea = rivafb_copyarea, .fb_imageblit = rivafb_imageblit, - .fb_cursor = soft_cursor, + .fb_cursor = rivafb_cursor, .fb_sync = rivafb_sync, }; -----------------------------------------8<----------------------------------------- -- Sven Schnelle, <schnelle@kabelleipzig.de> ----------------------------------------- [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: FBdev updates. @ 2003-02-20 1:40 Lawrence Lee (Shanghai) 0 siblings, 0 replies; 50+ messages in thread From: Lawrence Lee (Shanghai) @ 2003-02-20 1:40 UTC (permalink / raw) To: 'linux-kernel@vger.kernel.org' unsubscribe linux-kernel ^ permalink raw reply [flat|nested] 50+ messages in thread
* fbdev updates @ 2002-06-18 20:16 James Simmons 2002-06-18 20:22 ` Larry McVoy 0 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2002-06-18 20:16 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Linux Fbdev development list If anyone sent me updates in the last 14 days for the fbdev layer please send them again. I had a sync problem and then I attempted to fix it all my work got blown away for the last week by BK. I guess BK needs ALOT more work in this area. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: fbdev updates 2002-06-18 20:16 fbdev updates James Simmons @ 2002-06-18 20:22 ` Larry McVoy 0 siblings, 0 replies; 50+ messages in thread From: Larry McVoy @ 2002-06-18 20:22 UTC (permalink / raw) To: James Simmons; +Cc: Linux Kernel Mailing List, Linux Fbdev development list On Tue, Jun 18, 2002 at 01:16:26PM -0700, James Simmons wrote: > If anyone sent me updates in the last 14 days for the fbdev layer please > send them again. I had a sync problem and then I attempted to fix it all > my work got blown away for the last week by BK. I guess BK needs ALOT more > work in this area. Hmm. Can you be more specific than "blown away"? BK is careful to a fault about not deleting your data. Unless you did a "rm -rf my_repo" it's hard to imagine that you lost anything. How about you contact me offline and we'll see if you changes are actually still there? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 50+ messages in thread
* fbdev updates. @ 2002-06-05 16:39 James Simmons 2002-06-05 16:50 ` Russell King 0 siblings, 1 reply; 50+ messages in thread From: James Simmons @ 2002-06-05 16:39 UTC (permalink / raw) To: Linux Fbdev development list; +Cc: Linux Kernel Mailing List Since no one has complianed for some time I like to push the next set of changes to Linus. Anyone with objections please give a yell. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: fbdev updates. 2002-06-05 16:39 James Simmons @ 2002-06-05 16:50 ` Russell King 0 siblings, 0 replies; 50+ messages in thread From: Russell King @ 2002-06-05 16:50 UTC (permalink / raw) To: James Simmons; +Cc: Linux Fbdev development list, Linux Kernel Mailing List On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote: > Since no one has complianed for some time I like to push the next set of > changes to Linus. Anyone with objections please give a yell. A small suggestion - could you post diffstat -p1 output with your patch announcements please? -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2003-08-16 6:03 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-20 1:09 FBdev updates James Simmons 2003-02-20 1:17 ` Jeff Garzik 2003-02-20 1:22 ` James Simmons 2003-02-20 15:02 ` Dave Jones 2003-02-20 15:07 ` James Simmons 2003-02-20 18:29 ` Petr Vandrovec 2003-02-20 19:03 ` Jurriaan 2003-02-20 19:58 ` James Simmons 2003-02-20 22:00 ` [Linux-fbdev-devel] " Antonino Daplas 2003-02-21 9:09 ` Geert Uytterhoeven 2003-02-21 10:46 ` Antonino Daplas 2003-02-21 11:02 ` Geert Uytterhoeven 2003-02-21 1:45 ` David S. Miller 2003-02-21 9:04 ` [Linux-fbdev-devel] " Geert Uytterhoeven 2003-02-21 0:24 ` Antonino Daplas 2003-03-03 20:35 ` Petr Vandrovec 2003-03-03 21:25 ` Geert Uytterhoeven 2003-03-03 21:32 ` Antonino Daplas 2003-03-05 20:23 ` James Simmons 2003-03-06 1:18 ` Antonino Daplas 2003-03-04 21:29 ` Jurriaan 2003-03-04 21:46 ` Petr Vandrovec 2003-03-09 21:29 ` Petr Vandrovec 2003-03-09 22:27 ` Antonino Daplas 2003-03-09 22:54 ` Petr Vandrovec 2003-03-09 23:44 ` Antonino Daplas 2003-03-11 15:31 ` James Simmons 2003-03-05 20:22 ` James Simmons 2003-03-06 7:35 ` Sven Luther 2003-03-06 8:05 ` Antonino Daplas 2003-03-06 8:25 ` Sven Luther 2003-03-28 14:19 ` 2.5.66 fbdev performance (was Re: Re: FBdev updates) Petr Vandrovec 2003-03-28 18:50 ` [Linux-fbdev-devel] " Antonino Daplas 2003-02-20 15:10 ` FBdev updates Ivan Kokshaysky -- strict thread matches above, loose matches on Subject: below -- 2003-08-14 19:54 FBDEV updates James Simmons 2003-08-14 20:36 ` Otto Solares 2003-08-14 20:52 ` James Simmons 2003-08-15 8:40 ` Benjamin Herrenschmidt 2003-08-15 22:31 ` James Simmons 2003-08-15 23:42 ` Benjamin Herrenschmidt 2003-08-16 2:40 ` Otto Solares 2003-08-14 23:16 ` Greg KH 2003-08-15 22:37 ` James Simmons 2003-08-15 23:54 ` Greg KH 2003-08-16 6:01 ` Sven Schnelle 2003-02-20 1:40 FBdev updates Lawrence Lee (Shanghai) 2002-06-18 20:16 fbdev updates James Simmons 2002-06-18 20:22 ` Larry McVoy 2002-06-05 16:39 James Simmons 2002-06-05 16:50 ` Russell King
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).