Menu
▾
▴
linux-fbdev-devel
|
From: Tea A. <th...@vi...> - 2001-04-03 15:20:28
|
On Sunday 01 April 2001 16:49, James Simmons wrote: > We can always seen in a better driver. > > >> avaliable at http://www.visuelle-maschinen.de/ctfb > > > >Does the driver still work on PowerMac after that one? > > Don't know. Has anyone tried it out on other platforms? > Hello, I just uploaded some framebuffer stuff I found on the web in last months. Check http://www.visuelle-maschinen.de/ctfb/fb What I know about chipsfb: There was a chipsfb which did not run on my i386 - ct65554 machine. I could not fix the problem also I did not understand anything about framebuffer drivers and the register set of the ct65554. So I decided to write my own driver. Of course I started with chipsfb, but most of it is gone and replaced. Time went by, i improved the driver and adapted it to the ct69000. Than asiliantfb apeared on the sceene. Adrian Cox and I exchanged some mails with plans to merge both drivers - but, you know, we all have lots of other jobs and the project never starts. On Tuesday 28 November 2000 12:21, Adrian Cox <ap...@ag...> wrote concerning asiliantfb: > I'll probably be doing some more work on the driver in the new year. > This may include the video input port and some flat panel support. But > I've been concentrating on other issues recently. I'll probably be doing > 2.4 then. On Wednesday 29 November 2000 22:16, Susan Kleinmann <sg...@ne...> wrote: > This is just to report that I finally did succeed in loading X 4.0.1f on a > Toshiba 2515 CDS laptop (which has a C&T 69000 graphics chipset), using: > > -- Thomas Hohenleitner's ctfb.c framebuffer driver > (http://www.visuelle-maschinen.de/ctfb/ctfb0.40.tgz) with > > -- a 2.2 kernel configured with: > CONFIG_FB=y > CONFIG_FBCON_CFB8=m > CONFIG_FBCON_CFB16=m > CONFIG_FBCON_CFB24=m > (and also one has to follow the instructions at the end of ctfb.c, > to manually edit drivers/Makefile so that fbgen.o will be generated), > and > > -- an X configuration file with the Device section set as follows: > > Section "Device" > Identifier "Generic Graphics Device" > Driver "fbdev" > BusID "pci:0:4:0" > EndSection > > The device wasn't properly recognized til I entered the BusID line > above. > > From Mike McQuade <mi...@ci...>, I got mail (it is from 13. March 2001): > I am looking into putting some acceleration into the framebuffer > for the CT69000 part. We are doing large block copies and need some > speed. The ctfb verision 0.50 supports now 2.2 and 2.4 kernels. You can find it now under http://www.visuelle-maschinen.de/ctfb/fb/drivers/ctfb/ There is also asiliantfb and the old chipsfb available. I did also some work on the video-in part of the ct69000 - yes I grabbed pictures. But it came not to a driver. Just a working userland application. It is availiable under http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/ Actually I work with a i810 chipset and my current interest in ctfb is low. I can not spent too much time in this but I can offer support and help and do also some testing, if nesesary. Sorry for the long mail. Thomas |
|
From: Adrian C. <ad...@hu...> - 2001-04-03 16:04:08
|
Jordan Crouse wrote: > Now what we need is a volunteer to help us get all this stuff merged > out. No matter what we finally come up with, I don't think we should > let another kernel release go by > without some contributions. I've got a contract to support a machine with two 69030s supporting two monitors and two panels. I'm going to have to merge a lot of this code anyway over the next few weeks. So yes, I guess I'm volunteering. What do people actually want the driver to do? Should we attempt to support the entire Chips/Asiliant range in one driver, or separate out the early IO based devices from the later memory mapped devices? I don't have access to the earlier devices, so I'll be fumbling in the dark with them unless somebody is prepared to mail me a card. - Adrian |
|
From: Tea A. <th...@vi...> - 2001-04-03 16:35:09
|
On Tuesday 03 April 2001 18:03, Adrian Cox wrote: > Jordan Crouse wrote: > > Now what we need is a volunteer to help us get all this stuff merged > > out. No matter what we finally come up with, I don't think we should > > let another kernel release go by > > without some contributions. > > I've got a contract to support a machine with two 69030s supporting two > monitors and two panels. I'm going to have to merge a lot of this code > anyway over the next few weeks. So yes, I guess I'm volunteering. > Sounds good! I could offer some testing on a ct65554 and a ct69000 (intel boxes). ctfb0.50 is stable on my ct69000 (last versions not testet on the ct65554). Feel free to use the code as you like. > What do people actually want the driver to do? Should we attempt to > support the entire Chips/Asiliant range in one driver, or separate out > the early IO based devices from the later memory mapped devices? I don't > have access to the earlier devices, so I'll be fumbling in the dark with > them unless somebody is prepared to mail me a card. > If there is no test posibility for old devices the question is already anwered. Thomas |
|
From: Jordan C. <jo...@Ce...> - 2001-04-03 16:54:54
|
A tarball of the alpha 2.4.X driver and header file is on my website: http://cosmic.censoft.com If I can get a chance later, I will provide a patch against 2.4.2-ac25. ----- I also have a contract to provide support for 69000s on two flat panels, so I am willing to help Adrian as much as possible. As far as the functionality, I think that we should provide suport for the following: * full support for the 69000/69030 on i386 and PPC for both CRT and flat panel * provide multihead support for both CRT and flat panels (and a combination of both) * Provide simple legacy support for the 65550 family (nothing fancy, just get the thing to show pretty pictures) At some point, the future may include: * Accelerator support * NSC/PAL support (ugh!) * Video input (double ugh!) Adrian Cox wrote: > > I've got a contract to support a machine with two 69030s supporting two > monitors and two panels. I'm going to have to merge a lot of this code > anyway over the next few weeks. So yes, I guess I'm volunteering. > > What do people actually want the driver to do? Should we attempt to > support the entire Chips/Asiliant range in one driver, or separate out > the early IO based devices from the later memory mapped devices? I don't > have access to the earlier devices, so I'll be fumbling in the dark with > them unless somebody is prepared to mail me a card. > > - Adrian > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Tea A. <th...@vi...> - 2001-04-03 17:20:09
|
> > At some point, the future may include: > > * Accelerator support May be Mike McQuade <mi...@ci...> is active here? > * NSC/PAL support (ugh!) If you connect VGA out rgb with scart in rgb of a tv and join vsync and hsync thrugh 2 resisors of i.e. 120 Ohms to csync you should get a syncronized video on the tv screen (after playing with fbset). This should be possible with every framebuffer driver supporting tv timings. ctfb does and i810fb does it also now. I'm sure, matroxfb and many others do also the job. Programming additional registers for a separate video-out is not that terrible - the interesting thing here is the interface if you do not like to use special ioctls. > * Video input (double ugh!) see http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/ctvi_0.21/ before starting with that - the code fragments may help a little bit. > Thomas |
|
From: Mike M. <mi...@ci...> - 2001-04-03 17:35:53
|
Sorry, I just got all these emails. I have shifted projects, doing the accel work is back burner for me. Mike -----Original Message----- From: Tea Age [mailto:th...@vi...] Sent: Tuesday, April 03, 2001 10:22 AM To: Jordan Crouse; Adrian Cox Cc: Linux Fbdev development list; Mike McQuade Subject: Re: [Linux-fbdev-devel] Re: CHIPS drivers > > At some point, the future may include: > > * Accelerator support May be Mike McQuade <mi...@ci...> is active here? > * NSC/PAL support (ugh!) If you connect VGA out rgb with scart in rgb of a tv and join vsync and hsync thrugh 2 resisors of i.e. 120 Ohms to csync you should get a syncronized video on the tv screen (after playing with fbset). This should be possible with every framebuffer driver supporting tv timings. ctfb does and i810fb does it also now. I'm sure, matroxfb and many others do also the job. Programming additional registers for a separate video-out is not that terrible - the interesting thing here is the interface if you do not like to use special ioctls. > * Video input (double ugh!) see http://www.visuelle-maschinen.de/ctfb/fb/video_in_ct69000/ctvi_0.21/ before starting with that - the code fragments may help a little bit. > Thomas |
|
From: Jordan C. <jo...@Ce...> - 2001-04-03 15:41:58
|
Let me tell you what i have so far - I have taken chipsfb.c on 2.4 heavily modified it to provide dual 69000 support, and then recently merged it with most of Adrian's code (appropriately modified for 2.4.X of course). It seems that we have all been doing the same work (where was everyone when I was looking for drivers a month and a half ago??? :-) ), so I would propose that we all get together and somehow merge what we've got into a very good driver for 2.2.X and 2.4.X that we can fire off to Linus and Alan Cox and get it in the tree post haste. My driver works well with multiple PCI based 69000 devices on a x86 machine. I haven't touched the flat panel stuff, in part because my specific project uses the default BIOS settings, and partly because I don't have a flat panel to test with. In theory, I have support to switch modes on the fly, but that is completely untested at this point. I do know that I have 2 serious fbcon problems: 1) - Every time I recompile, the main console gets shifted to the right some amount. Everything works well, its just that the entire screen is shifted to the right. I didn't think penguins could fly, but mine sure can... :) 2) - Every once in a while, while running a framebuffer app on a console, if I switch to an new console, I still get my app drawing on the console. That definitely does not happen with VESA. Anyway, my code may be redundant or it may not, but at this point it 80% works and it is available. I will post a URL as soon as I can convince my IT department to let my machine extend past the firewall. Now what we need is a volunteer to help us get all this stuff merged out. No matter what we finally come up with, I don't think we should let another kernel release go by without some contributions. Anybody, anybody? Jordan |
Thanks for helping keep SourceForge clean.
X