linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] matroxfb dualhead instabilities

[Javier M. <jm...@po...>]

* Petr Vandrovec <VAN...@vc...> [021016 18:02]:

>> By more than one head you mean more than one physical card? Or does my
>> G400MAX with its two heads count as more than one?

>It counts as two if you are using /dev/fb1...

OK.

>> One strange thing I've seen though, is that I cannot use 'fbset -depth
>> xx' with xx other than 32 or I'll get:
>>     'ioctl FBIOPUT_VSCREENINFO: Invalid argument'

>16bpp should work too on second head.

I can only use 32 bits. Don't ask me why.

>> >If you'll use 'fbset -fb /dev/ttyX', no oops should occur.
>>=20
>> Whenever I try to pass a tty as argument to the -fb option I get the
>> same error I wrote above.

>16bpp and 32bpp should work. Because of values in default /etc/fb.modes
>are with 8bpp, you must use 'fbset 1024x768-60 -depth 32'. And if
>you are using Debian (maybe it is problem with stock fbset, I did not
>verified it), make sure that videomode 1024x768-72 in /etc/fb.modes
>does not use 10224 as xres/vxres... Most of monitors and videocards does=
=20
>not handle xres=3D10224 properly. You need dozen of megabytes vram to
>use this mode...

I have my custom fb.modes, indeed I'm trying to provide find some nice
default values to include in the package I'm writing for Gentoo, which
is the distribution I use, http://www.gentoo.org
Free and completely open source as Debian, but source based.

>> >> I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use=
 at

>> I know it is not a problem of the card itself, since without that patch
>> I don't have problems, but with it whenever a card on the 1st PCI tries
>> to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the
>> system blocks. No output, no sysrq, nothing, just a solid freeze.

>Maybe that it enables IRQ on card before installing IRQ handler.
>In such case nobody is going to clear IRQ in mga IRQ status register,
>and your system is processing endless stream of interrupts. Buying
>another CPU may give you chance to debug it. Or if you'll send
>me pointer to the patch, I can review it...

You mean the patch that gives the problem or .. what? It's the
vsync-irq-patch on your ftp server.

>Which one? fbset-through-vt? It should not change behavior of
>fbset when using 'fbset -fb /dev/fb*', it just adds possibility
>to use 'fbset -fb /dev/tty*' to set videomode on specific virtual
>terminal. And it should not cause any behavior changes to matroxset.

Oh, I see. That's what I wanted to know exactly, what that patch was
exactly for. Now it's everything more clear :)

>If mga-*-tvout, it adds support for DVI-D and TV outputs available
>on G450/G550.

OK, I don't need that one but it's already included in -ac branch.
Maybe Alan agrees to include the fbset-through-vt one too, even if
Marcelo, or whoever, refused to include it.

>> >set -e

>> What is this for? emacs mode?

>Stop on error... so in your case it will stop just immediately
>after fbset will fail, instead of performing (now useless and
>dangerous) second fbset, matroxset, and chvt.

I'll add it then.

>> I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO:
>> Invalid argument'. The only way I've found is to switch to the desired
>> vt, and run fbset there.

>Do you have 16MB or 32MB device? -vyres 3276 will work only if
>you have 8MB available for second head. With 16MB device maybe
>only 7.9MB is available for second head. And of course, you must have

I have 32MB device. G400MAX DH. The best one IMHO that matrox did of the
G4xx series.

>Yes. With yres=3Dvyres you cannot use hardware panning, hardware must
>always move full screen 16 graphics lines up. Even if MGA core
>can transfer 1GBps, it takes some time to scroll 3MB (for 1024x768/32bpp)
>up - to scroll out all 48 lines it is 144MB read + 144MB written...

I see, then my assumptions were correct.

>> Also, with fastfonts
>> enabled, it's terribly slow, while in the kernel documentation it's
>> stated than fastfonts is faster on Gx00 cards.
>> Has that anything to do with the scrollback you told me before? I have
>> not tried it yet.

>No. fastfont should be used only on G200 (if anywhere...). On G200
>you'll get about 10% speed gain, on older chips about 10% slowdown.
>But (for unknown reason...) on G400 you'll get about 1000% slowdown.
>Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt
>also on newer hardware.

Tell me if you wanna have results from other systems.

>> Anyway, thanks, and I mean a BIG thanks for your detailed quick and
>> prompt response. I wish I got such a nice help with a bttv/DVB cards
>> problem I cannot solve.

>Buy me one... if it is terrestric digital broadcast, maybe I could
>even receive some digital signal here.

Believe me, I would. But being a student with nearly zero income, I just
can't. Indeed, getting a different DVB card might give me some pointer
to where the problem is.

The thing is that without my DVB card installed on the system, I can use
the bttv analog TV card just fine. The kernel recognizes it as a 'WinTV
Go' - it's one of the two bttv cards I have over here -, and it works.
However, once I plug the DVB in a PCI slot, anyone of them, the bttv
card is not even recognized by the kernel.

With both cards inserted I get this out of 'lspci -v':

00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
	Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000
	Flags: bus master, medium devsel, latency 32, IRQ 15
	Memory at de800000 (32-bit, non-prefetchable) [size=3D512]

00:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capt=
ure (rev 11)
	Subsystem: Unknown device 0030:13eb
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at e1000000 (32-bit, prefetchable) [size=3D4K]
	Capabilities: [04] #06 [0290]

00:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (r=
ev 11)
	Subsystem: Unknown device 0030:13eb
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at e0800000 (32-bit, prefetchable) [size=3D4K]
	Capabilities: [04] #06 [0290]

Whereas if I remove the DVB card, the output is:

00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capt=
ure (rev 11)
	Subsystem: Hauppauge computer works Inc. WinTV/GO
	Flags: bus master, medium devsel, latency 32, IRQ 15
	Memory at e1000000 (32-bit, prefetchable) [size=3D4K]
	Capabilities: [44] Vital Product Data
	Capabilities: [4c] Power Management version 2

00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (r=
ev 11)
	Subsystem: Hauppauge computer works Inc. WinTV/GO
	Flags: bus master, medium devsel, latency 32, IRQ 15
	Memory at e0800000 (32-bit, prefetchable) [size=3D4K]
	Capabilities: [44] Vital Product Data
	Capabilities: [4c] Power Management version 2

The most strange thing is that in the past I know they worked under
Windows at the same time, and I believe I once made them work in Linux
at the same time. I've tried kernels from 2.4.18 to latest 2.4.20-pre,
I've come back several revisions of my BIOS, everything. They just
cannot coexist on my system at the same time.
When I try to use the bttv when it's not correctly recognized, I can
load the bttv modules and the card is found, yet If I try to use it, I
can only get sound and lots of SYNC IRQ problems with my SCSI card:

Oct 15 00:51:22 [kernel] bttv0: registered device video0
Oct 15 00:51:33 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x9
Oct 15 00:51:33 [kernel] bttv0: irq: SCERR risc_count=3D12670014
Oct 15 00:51:33 [kernel] bttv0: irq: SCERR risc_count=3D12670014
Oct 15 00:51:38 [kernel] bttv0: resetting chip
Oct 15 00:51:38 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x8
Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670014
Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670014
Oct 15 00:51:38 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x9
Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670000

This is of course without having loaded any DVB driver.

All right, forgive me for the off-topic. I might make it somewhat
on-topic by saying that the errors above were using 'fbtv' which uses
the framebuffer to show the TV signal.


--=20
Javier Marcet <jm...@po...>
Saint Louis University, Madrid Campus

Re: [Linux-fbdev-devel] matroxfb dualhead instabilities

[Petr V. <VAN...@vc...>]

On 16 Oct 02 at 17:33, Javier Marcet wrote:
> * Petr Vandrovec <VAN...@vc...> [021016 09:19]:
> 
> >> I patched my kernel with fbset-through-vt-2.4.19-rc5.gz,
> >> mga-2.4.19-rc5-tvout.gz was already merged by Alan Cox on his tree.
> >> However I get oopses often when using a console on my TV if I am playing
> >> with matroxset & fbset, which I am right now as I am polishing some
> >> scripts and default config files to include in the package for Gentoo.
> >> I have just removed it from my kernel and I'll see if the oopses show up
> >> again.
> 
> >Make sure that you boot with 'video=scrollback:0' if you have more
> >than one head... It is also very dangerous to use 'fbset -fb /dev/fbX'
> 
> By more than one head you mean more than one physical card? Ot does my
> G400MAX with its two heads count as more than one?

It counts as two if you are using /dev/fb1...
 
> >in multihead environment, because of PROC_CONSOLE() returns vt
> >number from the VT for the process, happilly passing VT initialized
> >by vga16 or primary head of matroxfb to secondary head. And secondary
> >head is certainly surprised if it is invoked on console saying
> >8bpp, while it supports only 16/32...
> 
> One strange thing I've seen though, is that I cannot use 'fbset -depth
> xx' with xx other than 32 or I'll get:
>     'ioctl FBIOPUT_VSCREENINFO: Invalid argument'

16bpp should work too on second head.
     
> >If you'll use 'fbset -fb /dev/ttyX', no oops should occur.
> 
> Whenever I try to pass a tty as argument to the -fb option I get the
> same error I wrote above.

16bpp and 32bpp should work. Because of values in default /etc/fb.modes
are with 8bpp, you must use 'fbset 1024x768-60 -depth 32'. And if
you are using Debian (maybe it is problem with stock fbset, I did not
verified it), make sure that videomode 1024x768-72 in /etc/fb.modes
does not use 10224 as xres/vxres... Most of monitors and videocards does 
not handle xres=10224 properly. You need dozen of megabytes vram to
use this mode...

> >> I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use at
> >> all any board on my first PCI slot since the Matrox is using the IRQ.
> >> What is the patch good for? I just have a crowded PC and no free slots.
> 
> >I did not wrote that patch... Make sure that request_irq() is done
> >for shared irq, Matrox hardware has no problem with sharing irq, and
> >if irq handler in matroxfb-vsync-irq-patch is written correctly, it
> >should just work.
> 
> I know it is not a problem of the card itself, since without that patch
> I don't have problems, but with it whenever a card on the 1st PCI tries
> to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the
> system blocks. No output, no sysrq, nothing, just a solid freeze.

Maybe that it enables IRQ on card before installing IRQ handler.
In such case nobody is going to clear IRQ in mga IRQ status register,
and your system is processing endless stream of interrupts. Buying
another CPU may give you chance to debug it. Or if you'll send
me pointer to the patch, I can review it...

> BTW, of the other two patches available, what is the one quoted at the
> top of this message for? I have removed it and since then I get no more
> locks when heavily using my second head, which was specially sensitive
> when doing lots of 'fbset', 'matroxset' et all.

Which one? fbset-through-vt? It should not change behavior of
fbset when using 'fbset -fb /dev/fb*', it just adds possibility
to use 'fbset -fb /dev/tty*' to set videomode on specific virtual
terminal. And it should not cause any behavior changes to matroxset.

If mga-*-tvout, it adds support for DVI-D and TV outputs available
on G450/G550.

> >> tvgetty.sh from inittab there aren't any kind of problems, but if I
> >> launch it from another console, the first time works as expected, but
> >> after the first one, not only console 4 changes of mode, but the console
> >> I am calling it from also changes to pal mode.
> >> I couldn't understand why. DO you see any reason?
> 
> >Yes. Second time it will call secondary's head set_var with console
> >argument 0, because of PROC_CONSOLE() will return that... 
> >Use 'fbset -fb /dev/tty4', and all problems will magically disappear.
> >I'm using
> 
> >set -e
> 
> What is this for? emacs mode?
> I use 'set -vi' :)

Stop on error... so in your case it will stop just immediately
after fbset will fail, instead of performing (now useless and
dangerous) second fbset, matroxset, and chvt.
 
> >con2fb /dev/fb1 /dev/tty8
> 
> This is the command less problems has given to me ;-) Simple code and
> apparently bug-free :)
> 
> >fbset -fb /dev/tty8 1280x1024-60 -depth 16
> >fbset -fb /dev/tty8 -vyres 3276
> 
> I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO:
> Invalid argument'. The only way I've found is to switch to the desired
> vt, and run fbset there.

Do you have 16MB or 32MB device? -vyres 3276 will work only if
you have 8MB available for second head. With 16MB device maybe
only 7.9MB is available for second head. And of course, you must have
fbset-through-vt patch in your kernel, otherwise you'll get -EINVAL
too.
 
> >> Besides, if you read tvgetty.sh, you'll see a line with 'setfont'.
> >> That's because without it I do not get 8bit mode on that console, and
> >> thus can't see extended characters. Is it normal that I have to
> >> re-run that kind of init scripts, which are system-wide (for all the
> >> consoles) on my system, for the second head?
> 
> >Probably. Console subsystem tends to load default font to the tty
> >on mode sets: look at fbcon_setup: it will find whether
> >some other VT on specified fb uses some font, then it releases
> >current font, and now, if it found some font in previous step
> >(i.e. at least two VTs use this fbdev...), it will copy this font
> >to the VT in question, otherwise it will try fbdev default font
> >(as specified by video=matrox:font:...), or system global default
> >font (fbcon_get_default_font()).
> 
> That was it, I have to change the font on fb1 at least once and it'll be
> in effect from there on on any vt open on fb1.

OK.
 
> Another question. To get a fast vertical scroll I have to run with a
> bigger virtual yres than real's. Is this normal? 

Yes. With yres=vyres you cannot use hardware panning, hardware must
always move full screen 16 graphics lines up. Even if MGA core
can transfer 1GBps, it takes some time to scroll 3MB (for 1024x768/32bpp)
up - to scroll out all 48 lines it is 144MB read + 144MB written...

> Also, with fastfonts
> enabled, it's terribly slow, while in the kernel documentation it's
> stated than fastfonts is faster on Gx00 cards.
> Has that anything to do with the scrollback you told me before? I have
> not tried it yet.

No. fastfont should be used only on G200 (if anywhere...). On G200
you'll get about 10% speed gain, on older chips about 10% slowdown.
But (for unknown reason...) on G400 you'll get about 1000% slowdown.
Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt
also on newer hardware.

> Anyway, thanks, and I mean a BIG thanks for your detailed quick and
> prompt response. I wish I got such a nice help with a bttv/DVB cards
> problem I cannot solve.

Buy me one... if it is terrestric digital broadcast, maybe I could
even receive some digital signal here.
                                                Petr
                                                

Re: [Linux-fbdev-devel] matroxfb dualhead instabilities

[Javier M. <jm...@po...>]

* Petr Vandrovec <VAN...@vc...> [021016 09:19]:

>> I patched my kernel with fbset-through-vt-2.4.19-rc5.gz,
>> mga-2.4.19-rc5-tvout.gz was already merged by Alan Cox on his tree.
>> However I get oopses often when using a console on my TV if I am playing
>> with matroxset & fbset, which I am right now as I am polishing some
>> scripts and default config files to include in the package for Gentoo.
>> I have just removed it from my kernel and I'll see if the oopses show up
>> again.

