Re: CT65550 / chipsfb driver status...

On Sun, 2004-10-24 at 11:23, Antonino A. Daplas wrote:
> On Friday 22 October 2004 17:06, Laurence Abbott wrote:
> > What is the current status of the driver for the Chips and Technologies
> > 65550 chipset? I can only find mentions of it from a couple of years
> > back with regard to a new version of the driver (links to that driver no
> > longer work).
> 
> There is a chipsfb driver in 2.6 which looks like is properly coded.

Well, to get chipsfb.c to compile on ix86 architecture, I had to remove
the dependency on PPC in /usr/src/linux/driver/video/Kconfig, and then
compilation barfed at line 414:

        p->screen_base = __ioremap(addr, 0x200000, _PAGE_NO_CACHE);

because _PAGE_NO_CACHE is only defined for PPC. Looking through fbmem.c
for the same symbol, I found that for some architectures other than
ix86:

pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;

and for ix86:

pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;

Changing _PAGE_NO_CACHE for _PAGE_PCD in chipsfb.c allowed it co compile
cleanly (not too sure how legitimate this fix is but it seemed to work
as a quick bodge!).

> > I have recently acquired a Keycorp K57 LCD monitor with a dedicated
> > graphics card based on the CT65550 chip, and I'm hoping to get this
> > working as a basic framebuffer device.
> >
> > I believe the current driver only works on PPC architecture but with a
> > bit of tweaking, I managed to compile the chipsfb module on the ix86
> > machine containing the card.
> >
> > Is this ever likely to work?! Is it likely to work with the VESA driver?
> 
> Possibly, as long it's VESA VBE Version 2.0 at least. And I think the
> ct65550 does have the 2.0 version.

After much more fiddling about (and discovering that the connection to
the monitor is a bit dodgy), I have got a picture on the monitor
attached to the ct65550 using the above fix to chipsfb.c. However, this
is only really with X and the chips driver rather than a proper frame
buffer driver.

I'm not totally sure how I work with multiple framebuffer devices: my
AGP card gives me two: /dev/fb/0 which works as I'd expect, and
/dev/fb/2, which I think may be TV-out, or something, but this one is
only VGA16. The ct65550 one appears as /dev/fb/1.

I'm currently using the vesafb-tng driver (as part of Gentoo) and think
that this may be causing some of my problems! If I use:

% fbset -fb /dev/fb/1

It tells me that the ct65550 is running in 800 x 600 and 8-bit depth.
Fair enough. If I try to change the depth on that framebuffer, it
corrupts /dev/fb/0 and I can no longer see what I'm doing! I will try
with the standard vesafb driver tonight to see if that works any better.

In the framebuffer HOWTO, it says that you can only run fbset from teh
framebuffer itself. Is this the case? Surely that is the whole point of
the -fb switch!

Is there a simple command which can be used to restore a framebuffer
back to a sane state, rather than having to reboot?

Cheers,

Laz



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl