Bug 10205

Reply-To: akpm@linux-foundation.org

On Sun,  9 Mar 2008 08:55:52 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=10205
> 
>            Summary: BUG: Display gets corrupted when using lxfb driver on a
>                     GeodeLX 5535 based chipset
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.24.2
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Console/Framebuffers
>         AssignedTo: jsimmons@infradead.org
>         ReportedBy: nestorac@gmail.com
> 
> 
> Latest working kernel version:
>  None or unknown
> Earliest failing kernel version:
>  Latest version
> Distribution:
>  Debian Stable (Etch)
> Hardware Environment:
>  AMD Geode 32 bit A830 board, 5536 chipset based embedded computer (TFT 10"
>  800x600), with GeodeLX embedded GPU. It's webpage is at:
>  http://www.winmatev.com.tw/PPc/PPcSpec.asp?Prod=03_0013&Typeid=03020101
>  I own a cheaper version using GeodeGX 500 processor, 256MiB RAM, no
>  touchscreen.
> Software Environment:
>  Debian 4.0 Stable (Etch), Kernel 2.4.22.2 vanilla + AUFS patch (it has
>  nothing
>  to do with graphics, but BTW...), all i386, kernel specifically compiled for
>  Geode GX/LX Processor target (but also does not work for generic i386
>  target).
> Problem Description:
>  I get a blurry screen when trying to enable Framebuffer, vga=788
>  option (800x600). Screen gets corrupted, but when I start X.org, it shows
>  Ok, until I switch again to console. Everything works fine with Vesa FB,
>  except that, of course, it's more CPU consuming and slower [supposedly].
>  When blurry, screen looks like it was under a lake.
> Steps to reproduce:
>  1) Compile the kernel, include support for GeodeLX Framebuffer.
>  2) Install the kernel on the machine
>  3) Boot it up, adding vga=788 mode to bootloader.
>  4) Screen gets completely blurry until X.org starts.
> 

Guys, this is a post-2.6.24 regression hence needs
running-around-with-your-hair-on-fire priority please.

Can anyone think what we did to cause this?  Recent changes to
drivers/video/geode/ look pretty tame.

Please, tell me if you need more information. That's an embedded machine, so it's more complicated than usual to get the info, but I will do if necessary. If it worked before, you're ok: it's a regression, since it doesn't work for me now (I haven't tried it earlier).

Thanks!!

First, is it correct that the problem happens with the 2.6.24.2 kernel?  In the "software environment" you said the kernel was 2.4.22.2 ...

Second, has it _ever_ worked for you correctly?  If that's the case, what's the last kernel it worked with?

Are there any error messages from the kernel (in dmesg)?  If sounds like some register or MSR isn't being set by the framebuffer driver but is getting set by the xorg driver.  If that is the case (and you're using a 2.6 kernel), I can whip up a patch to dump registers to compare contents before and after X runs.

I have only tested with 2.6.24.2, sorry (no 2.6.22). I have not been able to make it work with Geode LX FB, never. Only get fuzzy screen. I can't test with X.org AMD driver, only VESA driver (AMD driver also looks broken, I have already sent a message to X.org folks). Everything works fine with Vesa driver: Framebuffer (kernel) and X.org. X.org starts up after FB, obviously, so I think it has nothing to do with it, since kernel FB should be able to set the proper modes for itself. I'm going to post some dmesg when I'm able to get it, since it's embedded computer and it's harder to get it. Thank you, guys!

Created attachment 15192 [details]
Dmesg messages

This is the Dmesg message

Created attachment 15193 [details]
A photo of the failure

Some photo of the machine failing with GeodeLX FB driver, and a video (when the system is already started up completely).
I have uploaded it to Youtube, since I had no space here to attach it (just 1MiB):
http://www.youtube.com/v/xARweKVDZNE
Note that everything works fine except that the FBuffer, there's no machine lockup. X.org works well also. Thanks!!

Rather than using vga=, does using lxfb.mode_options=800x600 make a difference?

I have tried this mode, and no, not real difference. Some colors might change ;-), but it's almost the same thing with lxfb.mode_options=800x600. Could you test it in your own hardware? Does anyone also have a GeodeLX card?
I have realized on one thing: The text might show on the back of the "cloud". I'm not sure, but it might be so, since some text appears from the boot manager, then the cloud gets on it, then everything dissappears.It's not like everything is broken, it's like it has some kind of failure that draws "clouds" on top of the text (but I can't see any text, anyways, since it gets REALLY "cloudy").