>Make sure that you boot with 'video=3Dscrollback:0' if you have more
>than one head... It is also very dangerous to use 'fbset -fb /dev/fbX'

By more than one head you mean more than one physical card? Ot does my
G400MAX with its two heads count as more than one?

>in multihead environment, because of PROC_CONSOLE() returns vt
>number from the VT for the process, happilly passing VT initialized
>by vga16 or primary head of matroxfb to secondary head. And secondary
>head is certainly surprised if it is invoked on console saying
>8bpp, while it supports only 16/32...

One strange thing I've seen though, is that I cannot use 'fbset -depth
xx' with xx other than 32 or I'll get:
	'ioctl FBIOPUT_VSCREENINFO: Invalid argument'
=09
>If you'll use 'fbset -fb /dev/ttyX', no oops should occur.

Whenever I try to pass a tty as argument to the -fb option I get the
same error I wrote above.

>> I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use at
>> all any board on my first PCI slot since the Matrox is using the IRQ.
>> What is the patch good for? I just have a crowded PC and no free slots.

>I did not wrote that patch... Make sure that request_irq() is done
>for shared irq, Matrox hardware has no problem with sharing irq, and
>if irq handler in matroxfb-vsync-irq-patch is written correctly, it
>should just work.

I know it is not a problem of the card itself, since without that patch
I don't have problems, but with it whenever a card on the 1st PCI tries
to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the
system blocks. No output, no sysrq, nothing, just a solid freeze.

BTW, of the other two patches available, what is the one quoted at the
top of this message for? I have removed it and since then I get no more
locks when heavily using my second head, which was specially sensitive
when doing lots of 'fbset', 'matroxset' et all.

>> tvgetty.sh from inittab there aren't any kind of problems, but if I
>> launch it from another console, the first time works as expected, but
>> after the first one, not only console 4 changes of mode, but the console
>> I am calling it from also changes to pal mode.
>> I couldn't understand why. DO you see any reason?

>Yes. Second time it will call secondary's head set_var with console
>argument 0, because of PROC_CONSOLE() will return that...=20
>Use 'fbset -fb /dev/tty4', and all problems will magically disappear.
>I'm using

>set -e

What is this for? emacs mode?
I use 'set -vi' :)

>con2fb /dev/fb1 /dev/tty8

This is the command less problems has given to me ;-) Simple code and
apparently bug-free :)

>fbset -fb /dev/tty8 1280x1024-60 -depth 16
>fbset -fb /dev/tty8 -vyres 3276

I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO:
Invalid argument'. The only way I've found is to switch to the desired
vt, and run fbset there.

>> Besides, if you read tvgetty.sh, you'll see a line with 'setfont'.
>> That's because without it I do not get 8bit mode on that console, and
>> thus can't see extended characters. Is it normal that I have to
>> re-run that kind of init scripts, which are system-wide (for all the
>> consoles) on my system, for the second head?

>Probably. Console subsystem tends to load default font to the tty
>on mode sets: look at fbcon_setup: it will find whether
>some other VT on specified fb uses some font, then it releases
>current font, and now, if it found some font in previous step
>(i.e. at least two VTs use this fbdev...), it will copy this font
>to the VT in question, otherwise it will try fbdev default font
>(as specified by video=3Dmatrox:font:...), or system global default
>font (fbcon_get_default_font()).

That was it, I have to change the font on fb1 at least once and it'll be
in effect from there on on any vt open on fb1.

Another question. To get a fast vertical scroll I have to run with a
bigger virtual yres than real's. Is this normal? Also, with fastfonts
enabled, it's terribly slow, while in the kernel documentation it's
stated than fastfonts is faster on Gx00 cards.
Has that anything to do with the scrollback you told me before? I have
not tried it yet.

Anyway, thanks, and I mean a BIG thanks for your detailed quick and
prompt response. I wish I got such a nice help with a bttv/DVB cards
problem I cannot solve.


--=20
Javier Marcet <jm...@po...>
Saint Louis University, Madrid Campus

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[Petr V. <VAN...@vc...>]

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

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[Carlo E. P. <fl...@fl...>]

	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)

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[<sy...@sc...>]

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/

Re: [Linux-fbdev-devel] matroxfb dualhead instabilities

[Petr V. <VAN...@vc...>]

On 16 Oct 02 at 2:08, Javier Marcet wrote:
> 
> I patched my kernel with fbset-through-vt-2.4.19-rc5.gz,
> mga-2.4.19-rc5-tvout.gz was already merged by Alan Cox on his tree.
> However I get oopses often when using a console on my TV if I am playing
> with matroxset & fbset, which I am right now as I am polishing some
> scripts and default config files to include in the package for Gentoo.
> I have just removed it from my kernel and I'll see if the oopses show up
> again.

Make sure that you boot with 'video=scrollback:0' if you have more
than one head... It is also very dangerous to use 'fbset -fb /dev/fbX'
in multihead environment, because of PROC_CONSOLE() returns vt
number from the VT for the process, happilly passing VT initialized
by vga16 or primary head of matroxfb to secondary head. And secondary
head is certainly surprised if it is invoked on console saying
8bpp, while it supports only 16/32...

