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: Geert U. <ge...@li...> - 2002-11-23 21:09:31
|
On Fri, 22 Nov 2002, James Simmons wrote:
> Geert is busy porting the Amigia driver to the new api. That means all the
> ilbm, iplan stuff will go away :-)
I have first code for amifb, but it doesn't work yet, due to other problems
with 2.5.x on Amiga. I hope to fix these tomorrow...
Besides, we still need someone to take care of the Atari 2-byte interleaved
bitplanes (iplan2p*), since I don't have the hardware, and am not 100% sure how
they work. But reviving 2.5.x on Atari will be even harder...
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: Josh M. <jb...@jo...> - 2002-11-23 20:45:16
|
On Sat, 23 Nov 2002, Geert Uytterhoeven wrote:
> On Fri, 22 Nov 2002, Josh Myer wrote:
> > I've got an EPIA board, with a trident CyberBlade chipset. Does anyone
> > have doco on this chipset? The random Xfree stuff available from VIA is
>
> Is this the Cyber9397? I have some PDF docs about that chip at home.
>
> Gr{oetje,eeting}s,
>
> Geert
Unfortunately, it's a CyberBlade i1, which looks to be distinct from that
chip in the driver source i have here.
lspci -vv:
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev
6a) (prog-if 00 [VGA])
Subsystem: Trident Microsystems CyberBlade/i1
--
/jbm, but you can call me Josh. Really, you can!
"What's a metaphor?" "For sheep to graze in"
7958 1C1C 306A CDF8 4468 3EDE 1F93 F49D 5FA1 49C4
|
|
From: Geert U. <ge...@li...> - 2002-11-23 20:36:25
|
On Fri, 22 Nov 2002, Josh Myer wrote:
> I've got an EPIA board, with a trident CyberBlade chipset. Does anyone
> have doco on this chipset? The random Xfree stuff available from VIA is
Is this the Cyber9397? I have some PDF docs about that chip at home.
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: Jochen R. <jo...@pa...> - 2002-11-23 11:19:46
|
Hello, I am in the process of porting Linux to the IBM NetworkStation series of thin clients. I am currently working on the NS 1000 model, which is based on a 200 MHz 603ev and some PReP support hardware, NatSemi SuperIO, S3TrioV2/DX, and AMD 10/100 Ethernet for the Ethernet models. See http://sourceforge.net/projects/networkstation/ for patches. I got S3triofb working on the machine as a crude hack with static mappings, etc. The NS models do not have open firmware or residual data. I plan to set up mock residual data in the boot loader, but that does not really belong here. My plan for the S3 Trio driver was to make it depend on PCI device configuration only, and use OF information if present to determine things like the default graphics mode. Here are some questions I have: - Who is the current maintainer for the S3triofb? Maybe I wasn't looking in the right places, but I didn't figure it out. I emailed Peter de Schrijver, who is listed in the driver as author, but I haven't heard back. - The current (2.4.19 for me) S3triofb has a workaround in it to reset the PCI BAR0 register to 0xc6000000, with size 64 megs. I a) want to figure out for what model this was necessary to add some sort of fix, and b) this does not make sense to me as the proper address for a 64 meg window wouldn't be 0xc6000000, but something naturally aligned, like 0xc[48]000000. Very weird. - I have not been able to find any programming reference for the S3 chip in my hardware, V2/DX. I have found s3.txt somewhere, I forget where -- immense help so far in understanding the current driver. Does anybody have documents for these chips? I tried s3graphics/VIA and got no response. I know that the XFree86 guys have docs as pdf, but I am not registered as a developer or contributor, and I was told this would take months to accomplish. - I looked briefly at http://gtf.org/garzik/kernel/files/s3fb/ -- is this code functional? I know, I should just ask Jeff Garzik. - I started out wanting to support the V2/DX in my box. Then it occured to me that, hey, I could support all Trio64 and 32 models while I'm at it. Next thing you know, you arrive at s3fb above. OTOH, Trios aren't exactly cutting edge, and S3 is pretty dead these days. Maybe the s3fb above is not in the mainline kernel for a reason? On Intel machines this hardware is probably supported by the vesa drivers, so there it not much incentive from that perspective. What do people here think? Regards, Jochen |
|
From: Antonino D. <ad...@po...> - 2002-11-22 20:04:58
|
On Sat, 2002-11-23 at 00:04, James Simmons wrote: > > > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > > but it already outperforms fb-2.4 especially at high color depths). > > Compared with the previous patch I submitted, this change is > > non-intrusive, so no other changes are required. > > > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > > only) > > > > 3. logo drawing for directcolor visuals. > > Please send me those patches ASAP!!! I will linclude them right away. > Okay. Instead of patches, I'll just attach a file with the targeted functions which you can choose to cut and paste or modify as you see fit. vga16fb_imageblit in vga16fb.c fbcon_show_logo in fbcon.c fbcon_accel_putcs in fbcon-accel.c |
|
From: Antonino D. <ad...@po...> - 2002-11-22 19:19:53
|
On Sat, 2002-11-23 at 00:04, James Simmons wrote: > > > Any patches in the meantime? I have a few changes I can pass to you: > > Yes of course!!!! > I mean, do you have patches against vanilla linux? I currently don't have bk right now. I browsed the bk repository, and it seems you made a lot of changes. > > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > > but it already outperforms fb-2.4 especially at high color depths). > > Compared with the previous patch I submitted, this change is > > non-intrusive, so no other changes are required. > > > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > > only) > > > > 3. logo drawing for directcolor visuals. > > Please send me those patches ASAP!!! I will linclude them right away. I can, but against 2.5.48 only + your old fbdev.diff. You might have a hard time merging it to your repository. > > > The above should complete softaccel support for most hardware except for > > the more esoteric ones (mostly authored by Geert). > > Geert is busy porting the Amigia driver to the new api. That means all the > ilbm, iplan stuff will go away :-) > > > Also cfbcursor is a bit misleading, no? It implies support for > > packed-pixels only, but I already use it with vga16fb. > > OOps. You are right. What should we call it? > I don't know, gen_cursor? Tony |
|
From: James S. <jsi...@in...> - 2002-11-22 19:06:00
|
> Any patches in the meantime? I have a few changes I can pass to you: Yes of course!!!! > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > but it already outperforms fb-2.4 especially at high color depths). > Compared with the previous patch I submitted, this change is > non-intrusive, so no other changes are required. > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > only) > > 3. logo drawing for directcolor visuals. Please send me those patches ASAP!!! I will linclude them right away. > The above should complete softaccel support for most hardware except for > the more esoteric ones (mostly authored by Geert). Geert is busy porting the Amigia driver to the new api. That means all the ilbm, iplan stuff will go away :-) > Also cfbcursor is a bit misleading, no? It implies support for > packed-pixels only, but I already use it with vga16fb. OOps. You are right. What should we call it? |
|
From: Antonino D. <ad...@po...> - 2002-11-22 18:52:45
|
On Fri, 2002-11-22 at 22:52, James Simmons wrote: > > Hi folks!!! > > Just to let you know where I am for the fbdev developement. I finished > off the latest api changes. The cursor api has been cleaned up and it uses > fb_image struct. This makes life easier. > I ported over the ATI 128 driver to the latest changes. I finished the > 3Dfx driver yesterday and got the ATI mach 64 driver done this morning. > I will test it tomorrow. Then I will finsih up the NVIDIA driver. After > that I'm going to push the code to linus. Any patches in the meantime? I have a few changes I can pass to you: 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch but it already outperforms fb-2.4 especially at high color depths). Compared with the previous patch I submitted, this change is non-intrusive, so no other changes are required. 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes only) 3. logo drawing for directcolor visuals. The above should complete softaccel support for most hardware except for the more esoteric ones (mostly authored by Geert). Also cfbcursor is a bit misleading, no? It implies support for packed-pixels only, but I already use it with vga16fb. Tony |
|
From: James S. <jsi...@in...> - 2002-11-22 17:53:51
|
Hi folks!!! Just to let you know where I am for the fbdev developement. I finished off the latest api changes. The cursor api has been cleaned up and it uses fb_image struct. This makes life easier. I ported over the ATI 128 driver to the latest changes. I finished the 3Dfx driver yesterday and got the ATI mach 64 driver done this morning. I will test it tomorrow. Then I will finsih up the NVIDIA driver. After that I'm going to push the code to linus. I started to hack at fbcon.c but realized it is such a mess I am going to rewrite it from scratch. This will be after the push to linus. I plan to use MDA console and create a modular fbcon that I can play with at will. The other annoucement is I have started to look for funding for this developement. At present I haven't found anything. I realized for the fbdev and console changes to be done I need to devote all my time to do this. To do this will require funding so I can pay my most basic bills. Wish me luck. |
|
From: Josh M. <jb...@jo...> - 2002-11-22 17:50:52
|
Hi, I've got an EPIA board, with a trident CyberBlade chipset. Does anyone have doco on this chipset? The random Xfree stuff available from VIA is less-than-enlightening (I'm not familiar with X internals). I'm basically just interested in getting FB working for NTSC output. Someone was working on this in the VIA forums, but i haven't noticed any output from him recently. Pointers to documentation/other posts on this are greatly appreciated. -- /jbm, but you can call me Josh. Really, you can! "What's a metaphor?" "For sheep to graze in" 7958 1C1C 306A CDF8 4468 3EDE 1F93 F49D 5FA1 49C4 |
|
From: James S. <jsi...@in...> - 2002-11-21 18:47:26
|
> does 2.4.19 support geforce4 ti4200 in accelerated mode (video=riva:....) > > i couldnt manage to get it work, tnt2 works. > > here is my lilo append line: No. That is a new card so the driver needs to be patched to support it. |
|
From: James S. <jsi...@in...> - 2002-11-21 18:39:57
|
> Excellent! Two other questions (not necessarily related): > > A) Is it (or will it ever be) possible to run dual head > using two different cards (like radeon & riva-tnt2)? I know > there is still much work to be done, but I was curious if > this was even remotely possible. Sorta hate to let a good > video card go to waste if you know what I mean :-). Well that depends on if it is possible to initialize the card fully without using the graphics BIOS. To my current knowledge the Matrox card can do this and it is possible for the 3Dfx family of cards. This I have seen in the docs. As for NVIDIA cards they don't release that info and ATI is also funny about release such info as well :-( > XFree-4.2? I only ask because the XFree modelines are all > determined by i2c DDC probing, thus there are none in the Ah DDC support. I really wanted to add that into the fbdev layer but unfortunely I don't have the time to do that :-( Only if I did fbdev for a living. |
|
From: James S. <jsi...@in...> - 2002-11-21 17:25:58
|
> > > console doesn't show a single pixel.
> >
> > :-( Can you post your .config file.
>
> Attached.
Hm. Strange. It should work. Can you get serial console working?
> I did some changes to sgivwfb.c to make it compilable, patch attached.
> Can you take a look at it ?
Applied your patch to the BK tree.
> > I will be posting a new fbdev patch today against 2.5.48 today. Giev it a
> > try.
>
> Didn't see proposed fbdev patch yet :(
Sorry about that. You are not the only one that has asked me. Also I
keep getting lots of error reports about drivers being broken. The problem
is having enough time. For example I haven't found the time to create this
patch. This brings up a serious point which I have been wrestling with. The
framebuffer layer has been broken for a long time durning the 2.5.X cycle.
The problem is both maintainers of this subsystem, Geert and I, both have
very little time to work on it. For both of us we don't work on the
framebuffer code for a living. I work with wireless networking cards. I
work 8 hours a day on networking code and travel 3 hours total every day
to work. Including eating a sleeping and I have at most 1 to 2 hours a day
to work on the framebuffer stuff. Weekends I have to do other survial
things like buy food. So the framebuffer developement has gone at a
snail pace and will continue to do so unless things change. I estimate
about 20+ more versions before the framebuffer layer properly works.
It pains me that this is happening. I really enjoy working on the
framebuffer and console layer. So I have been thinking about what to
do ? One which is the most likely is to step down from maintaintership
and hope someone else who can devote there full time and energy to it
can take over. Will someone else take over? I seriously doubt it. We all
have to make a living and that means working on things the linux industry
cares about which is only server stuff. So I except the framebuffer layer
will go into serious code decay. So the best situtation which I except to
happen is that I finish as much as I can for the fbdev layer and then
step down.
I have tried to look for work locallly (can't really affored to move
cross country very few years) relating to the framebuffer layer. In my
search I only found one company that seemed interested in this developement,
strangeberry (http://www.strangeberry.com). I sent them my resume but
never heard from them. As for funding I serious doubt that would happen
since it isn't server related. The reality is for proper maintiance of any
subsystem you need people hired to solely work to keep it going.
Unfortunely the framebuffer layer is one of those few ones that doesn't
have that.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@us...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: Steve L. <st...@mv...> - 2002-11-21 00:56:26
|
Geert Uytterhoeven wrote: >On 13 Nov 2002, Benjamin Herrenschmidt wrote: > > >>On Fri, 2002-11-08 at 16:28, Steven Newbury wrote: >> >> >>>Is atyfb in 2.4 known to work with recent Mach64 chips like Rage XL? >>>When I install the driver it detects the chip but results in just a >>>black screen. I also noticed that it detects WRAM, whereas I am certain >>>it should be SGRAM. The XFree86 driver detects everything ok and just >>>works. >>> >>> >>Well, I don't know if Geert still have much time to maintain >>this driver, any help implementing the missing features would >>be nice ;) >> >> > >Erhm, not really... > >For RAGE XL support, you want to contact Steve Longerbeam <st...@mv...>. > I reverse-engineered ATI's video BIOS on the Xpert98 PCI card (RageXL) using a PCI bus analyzer. Got atyfb to work on embedded platforms and PC's that way. It could work with other RageXL-based cards with some tweaking. I'll give you the source if you're interested. -- Steve Longerbeam MontaVista Software, Inc. office:408-328-9008, fax:408-328-3875 http://www.mvista.com |
|
From: James S. <jsi...@in...> - 2002-11-18 19:57:23
|
I just finished the aty128 driver last night to tha lastest api. I haven't commited just yet. I started to test the 3Dfx driver and will work on the riva driver tonight. |
|
From: Geert U. <ge...@li...> - 2002-11-14 11:10:45
|
On 13 Nov 2002, Benjamin Herrenschmidt wrote:
> On Fri, 2002-11-08 at 16:28, Steven Newbury wrote:
> > Is atyfb in 2.4 known to work with recent Mach64 chips like Rage XL?
> > When I install the driver it detects the chip but results in just a
> > black screen. I also noticed that it detects WRAM, whereas I am certain
> > it should be SGRAM. The XFree86 driver detects everything ok and just
> > works.
>
> Well, I don't know if Geert still have much time to maintain
> this driver, any help implementing the missing features would
> be nice ;)
Erhm, not really...
For RAGE XL support, you want to contact Steve Longerbeam <st...@mv...>.
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: Benjamin H. <be...@ke...> - 2002-11-12 23:09:30
|
On Fri, 2002-11-08 at 16:28, Steven Newbury wrote: > Is atyfb in 2.4 known to work with recent Mach64 chips like Rage XL? > When I install the driver it detects the chip but results in just a > black screen. I also noticed that it detects WRAM, whereas I am certain > it should be SGRAM. The XFree86 driver detects everything ok and just > works. Well, I don't know if Geert still have much time to maintain this driver, any help implementing the missing features would be nice ;) > I have also noticed that the radeonfb driver lacks support for > initialising the card if the BIOS hasn't already done it. I have > recently changed from a matrox setup where the matroxfb driver would > initialise any matrox cards found irrespective of whether the BIOS > decided to do it unless it was told not to. Is there any chance that > this functionality is going to be added to the radeonfb driver? In > 2.5/6 perhaps? If you can get ATI to provide POST code for every single ASIC rev. out there, that may be a good start. Ben. |
|
From: James S. <jsi...@ph...> - 2002-11-12 17:45:29
|
IT will be fixed in the next change set. On Mon, 11 Nov 2002, Michael Kummer wrote: > make -f scripts/Makefile.build obj=drivers/video/riva > gcc -Wp,-MD,drivers/video/riva/.fbdev.o.d -D__KERNEL__ -Iinclude -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 > -march=i686 -malign-functions=4 -Iarch/i386/mach-generic -nostdinc > -iwithprefix include -DKBUILD_BASENAME=fbdev -c -o > drivers/video/riva/fbdev.o drivers/video/riva/fbdev.c > drivers/video/riva/fbdev.c: In function `riva_set_dispsw': > drivers/video/riva/fbdev.c:665: structure has no member named `type' > drivers/video/riva/fbdev.c:666: structure has no member named `type_aux' > drivers/video/riva/fbdev.c:667: structure has no member named `ypanstep' > drivers/video/riva/fbdev.c:668: structure has no member named `ywrapstep' > drivers/video/riva/fbdev.c:677: structure has no member named > `line_length' > drivers/video/riva/fbdev.c:678: structure has no member named `visual' > drivers/video/riva/fbdev.c:686: structure has no member named > `line_length' > drivers/video/riva/fbdev.c:687: structure has no member named `visual' > drivers/video/riva/fbdev.c:695: structure has no member named > `line_length' > drivers/video/riva/fbdev.c:696: structure has no member named `visual' > drivers/video/riva/fbdev.c: In function `rivafb_get_fix': > drivers/video/riva/fbdev.c:1294: structure has no member named `type' > drivers/video/riva/fbdev.c:1295: structure has no member named `type_aux' > drivers/video/riva/fbdev.c:1296: structure has no member named `visual' > drivers/video/riva/fbdev.c:1302: structure has no member named > `line_length' > drivers/video/riva/fbdev.c: In function `rivafb_pan_display': > drivers/video/riva/fbdev.c:1611: structure has no member named > `line_length' > drivers/video/riva/fbdev.c:1586: warning: `base' might be used > uninitialized in this function > drivers/video/riva/fbdev.c: At top level: > drivers/video/riva/fbdev.c:1748: unknown field `fb_get_fix' specified in > initializer > drivers/video/riva/fbdev.c:1748: warning: initialization from incompatible > pointer type > drivers/video/riva/fbdev.c:1749: unknown field `fb_get_var' specified in > initializer > drivers/video/riva/fbdev.c:1749: warning: initialization from incompatible > pointer type > make[3]: *** [drivers/video/riva/fbdev.o] Error 1 > make[2]: *** [drivers/video/riva] Error 2 > make[1]: *** [drivers/video] Error 2 > make: *** [drivers] Error 2 > > > |
|
From: L.Y.Mesentsev <L.M...@tv...> - 2002-11-12 09:52:25
|
Hi All, Recently I've purchased a settopbox from AllWell ( http://www.gctglobal.com/Products/Set_Top_Box/Metallic6086N2/metallic6086n2.html ) equipped with TVIA CyberPro 5005 chipset. In order to use it with DirectFB + VDR under Linux I'm looking for framebuffer driver for it. The only driver I've found is cyber2000fb available with a current kernels and it claims to support ex-IGS (now TVIA) CyberPro 5000 chipsets, that should be compatible with 5005 chipsets ( I have a full complete documentation on my chipset and it seems to be true ). The problem is that after cyber2000fb.o is correctly loaded into the kernel ( it properly recognizes 500X chipset, video memory amount and don't log warnings either errors ) - I see a white square on the screen ( ~ 640x480 on 720x576 ) traced with weird green diagonal lines. When I try to launch any example from DirectFB ( 640x480x16 60Hz for instance ) - the screen becomes flicking and BW, but I can see the graphic output ( images & animation ). Unfortunately I have not enough skill to solve this problem myself, but I have a full set of documentation for 500X chipset and big desire to learn. Please, help me to make this chipset work - any help will be appreciated. |
|
From: Scott H. <she...@si...> - 2002-11-11 23:28:17
|
I get this error while trying to compile the radeonfb on 2.4.47 gcc -Wp,-MD,drivers/video/.radeonfb.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=radeonfb -c -o drivers/video/radeonfb.o drivers/video/radeonfb.c drivers/video/radeonfb.c:605: unknown field `fb_get_fix' specified in initializer drivers/video/radeonfb.c:605: warning: initialization from incompatible pointer type drivers/video/radeonfb.c:606: unknown field `fb_get_var' specified in initializer drivers/video/radeonfb.c:606: warning: initialization from incompatible pointer type drivers/video/radeonfb.c: In function `radeon_set_dispsw': drivers/video/radeonfb.c:1385: structure has no member named `type' drivers/video/radeonfb.c:1386: structure has no member named `type_aux' drivers/video/radeonfb.c:1387: structure has no member named `ypanstep' drivers/video/radeonfb.c:1388: structure has no member named `ywrapstep' drivers/video/radeonfb.c:1397: structure has no member named `visual' drivers/video/radeonfb.c:1398: structure has no member named `line_length' drivers/video/radeonfb.c:1405: structure has no member named `visual' drivers/video/radeonfb.c:1406: structure has no member named `line_length' drivers/video/radeonfb.c:1413: structure has no member named `visual' drivers/video/radeonfb.c:1414: structure has no member named `line_length' drivers/video/radeonfb.c:1421: structure has no member named `visual' drivers/video/radeonfb.c:1422: structure has no member named `line_length' drivers/video/radeonfb.c: In function `radeonfb_get_fix': drivers/video/radeonfb.c:1514: structure has no member named `type' drivers/video/radeonfb.c:1515: structure has no member named `type_aux' drivers/video/radeonfb.c:1516: structure has no member named `visual' drivers/video/radeonfb.c:1522: structure has no member named `line_length' drivers/video/radeonfb.c: In function `radeonfb_set_var': drivers/video/radeonfb.c:1578: structure has no member named `line_length' drivers/video/radeonfb.c:1579: structure has no member named `visual' drivers/video/radeonfb.c:1590: structure has no member named `line_length' drivers/video/radeonfb.c:1591: structure has no member named `visual' drivers/video/radeonfb.c:1606: structure has no member named `line_length' drivers/video/radeonfb.c:1607: structure has no member named `visual' drivers/video/radeonfb.c:1619: structure has no member named `line_length' drivers/video/radeonfb.c:1620: structure has no member named `visual' drivers/video/radeonfb.c: At top level: drivers/video/radeonfb.c:2487: warning: `fbcon_radeon8' defined but not used drivers/video/radeonfb.c:598: warning: `radeon_read_OF' declared `static' but never defined drivers/video/radeonfb.c:1710: warning: `radeonfb_set_cmap' defined but not used make[3]: *** [drivers/video/radeonfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-2.5.47' make: *** [stamp-build] Error 2 |
|
From: Michael K. <mi...@ku...> - 2002-11-11 10:06:05
|
make -f scripts/Makefile.build obj=drivers/video/riva gcc -Wp,-MD,drivers/video/riva/.fbdev.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -Iarch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=fbdev -c -o drivers/video/riva/fbdev.o drivers/video/riva/fbdev.c drivers/video/riva/fbdev.c: In function `riva_set_dispsw': drivers/video/riva/fbdev.c:665: structure has no member named `type' drivers/video/riva/fbdev.c:666: structure has no member named `type_aux' drivers/video/riva/fbdev.c:667: structure has no member named `ypanstep' drivers/video/riva/fbdev.c:668: structure has no member named `ywrapstep' drivers/video/riva/fbdev.c:677: structure has no member named `line_length' drivers/video/riva/fbdev.c:678: structure has no member named `visual' drivers/video/riva/fbdev.c:686: structure has no member named `line_length' drivers/video/riva/fbdev.c:687: structure has no member named `visual' drivers/video/riva/fbdev.c:695: structure has no member named `line_length' drivers/video/riva/fbdev.c:696: structure has no member named `visual' drivers/video/riva/fbdev.c: In function `rivafb_get_fix': drivers/video/riva/fbdev.c:1294: structure has no member named `type' drivers/video/riva/fbdev.c:1295: structure has no member named `type_aux' drivers/video/riva/fbdev.c:1296: structure has no member named `visual' drivers/video/riva/fbdev.c:1302: structure has no member named `line_length' drivers/video/riva/fbdev.c: In function `rivafb_pan_display': drivers/video/riva/fbdev.c:1611: structure has no member named `line_length' drivers/video/riva/fbdev.c:1586: warning: `base' might be used uninitialized in this function drivers/video/riva/fbdev.c: At top level: drivers/video/riva/fbdev.c:1748: unknown field `fb_get_fix' specified in initializer drivers/video/riva/fbdev.c:1748: warning: initialization from incompatible pointer type drivers/video/riva/fbdev.c:1749: unknown field `fb_get_var' specified in initializer drivers/video/riva/fbdev.c:1749: warning: initialization from incompatible pointer type make[3]: *** [drivers/video/riva/fbdev.o] Error 1 make[2]: *** [drivers/video/riva] Error 2 make[1]: *** [drivers/video] Error 2 make: *** [drivers] Error 2 -- best regards Michael Kummer -- Michael Kummer - [A]ustrian [E]lite [S]printer Lieferinger-Hauptstrasse 47 - A 5020 Salzburg Mobile: +43 664 3333995 EMail: mi...@ku... Web: http://www.sprinter.cc |
|
From: Michal C. <ci...@li...> - 2002-11-11 09:36:09
|
Hi Current radeonfb causes to switch off monitor when I change video mode (eg. using fbset), but changing vts corrected it (calling 'fbset something; chvt 2; chvt 1;' worked fine). I took a look into radeonfb source and attempted to make quick fix for this issue. I saw there some "absurd hack" that seemed to me like thing that could solve my problem so I moved it into other place and it now works. I have Radeon 7500 QW and the patched radeonfb seems to work for me, but I'm not really sure if I moving that "absurd hack" doesn't cause any problems with other cards elsewhere. If you thing it won't please apply it, it you thing it would, then probably just adding that code should work (= apply just + part of my patch). I'm not on linux-fbdev-devel list, so please CC me the replies... Regards Michal Cihar http://cihar.liten.cz |
|
From: Meelis R. <mr...@li...> - 2002-11-11 09:14:19
|
SN> Is atyfb in 2.4 known to work with recent Mach64 chips like Rage XL? I did run a sparc64 with builtin Rage XL for about a year (2.4.18 time), it worked fine. Don't remember the type of the RAM but it had 8M. At first I had a problem with pixel clock frequency - the kernel new a higer value for XL than the sparc64 implemented and so the description of XL in kernel driver got changed for lower clock. But I doubt this helps you :( -- Meelis Roos (mr...@li...) |
|
From: Sven L. <lu...@dp...> - 2002-11-09 07:52:31
|
On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote: > > How, well, maybe i should wait for the new patches from James to be > > accepted into the linus tree. > > > > Notice, maybe this is due to me not having defined yet any of the > > check_var, set_par, blank, ... functions, but my idea, for the howto > > afterward, was to write first the most minimal working fbdev. > > > > BTW, should i work on james BK tree directly ? Is there an howto on how > > to do that ? Or could it be possible to get a patch against 2.5.44 ? > > > Try Documentation/BK-usage. You will need a very fat pipe, then for a > start, > > bk clone bk://fbdev.bkbits.net/fbdev-2.5 How the hell can i use this ? i don't have any bk installed, and i doubt bk will ever be debian packaged so i will have to clutter my system, and they ask me about some collection of stupid questions before i can download, and finally it is not even possible to download this stuff. I suppose there is another free solution for downloading the bk kernel, does anyone have a link to it or to documentation about how to do it ? Friendly, Sven Luther |
|
From: Bom Luzares-D. <bo...@oa...> - 2002-11-09 02:30:57
|
-----Original Message----- From: James Simmons <jsi...@in...> To: Antonino Daplas <ad...@po...> Cc: Linux Fbdev development list <lin...@li...> Date: Friday, November 08, 2002 8:03 AM Subject: Re: [Linux-fbdev-devel] [BK fbdev updates] > >> > fbcon_switch has to be rewritten. I'm going threw the process of cleaning >> > up the upper fbcon layer. Its such a mess. Yuck!!! >> Thank goodness for this :) I was already thinking of adding an 'Option >> Usefbdev' for the xfree86 driver. > >There is already a option like that for XFree86. Yes, but not all drivers support it, I think only one of the ATI's. > >> > Yes!!! Of course there is the issue is the framebuffer that actual one >> > used for vgacon or is it independent, thinking multihead here. >> > >> I was trying to confirm if vgacon should restore its own state or not. >> >> But this one is neat :) I added VGA save/restore state routines to >> fb_open() and fb_release(). I was able to boot to a VGA console, fired >> up XFBDev and DirectFB and exited back again to a VGA console. DirectFB >> came back without problems, XFBDev needed a console reset. > >WOW!!! That is way to awesome. I have always wanted to see that actually >work. > Yeah, I love it too :) >> I guess the save/restore state routines will only be needed for graphics >> card with a VGA core. I think multiple graphics card or multi-head >> systems will not be affected since the driver will only be >> saving/restoring its own hardware anyway. > >Correct. One thing I do like is when you insmod a driver it doesn't change >the mode. For example for the neomagic fbdev driver I compiled as a module >and then insmod while using vgacon. Its didn't change the graphics mode so >I was able to find a nasty bug. I could change the video mode once I did a >set_var via userland. > Right, insmoding fbdev does not change the mode, at least that's how the i810fb driver works. Only upon explicit mode change will it do so. >> config FONT_8x16 >> bool "VGA 8x16 font" if FBCON_FONTS >> depends on FB && SGI_NEWPORT_CONSOLE=y >> >> I changed the '&&' operator to '||' in my case. > >Applied. > >> > > 5. The cfb_* drawing functions still behave erratically, especially in >> > > emacs. Geert has made some versions that work correctly for me. This >> > > was discussed in a thread sometimes ago. >> > >> > Where are the patchs. I like to incorporate them into BK. >> The patch exceeded 40K uncompressed, so here's a link: >> >> http://i810fb.sourceforge.net/draw_ops.diff.gz >> >> The diff is against 2.5.45 plus your fbdev.diff. > >It didn't work. Can you send me those files direct. I like to apply them. The patch did not, or unable to download? I think Sourceforge had a scheduled outage. You can try again. Currently, I'm experiencing a hardware failure, I'm currently doing this in a Windows box. So I won't be able to send it to you for some days yet. Tony |