Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2002-10-15 11:00:13
|
On 15 Oct 02 at 12:33, Carlo E. Prelz wrote:
> Now that I can see the output of the second card, I have a new
> problem. WIth both versions of the driver, the output on the second
> head is influenced by what is sent to the first head. It is very
> difficult for me to describe, especially because the relative PC is
> very far from me. But I see that, if I set the second head to 16bpp,
> the amount of disruption to it is little if the first head is set to
> 32bpp, medium if set to 16 and very high if the first head is set to
> 8bpp. It seems the info for the first head is spilling to the second
> one. This does not happen if the g400 is by itself, only if the
> Millennium is also present.
> -40: 20 41 04 50 00 3c 00 00 06 ff ff 06 00 00 00 00
> -50: 00 30 00 01 19 a4 90 01 00 00 00 00 00 00 00 00
> +40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
> +50: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
It looks ok - VGA aperture (bit 0 of reg 0x41) is disabled,
so no corruption should occur.
> All the above comes from 2.4.20-pre10-ac2 with your previous
> patch. Can you help again? Any other info that you may need?
By default (after powerup) you'll see garbage on secondary monitors.
They'll be up in 640x480/60Hz, but without usable picture. You
must do 'con2fb /dev/fb1 /dev/tty5' to get usable picture on
screen. And you must boot with 'video=scrollback:0', otherwise
picture will get corrupted if you'll hit 'shift-pgup'. But until
you hit shift-pgup, picture should be ok.
Petr
|
|
From: Petr V. <VAN...@vc...> - 2002-10-15 15:37:28
|
On 15 Oct 02 at 17:04, Carlo E. Prelz wrote: > > Having spent the last hours doing tests, I return to you with the > exact certainty that the two displays of the G400 work perfectly when > the millennium card is not present, but the second head of the G400 > starts to misbehave when the millennium card is inserted. I have no idea. Can you try patching your kernel with ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/fbset-through-vt-2.4.19-rc5.gz? (if you are using 2.5.x, I can send you patch on request). Maybe you'll get an 'Crossdevice link' error on some of your fbset commands. > Here is my methology: for each head I first call > > fbset -fb /dev/fbX 800x600-60 -depth 32 Always make sure that you are running fbset on foreground device. Otherwise bad things will happen. > When I run fbset on /dev/fb1 (first head of g400) the output of the > second head is corrupted. Moving diagonal bands appear. The situation > does not change when the image is copied to the first head. The image > on the G400's first head as well as that on the millennium is > perfect. If you'll read contents of /dev/fb2 and put it to /dev/fb1, is this picture correct or not? > I am attaching a small jpeg that shows the three monitors (this is > from a remote webcam and is all I also can see from the screens) when > the image that I am attaching has been sent to all three Unfortunately I do not see anything. I see horizontal black lines on all three monitors, and nothing else... > monitors. Monitors are, in order, first and second head of G400, and > millennium. You can see the diagonal bands on the central screen. Can you try 'matroxset -f /dev/fb2 -m 0' 'matroxset -f /dev/fb1 -m 3' Now both G400 monitor should show same picture. If they do not, problem is in secondary output path... (I'd like to know where...). 'matroxset -f /dev/fb1 -m 0' 'matroxset -f /dev/fb2 -m 3' Now both outputs are driven by secondary head, /dev/fb2... 'matroxset -f /dev/fb2 -m 1' 'matroxset -f /dev/fb1 -m 2' Now both outputs are swapped: /dev/fb1 drives secondary monitor, and /dev/fb2 primary. 'matroxset -f /dev/fb1 -m 0' 'matroxset -f /dev/fb2 -m 2' 'matroxset -f /dev/fb1 -m 1' And now it is back in initial state... Maybe it is some poweron initialization problem of Maven. Can you ask your friend on the remote site to go into the BIOS, and select 'AGP' as primary device in the BIOS? Then G400 will be initialized by BIOS, and Millennium by matroxfb. Maybe it will make things better. Petr |
|
From: Petr V. <VAN...@vc...> - 2002-10-16 07:01:04
|
On 15 Oct 02 at 22:29, Carlo E. Prelz wrote:
> > > the image that I am attaching has been sent to all three
> >
> > Unfortunately I do not see anything. I see horizontal black lines
> > on all three monitors, and nothing else...
>
> I am now adding a version where I underline - with yellow lines - the
> places where these artifacts appear.
Ah, these ones... What pixclocks do you use? It is like if CRTC2 has
not enough memory bandwidth available, and so it displays stale data.
But it looks strange anyway. I'm afraid that I cannot help you,
sorry. You can try experimenting with different pixclocks, different
bit depths, and so on. But I cannot explain why it happens only
when old Millennium is also in the box.
> Everything happens as expected. First both good, then both bad, then
> first bad and second good.
So it is really caused by CRTC2, not by Maven. Even more strange, then
it looks like that CRTC2 bus accesses are only possible source of problem
(it could be also subpicture displayed over picture, but because of
subpicture is YUV, while your corruption is copy of RGB surface, I think
that it is impossible).
Only problem I can think of is that system VCO frequency is always set
to 133333 kHz (for G100/200/400) in matroxfb_DAC1064.c. Your PINS
suggest that 200MHz are correct system clocks for your chip.
Thanks,
Petr Vandrovec
van...@vc...
|
|
From: <sy...@sc...> - 2002-10-16 09:00:03
|
On Wed, Oct 16, 2002 at 09:00:27AM +0200, Petr Vandrovec wrote: > Ah, these ones... What pixclocks do you use? It is like if CRTC2 has > not enough memory bandwidth available, and so it displays stale data. Can the CRTC high priority stuff affect this? Does matroxfb touch the priority registers? > Only problem I can think of is that system VCO frequency is always set > to 133333 kHz (for G100/200/400) in matroxfb_DAC1064.c. Your PINS > suggest that 200MHz are correct system clocks for your chip. What do you think about making matroxfb do clock setup accrding to PINS? XFree86 mga driver does it own clock setup but DirectFB matrox driver does not. I'm pretty sure increasing the clocks would provide some speed benefits since the BIOS default clocks are pretty low. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: Carlo E. P. <fl...@fl...> - 2002-10-16 10:16:49
|
Subject: Re: [Linux-fbdev-devel] Another problem, seemingly coming f Date: mer, ott 16, 2002 at 09:00:27 +0200 Quoting Petr Vandrovec (VAN...@vc...): > Ah, these ones... What pixclocks do you use? It is like if CRTC2 has > not enough memory bandwidth available, and so it displays stale data. > But it looks strange anyway. I'm afraid that I cannot help you, > sorry. You can try experimenting with different pixclocks, different > bit depths, and so on. But I cannot explain why it happens only > when old Millennium is also in the box. I was able to reduce video artifacts to a minimum (seemingly acceptable ;-) by setting - millennium to 800x600-60 - G400 1st head to 800x600-90 - G400 2nd head to 800x600-75 These are standard framebuffer modes found in /etc/fb.modes. I am getting most artifacts when setting both heads of the G400 to the same fb mode - which one does not influence things too much. Thanks for your help Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Petr V. <VAN...@vc...> - 2002-10-16 14:25:44
|
On 16 Oct 02 at 11:59, Ville Syrj=E4l=E4 wrote:
> On Wed, Oct 16, 2002 at 09:00:27AM +0200, Petr Vandrovec wrote:
> > Ah, these ones... What pixclocks do you use? It is like if CRTC2 has
> > not enough memory bandwidth available, and so it displays stale data.
>
> Can the CRTC high priority stuff affect this? Does matroxfb touch the
> priority registers?
Yes, matroxfb sets them to default values, recommended for low pixclock
rates. You must set them when you initialize hardware after poweron.
> > Only problem I can think of is that system VCO frequency is always set
> > to 133333 kHz (for G100/200/400) in matroxfb_DAC1064.c. Your PINS
> > suggest that 200MHz are correct system clocks for your chip.
>
> What do you think about making matroxfb do clock setup accrding to PINS?
> XFree86 mga driver does it own clock setup but DirectFB matrox driver
> does not. I'm pretty sure increasing the clocks would provide some
> speed benefits since the BIOS default clocks are pretty low.
I'll not use other clocks than specified in the BIOS (BIOS uses value
specified in PINS). It is highest rate Matrox says to use. That Matrox
windows drivers use higher frequency is another story: they have access
to other information than I have, and so they can select highest system
clock from chip revision, serial number and other values...
On G450/G550 I use frequency specified in BIOS PINS. G400 (and older)
historically used hardwired values in matroxfb, and because of I do not
use them regulary anymore, I try to not touch their initialization code
(and as you can saw, even then I had mistake in G400 initialization...
unfortunately testing powerup initialization requires plugging in another
videocard, unplugging powercord, and then trying again and again...).
If you'll cook and test patch which will set system clocks on G400
according to the value specified in the BIOS, or if you'll create
patch which will add ioctl() or some other operation to set system
PLL, I'll apply it without problem (if code is correct, changing
system PLL is not trivial operation).
Petr Vandrovec
van...@vc...
|
|
From: <sy...@sc...> - 2002-10-16 18:40:38
|
On Wed, Oct 16, 2002 at 04:25:20PM +0200, Petr Vandrovec wrote: > On G450/G550 I use frequency specified in BIOS PINS. G400 (and older) > historically used hardwired values in matroxfb, and because of I do not > use them regulary anymore, I try to not touch their initialization code Ok that clears it up. I have a G400. > If you'll cook and test patch which will set system clocks on G400 > according to the value specified in the BIOS, or if you'll create > patch which will add ioctl() or some other operation to set system > PLL, I'll apply it without problem (if code is correct, changing > system PLL is not trivial operation). Maybe I'll try something if/when I have too much time on my hands. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
Thanks for helping keep SourceForge clean.
X