If you'll use 'fbset -fb /dev/ttyX', no oops should occur.
 
> I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use at
> all any board on my first PCI slot since the Matrox is using the IRQ.
> What is the patch good for? I just have a crowded PC and no free slots.

I did not wrote that patch... Make sure that request_irq() is done
for shared irq, Matrox hardware has no problem with sharing irq, and
if irq handler in matroxfb-vsync-irq-patch is written correctly, it
should just work.
 
> I send attached two of the scripts I've written. There is something
> which I could not yet understand.
> If you run 'mgafb.sh pal fb1 4' to set fb1 in pal mode and control
> virtual console 4, in principle works just fine. If I run it from
> tvgetty.sh from inittab there aren't any kind of problems, but if I
> launch it from another console, the first time works as expected, but
> after the first one, not only console 4 changes of mode, but the console
> I am calling it from also changes to pal mode.
> I couldn't understand why. DO you see any reason?

Yes. Second time it will call secondary's head set_var with console
argument 0, because of PROC_CONSOLE() will return that... 
Use 'fbset -fb /dev/tty4', and all problems will magically disappear.
I'm using

#! /bin/bash

set -e
con2fb /dev/fb1 /dev/tty8
fbset -fb /dev/tty8 1280x1024-60 -depth 16
fbset -fb /dev/tty8 -vyres 3276
matroxset -f /dev/fb0 -m 2
matroxset -f /dev/fb1 -m 5
chvt 8

and it works as one expect...

> Besides, if you read tvgetty.sh, you'll see a line with 'setfont'.
> That's because without it I do not get 8bit mode on that console, and
> thus can't see extended characters. Is it normal that I have to
> re-run that kind of init scripts, which are system-wide (for all the
> consoles) on my system, for the second head?

Probably. Console subsystem tends to load default font to the tty
on mode sets: look at fbcon_setup: it will find whether
some other VT on specified fb uses some font, then it releases
current font, and now, if it found some font in previous step
(i.e. at least two VTs use this fbdev...), it will copy this font
to the VT in question, otherwise it will try fbdev default font
(as specified by video=matrox:font:...), or system global default
font (fbcon_get_default_font()).

                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[Petr V. <VAN...@vc...>]

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

Re: [Linux-fbdev-devel] matroxfb dualhead instabilities

[Javier M. <jm...@po...>]

* Javier Marcet <jm...@po...> [021016 02:11]:

BTW, I have a Matrox G400MAX, and use it on an ASUS A7V133 with an
Athlon 1800XP.

The commandline I use to set up matroxfb at boot time is:
video=3Dmatrox:mem:32,xres:1280,yres:960,left:264,right:24,hslen:160,upper:=
47,lower:1,vslen:3,pixclock:6024,sync:0x03,depth:32,pan

I can send you my dmesg if needed.


--=20
Javier Marcet <jm...@po...>
Saint Louis University, Madrid Campus

[Linux-fbdev-devel] matroxfb dualhead instabilities

[Javier M. <jm...@po...>]

Hi Petr,
I am doing a package for Gentoo with some tools for matrox dual-head
cards, mainly developed by you and available on your ftp.

I am using linux 2.4.20-pre8-ac3 at the moment. I hadn't used the second
head too much until now.

I patched my kernel with fbset-through-vt-2.4.19-rc5.gz,
mga-2.4.19-rc5-tvout.gz was already merged by Alan Cox on his tree.
However I get oopses often when using a console on my TV if I am playing
with matroxset & fbset, which I am right now as I am polishing some
scripts and default config files to include in the package for Gentoo.
I have just removed it from my kernel and I'll see if the oopses show up
again.

I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use at
all any board on my first PCI slot since the Matrox is using the IRQ.
What is the patch good for? I just have a crowded PC and no free slots.

I send attached two of the scripts I've written. There is something
which I could not yet understand.
If you run 'mgafb.sh pal fb1 4' to set fb1 in pal mode and control
virtual console 4, in principle works just fine. If I run it from
tvgetty.sh from inittab there aren't any kind of problems, but if I
launch it from another console, the first time works as expected, but
after the first one, not only console 4 changes of mode, but the console
I am calling it from also changes to pal mode.
I couldn't understand why. DO you see any reason?

Besides, if you read tvgetty.sh, you'll see a line with 'setfont'.
That's because without it I do not get 8bit mode on that console, and
thus can't see extended characters. Is it normal that I have to
re-run that kind of init scripts, which are system-wide (for all the
consoles) on my system, for the second head?

I hope I made me clear enough. Otherwise, tell me what needs to be
clarified.


-- 
Javier Marcet <jm...@po...>
Saint Louis University, Madrid Campus

Re: [Linux-fbdev-devel] Status of radeonfb in 2.5?

[Ani J. <aj...@un...>]

radeonfb for 2.5 will be updated in the next release (or 2).


ani


