Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ani J. <aj...@sh...> - 2002-03-25 18:36:59
|
Jing, What type of projector are you using? Does this projector use any display resolution the card outputs or is it fixed? It seems the projector doesn't support DDC which is why the driver can't detetct it and its resolution properly in the BIOS. You can try hardcoding the resolution, or forcing it to use the default mode. ani On Sun, 24 Mar 2002, Jing Xu wrote: > Hi, Ani, > > I tried kernel 2.4.18 on redhat 7.2, and use radeonfb > driver for my card. The version of radeonfb is > "0.1.4". I built this driver into the kernel instead > of as a module, then connected a projector with DVI > port and reboot system. Radeonfb driver can detect > "DVI port CRT monitor connected.", but there is no > signal sent to the projector. > > I read radeonfb.c and found that DVI port is primary > monitor, does that mean that DVI output is enabled > automatically if there is a device like projector > connected with the DVI port? > > If not, how can I enable the DVI output? Do I need to > change the driver source code? > > I don't want to use X windows system. Is that OK to > use DVI output? > > Thank you very much, > > jing |
|
From: Christopher P W. <softpixel.com> <cw...@so...> - 2002-03-25 17:06:10
|
Hello all! I am curious as to how a fb driver gets used by the console code. The driver i am working on is initially a module, and I'm not sure how the console (normally text mode) will operate once that changes to a framebuffer mode. are there calls that the driver must make to inform the console layer of the change? also, are there any fairly recent docs on the api that is used in 2.4 (if it changed any from 2.2, doesn't seem like it), and possibly the newer api merged into 2.5.something thanks in advance =) chris |
|
From: Christopher P W. <softpixel.com> <cw...@so...> - 2002-03-25 16:53:02
|
> Is anyone among the group actively using vesafb in their kernels? > If so what is the latest kernel version that you have built vesafb support > into? I am. I have kernel 2.4.14, it works perfectly (as perfectly as vesafb can be, at least). christopher wright cw...@so... |
|
From: William S. <ch...@dm...> - 2002-03-25 13:22:55
|
I'm feeling a bit foolish today, after a week and a half of stupidity. I was so close to the problem that I was no longer able to look at it with objectivity. My buddy noticed my problem as soon as he looked at my lilo.conf. I was passing the vga=791 argument as a lilo append= option, which was WRONG, and just my stupidity... sorry for the noise... vesafb is just fine! So kudos to the developers! Thanks to the vesafb, my project gets a nice X interface without having to know the details of everyone's video hardware... I like it! http://biatchux.sourceforge.net thanks, William Salusky ch...@dm... Geert Uytterhoeven <ge...@li...> said: > ---------- Forwarded message ---------- > Date: Sat, 23 Mar 2002 20:19:50 -0000 > From: William Salusky <ch...@dm...> > Subject: vesafb in kernel 2.4.18? > > Hello all, > > Is anyone among the group actively using vesafb in their kernels? > If so what is the latest kernel version that you have built vesafb support > into? > > I am starting to believe that proper vesafb support has been accidentally > dropped in the 2.4x kernel somewhere after 2.4.5 as that is the last kernel > that I can have had it working under. I'm trying to build vesafb under > 2.4.18 in support of an X implementation for the biatchux bootable cd, > http://biatchux.sourceforge.net > > I'm begging for help at this point... I've downgraded as far as 2.4.14 and > still can't find proper vesafb support. I do not want to go all the way back > to 2.4.5 as I would lose many features that were made available with the > latest stable. > > thanks, > > -- > William Salusky > ch...@dm... > cell: 925-250-6092 > > > -- William Salusky ch...@dm... cell: 925-250-6092 |
|
From: Geert U. <ge...@li...> - 2002-03-25 10:03:24
|
---------- Forwarded message ---------- Date: Sat, 23 Mar 2002 20:19:50 -0000 From: William Salusky <ch...@dm...> Subject: vesafb in kernel 2.4.18? Hello all, Is anyone among the group actively using vesafb in their kernels? If so what is the latest kernel version that you have built vesafb support into? I am starting to believe that proper vesafb support has been accidentally dropped in the 2.4x kernel somewhere after 2.4.5 as that is the last kernel that I can have had it working under. I'm trying to build vesafb under 2.4.18 in support of an X implementation for the biatchux bootable cd, http://biatchux.sourceforge.net I'm begging for help at this point... I've downgraded as far as 2.4.14 and still can't find proper vesafb support. I do not want to go all the way back to 2.4.5 as I would lose many features that were made available with the latest stable. thanks, -- William Salusky ch...@dm... cell: 925-250-6092 |
|
From: Jing Xu <xuj...@ya...> - 2002-03-25 02:59:16
|
Hi, Ani, I tried kernel 2.4.18 on redhat 7.2, and use radeonfb driver for my card. The version of radeonfb is "0.1.4". I built this driver into the kernel instead of as a module, then connected a projector with DVI port and reboot system. Radeonfb driver can detect "DVI port CRT monitor connected.", but there is no signal sent to the projector. I read radeonfb.c and found that DVI port is primary monitor, does that mean that DVI output is enabled automatically if there is a device like projector connected with the DVI port? If not, how can I enable the DVI output? Do I need to change the driver source code? I don't want to use X windows system. Is that OK to use DVI output? Thank you very much, jing --- Ani Joshi <aj...@sh...> wrote: > > Use kernel 2.4.18. > > > ani > > On Tue, 19 Mar 2002, Jing Xu wrote: > > > Hi, > > > > I have an ATI Radeon QY VE(PCI) video card, and > use > > the frame buffer device driver radeonfb on kernel > > 2.4.14. How can I output the content of the screen > to > > DVI port? > > > > Thanks in advance, > > > > jing > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Sports - live college hoops coverage > > http://sports.yahoo.com/ > > > > _______________________________________________ > > Linux-fbdev-devel mailing list > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > > > __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ |
|
From: Jing Xu <xuj...@ya...> - 2002-03-22 16:39:22
|
Hi, I have an ATI Radeon QY VE(PCI) video card, and use the frame buffer device driver radeonfb on kernel 2.4.18. DVI output is connected with a projector. I set force_dfp = 1, but driver failed at pci register phase. The boot message is as follows: radeonfb_pci_register BEGIN radeonfb: ref_clk=2700, ref_div=12, xclk=18300 from BIOS radeonfb: probed DDR SGRAM 32768k videoram radeonfb: dviDisp_type = MT_DFP. radeonfb: panel ID string: radeonfb: detected DFP panel size from BIOS: 1x0 radeonfb: Failed to detect DFP panel size Your help will be highly appreciated. jing __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ |
|
From: Carlo E. P. <fl...@fl...> - 2002-03-21 20:57:58
|
Subject: [Linux-fbdev-devel] Stupid questions Date: Wed, Mar 20, 2002 at 09:38:19PM +0100 Quoting Marian Krivos (ne...@in...): > There are in the 2.5.x kernels any plans to add support for HW > acceleration of primitives (lines, rectangles etc.) of the fbdev from > the user space? Have a look at directfb (http://www.directfb.org). For selected cards, it provides user-space acceleration over 2.4 kernel framebuffer code. Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Christopher P W. <softpixel.com> <cw...@so...> - 2002-03-21 20:32:19
|
> There are in the 2.5.x kernels any plans to add support for HW > acceleration of primitives (lines, rectangles etc.) of the fbdev from > the user space? > > Best wishes, > > MArian Krivos. unfortunatly, I don't think this will even happen with fbdev. fbdev's job is just mode setting and information collecting. some minor accelerations come with bitblt, but this may not be general use (does the tux boot logo). However, a library could make use of the information provided by fbdev to accelerate in userspace. ttyl chris |
|
From: Aleksandr K. <ale...@ek...> - 2002-03-21 07:05:50
|
You might also try a fb-compatible driver from Nick Kurshev distributed with the mplayer-project. The problem with the .18 radeonfb driver is that it doesn't handle crtc2 gracefully and after mode switches will get confused about which head is the first and which is the second. Altough, if the official .18-version works for you, you should use it, the palette handling is better in that version. Aleksandr Koltsoff -----Original Message----- From: lin...@li... [mailto:lin...@li...]On Behalf Of Jing Xu Sent: 19. maaliskuuta 2002 19:07 To: lin...@li... Subject: [Linux-fbdev-devel] Radeonfb DVI output? Hi, I have an ATI Radeon QY VE(PCI) video card, and use the frame buffer device driver radeonfb on kernel 2.4.14. How can I output the content of the screen to DVI port? Thanks in advance, jing __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Linux-fbdev-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Marian K. <ne...@in...> - 2002-03-20 20:38:23
|
There are in the 2.5.x kernels any plans to add support for HW acceleration of primitives (lines, rectangles etc.) of the fbdev from the user space? Best wishes, MArian Krivos. |
|
From: Jean J. T. <jea...@mc...> - 2002-03-20 04:43:06
|
Hi I need some hints about how to compile the CVS. I tried what is said on this page (http://linuxconsole.sourceforge.net/quick.html), but no success. I this page still up to date with the current development? Then I tried with kernel 2.5.7, but still not better (an error during the make in file fbcon.c). Thank for any advice. JJ |
|
From: Ani J. <aj...@sh...> - 2002-03-19 22:08:45
|
Use kernel 2.4.18. ani On Tue, 19 Mar 2002, Jing Xu wrote: > Hi, > > I have an ATI Radeon QY VE(PCI) video card, and use > the frame buffer device driver radeonfb on kernel > 2.4.14. How can I output the content of the screen to > DVI port? > > Thanks in advance, > > jing > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
|
From: Jing Xu <xuj...@ya...> - 2002-03-19 17:08:29
|
Hi, I have an ATI Radeon QY VE(PCI) video card, and use the frame buffer device driver radeonfb on kernel 2.4.14. How can I output the content of the screen to DVI port? Thanks in advance, jing __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ |
|
From: James S. <jsi...@tr...> - 2002-03-18 17:06:40
|
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common > -pipe -mpreferred-stack-boundary=2 -march=athlon > -DKBUILD_BASENAME=fbdev -c -o fbdev.o fbdev.c > In file included from /usr/src/linux/include/video/fbcon.h:17, > from rivafb.h:6, > from fbdev.c:48: > /usr/src/linux/include/linux/vt_kern.h:63: redefinition of `struct vc_data' > fbdev.c: In function `rivafb_init_one': > fbdev.c:1948: structure has no member named `fb_base' > fbdev.c:1950: structure has no member named `fb_base' > make[4]: *** [fbdev.o] Error 1 > make[4]: Leaving directory `/usr/src/linux/drivers/video/riva' Okay. I will start working on it today. |
|
From: Miles L. <mi...@me...> - 2002-03-18 16:55:06
|
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=athlon
-DKBUILD_BASENAME=fbdev -c -o fbdev.o fbdev.c
In file included from /usr/src/linux/include/video/fbcon.h:17,
from rivafb.h:6,
from fbdev.c:48:
/usr/src/linux/include/linux/vt_kern.h:63: redefinition of `struct vc_data'
fbdev.c: In function `rivafb_init_one':
fbdev.c:1948: structure has no member named `fb_base'
fbdev.c:1950: structure has no member named `fb_base'
make[4]: *** [fbdev.o] Error 1
make[4]: Leaving directory `/usr/src/linux/drivers/video/riva'
|
|
From: James S. <jsi...@tr...> - 2002-03-16 17:28:48
|
> what is the expected time frame for the new api? i'm writing this for the > 2.4.x api, but i think the new one would be better in the long run. i > don't have a system running 2.5 to try it out though. Very soon. I talked to Dave jones about pushing the stuff we have in the next few weeks. |
|
From: Christopher P W. <softpixel.com> <cw...@so...> - 2002-03-13 20:33:45
|
okie dokie, i have some time in the evenings, so im gonna start working on the sisfb(530) driver some more. as far as i know, the existing sisfb driver does not work with this chip. eventually, if i get it working, i may try to integrate it into the existing sisfb driver, and everyone can be happy. what is the expected time frame for the new api? i'm writing this for the 2.4.x api, but i think the new one would be better in the long run. i don't have a system running 2.5 to try it out though. is there anyone else with the same chip(sis530 (6326?) who would be willing to test it if/when it gets that far along? chris -- Come away, O human child! To the waters and the wild With a faery, hand in hand, For the world's more full of weeping than you can understand --William Butler Yeats |
|
From: Geert U. <ge...@li...> - 2002-03-13 08:57:35
|
On Tue, 12 Mar 2002, James Simmons wrote:
> > > This code provides software accels to replace all the fbcon-cfb* stuff.
> > > Gradually the fbdev drivers can be ported over to it. It is against
> > > 2.5.5-dj3. Please apply the patch.
> >
> > I'm still wondering whether it's a good idea to assume all color values (e.g.
> > fb_fillrect.color) are palette indices. This means you cannot draw a rectangle
> > with an arbitrary color using cfb_fillrect().
>
> Would we ever want to do that? Also using the color map regno is to a
> advantage for non packed pixel modes.
>
> > Furthermore this means that fillrect() and imageblit() (the color image case)
> > expect different formats: the former expects a palette index, the latter
> > expects the native frame buffer format (cfr. your comments in the code below).
>
> I need to change that. I want to have the image blit function use the
> color palette. The most we will ever use is 256 colors for the penguin.
> Do we need to expand that more?
I don't know. I'm just thinking about one day we want to do more with it in the
kernel.
> > The 17-entry (16 colors + 1 XOR mask) pseudo palette is actually something
> > related to the console, so I would not handle it in the low level drawing
> > routines, but in the frame buffer console layer. Of course the pseudo palette
> > still has to be initialized by the frame buffer device, since that is the part
> > that knows about the mapping from console palette indices to native pixel
> > values. This also means you'll have a pseudo palette for all modes, including
> > pseudocolor[*].
> >
> > What do you think?
>
> Hm. True pseudopalette is more a console thing. One of the reasons I made
> pseudo_palette a void was so anything type of data could be indexed to a
> color map regno. It really should be in a par struct for each driver.
> Personally I don't care for it and like to see it go away. Instead we
> could generate the color value from the fb_bitfields in struct
> fb_var_screeninfo and the red, green, blue etc from struct fb_cmap. The
> only thing preventing me from doing this is that it cost to generate those
> vlaues whereas we have the values already saved in pseudo_palette. The
> penalty tho only shows up when we draw each character.
Or you can precalculate them on each mode change and fill some tables. This is
what I do in fbtest, to make things as generic as possible, without a too high
speed penalty.
> > [*] Or set pseudo_palette to NULL, and use
> >
> > pixval = pseudo_palette ? pseudo_palette[idx] : idx;
> >
> > and
> >
> > xormask = pseudo_palette ? pseudo_palette[16] : 15;
>
> When we change from truecolor mode to pseudo color wouldn't we have to
> NULL the pseudo_palette pointer then?
Yes.
> > Color images are not yet implemented?
>
> Not yet. I wanted to have font support first.
OK.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: James S. <jsi...@tr...> - 2002-03-13 00:30:55
|
> > This code provides software accels to replace all the fbcon-cfb* stuff. > > Gradually the fbdev drivers can be ported over to it. It is against > > 2.5.5-dj3. Please apply the patch. > > I'm still wondering whether it's a good idea to assume all color values (e.g. > fb_fillrect.color) are palette indices. This means you cannot draw a rectangle > with an arbitrary color using cfb_fillrect(). Would we ever want to do that? Also using the color map regno is to a advantage for non packed pixel modes. > Furthermore this means that fillrect() and imageblit() (the color image case) > expect different formats: the former expects a palette index, the latter > expects the native frame buffer format (cfr. your comments in the code below). I need to change that. I want to have the image blit function use the color palette. The most we will ever use is 256 colors for the penguin. Do we need to expand that more? > The 17-entry (16 colors + 1 XOR mask) pseudo palette is actually something > related to the console, so I would not handle it in the low level drawing > routines, but in the frame buffer console layer. Of course the pseudo palette > still has to be initialized by the frame buffer device, since that is the part > that knows about the mapping from console palette indices to native pixel > values. This also means you'll have a pseudo palette for all modes, including > pseudocolor[*]. > > What do you think? Hm. True pseudopalette is more a console thing. One of the reasons I made pseudo_palette a void was so anything type of data could be indexed to a color map regno. It really should be in a par struct for each driver. Personally I don't care for it and like to see it go away. Instead we could generate the color value from the fb_bitfields in struct fb_var_screeninfo and the red, green, blue etc from struct fb_cmap. The only thing preventing me from doing this is that it cost to generate those vlaues whereas we have the values already saved in pseudo_palette. The penalty tho only shows up when we draw each character. > [*] Or set pseudo_palette to NULL, and use > > pixval = pseudo_palette ? pseudo_palette[idx] : idx; > > and > > xormask = pseudo_palette ? pseudo_palette[16] : 15; When we change from truecolor mode to pseudo color wouldn't we have to NULL the pseudo_palette pointer then? > Color images are not yet implemented? Not yet. I wanted to have font support first. |
|
From: Geert U. <ge...@li...> - 2002-03-12 09:38:57
|
On Mon, 11 Mar 2002, James Simmons wrote:
> This code provides software accels to replace all the fbcon-cfb* stuff.
> Gradually the fbdev drivers can be ported over to it. It is against
> 2.5.5-dj3. Please apply the patch.
I'm still wondering whether it's a good idea to assume all color values (e.g.
fb_fillrect.color) are palette indices. This means you cannot draw a rectangle
with an arbitrary color using cfb_fillrect().
Furthermore this means that fillrect() and imageblit() (the color image case)
expect different formats: the former expects a palette index, the latter
expects the native frame buffer format (cfr. your comments in the code below).
The 17-entry (16 colors + 1 XOR mask) pseudo palette is actually something
related to the console, so I would not handle it in the low level drawing
routines, but in the frame buffer console layer. Of course the pseudo palette
still has to be initialized by the frame buffer device, since that is the part
that knows about the mapping from console palette indices to native pixel
values. This also means you'll have a pseudo palette for all modes, including
pseudocolor[*].
What do you think?
[*] Or set pseudo_palette to NULL, and use
pixval = pseudo_palette ? pseudo_palette[idx] : idx;
and
xormask = pseudo_palette ? pseudo_palette[16] : 15;
> diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
> --- linux-2.5.5-dj3/drivers/video/cfbimgblt.c Wed Dec 31 16:00:00 1969
> +++ linux/drivers/video/cfbimgblt.c Mon Mar 11 14:29:37 2002
[...]
> + * This function copys a image from system memory to video memory. The
> + * image can be a bitmap where each 0 represents the background color and
> + * each 1 represents the foreground color. Great for font handling. It can
> + * also be a color image. This is determined by image_depth. The color image
> + * must be laid out exactly in the same format as the framebuffer. Yes I know
> + * their are cards with hardware that coverts images of various depths to the
> + * framebuffer depth. But not every card has this. All images must be rounded
> + * up to the nearest byte. For example a bitmap 12 bits wide must be two
> + * bytes width.
Color images are not yet implemented?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Jean J. T. <jea...@mc...> - 2002-03-12 00:41:32
|
Hi I am new to this list. I am interrested to understand (and eventually participate) on the framebuffer dev. I have been looking inside the source of kernel 2.4.18 for sometime now. I heard that framebuffer for 2.5.x (and eventually 2.6.x) will be very different. How much different? Thanks JJ |
|
From: James S. <jsi...@tr...> - 2002-03-12 00:23:07
|
This code provides software accels to replace all the fbcon-cfb* stuff.
Gradually the fbdev drivers can be ported over to it. It is against
2.5.5-dj3. Please apply the patch.
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/Config.in linux/drivers/video/Config.in
--- linux-2.5.5-dj3/drivers/video/Config.in Wed Mar 6 10:46:02 2002
+++ linux/drivers/video/Config.in Mon Mar 11 14:40:53 2002
@@ -259,7 +259,7 @@
if [ "$CONFIG_FB_ACORN" = "y" -o "$CONFIG_FB_ATARI" = "y" -o \
"$CONFIG_FB_ATY" = "y" -o "$CONFIG_FB_MAC" = "y" -o \
"$CONFIG_FB_OF" = "y" -o "$CONFIG_FB_TGA" = "y" -o \
- "$CONFIG_FB_VESA" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \
+ "$CONFIG_FB_PM3" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \
"$CONFIG_FB_TCX" = "y" -o "$CONFIG_FB_CGTHREE" = "y" -o \
"$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \
"$CONFIG_FB_CGFOURTEEN" = "y" -o "$CONFIG_FB_G364" = "y" -o \
@@ -267,7 +267,6 @@
"$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
"$CONFIG_FB_IGA" = "y" -o "$CONFIG_FB_MATROX" = "y" -o \
"$CONFIG_FB_CT65550" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
- "$CONFIG_FB_PM3" = "y" -o \
"$CONFIG_FB_P9100" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \
"$CONFIG_FB_RIVA" = "y" -o "$CONFIG_FB_RADEON" = "y" -o \
"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" -o \
@@ -280,7 +279,7 @@
if [ "$CONFIG_FB_ACORN" = "m" -o "$CONFIG_FB_ATARI" = "m" -o \
"$CONFIG_FB_ATY" = "m" -o "$CONFIG_FB_MAC" = "m" -o \
"$CONFIG_FB_OF" = "m" -o "$CONFIG_FB_TGA" = "m" -o \
- "$CONFIG_FB_VESA" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \
+ "$CONFIG_FB_PM3" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \
"$CONFIG_FB_TCX" = "m" -o "$CONFIG_FB_CGTHREE" = "m" -o \
"$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \
"$CONFIG_FB_CGFOURTEEN" = "m" -o "$CONFIG_FB_G364" = "m" -o \
@@ -288,7 +287,6 @@
"$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
"$CONFIG_FB_IGA" = "m" -o "$CONFIG_FB_MATROX" = "m" -o \
"$CONFIG_FB_CT65550" = "m" -o "$CONFIG_FB_PM2" = "m" -o \
- "$CONFIG_FB_PM3" = "m" -o \
"$CONFIG_FB_P9100" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \
"$CONFIG_FB_RIVA" = "m" -o "$CONFIG_FB_3DFX" = "m" -o \
"$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" -o \
@@ -300,7 +298,7 @@
fi
fi
if [ "$CONFIG_FB_ATARI" = "y" -o "$CONFIG_FB_ATY" = "y" -o \
- "$CONFIG_FB_MAC" = "y" -o "$CONFIG_FB_VESA" = "y" -o \
+ "$CONFIG_FB_MAC" = "y" -o "$CONFIG_FB_PM3" = "y" -o \
"$CONFIG_FB_VIRTUAL" = "y" -o "$CONFIG_FB_TBOX" = "y" -o \
"$CONFIG_FB_Q40" = "y" -o "$CONFIG_FB_RADEON" = "y" -o \
"$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \
@@ -308,7 +306,6 @@
"$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
"$CONFIG_FB_CT65550" = "y" -o "$CONFIG_FB_MATROX" = "y" -o \
"$CONFIG_FB_PM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \
- "$CONFIG_FB_PM3" = "y" -o \
"$CONFIG_FB_RIVA" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \
"$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_3DFX" = "y" -o \
"$CONFIG_FB_SIS" = "y" -o "$CONFIG_FB_SA1100" = "y" -o \
@@ -317,7 +314,7 @@
define_tristate CONFIG_FBCON_CFB16 y
else
if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \
- "$CONFIG_FB_MAC" = "m" -o "$CONFIG_FB_VESA" = "m" -o \
+ "$CONFIG_FB_MAC" = "m" -o "$CONFIG_FB_PM3" = "m" -o \
"$CONFIG_FB_VIRTUAL" = "m" -o "$CONFIG_FB_TBOX" = "m" -o \
"$CONFIG_FB_Q40" = "m" -o "$CONFIG_FB_3DFX" = "m" -o \
"$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \
@@ -325,7 +322,6 @@
"$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
"$CONFIG_FB_CT65550" = "m" -o "$CONFIG_FB_MATROX" = "m" -o \
"$CONFIG_FB_PM2" = "m" -o "$CONFIG_FB_SGIVW" = "m" -o \
- "$CONFIG_FB_PM3" = "m" -o \
"$CONFIG_FB_RIVA" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \
"$CONFIG_FB_CYBER2000" = "m" -o "$CONFIG_FB_SIS" = "m" -o \
"$CONFIG_FB_SA1100" = "m" -o "$CONFIG_FB_RADEON" = "m" -o \
@@ -352,11 +348,10 @@
fi
fi
if [ "$CONFIG_FB_ATARI" = "y" -o "$CONFIG_FB_ATY" = "y" -o \
- "$CONFIG_FB_VESA" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \
+ "$CONFIG_FB_PM3" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \
"$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \
"$CONFIG_FB_TGA" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
"$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
- "$CONFIG_FB_PM3" = "y" -o \
"$CONFIG_FB_RIVA" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \
"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \
"$CONFIG_FB_RADEON" = "y" -o "$CONFIG_FB_PVR2" = "y" -o \
@@ -365,11 +360,10 @@
define_tristate CONFIG_FBCON_CFB32 y
else
if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \
- "$CONFIG_FB_VESA" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \
+ "$CONFIG_FB_PM3" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \
"$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \
"$CONFIG_FB_TGA" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
"$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \
- "$CONFIG_FB_PM3" = "m" -o \
"$CONFIG_FB_RIVA" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \
"$CONFIG_FB_3DFX" = "m" -o "$CONFIG_FB_RADEON" = "m" -o \
"$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_SIS" = "m" -o \
@@ -377,10 +371,10 @@
define_tristate CONFIG_FBCON_CFB32 m
fi
fi
- if [ "$CONFIG_FB_NEOMAGIC" = "y" ]; then
+ if [ "$CONFIG_FB_NEOMAGIC" = "y" -o "$CONFIG_FB_VESA" = "y" ]; then
define_tristate CONFIG_FBCON_ACCEL y
else
- if [ "$CONFIG_FB_NEOMAGIC" = "m" ]; then
+ if [ "$CONFIG_FB_NEOMAGIC" = "m" -o "$CONFIG_FB_VESA" = "m" ]; then
define_tristate CONFIG_FBCON_ACCEL m
fi
fi
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/Makefile linux/drivers/video/Makefile
--- linux-2.5.5-dj3/drivers/video/Makefile Wed Mar 6 10:46:02 2002
+++ linux/drivers/video/Makefile Mon Mar 11 14:40:59 2002
@@ -69,7 +69,7 @@
obj-$(CONFIG_FB_TRIDENT) += tridentfb.o
obj-$(CONFIG_FB_S3TRIO) += S3triofb.o
obj-$(CONFIG_FB_TGA) += tgafb.o
-obj-$(CONFIG_FB_VESA) += vesafb.o
+obj-$(CONFIG_FB_VESA) += vesafb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
obj-$(CONFIG_FB_VGA16) += vga16fb.o fbcon-vga-planes.o
obj-$(CONFIG_FB_VIRGE) += virgefb.o
obj-$(CONFIG_FB_G364) += g364fb.o
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.5.5-dj3/drivers/video/cfbcopyarea.c Wed Dec 31 16:00:00 1969
+++ linux/drivers/video/cfbcopyarea.c Mon Mar 11 17:12:37 2002
@@ -0,0 +1,217 @@
+/*
+ * Generic function for frame buffer with packed pixels of any depth.
+ *
+ * Copyright (C) June 1999 James Simmons
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * NOTES:
+ *
+ * This is for cfb packed pixels. Iplan and such are incorporated in the
+ * drivers that need them.
+ *
+ * FIXME
+ * The code for 24 bit is horrible. It copies byte by byte size instead of
+ * longs like the other sizes. Needs to be optimized.
+ *
+ * Also need to add code to deal with cards endians that are different than
+ * the native cpu endians. I also need to deal with MSB position in the word.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/fb.h>
+#include <linux/slab.h>
+#include <asm/types.h>
+#include <asm/io.h>
+#include <video/fbcon.h>
+
+void cfb_copyarea(struct fb_info *p, struct fb_copyarea *area)
+{
+ unsigned long start_index, end_index, start_mask, end_mask, last, tmp, height;
+ int x2, y2, n, j, lineincr, shift, shift_right, shift_left, old_dx, old_dy;
+ int linesize = p->fix.line_length, bpl = sizeof(unsigned long);
+ unsigned long *dst = NULL, *src = NULL;
+ char *src1,*dst1;
+
+ /* clip the destination */
+ old_dx = area->dx;
+ old_dy = area->dy;
+
+ /*
+ * We could use hardware clipping but on many cards you get around
+ * hardware clipping by writing to framebuffer directly.
+ */
+ x2 = area->dx + area->width;
+ y2 = area->dy + area->height;
+ area->dx = area->dx > 0 ? area->dx : 0;
+ area->dy = area->dy > 0 ? area->dy : 0;
+ x2 = x2 < p->var.xres_virtual ? x2 : p->var.xres_virtual;
+ y2 = y2 < p->var.yres_virtual ? y2 : p->var.yres_virtual;
+ area->width = x2 - area->dx;
+ area->height = y2 - area->dy;
+
+ /* update sx1,sy1 */
+ area->sx += (area->dx - old_dx);
+ area->sy += (area->dy - old_dy);
+
+ height = area->height;
+
+ /* the source must be completely inside the virtual screen */
+ if (area->sx < 0 || area->sy < 0 ||
+ (area->sx + area->width) > p->var.xres_virtual ||
+ (area->sy + area->height) > p->var.yres_virtual)
+ return;
+
+ if (area->dy < area->sy || (area->dy == area->sy && area->dx < area->sx)) {
+ /* start at the top */
+ src1 = p->screen_base + area->sy * linesize +
+ ((area->sx * p->var.bits_per_pixel) >> 3);
+ dst1 = p->screen_base + area->dy * linesize +
+ ((area->dx * p->var.bits_per_pixel) >> 3);
+ lineincr = linesize;
+ } else {
+ /* start at the bottom */
+ src1 = p->screen_base + (area->sy + area->height-1)*linesize +
+ (((area->sx + area->width - 1) * p->var.bits_per_pixel) >> 3);
+ dst1 = p->screen_base + (area->dy + area->height-1)*linesize +
+ (((area->dx + area->width - 1) * p->var.bits_per_pixel) >> 3);
+ lineincr = -linesize;
+ }
+
+ if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) {
+ int ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+ int n = ((area->width * p->var.bits_per_pixel) >> 3);
+
+ start_index = ((unsigned long) src1 & (bpl-1));
+ end_index = ((unsigned long) (src1 + n) & (bpl-1));
+ shift = ((unsigned long)dst1 & (bpl-1)) - ((unsigned long) src1 & (bpl-1));
+ start_mask = end_mask = 0;
+
+ if (start_index) {
+ start_mask = -1 >> (start_index << 3);
+ n -= (bpl - start_index);
+ }
+
+ if (end_index) {
+ end_mask = -1 << ((bpl - end_index) << 3);
+ n -= end_index;
+ }
+ n = n/bpl;
+
+ if (n <= 0) {
+ if (start_mask) {
+ if (end_mask)
+ end_mask &= start_mask;
+ else
+ end_mask = start_mask;
+ start_mask = 0;
+ }
+ n = 0;
+ }
+
+ if (shift) {
+ if (shift > 0) {
+ /* dest is over to right more */
+ shift_right = shift * p->var.bits_per_pixel;
+ shift_left = (ppw - shift) * p->var.bits_per_pixel;
+ } else {
+ /* source is to the right more */
+ shift_right = (ppw + shift) * p->var.bits_per_pixel;
+ shift_left = -shift * p->var.bits_per_pixel;
+ }
+ /* general case, positive increment */
+ if (lineincr > 0) {
+ if (shift < 0)
+ n++;
+ do {
+ dst = (unsigned long *) dst1;
+ src = (unsigned long *) src1;
+
+ last = (fb_readl(src) & start_mask);
+
+ if (shift > 0)
+ fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+ for (j = 0; j < n; j++) {
+ dst++;
+ tmp = fb_readl(src);
+ src++;
+ fb_writel((last << shift_left) |
+ (tmp >> shift_right),dst);
+ last = tmp;
+ src++;
+ }
+ fb_writel(fb_readl(dst) | (last << shift_left), dst);
+ src1 += lineincr;
+ dst1 += lineincr;
+ } while (--height);
+ } else {
+ /* general case, negative increment */
+ if (shift > 0)
+ n++;
+ do {
+ dst = (unsigned long *) dst1;
+ src = (unsigned long *) src1;
+
+ last = (fb_readl(src) & end_mask);
+
+ if (shift < 0)
+ fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+ for (j = 0; j < n; j++) {
+ dst--;
+ tmp = fb_readl(src);
+ src--;
+ fb_writel((tmp << shift_left) |
+ (last >> shift_right),dst);
+ last = tmp;
+ src--;
+ }
+ fb_writel(fb_readl(dst) | (last >> shift_right), dst);
+ src1 += lineincr;
+ dst1 += lineincr;
+ } while (--height);
+ }
+ } else {
+ /* no shift needed */
+ if (lineincr > 0) {
+ /* positive increment */
+ do {
+ dst = (unsigned long *) (dst1 - start_index);
+ src = (unsigned long *) (src1 - start_index);
+
+ if (start_mask)
+ fb_writel(fb_readl(src) | start_mask, dst);
+
+ for (j = 0; j < n; j++) {
+ fb_writel(fb_readl(src), dst);
+ dst++;
+ src++;
+ }
+
+ if (end_mask)
+ fb_writel(fb_readl(src) | end_mask,dst);
+ src1 += lineincr;
+ dst1 += lineincr;
+ } while (--height);
+ } else {
+ /* negative increment */
+ do {
+ dst = (unsigned long *) dst1;
+ src = (unsigned long *) src1;
+
+ if (start_mask)
+ fb_writel(fb_readl(src) | start_mask, dst);
+ for (j = 0; j < n; j++) {
+ fb_writel(fb_readl(src), dst);
+ dst--;
+ src--;
+ }
+ src1 += lineincr;
+ dst1 += lineincr;
+ } while (--height);
+ }
+ }
+ }
+}
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.5.5-dj3/drivers/video/cfbfillrect.c Wed Dec 31 16:00:00 1969
+++ linux/drivers/video/cfbfillrect.c Mon Mar 11 15:09:43 2002
@@ -0,0 +1,189 @@
+/*
+ * Generic fillrect for frame buffers with packed pixels of any depth.
+ *
+ * Copyright (C) 2000 James Simmons (jsi...@li...)
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * NOTES:
+ *
+ * The code for depths like 24 that don't have integer number of pixels per
+ * long is broken and needs to be fixed. For now I turned these types of
+ * mode off.
+ *
+ * Also need to add code to deal with cards endians that are different than
+ * the native cpu endians. I also need to deal with MSB position in the word.
+ *
+ */
+#include <linux/string.h>
+#include <linux/fb.h>
+#include <asm/types.h>
+#include <video/fbcon.h>
+
+void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect)
+{
+ unsigned long start_index, end_index, start_mask = 0, end_mask = 0;
+ unsigned long height, ppw, fg, fgcolor;
+ int i, n, x2, y2, linesize = p->fix.line_length;
+ int bpl = sizeof(unsigned long);
+ unsigned long *dst;
+ char *dst1;
+
+ if (!rect->width || !rect->height) return;
+
+ /* We could use hardware clipping but on many cards you get around
+ * hardware clipping by writing to framebuffer directly. */
+ x2 = rect->dx + rect->width;
+ y2 = rect->dy + rect->height;
+ x2 = x2 < p->var.xres_virtual ? x2 : p->var.xres_virtual;
+ y2 = y2 < p->var.yres_virtual ? y2 : p->var.yres_virtual;
+ rect->width = x2 - rect->dx;
+ height = y2 - rect->dy;
+
+ /* Size of the scanline in bytes */
+ n = ((rect->width * p->var.bits_per_pixel) >> 3);
+ ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+
+ dst1 = p->screen_base + rect->dy * linesize + ((rect->dx * p->var.bits_per_pixel) >> 3);
+ start_index = ((unsigned long) dst1 & (bpl-1));
+ end_index = ((unsigned long)(dst1 + n) & (bpl-1));
+
+ if (p->fix.visual == FB_VISUAL_TRUECOLOR)
+ fg = fgcolor = ((u32 *)(p->pseudo_palette))[rect->color];
+ else
+ fg = fgcolor = rect->color;
+
+ for (i = 0; i < ppw-1; i++) {
+ fg <<= p->var.bits_per_pixel;
+ fg |= fgcolor;
+ }
+
+ if (start_index) {
+ start_mask = fg << (start_index << 3);
+ n -= (bpl - start_index);
+ }
+
+ if (end_index) {
+ end_mask = fg >> ((bpl - end_index) << 3);
+ n -= end_index;
+ }
+
+ n = n/bpl;
+
+ if (n <= 0) {
+ if (start_mask) {
+ if (end_mask)
+ end_mask &= start_mask;
+ else
+ end_mask = start_mask;
+ start_mask = 0;
+ }
+ n = 0;
+ }
+
+ if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) {
+ switch (rect->rop) {
+ case ROP_COPY:
+ do {
+ /* Word align to increases performace :-) */
+ dst = (unsigned long *) (dst1 - start_index);
+
+ if (start_mask) {
+#if BITS_PER_LONG == 32
+ fb_writel(fb_readl(dst) | start_mask, dst);
+#else
+ fb_writeq(fb_readq(dst) | start_mask, dst);
+#endif
+ dst++;
+ }
+
+ for ( i=0; i < n; i++) {
+#if BITS_PER_LONG == 32
+ fb_writel(fg, dst);
+#else
+ fb_writeq(fg, dst);
+#endif
+ dst++;
+ }
+
+ if (end_mask)
+#if BITS_PER_LONG == 32
+ fb_writel(fb_readl(dst) | end_mask, dst);
+#else
+ fb_writeq(fb_readq(dst) | end_mask, dst);
+#endif
+ dst1+=linesize;
+ } while (--height);
+ break;
+ case ROP_XOR:
+ do {
+ dst = (unsigned long *) (dst1 - start_index);
+#if BITS_PER_LONG == 32
+ fb_writel(fb_readl(dst) ^ start_mask, dst);
+#else
+ fb_writeq(fb_readq(dst) ^ start_mask, dst);
+#endif
+ for( i=0; i < n; i++) {
+ dst++;
+#if BITS_PER_LONG == 32
+ fb_writel(fb_readl(dst) ^ fg, dst);
+#else
+ fb_writeq(fb_readq(dst) ^ fg, dst);
+#endif
+ }
+
+ if (end_mask) {
+ dst++;
+#if BITS_PER_LONG == 32
+ fb_writel(fb_readl(dst) ^ end_mask, dst);
+#else
+ fb_writeq(fb_readq(dst) ^ end_mask, dst);
+#endif
+ }
+ dst1+=linesize;
+ } while (--height);
+ break;
+ }
+ } else {
+ /* Odd modes like 24 or 80 bits per pixel */
+ start_mask = fg >> (start_index * p->var.bits_per_pixel);
+ end_mask = fg << (end_index * p->var.bits_per_pixel);
+ /* start_mask =& PFILL24(x1,fg);
+ end_mask_or = end_mask & PFILL24(x1+width-1,fg); */
+
+ n = (rect->width - start_index - end_index)/ppw;
+
+ switch (rect->rop) {
+ case ROP_COPY:
+ do {
+ dst = (unsigned long *)dst1;
+ if (start_mask) *dst |= start_mask;
+ if ((start_index + rect->width) > ppw) dst++;
+
+ /* XXX: slow */
+ for (i = 0;i < n; i++) {
+ *dst++ = fg;
+ }
+ if (end_mask) *dst |= end_mask;
+ dst1+=linesize;
+ } while (--height);
+ break;
+ case ROP_XOR:
+ do {
+ dst = (unsigned long *)dst1;
+ if (start_mask) *dst ^= start_mask;
+ if ((start_mask + rect->width) > ppw) dst++;
+
+ for( i = 0; i < n; i++) {
+ *dst++ ^= fg; /* PFILL24(fg,x1+i); */
+ }
+ if (end_mask) *dst ^= end_mask;
+ dst1+=linesize;
+ } while (--height);
+ break;
+ }
+ }
+ return;
+}
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.5-dj3/drivers/video/cfbimgblt.c Wed Dec 31 16:00:00 1969
+++ linux/drivers/video/cfbimgblt.c Mon Mar 11 14:29:37 2002
@@ -0,0 +1,107 @@
+/*
+ * Generic BitBLT function for frame buffer with packed pixels of any depth.
+ *
+ * Copyright (C) June 1999 James Simmons
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * NOTES:
+ *
+ * This function copys a image from system memory to video memory. The
+ * image can be a bitmap where each 0 represents the background color and
+ * each 1 represents the foreground color. Great for font handling. It can
+ * also be a color image. This is determined by image_depth. The color image
+ * must be laid out exactly in the same format as the framebuffer. Yes I know
+ * their are cards with hardware that coverts images of various depths to the
+ * framebuffer depth. But not every card has this. All images must be rounded
+ * up to the nearest byte. For example a bitmap 12 bits wide must be two
+ * bytes width.
+ *
+ * FIXME
+ * The code for 24 bit is horrible. It copies byte by byte size instead of
+ * longs like the other sizes. Needs to be optimized.
+ *
+ * Also need to add code to deal with cards endians that are different than
+ * the native cpu endians. I also need to deal with MSB position in the word.
+ *
+ */
+#include <linux/string.h>
+#include <linux/fb.h>
+#include <asm/types.h>
+
+#include <video/fbcon.h>
+
+#define DEBUG
+
+#ifdef DEBUG
+#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt,__FUNCTION__,## args)
+#else
+#define DPRINTK(fmt, args...)
+#endif
+
+void cfb_imageblit(struct fb_info *p, struct fb_image *image)
+{
+ int ppw, shift, shift_right, shift_left, x2, y2, n, i, j, k, l = 7;
+ unsigned long tmp = ~0 << (BITS_PER_LONG - p->var.bits_per_pixel);
+ unsigned long fgx, bgx, fgcolor, bgcolor, eorx;
+ unsigned long end_index, end_mask, mask;
+ unsigned long *dst = NULL;
+ u8 *dst1, *src;
+
+ /*
+ * We could use hardware clipping but on many cards you get around hardware
+ * clipping by writing to framebuffer directly like we are doing here.
+ */
+ x2 = image->dx + image->width;
+ y2 = image->dy + image->height;
+ image->dx = image->dx > 0 ? image->dx : 0;
+ image->dy = image->dy > 0 ? image->dy : 0;
+ x2 = x2 < p->var.xres_virtual ? x2 : p->var.xres_virtual;
+ y2 = y2 < p->var.yres_virtual ? y2 : p->var.yres_virtual;
+ image->width = x2 - image->dx;
+ image->height = y2 - image->dy;
+
+ dst1 = p->screen_base + image->dy * p->fix.line_length +
+ ((image->dx * p->var.bits_per_pixel) >> 3);
+
+ ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+
+ src = image->data;
+
+ if (p->fix.visual == FB_VISUAL_TRUECOLOR) {
+ fgx = fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
+ bgx = bgcolor = ((u32 *)(p->pseudo_palette))[image->bg_color];
+ } else {
+ fgx = fgcolor = image->fg_color;
+ bgx = bgcolor = image->bg_color;
+ }
+
+ for (i = 0; i < ppw-1; i++) {
+ fgx <<= p->var.bits_per_pixel;
+ bgx <<= p->var.bits_per_pixel;
+ fgx |= fgcolor;
+ bgx |= bgcolor;
+ }
+ eorx = fgx ^ bgx;
+ l = 7;
+
+ for (i = 0; i < image->height; i++) {
+ dst = (unsigned long *) dst1;
+
+ for (j = image->width/ppw; j > 0; j--) {
+ mask = 0;
+
+ for (k = ppw; k > 0; k--) {
+ if (test_bit(l, src))
+ mask |= (tmp >> (p->var.bits_per_pixel*(k-1)));
+ l--;
+ if (l < 0) { l = 7; src++; }
+ }
+ fb_writel((mask & eorx)^bgx, dst);
+ dst++;
+ }
+ dst1 += p->fix.line_length;
+ }
+}
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/fbgen.c linux/drivers/video/fbgen.c
--- linux-2.5.5-dj3/drivers/video/fbgen.c Wed Mar 6 10:46:03 2002
+++ linux/drivers/video/fbgen.c Mon Mar 11 14:38:54 2002
@@ -444,63 +444,19 @@
if (con < 0 || info->var.activate & FB_ACTIVATE_ALL)
info->disp->var = info->var;
- if (!info->var.accel_flags) {
+ if (info->var.bits_per_pixel == 24) {
+#ifdef FBCON_HAS_CFB24
display->scrollmode = SCROLL_YREDRAW;
-#ifdef FBCON_HAS_ACCEL
- } else {
- display->scrollmode = SCROLL_YNOMOVE;
- display->dispsw = &fbcon_accel;
+ display->dispsw = &fbcon_cfb24;
return;
#endif
}
- switch (info->var.bits_per_pixel)
- {
-#ifdef FBCON_HAS_MFB
- case 1:
- display->dispsw = &fbcon_mfb;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB2
- case 2:
- display->dispsw = &fbcon_cfb2;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB4
- case 4:
- display->dispsw = &fbcon_cfb4;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB8
- case 8:
- display->dispsw = &fbcon_cfb8;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB16
- case 16:
- display->dispsw = &fbcon_cfb16;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB24
- case 24:
- display->dispsw = &fbcon_cfb24;
- break;
-#endif
-
-#ifdef FBCON_HAS_CFB32
- case 32:
- display->dispsw = &fbcon_cfb32;
- break;
+#ifdef FBCON_HAS_ACCEL
+ display->scrollmode = SCROLL_YNOMOVE;
+ display->dispsw = &fbcon_accel;
#endif
- default:
- display->dispsw = &fbcon_dummy;
- break;
- }
+ return;
}
/**
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.5-dj3/drivers/video/riva/fbdev.c Wed Mar 6 10:46:03 2002
+++ linux/drivers/video/riva/fbdev.c Wed Mar 6 10:46:50 2002
@@ -34,7 +34,6 @@
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
-#include <linux/selection.h>
#include <linux/tty.h>
#include <linux/slab.h>
#include <linux/delay.h>
diff -urN -X /home/jsimmons/dontdiff linux-2.5.5-dj3/drivers/video/vesafb.c linux/drivers/video/vesafb.c
--- linux-2.5.5-dj3/drivers/video/vesafb.c Wed Mar 6 10:46:04 2002
+++ linux/drivers/video/vesafb.c Mon Mar 11 14:53:23 2002
@@ -36,7 +36,6 @@
activate: FB_ACTIVATE_NOW,
height: -1,
width: -1,
-// accel_flags: FB_ACCELF_TEXT,
vmode: FB_VMODE_NONINTERLACED,
};
@@ -136,13 +135,13 @@
case 16:
if (info->var.red.offset == 10) {
/* 1:5:5:5 */
- ((u16*) (info->pseudo_palette))[regno] =
+ ((u32*) (info->pseudo_palette))[regno] =
((red & 0xf800) >> 1) |
((green & 0xf800) >> 6) |
((blue & 0xf800) >> 11);
} else {
/* 0:5:6:5 */
- ((u16*) (info->pseudo_palette))[regno] =
+ ((u32*) (info->pseudo_palette))[regno] =
((red & 0xf800) ) |
((green & 0xfc00) >> 5) |
((blue & 0xf800) >> 11);
@@ -179,9 +178,9 @@
fb_set_cmap: gen_set_cmap,
fb_setcolreg: vesafb_setcolreg,
fb_pan_display: vesafb_pan_display,
-// fb_fillrect: cfb_fillrect,
-// fb_copyarea: cfb_copyarea,
-// fb_imageblit: cfb_imageblit,
+ fb_fillrect: cfb_fillrect,
+ fb_copyarea: cfb_copyarea,
+ fb_imageblit: cfb_imageblit,
};
int __init vesafb_setup(char *options)
|
|
From: Antonino D. <ad...@po...> - 2002-03-08 06:54:36
|
Hi,
I was actually wondering how feasible it is to implement the GTF in the
framebuffer. The fb timings are in table format, and aside from that,
most drivers utilize timing tables which can really take a toll on
kernel resources. With GTF, you can have just have a small code that
given xres, yres, and one of the three: hsync, vrefresh, or pixelclock,
video timings can be generated. Another advantage is that it can also
generate non-discrete timings.
I've inserted code in modedb.c that really does not do anything but fill
an fb_videomode structure with all the values, given xres, yres, and
vrefresh, then prints the result. A lot of default values I've fixed as
#defines and they are based on US specs. They can probably be changed
through EDID/DDC, or as user-entered info.
The GTF with the default numbers seems to be acceptable for my display,
and also to some people who were willing to test the fb driver I'm
writing.
I'm not sure how universal/applicable/feasible this is, so I'd rather
ask this list for comments.
Thanks
Tony
I have these results for 640x480 @ 60Hz, and 800x600 @ 85Hz
#----------------------------------------------------------------------
Console: switching to colour frame buffer device 128x48
VESA GTF:
640x480 @ 60Hz
pixclock : 43103
left margin : 16
right margin: 80
upper margin: 1
lower margin: 13
hsync len : 64
vsync len : 3
VESA GTF:
800x600 @ 85Hz
pixclock : 17867
left margin : 40
right margin: 128
upper margin: 1
lower margin: 26
hsync len : 88
vsync len : 3
#---------------------------------------------------------------------------
Here's part of the output from the GTF spreadsheet (800x600 @ 85Hz) that
I've found in an FTP site. The numbers do corresponde but precision may be lost
especially for pixclock. Also, I haven't checked for all possible modes yet.
#----------------------------------------------------------------------------
THE VESA GENERALIZED TIMING FORMULA (GTF)
GTF SPREADSHEET BY ANDY MORRISH 1/5/97
HOR PIXELS 800PIXELS
VER PIXELS 600LINES
HOR FREQUENCY 53.550 kHz
VER FREQUENCY 85.000 Hz
PIXEL CLOCK 56.549 MHz 1 PIXELS
CHARACTER WIDTH 141.471 ns 8 PIXELS
SCAN TYPE NON-INT
PREDICTED H BLANK DUTY CYCLE 24.398 %
(from blanking formula)
HOR TOTAL TIME 18.674 us 132 CHARS
HOR ADDR TIME 14.147 us 100 CHARS
HOR BLANK TIME 4.527 us 32 CHARS
HOR BLANK+MARGIN TIME 4.527 us 32 CHARS
ACTUAL HOR BLANK DUTY CYCLE 24.242 %
ACT. HOR BLNK+MARGIN DUTY CYCLE 24.242 %
H LEFT MARGIN 0.000 us 0 CHARS
H FRONT PORCH 0.707 us 5 CHARS
HOR SYNC TIME 1.556 us 11 CHARS
H BACK PORCH 2.264 us 16 CHARS
H RIGHT MARGIN 0.000 us 0 CHARS
VER TOTAL TIME 11.765 ms 630.0 LINES
VER ADDR TIME 11.204 ms 600.0 LINES
VER BLANK TIME 0.560 ms 30.0 LINES
V TOP MARGIN 0.000 us 0.0 LINES
V FRONT PORCH 18.674 us 1.0 LINES
VER SYNC TIME 56.022 us 3.0 LINES
V BACK PORCH 485.528 us 26.0 LINES
V BOTTOM MARGIN 0.000 us 0.0 LINES
COMMENT: GTF Version1 Rev 1.0 Andy Morrish National Semiconductor 1/5/97
#--------------------------------------------------------------------------------------
Finally, here's part of modedb.c:
#define FLYBACK 550
#define FRONTPORCH 1
#define VSYNC_LEN 3
#define OFFSET 40
#define SCALEFACTOR 20
#define BLANKSCALE 128
#define GRADIENT 600
#include <asm/div64.h>
/**
* fb_get_gtf - gets video timings using VESA GTF
* @xres: horizontal resolution in pixels
* @yres: vertical resoltion in scanlines
* @refresh: refresh rate
* @gtf: pointer to fb_videomode structure
*
* Calculates required video timings using GTF
* given xres, yres and rr, then
* writes all timing values to @gtf
*/
static void fb_get_gtf(unsigned int xres, unsigned int yres,
unsigned int refresh, struct fb_videomode *gtf)
{
unsigned int long scratch;
unsigned int denom, hfreq, vblank, hblank, duty_cycle, m_val, htotal;
/* Estimate hsync using yres and refresh */
scratch = (unsigned long long) (yres + FRONTPORCH) *
(unsigned long long) (refresh) * 1000000;
denom = 1000000 - (refresh * FLYBACK);
do_div(scratch, denom);
hfreq = (u32) scratch;
/* Compute for vblank (vtotal - yres) given hsync*/
vblank = (hfreq * FLYBACK)/1000;
vblank = (vblank + 500)/1000 + FRONTPORCH;
/* Compute for hblank (htotal - xres) given hfreq and xres */
duty_cycle = (((OFFSET - SCALEFACTOR) * BLANKSCALE)/256 +
SCALEFACTOR) * 1000;
m_val = (BLANKSCALE * GRADIENT)/256;
m_val = (m_val * 1000000)/hfreq;
duty_cycle -= m_val;
hblank = (xres * duty_cycle)/(100000 - duty_cycle);
hblank = (hblank + 4) & ~7;
htotal = hblank + xres;
gtf->name = NULL;
gtf->refresh = refresh;
gtf->xres = xres;
gtf->yres = yres;
gtf->pixclock = 1000000000/((hfreq/1000) * htotal);
/* hsync_len: default to 8% of htotal */
gtf->hsync_len = (htotal * 8)/100;
gtf->hsync_len = (gtf->hsync_len + 4) & ~7;
gtf->left_margin = (hblank >> 1) - gtf->hsync_len;
gtf->left_margin = (gtf->left_margin + 4) & ~7;
gtf->right_margin = gtf->hsync_len + gtf->left_margin;
gtf->upper_margin = FRONTPORCH;
gtf->vsync_len = VSYNC_LEN;
gtf->lower_margin = vblank - (FRONTPORCH + VSYNC_LEN);
gtf->sync = FB_VMODE_NONINTERLACED;
/* What do we place here */
gtf->vmode = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT;
}
/**
* fb_find_mode - finds a valid video mode
* @var: frame buffer user defined part of display
* @info: frame buffer info structure
* @mode_option: string video mode to find
* @db: video mode database
* @dbsize: size of @db
* @default_mode: default video mode to fall back to
* @default_bpp: default color depth in bits per pixel
*
* Finds a suitable video mode, starting with the specified mode
* in @mode_option with fallback to @default_mode. If
* @default_mode fails, all modes in the video mode database will
* be tried.
*
* Valid mode specifiers for @mode_option:
*
* <xres>x<yres>[-<bpp>][@<refresh>] or
* <name>[-<bpp>][@<refresh>]
*
* with <xres>, <yres>, <bpp> and <refresh> decimal numbers and
* <name> a string.
*
* NOTE: The passed struct @var is _not_ cleared! This allows you
* to supply values for e.g. the grayscale and accel_flags fields.
*
* Returns zero for failure, 1 if using specified @mode_option,
* 2 if using specified @mode_option with an ignored refresh rate,
* 3 if default mode is used, 4 if fall back to any valid mode.
*
*/
int __init fb_find_mode(struct fb_var_screeninfo *var,
struct fb_info *info, const char *mode_option,
const struct fb_videomode *db, unsigned int dbsize,
const struct fb_videomode *default_mode,
unsigned int default_bpp)
{
int i, j;
/* Set up defaults */
if (!db) {
db = modedb;
dbsize = sizeof(modedb)/sizeof(*modedb);
}
if (!default_mode)
default_mode = &modedb[DEFAULT_MODEDB_INDEX];
if (!default_bpp)
default_bpp = 8;
/* Did the user specify a video mode? */
if (mode_option || (mode_option = global_mode_option)) {
const char *name = mode_option;
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
int yres_specified = 0;
for (i = namelen-1; i >= 0; i--) {
switch (name[i]) {
case '@':
namelen = i;
if (!refresh_specified && !bpp_specified &&
!yres_specified) {
refresh = my_atoi(&name[i+1]);
refresh_specified = 1;
} else
goto done;
break;
case '-':
namelen = i;
if (!bpp_specified && !yres_specified) {
bpp = my_atoi(&name[i+1]);
bpp_specified = 1;
} else
goto done;
break;
case 'x':
if (!yres_specified) {
yres = my_atoi(&name[i+1]);
yres_specified = 1;
} else
goto done;
break;
case '0'...'9':
break;
default:
goto done;
}
}
if (i < 0 && yres_specified) {
xres = my_atoi(name);
res_specified = 1;
}
done:
/* Tony: VESA GTF */
DPRINTK("Trying VESA GTF\n");
struct fb_videomode gtf;
fb_get_gtf(xres, yres, refresh, >f);
printk("VESA GTF:\n"
"%dx%d @ %dHz\n"
"pixclock : %d\n"
"left margin : %d\n"
"right margin: %d\n"
"upper margin: %d\n"
"lower margin: %d\n"
"hsync len : %d\n"
"vsync len : %d\n",
gtf.xres, gtf.yres, gtf.refresh, gtf.pixclock,
gtf.left_margin, gtf.right_margin, gtf.upper_margin,
gtf.lower_margin, gtf.hsync_len, gtf.vsync_len);
for (i = refresh_specified; i >= 0; i--) {
DPRINTK("Trying specified video mode%s\n",
i ? "" : " (ignoring refresh rate)");
for (j = 0; j < dbsize; j++)
if ((name_matches(db[j], name, namelen) ||
(res_specified && res_matches(db[j], xres, yres))) &&
(!i || db[j].refresh == refresh) &&
__fb_try_mode(var, info, &db[j], bpp))
return 2-i;
}
}
DPRINTK("Trying default video mode\n");
if (__fb_try_mode(var, info, default_mode, default_bpp))
return 3;
DPRINTK("Trying all modes\n");
for (i = 0; i < dbsize; i++)
if (__fb_try_mode(var, info, &db[i], default_bpp))
return 4;
DPRINTK("No valid mode found\n");
return 0;
}
Tony
|
|
From: Geert U. <ge...@li...> - 2002-03-04 12:55:09
|
On Wed, 27 Feb 2002, Andrey Ulanov wrote: > i wrote intel740 frame-buffer driver. i tested it with my hardware > with kernels 2.4.8, 2.4.14, 2.4.17 and 2.5.5. > > you can download the patch > http://i740fbdev.sourceforge.net/download/patch-2.5.5-i740fb-020225.diff.gz > > if anybody tested it, please drop me a report Since i740fb uses resource management, please move its initialization up in drivers/video/fbmem.c. BTW, I also noticed a typo (`retrun' instead of `return'). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
754 messages has been excluded from this view by a project administrator.
