Re: A black strip on right side of LCD by John
John
Thu Jul 31 19:42:09 PDT 2008
Hi Bradley,
I've got the datasheet from LCD vendor. According to the datasheet, Win XP's
signal forms are actually wrong and Win CE's signal forms are correct. But if
HSync action happens at the falling edge exactly, the Win XP signals should
also work.
Then I measured the timing of each signals and calculated how many data
could be sent between DENA signal. I was suppresied to find out that the Win
CE sends out exactly 800 data and Win XP sends out 804. I guess the extra 4
is due to my measurement error. So, my Win CE did send out 800 data
horizontally. Then the last 100 data (because I got only 700 pixels in
drawing a line horizontally) must be lost before the place the timing is
generated. I found an artical talked about display driver briefly. It seems
even the display driver calls functions with the resolution paramenter passed
to it. So, it seems my data are lost between the driver and whoever generates
the timing (assuming the driver got the data from boot.ini correctly). Am I
right? And what can I do to solve (or further trace) the problem? Any
suggestions?
Many thanks in advance!
John
PS. Other experts, any ideas and suggestions? Thanks.
"John" wrote:
> Hi Bradley,
>
> Your reply is very educaional. I think I've got a good idea of how a SBC
> drives a CRT and an LCD simutanously. Thanks a lot.
>
> I measured the frequencies on the LCD connector with running Win XP and Win
> CE. The clock/DENA/HSync/VSync are a little different but all in the range of
> the specs of my LCD module. The only thing puzzled me is that: the HSync
> under WinXP is a positive pulse train. The pulse is about 3.8uS wide and two
> pulses are about 32.1uS apart. The HSync under WinCE is a negative pulse
> train. The pulse is about 3.2uS wide and two pulses are 26.4uS apart. If like
> a CRT, the scanning signals use the polairty to control brightness (e.g. the
> polarity of the pulse is for blanking the returning beam) how one of these
> two HSync signals will ever work when the LCD module they drive is the same
> module?
>
> Also my SBC uses AMD LX800 display driver. I think it's file name is
> ddi_agx.dll. Do you know anything about it, such as the effect of its keys in
> registry, related ini file, its source code, ...? Do you know any other
> display drivers that are compatible with an AMD CPU that I may be able to use
> to replace ddi_agx.dll and give it a try?
>
> BTW, I also drew some lines with different lengths on the LCD under WinCE.
> The available width is 700 pixels (i.e. the black strip is 100 pixel wide).
> Does this give you any clue?
>
> Many thanks!
>
> John
>
> "Bradley Remedios" wrote:
>
> > On Jul 30, 12:15 am, John <J...@discussions.microsoft.com> wrote:
> > > Thank you for the help. I am going to check the frequencies tomorrow. It
> > > will be very interesting to see what the actual frequencies are. In the
> > > meantime, could you teach me a little bit more about the display driving?
> >
> > There are many methods of connecting a display that I am aware of for
> > Embedded Devices
> > 1. Any Standard Interface (DVI/VGA/HDMI, ...) that is often found on
> > Desktops
> > 2. Standard RGB Interface. This basically is a line for each bit, a
> > clock and some sync signals.
> > 3. Another Interface whose name eludes me at the moment.
> > 4. Probably more that I am not aware of.
> >
> > I am not an expert in all the modes (in fact I've only dealt with the
> > RGB Interface myself.) The timing is pretty simple for the RGB
> > Interface. Essentially a pixel of color data is clocked into the
> > LCD. The frame is drawn horizontal line by horizontal line. The
> > Hsync and VSync is used to define where the frame starts and the
> > Porches are used to define data that gets thrown away, or is not
> > displayed on the screen.
> >
> > I should have been more clear in my previous post, it assumed that the
> > Display Controller Outputs in format 2. Although, your problem is
> > most likely still a timing issue with your driver, where to look for
> > how the timing may be wrong may not be exactly as I mentioned if you
> > use a different interface from the Display Controller and to the LCD
> > itself.
> >
> > > My
> > > SBC board can drive a CRT and an LCD at the same time. I can hardly believe
> > > the CPU will spend time to run two display drivers to drive them seperately.
> >
> > It might, I don't know how your SBC is designed, or what processor you
> > are using. It could take a RGB signal from the Display / LCD
> > Controller pass it through another IC / FPGA and voila you have a VGA
> > signal suitable for a CRT and another passed through suitable for an
> > LCD, or vice versa it could output as VGA suitable for a CRT and pass
> > that through generating signals for RGB suitable for an LCD.
> >
> > It's also possible that there are two display controllers and two
> > video buffers and the display driver is handling the cloning (or
> > having both controllers point to the same video buffer.) It could
> > also be one display controller that that supports 2 Video Outputs and
> > 1 or 2 simultaneous outputs.
> >
> > > In addition, I never specified what type of display to use when I built the
> > > NK.bin. The reason I want to learn this is I want to know where the desktop
> > > image signals are seperated and goes to each display, in software or in
> > > hardware. This may give me some clues where to look for the problem because I
> > > can drive both displays at the same time, one works fine and the other has a
> > > black strip. But if say this is a hardware problem, I can have right (full)
> > > images on both displays if I use Win XP. I hope you see why I am puzzled.
> >
> > To proceed I would try to understand how your hardware is setup, then
> > I would look at your Display Driver. Because of the fact that it
> > works with another OS (Windows XP) I would assume that this is a
> > software problem with your BSP and that likely, it is configuring the
> > timing for the LCD incorrectly.
> >
> > Hope that helps,
> > Brad.
> >