On Tue, 15 Oct 2002, Nicholas Wourms wrote:

> Hi,
>
> I was curious to know if the maintainer for the radeonfb
> driver was planning to update it wrt James' recent API
> changes.  Considiering it is the latest line available, I'd
> hope that its brokeness will not be permanent ;-).
>
> Cheers,
> Nicholas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

[Linux-fbdev-devel] Status of radeonfb in 2.5?

[Nicholas W. <nw...@ne...>]

Hi,

I was curious to know if the maintainer for the radeonfb 
driver was planning to update it wrt James' recent API 
changes.  Considiering it is the latest line available, I'd 
hope that its brokeness will not be permanent ;-).

Cheers,
Nicholas

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[Petr V. <VAN...@vc...>]

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
                                                        

Re: [Linux-fbdev-devel] Another problem, seemingly coming f

[Petr V. <VAN...@vc...>]

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
                                                

[Linux-fbdev-devel] Another problem, seemingly coming from mixing millennium and g400

[Carlo E. P. <fl...@fl...>]

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.

In both cases, the matrox_pins output is unchanged to what I had sent
to you before. But the lspci output changes a lot. Here you have a
diff: lspcialone is where the g400 is by itself, while lspciwithmill
is when the millennium is also present.


--- lspcialone  Tue Oct 15 11:55:21 2002
+++ lspciwithmill       Tue Oct 15 12:04:25 2002
@@ -1,33 +1,32 @@
 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G400 Dual Head Max
-       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
+       Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
-       Latency: 64 (4000ns min, 8000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=32M]
        Region 1: Memory at e4000000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at e5000000 (32-bit, non-prefetchable) [size=8M]
-       Expansion ROM at <unassigned> [disabled] [size=64K]
+       Expansion ROM at e6000000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
-               Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1
-00: 2b 10 25 05 07 00 90 02 04 00 00 03 08 40 00 00
+               Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
+00: 2b 10 25 05 02 00 90 02 04 00 00 03 08 40 00 00
 10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
-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
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-f0: 02 00 20 00 03 02 00 1f 01 03 00 1f 00 00 00 00
+f0: 02 00 20 00 03 02 00 1f 00 00 00 00 00 00 00 00

In case you need it, I also add the lspci info for the millennium:

00:09.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01) (prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size=16K]
        Region 1: Memory at eb000000 (32-bit, prefetchable) [size=8M]
        Expansion ROM at ec000000 [disabled] [size=64K]
00: 2b 10 19 05 83 00 80 02 01 00 00 03 00 00 00 00
10: 00 00 00 ea 08 00 00 eb 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 ec 00 00 00 00 00 00 00 00 0a 01 00 00
40: 00 11 2c 5f 00 3c 00 00 06 aa ff 06 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

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?

Thanks in advance

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)

[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[Russell K. <rm...@ar...>]

On Tue, Oct 15, 2002 at 11:14:03AM +0200, Geert Uytterhoeven wrote:
> So the generic part of the code should behave like this:
> 
>   if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
>       /* use hardware blanking */
>   } else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> 	     info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
>       /* use software blanking */
>   } else {
>       /* no blanking possible, except for filling the screen with black, which
> 	 is not appropriate (unless we save/restore the contents?) */
>   }
> 
> Is that OK for you?

That's fine for me, but I'd expect other people to find problems with it.

Would it not be better to allow drivers to decide which type of blanking
they want to use depending on the current parameters set via the set_par
callback?  Only the drivers themselves know what their fb_blank method is
capable of performing.

I think with the above you'll inadvertently encourage drivers to mundge
the fb_blank function pointer in their set_par method.

There is also the argument about wanting soft blanking, but hardware power
saving.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[Geert U. <ge...@li...>]

On Tue, 15 Oct 2002, Russell King wrote:
> I'm not sure this "set var" business has been thought out as much as it
> should be.
> 
> If can_soft_blank is not set, the driver will never, ever receive any
> calls to perform blanking via the fb_blank callback.  Even the power
> management blanking calls are blocked, and fbcon clears the screen
> instead.  This in itself is fine.
> 
> However, since the set_var method has gone, drivers are now unable to
> set can_soft_blank according to their capabilities because
> fbgen.c:gen_set_disp will do it for them thusly:
> 
>         if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
>             info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
>                 display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
>                 display->dispsw_data = NULL;
>         } else {
>                 display->can_soft_blank = 0;
>                 display->dispsw_data = info->pseudo_palette;
>         }
> 
> This sucks on devices where blanking can be performed by hardware means.
> For example, on embedded devices, you can turn off the LCD controller
> and LCD panel (and thereby save power).  There's no point in having both
> these powered/running when the display is not in use, draining valuable
> battery power.
> 
> This is also true of most, if not all VGA cards when VESA blanking is in
> effect.  As the code currently stands, if the console is in pseudo colour
> or direct colour mode, everything works as expected.  However, if it isn't,
> you can't even power down your monitor when the screen blanks.
> 
> In 2.5.42, there is a work around possible - it is possible to intercept
> the call to gen_set_var, and set con_soft_blank according to your driver
> capabilities.  However, with the fb_set_var method going away, this is no
> longer possible.

