Re: [Linux-fbdev-users] CT65550 / chipsfb driver status...

[Antonino A. D. <ad...@ho...>]

On Monday 25 October 2004 16:34, Laurence Abbott wrote:
> 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.
>

Doing a cat /proc/fb should tell you what drivers are loaded. What kernel
version are you using?

> 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

Normal behavior is not to affect /dev/fb0 if the command is explicit
to /dev/fb1.  So there is a bug somewhere.  (however, this may happen
if you have 2 drivers for the same physical device, say vga16fb and
a driver specific driver)

> 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!

No, you can run fbset anywhere, even within xterm, if you have the guts.
If there is no -fb, it defaults to /dev/fb0.

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

There are a few drivers that can restore the hardware state, but the answer
is generally no.  You can try to have > 1 video cards, load each of their
drivers.  If your console becomes corrupt, you can use con2fbmap to
move your console to the known working driver.

Tony