Are you using a GX or a LX processor?  You've stated both in your report.  If you have a GX then you are using the wrong driver.

Regardless, the failure is the same - the timings are wrong for your TFT panel, a common problem since the video timings in the kernel are tuned for a CRT.  So you have two options - either patch the driver with the correct timings, or just use VGA for the text console, and run your graphics from X (which seems to be your intent).  You can get the absolute timings from your vendor, but in the mean time, you can try these timings and see if they help.

For the kernel - this is a struct fb_videomode: 

/* 800x600-40 (PANEL) */
{ NULL, 40, 800, 600, 37697, 88, 40, 23, 1, 128, 4,
  FB_SYNC_HOR_HIGH_ACT, FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, 0 }

And here is a modeline for X:

Modeline "800x600-40" 26.53 800 840 968 1056 600 601 605 628 -hsync -vsync

The panel mode should be used in X - but a quick look at the GX driver shows that it isn't, and I bet it isn't for LX either (/me shakes his fist at Andres).  I'll handle that bug immediately.

akpm & Andres - is it worth our while to add a second modedb list of common panel timings to the drivers?

 

Thank you, guys!! I'm going to test it tomorrow, at work. I'm telling you. BTW, the board is LX (Graphic Card is GeodeLX, as seen by 'lspci', not GX), but processor is GX. So everything is LX, but the processor, which is GX. I though that they just sent me a new LX board with an old GX rather than a newer LX processor. So correct me if I'm wrong, but I would bet I should use a LX driver.
The MoBo is an A830 model from Winmate, 256MiB RAM, GeodeGX processor, 10" LCD SVGA.
I wonder if it was possible to patch the kernel so it recognizes the LCD panel automatically. Should it use some kind of DCC?? Or maybe just put some option to choose it manually, but not having to recompile the whole kernel.

LX and GX are processors, not boards.  Furthermore, both processors have video built in, so the video driver you use is determined by the processor you have, not by the board you have.

Your dmesg says you have a LX processor, so thats what we're going to go with.

There isn't anyway to detect the LCD panel timings automatically - there is no DDC like mechanism for TFT panels.  We should probably have built in kernel timings for panels, but thats a matter of debate.

But again, I recommend that you not use the framebuffer driver at all unless you need it - the VGA console will work fine, and you can use X for advanced graphics and 2D acceleration.

I see. I have run perfectly both framebuffer and X.org in VGA CRT display. I have tested X.org patch and works fine for CRT, I'm telling them. But my problem is that I must put a graphical bootsplash (and not use CRT, but TFT panel), since it's for building an embedded system for people that do not want to see any text messages. Any idea?? The best way I have found is by using VESA Framebuffer, and, as far as X.org managed well with this Graphic Card (it still does not work for TFT panel with AMD driver), there should be no problem except for efficiency (VESA FB is not very fast). Is there any way to guess the correct modes for the screen?? I put the Modeline you told me in xorg.conf, but still does not work.

So my situation is:
With CRT: Everything OK, as far as I see
With TFT panel:
 Framebuffer:
  VESA: Ok
  GEODELX: Failure, I haven't yet tested it with the new fb_videomode, need further work from me.
 X.org:
  VESA: Ok
  AMD: Failure, it complains about incorrect horiz sync in Xorg.0.log, changed it and still no way

The ideal situation would be to use the proper driver, not generic VESA, for both Framebuffer and X.org.

One more question: How does VESA detect the correct modes [and work] for all situations? Is this a stupid question for some reason?

Okay - this confirms that this is a panel timing issue, so no regression, but new breakage.

You will need to apply the timings I gave you to the lxfb driver in order to use it for your panel.  You do not need to use the LXFB framebuffer for a simple splashscreen in the kernel if you do not wish to patch the kernel - you can use VESA instead; the drawing speed for a splashscreen will be the same for both.  The only advantage the lxfb driver has right now is that it will allow you to use non-VESA modes, but 800x600 *is* a VESA mode.  

The X problem is a different one, and you are perusing it on the mailing list, no need to confuse the kernel folks with this.

Summarize:
Use vesafb
Work with the X driver developers on the X issue
Jordan and Andres have been discussing how to include panel modes in the lxfb

Is this still a issue?