So the generic part of the code should behave like this:

  if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
      /* use hardware blanking */
  } else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
	     info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
      /* use software blanking */
  } else {
      /* no blanking possible, except for filling the screen with black, which
	 is not appropriate (unless we save/restore the contents?) */
  }

Is that OK for you?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[Russell K. <rm...@ar...>]

On Mon, Oct 14, 2002 at 09:39:31AM -0700, James Simmons wrote:
>  drivers/video/clps711xfb.c        |    2

Ok, this won't clash with the updates Linus pulled recently from me
that actually allow this driver to build again in 2.5.42.

> diff -Nru a/drivers/video/clps711xfb.c b/drivers/video/clps711xfb.c
> --- a/drivers/video/clps711xfb.c	Mon Oct 14 09:36:34 2002
> +++ b/drivers/video/clps711xfb.c	Mon Oct 14 09:36:34 2002
> @@ -194,7 +194,6 @@
>  	.owner		= THIS_MODULE,
>  	.fb_check_var	= clps7111fb_check_var,
>  	.fb_set_par	= clps7111fb_set_par,
> -	.fb_set_var	= gen_set_var,
>  	.fb_setcolreg	= clps7111fb_setcolreg,
>  	.fb_blank	= clps7111fb_blank,
>  	.fb_fillrect	= cfb_fillrect,
> @@ -322,7 +321,6 @@
>  		clps_writeb(clps_readb(PDDR) | EDB_PD3_LCDBL, PDDR);
>  	}
> 
> -	gen_set_var(&cfb->var, -1, cfb);
>  	err = register_framebuffer(cfb);
> 
>  out:	return err;

I'm not sure this "set var" business has been thought out as much as it
should be.

If can_soft_blank is not set, the driver will never, ever receive any
calls to perform blanking via the fb_blank callback.  Even the power
management blanking calls are blocked, and fbcon clears the screen
instead.  This in itself is fine.

However, since the set_var method has gone, drivers are now unable to
set can_soft_blank according to their capabilities because
fbgen.c:gen_set_disp will do it for them thusly:

        if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
            info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
                display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
                display->dispsw_data = NULL;
        } else {
                display->can_soft_blank = 0;
                display->dispsw_data = info->pseudo_palette;
        }

This sucks on devices where blanking can be performed by hardware means.
For example, on embedded devices, you can turn off the LCD controller
and LCD panel (and thereby save power).  There's no point in having both
these powered/running when the display is not in use, draining valuable
battery power.

This is also true of most, if not all VGA cards when VESA blanking is in
effect.  As the code currently stands, if the console is in pseudo colour
or direct colour mode, everything works as expected.  However, if it isn't,
you can't even power down your monitor when the screen blanks.

In 2.5.42, there is a work around possible - it is possible to intercept
the call to gen_set_var, and set con_soft_blank according to your driver
capabilities.  However, with the fb_set_var method going away, this is no
longer possible.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[Geert U. <ge...@li...>]

On Mon, 14 Oct 2002, James Simmons wrote:
> > On Sun, 13 Oct 2002, James Simmons wrote:
> > > This is nearly the last of the fbdev api changes (90% of them). Alot of
> > > driver fixes as well. The console related stuff in each fbdev driver
> > > is nearly gone!!! Please do a pull. Thank you.
> > >
> > > bk://fbdev.bkbits.net/fbdev-2.5
> >
> > Please add the output of diffstat, so we know which files you changed.
> 
> Better yet here is the BK patch via email.
> @@ -220,12 +218,7 @@
>     bool '  Advanced low level driver options' CONFIG_FBCON_ADVANCED
>     if [ "$CONFIG_FBCON_ADVANCED" = "y" ]; then
>        tristate '    Monochrome support' CONFIG_FBCON_MFB

CONFIG_FBCON_MFB can be deleted, because of this change to the Makefile:

> -obj-$(CONFIG_FBCON_MFB)           += fbcon-mfb.o

>  #      tristate '    Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16

FBCON_IPLAN2P16 can be deleted, since it doesn't exist.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] fbdev changes.

[Michel <mi...@da...>]

On Son, 2002-10-13 at 22:27, James Simmons wrote:=20
>=20
>   The final changes to the fbdev layer are at hand. One of the last
> changes I wanted to purpose was to create a console driectory in
> drivers/video and move all console related stuff into that directory.
> The next step was to move the dri stuff into that directory with the agp
> code possible. The questions I have is should we move the agp code over t=
o
> that directory. Should the DRI code move over directly or should we move
> DRI driver specific code into the same directory as the fbdev driver
> directories? For example in aty directory we have all the ati framebuffer
> and ATI dri code. What do you think?

Wouldn't that complicate merges between the kernel and DRI CVS? At any
rate, I think discussion related to the DRI should take place on
dri-devel.


--=20
Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] [2.5.42] screen corruption with vesafb

[Antonino D. <ad...@po...>]

On Sun, 2002-10-13 at 20:47, Jochen Hein wrote: 
> 
> When running Emacs on a framebuffer console and inserting characters
> in the middle of a line, the character after the cursor get corrupted
> in two of three tries.  A redraw (Ctrl-L) fixes it, so I suspect a
> framebuffer bug.  I can provide a screenshot if there is a need.
> 
I experienced similar problems before.  In my case, this was due to
problems with cfbfillrect.c and cfbcopyarea.c.  

Geert wrote similar routines in the CVS version of fbtest.  I modified
them so they can be used as drop-in replacements for the kernel
framebuffer.  See the thread "Console Rotation" last month. 

Tony

Re: [Linux-fbdev-devel] fbdev changes.

[Antonino D. <ad...@po...>]

On Mon, 2002-10-14 at 04:27, James Simmons wrote:
[...]
> 
> Second change!! We need a uiversal cursor api. I purposed some time ago a
> api but nothing happend.I like to resolve this final part to remove th
> last bit of console crude from the fbdev layer.
> 
> The api I suggested was :
> 
> 
> /*
>  * hardware cursor control
>  */
> 
> #define FB_CUR_SETCUR   0x01
> #define FB_CUR_SETPOS   0x02
> #define FB_CUR_SETHOT   0x04
> #define FB_CUR_SETCMAP  0x08
> #define FB_CUR_SETSHAPE 0x10
> #define FB_CUR_SETALL   0x1F
> 
> struct fbcurpos {
>         __u16 x, y;
> };
> 
> struct fbcursor {
>         __u16 set;              /* what to set */
>         __u16 enable;           /* cursor on/off */
>         struct fbcurpos pos;    /* cursor position */
>         struct fbcurpos hot;    /* cursor hot spot */
>         struct fb_cmap cmap;    /* color map info */
>         struct fbcurpos size;   /* cursor bit map size */
>         char *image;            /* cursor image bits */
>         char *mask;             /* cursor mask bits */
> };
> 
> If you have any suggestion please post you purpose struct. Thank you.

Can you clarify the usage of the above?  Assuming the console cursor is
monochrome, half-height, and fontsize is 8x16, how would the structure
be filled up?

We will also need a field for the bit operation (xor, solid, trans, etc)
as suggested by Petr, at least for monochrome.

Finally, another field for the font bitmap that is overlying the cursor
may be needed.  Only for the console and a monochrome cursor.  This way,
the driver can manually do the bit operation if the hardware is
incapable of doing so.

If I'm to guess at the structure usage (in console):

set - which of the fbcursor fields have changed
enable - make cursor visible/invisible
hot - how will this be used?  
size - is this fontsize or the actual cursor size?
image - bitmap where all bits are set to 1?
mask - does this correlate with the shape of the cursor or with the
underlying font bitmap?

image and mask has the same dimensions (fbcursor.size)?

Tony

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

[Carlo E. P. <fl...@fl...>]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: lun, ott 14, 2002 at 02:54:40 +0200

Quoting Petr Vandrovec (van...@vc...):

> Small mistake. Please apply patch below, it should fix your
> problem.

It does! Thanks.

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)

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

[Petr V. <van...@vc...>]

On Mon, Oct 14, 2002 at 07:50:53AM +0200, Carlo E. Prelz wrote:
> --- lspciold	Mon Oct 14 07:30:53 2002
> +++ lspcinew	Mon Oct 14 07:35:09 2002
> @@ -17,7 +17,7 @@
>  10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
>  20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
>  30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
> -40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
> +40: 20 08 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00

Oops.

>   OPTION flags:                  0xC2

Small mistake. Please apply patch below, it should fix your
problem.
						Best regards,
							Petr Vandrovec
							van...@vc...


--- linux-2.5.41-c748/drivers/video/matrox/matroxfb_misc.c.orig	2002-10-10 18:11:14.000000000 +0200
+++ linux-2.5.41-c748/drivers/video/matrox/matroxfb_misc.c	2002-10-14 14:50:29.000000000 +0200
@@ -849,7 +849,7 @@
 					  ( bd->pins[86]        & 0x0000000F);
 	MINFO->values.reg.opt		= ((bd->pins[53] << 15) & 0x00400000) |
 					  ((bd->pins[53] << 22) & 0x10000000) |
-					  ((bd->pins[53] << 10) & 0x00001C00);
+					  ((bd->pins[53] <<  7) & 0x00001C00);
 	MINFO->values.reg.opt3		= get_u32(bd->pins + 67);
 	MINFO->values.pll.system	= (bd->pins[ 65] == 0xFF) ? 200000 			: bd->pins[ 65] * 4000;
 	MINFO->features.pll.ref_freq	= (bd->pins[ 92] & 0x01) ? 14318 : 27000;

[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[Geert U. <ge...@li...>]

On Sun, 13 Oct 2002, James Simmons wrote:
> This is nearly the last of the fbdev api changes (90% of them). Alot of
> driver fixes as well. The console related stuff in each fbdev driver
> is nearly gone!!! Please do a pull. Thank you.
> 
> bk://fbdev.bkbits.net/fbdev-2.5

Please add the output of diffstat, so we know which files you changed.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds