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

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[Sven L. <lu...@dp...>]

On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel D=E4nzer wrote:
> On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
> > >=20
> > > You don't need X to use the DRM, just some privileged client to
> > > initialize it.
> >=20
> > You're right.  I just realized that since DRM already has an interrup=
t
> > handler, it is unwise for fbdev to install its own interrupt handler
> > too, as this will fatally lock up the machine when DRM and fbdev are
> > loaded simultaneously.
> >=20
> > So, how about this?  Let fbdev have its own vblank ioctl, but for fbd=
ev
> > drivers with a DRM counterpart, fbdev will just call the DRM
> > wait_vblank() and send_vbl_signals() functions.   Do you think this i=
s
> > doable, I haven't examined the code thoroughly? =20
> >=20
> > The main goal is too avoid having 2 independent interrupt handlers fo=
r
> > one device.
>=20
> A noble goal, but the framebuffer device would still need its own code
> when the DRM isn't active, so I'm afraid there's no way around code
> duplication, unless we could somehow factor out the common code for the
> two to share?

Could it not be that the fbdev sort of minimally intialize the DRM when
it is not already active ? After all, the fbdev knows as much, if not
more, than the X driver about the graphic chips state, especially if the
X driver is using the fbdev.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> On Fri, 2003-01-31 at 19:24, Michel Dänzer wrote:
> > 
> > You don't need X to use the DRM, just some privileged client to
> > initialize it.
> 
> You're right.  I just realized that since DRM already has an interrupt
> handler, it is unwise for fbdev to install its own interrupt handler
> too, as this will fatally lock up the machine when DRM and fbdev are
> loaded simultaneously.
> 
> So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
> drivers with a DRM counterpart, fbdev will just call the DRM
> wait_vblank() and send_vbl_signals() functions.   Do you think this is
> doable, I haven't examined the code thoroughly?  
> 
> The main goal is too avoid having 2 independent interrupt handlers for
> one device.

A noble goal, but the framebuffer device would still need its own code
when the DRM isn't active, so I'm afraid there's no way around code
duplication, unless we could somehow factor out the common code for the
two to share?


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

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
>=20
> You don't need X to use the DRM, just some privileged client to
> initialize it.
>=20

You're right.  I just realized that since DRM already has an interrupt
handler, it is unwise for fbdev to install its own interrupt handler
too, as this will fatally lock up the machine when DRM and fbdev are
loaded simultaneously.

So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
drivers with a DRM counterpart, fbdev will just call the DRM
wait_vblank() and send_vbl_signals() functions.   Do you think this is
doable, I haven't examined the code thoroughly? =20

The main goal is too avoid having 2 independent interrupt handlers for
one device.

Tony=20
=20

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Fri, Jan 31, 2003 at 12:24:33PM +0100, Michel Dänzer wrote:
> > Yes, I've seen the dri list archives, and adding support for this in
> > fbdev will result in code dupliation :-(.
> > 
> > However, at least 3 people have mailed me that they are using their
> > somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> > X.
> 
> You don't need X to use the DRM, just some privileged client to
> initialize it.

It feels a bit silly to to use drm just for vsync interrupts. Besides
there are a lot of cards that don't have a drm driver but do have an fbdev
driver. IMHO fbdev is the logical place for this stuff.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Fre, 2003-01-31 at 00:22, Antonino Daplas wrote:
> On Thu, 2003-01-30 at 19:45, Michel Dänzer wrote:
> > On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> > > On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > > > 
> > > > > Are there any plans on merging DirectFB features? Stuff like vertical
> > > > > retrace interrupts etc.?
> > > 
> > > I wholeheartedly agree with this.  There are a lot of applications out
> > > there (especially video players) where vtrace signal delivery is
> > > critical for optimum operation.  Polling for VGA registers is not
> > > totally correct for newer cards and is too inefficient, so this has to
> > > be done at a per driver level.
> > 
> > Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> > generic ioctl which can block or send a signal on vertical blank
> > interrupts.
> 
> Yes, I've seen the dri list archives, and adding support for this in
> fbdev will result in code dupliation :-(.
> 
> However, at least 3 people have mailed me that they are using their
> somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> X.

You don't need X to use the DRM, just some privileged client to
initialize it.


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

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Fri, 2003-01-31 at 08:16, Fredrik Noring wrote:
> Hi Antonino,
> 
> fre 2003-01-31 klockan 00.22 skrev Antonino Daplas:
> > However, at least 3 people have mailed me that they are using their
> > somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> > X.  The image instability is noticeable because they are driving
> > big-screen TV's, especially because DirecFB is double-buffered, with
> > triple-buffering in the TODO list.
> 
> I don't think vertical retrace synchronisation is strictly necessary 
> for excellent video playback on low-grade systems. Reason is that I
> believe most graphics cards delay the flip automatically in hardware
> using shadow registers which load the real registers during retrace.

This is true if you have triple, or more, buffers -- (buffer currently
being displayed, buffer waiting to be displayed, and buffer being
decoded to) and if the display refresh rate is faster than the video
frame frate.  In this case, you can just simply rely on the hardware
doing the actual buffer flip during vblank since you are guaranteed that
the next frame will not arrive until at least one vertical retrace
later.

With double buffers, you still need to synchronize with the retrace
signal, otherwise the video decoder will write to the buffer currently
being displayed (because the actual flip was delayed by the hardware). 
Polling for the VGA registers will be enough in most cases, but will not
work correctly with some hardware.
 
> 
> The software only needs to flip the buffers with approximately the same
> frequency, and it'll work fine.

Right, the software will flip the buffers at the correct frequency.
However, decoding will occur immediately after returning from the flip
command.

> 
> I've sent a few patches to the Xine (video player) developers to improve
> the frame buffer driver and player. The new driver allocates as many
> buffers as possible natively in video RAM. Thus, with a 16 MB TNT card
> you'll get about 9 buffers at 768x576x32 (PAL DVD) resolution. That
> should give the driver plenty of margins to deal with occasional
> scheduling problems etc. because the only essential thing it needs to
> do meanwhile is flipping buffers using the FBIOPAN_DISPLAY ioctl. This
> can be done with the regular Linux kernel frame buffer drivers.

Ahh, you have a lot of buffers here, so vretrace synchronization is not
a problem.  I was referring to DirectFB which is only double-buffered. 

Tony

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[Fredrik N. <no...@no...>]

Hi Antonino,

fre 2003-01-31 klockan 00.22 skrev Antonino Daplas:
> However, at least 3 people have mailed me that they are using their
> somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
> X.  The image instability is noticeable because they are driving
> big-screen TV's, especially because DirecFB is double-buffered, with
> triple-buffering in the TODO list.

I don't think vertical retrace synchronisation is strictly necessary 
for excellent video playback on low-grade systems. Reason is that I
believe most graphics cards delay the flip automatically in hardware
using shadow registers which load the real registers during retrace.

The software only needs to flip the buffers with approximately the same
frequency, and it'll work fine.

I've sent a few patches to the Xine (video player) developers to improve
the frame buffer driver and player. The new driver allocates as many
buffers as possible natively in video RAM. Thus, with a 16 MB TNT card
you'll get about 9 buffers at 768x576x32 (PAL DVD) resolution. That
should give the driver plenty of margins to deal with occasional
scheduling problems etc. because the only essential thing it needs to
do meanwhile is flipping buffers using the FBIOPAN_DISPLAY ioctl. This
can be done with the regular Linux kernel frame buffer drivers.

I think Xine being threaded (as compared with mplayer which is not) is
an advantage when implementing this. It's still work-in-progress but I
hope the theory will work out when I have the ability to do more
advanced tests than I've done so far. :)

	Fredrik

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Thu, 2003-01-30 at 19:45, Michel D=E4nzer wrote:
> On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> > On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > >=20
> > > > Are there any plans on merging DirectFB features? Stuff like vertic=
al
> > > > retrace interrupts etc.?
> >=20
> > I wholeheartedly agree with this.  There are a lot of applications out
> > there (especially video players) where vtrace signal delivery is
> > critical for optimum operation.  Polling for VGA registers is not
> > totally correct for newer cards and is too inefficient, so this has to
> > be done at a per driver level.
>=20
> Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
> generic ioctl which can block or send a signal on vertical blank
> interrupts.
>=20
>=20

Yes, I've seen the dri list archives, and adding support for this in
fbdev will result in code dupliation :-(.

However, at least 3 people have mailed me that they are using their
somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
X.  The image instability is noticeable because they are driving
big-screen TV's, especially because DirecFB is double-buffered, with
triple-buffering in the TODO list.  It's because of this that I have to
hack in vretrace signal delivary to i810fb.  There's also a similar
patch for matroxfb.


Tony

Re: [Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

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

On Fri, 2003-01-31 at 03:34, James Simmons wrote:
> 
> > >    To Tony. I applied your patches as well. The only patch I didn't was 
> > > the DIRECTCOLOR patch. The X server freaked out for my card when the video 
> > > mode was in a DIRECTCOLOR state.
> > > 
> > 
> > Yes I'm not sure about this too.  Also the patch I submitted is untested
> > for RGB565, tested only for RGB555 and RGB8888.  So, does X work for
> > rivafb?  It does not work in my hardware unless I add the directcolor
> > patch.
> 
> I applied your direct color patch. The X server has issues without it as 
> well. For some reason the screen is cut in half and the colors are wrong.
> Even when I leave X. The only solution is to switch back to 8 bpp mode.
> 

I get this too.  For some reason, X fails to dynamically set rivafb to
the mode it wants to use.  So, I have to use fbset first to set rivafb
to the mode and visual X is going to use.  After doing this, I get
XFBdev working nicely (at Depth 15).

I have no problems with DirectFB though.

Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

On Sat, 2003-01-25 at 04:14, James Simmons wrote:
> 
> I applied part of the patch. I like to avoid changing nv_driver to much 
> because it is based on the X windows driver. Easier to keep them sync. 
> What we could do is move the following 
> 
> riva_common_setup(par);
> ..
> 
> par->dclk_max = par->riva.MaxVClock..
> 
> from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it 
> works.
> 

I haven't tried this yet, but I think it will work.  The only (very
minor) problem with this is the rivafb's printk output will be incorrect
(no info on video memory size).  

Tony

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

On Sat, 2003-01-25 at 17:00, Geert Uytterhoeven wrote:
> On Fri, 24 Jan 2003, James Simmons wrote:
> > > > The only problem right now is how do you pass the monitor info to the
> > > > driver?  The best way is to parse the EDID block and use I2C/DDC. 
> > > > Personally, I think passing the monitor info as a boot/module option is
> > > > the simplest and safest method.
> > > 
> > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...?
> > > 
> > > Since ioctls are considered evil these days, changing the resolution etc. could
> > > work in a similar way as well.
> > 
> > Can you do this with sysfs? This is what I have been waiting for!!! The 
> > proc thing is don't care for tho.
> 
> Yes, you can create a fbdev filesystem, which shows frame buffers and
> information about them. By changing the contents of those virtual files (e.g. a
> file that corresponds to struct fb_var_screeninfo), you can change the video
> mode.  This can also solve the burden of maintaining backwards compatibility in
> struct fb_var_screeninfo. You want a new field? Just add a new virtual file to
> the filesystem.
> 
> One thing I'm still wondering about is how to keep things synchronized. You
> don't want to put all fields of struct fb_var_screeninfo in one file, you want
> separate files for resolution, timings, .... But in the end you usually want to
> change a video mode by changing all parameters at once, so you want the changes
> to the different virtual files to be synchronized. Perhaps some lock file?
> 

>From what I understand about sysfs, you can only have one type per file,
so each field will have to be in separate files.  To synchronize, we can
perhaps use a file ('sync', 'lock', 'update' or whatever) which is
similar in function to fb_var_screeninfo.activate. Only when the user
writes to this file that the new settings are synchronized and we call
fb_set_var() or whatever.

How do you think sysfs support will be written?  Will this mean that the
framebuffer system has to register its own kobject as the top level
entry in sysfs, no?  This would also mean that we need something similar
for the console subsystem if it has to support additional features, ie
rotation?

Tony

Re: [Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

[James S. <jsi...@in...>]

> >    To Tony. I applied your patches as well. The only patch I didn't was 
> > the DIRECTCOLOR patch. The X server freaked out for my card when the video 
> > mode was in a DIRECTCOLOR state.
> > 
> 
> Yes I'm not sure about this too.  Also the patch I submitted is untested
> for RGB565, tested only for RGB555 and RGB8888.  So, does X work for
> rivafb?  It does not work in my hardware unless I add the directcolor
> patch.

I applied your direct color patch. The X server has issues without it as 
well. For some reason the screen is cut in half and the colors are wrong.
Even when I leave X. The only solution is to switch back to 8 bpp mode.

[Linux-fbdev-devel] Re: [Solved] (was: Matrox G550, matroxfb: "Signal out of range")

[Stefan K. <sf...@bi...>]

Stefan Krah <sf...@bi...> wrote:
[kernel 2.4.20]
> The problem:
> 
> At bootup my monitor displays a warning sign saying:
> 
>        Signal out of range
>        125.8 kHz    173Hz
> 
> The warning sign is distorted (stretched vertically) and disappears
> after 4 seconds. From that moment on the framebuffer works normally
> and with the very frequencies I specified in /etc/lilo.conf.

I have just tried out 2.4.21-pre4 and the problem disappeared.


Stefan Krah

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Don, 2003-01-30 at 03:34, Antonino Daplas wrote:
> On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> > 
> > > Are there any plans on merging DirectFB features? Stuff like vertical
> > > retrace interrupts etc.?
> 
> I wholeheartedly agree with this.  There are a lot of applications out
> there (especially video players) where vtrace signal delivery is
> critical for optimum operation.  Polling for VGA registers is not
> totally correct for newer cards and is too inefficient, so this has to
> be done at a per driver level.

Let me point out that the DRM in XFree86 4.3.0 and 2.5 kernels has a
generic ioctl which can block or send a signal on vertical blank
interrupts.


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

[Linux-fbdev-devel] tool to reverse engineer a windows driver ?

[Sven L. <lu...@dp...>]

Hello, ...

Do some of you know of a (preferably free) way to reverse engineer a
windows driver ? I guess a simple disasembler would do the trick, since
after all i have the docs for my chip, but it has some inaccuracies, so
i would like to know what the windows driver does.

Spying the register writes would also be ok, i guess, but more
difficult, since the stuff i need is used on mode setup.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] Funny sync calculation correction

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

On Sun, 2003-01-26 at 07:18, Fredrik Noring wrote:
> > Works fine. I applied it to the 2.5.X tree.
> 
> Has anyone got Riva 128 or TNT cards working with 2.5.59 or
> later? My cards freeze up completely with the new driver when
> loading fbcon.
> 
> 	Fredrik
> 
> 
Works for STB Velocity 128 PCI (Riva 128)

Tony

Re: [Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

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

On Wed, 2003-01-29 at 03:29, James Simmons wrote:
> On 26 Jan 2003, Fredrik Noring wrote:
> 
> > Attached patch implements interlace for the rivafb driver and
> > the hardware that supports it (Riva 128, TNT, TNT2, some GeForce 
> > cards and possibly others).
> > 
> > It's a patch against 2.4.21-pre2 (with polarity and sync patches)
> > but it should fit with 2.5.x too skipping riva_hw.c and riva_hw.h 
> > which already are adopted from XFree86.
> 
> Applied. 
> 
> 
> P.S
>    To Tony. I applied your patches as well. The only patch I didn't was 
> the DIRECTCOLOR patch. The X server freaked out for my card when the video 
> mode was in a DIRECTCOLOR state.
> 

Yes I'm not sure about this too.  Also the patch I submitted is untested
for RGB565, tested only for RGB555 and RGB8888.  So, does X work for
rivafb?  It does not work in my hardware unless I add the directcolor
patch.

Tony

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

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

On Wed, 2003-01-29 at 03:21, James Simmons wrote:
> 
> > Are there any plans on merging DirectFB features? Stuff like vertical
> > retrace interrupts etc.?
> 

I wholeheartedly agree with this.  There are a lot of applications out
there (especially video players) where vtrace signal delivery is
critical for optimum operation.  Polling for VGA registers is not
totally correct for newer cards and is too inefficient, so this has to
be done at a per driver level.

> Thats already supported. Just add a poll function to fb_ops. To date no 
> one has used this feature.
> 

It's because there is no .poll entry in the struct file_operations in
fbmem.c  Something like this:

static struct file_operations fb_fops = {
	.owner =	THIS_MODULE,
	.read =		fb_read,
	.write =	fb_write,
	.ioctl =	fb_ioctl,
	.mmap =		fb_mmap,
	.open =		fb_open,
	.release =	fb_release,
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
	.get_unmapped_area = get_fb_unmapped_area,
#endif
	.poll =         fb_poll,
};

static unsigned int fb_poll(struct file *file, poll_table *wait)
{
	if (info->fbops->fb_poll)
		return (info->fbops->fb_poll(file, wait));
	return -EINVAL;
}

Also, poll is blocking.  You might want to include an .fasync entry too
for asynchronous I/O.

Finally, is the poll function too generic? I'm not sure about this but
basically we can only wait for events like 'there is data to read, it's
now okay to write', etc.  Is this too ambiguous?   Is it okay to define
a private event flag?  Or do we just agree that fb_poll means wait for
vretrace?

I know that there's already an overuse of ioctls, but for something
specific and important as this, we might not have a choice.

Tony

BTW:  It's not too difficult to add generic vsync interrupt handlers for
most VGA cards via register CR11. 

Re: [Linux-fbdev-devel] [2.5.59] radeonfb not working

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

> radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults

This line here says that radeonfb didn't acquire the pll clock values from
your BIOS properly and is using defaults, which are for the 1st gen
Radeon.  Is anyone else with a 9500 (or 9700) using radeonfb and can get
values from their BIOS?  (radeonfb will say "from BIOS" if it got them
properly).  This will explain your "out of scan range" problem because it
is not setting the mode right.


ani



On Wed, 29 Jan 2003, Kronos wrote:

> Hi,
> I've a  Radeon 9500 Pro board  and framebuffer isn't working. If  I boot
> with "video=radeon" monitor complains about "Out of scan range". This is
> from the bootlog:
>
> radeonfb_pci_register BEGIN
> radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults
> radeonfb: probed SDR SGRAM 131072k videoram
> radeon_get_moninfo: bios 4 scratch = 2000002
> radeonfb: ATI Radeon 9700 NE SDR SGRAM 128 MB
> radeonfb: DVI port no monitor connected
> radeonfb: CRT port CRT monitor connected
> radeonfb_pci_register END
> hStart = 664, hEnd = 760, hTotal = 800
> vStart = 491, vEnd = 493, vTotal = 525
> h_total_disp = 0x4f0063    hsync_strt_wid = 0x8c02a2
> v_total_disp = 0x1df020c           vsync_strt_wid = 0x8201ea
> post div = 0x8
> fb_div = 0x1f4
> ppll_div_3 = 0x301f4
> ron = 1024, roff = 23632
> vclk_freq = 2519, per = 844
> Console: switching to colour frame buffer device 80x30
>
> If   I  append   a  specific   video  mode   I'll  get   "out  of   scan
> range"   or  "no   signal"  depending   on  the   video  mode. This   is
> "video=radeon:640x480-16@85" (no signal):
>
> radeonfb_pci_register BEGIN
> radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults
> radeonfb: probed SDR SGRAM 131072k videoram
> radeon_get_moninfo: bios 4 scratch = 2000002
> radeonfb: ATI Radeon 9700 NE SDR SGRAM 128 MB
> radeonfb: DVI port no monitor connected
> radeonfb: CRT port CRT monitor connected
> radeonfb_pci_register END
> hStart = 696, hEnd = 752, hTotal = 832
> vStart = 481, vEnd = 484, vTotal = 509
> h_total_disp = 0x4f0067    hsync_strt_wid = 0x8702b9
> v_total_disp = 0x1df01fc           vsync_strt_wid = 0x8301e0
> post div = 0x4
> fb_div = 0x165
> ppll_div_3 = 0x20165
> ron = 960, roff = 16548
> vclk_freq = 3597, per = 591
> Console: switching to colour frame buffer device 80x30
>
> ciao,
> Luca
> --
> Reply-To: kr...@kr...
> Home: http://kronoz.cjb.net
> Il coraggio non mi manca.
> E` la paura che mi frega...
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

[Linux-fbdev-devel] [2.5.59] radeonfb not working

[Kronos <kr...@kr...>]

Hi,
I've a  Radeon 9500 Pro board  and framebuffer isn't working. If  I boot
with "video=radeon" monitor complains about "Out of scan range". This is
from the bootlog:

radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults
radeonfb: probed SDR SGRAM 131072k videoram
radeon_get_moninfo: bios 4 scratch = 2000002
radeonfb: ATI Radeon 9700 NE SDR SGRAM 128 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
radeonfb_pci_register END
hStart = 664, hEnd = 760, hTotal = 800
vStart = 491, vEnd = 493, vTotal = 525
h_total_disp = 0x4f0063    hsync_strt_wid = 0x8c02a2
v_total_disp = 0x1df020c           vsync_strt_wid = 0x8201ea
post div = 0x8
fb_div = 0x1f4
ppll_div_3 = 0x301f4
ron = 1024, roff = 23632
vclk_freq = 2519, per = 844
Console: switching to colour frame buffer device 80x30

If   I  append   a  specific   video  mode   I'll  get   "out  of   scan
range"   or  "no   signal"  depending   on  the   video  mode. This   is
"video=radeon:640x480-16@85" (no signal):

radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults
radeonfb: probed SDR SGRAM 131072k videoram
radeon_get_moninfo: bios 4 scratch = 2000002
radeonfb: ATI Radeon 9700 NE SDR SGRAM 128 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
radeonfb_pci_register END
hStart = 696, hEnd = 752, hTotal = 832
vStart = 481, vEnd = 484, vTotal = 509
h_total_disp = 0x4f0067    hsync_strt_wid = 0x8702b9
v_total_disp = 0x1df01fc           vsync_strt_wid = 0x8301e0
post div = 0x4
fb_div = 0x165
ppll_div_3 = 0x20165
ron = 960, roff = 16548
vclk_freq = 3597, per = 591
Console: switching to colour frame buffer device 80x30

ciao,
Luca
-- 
Reply-To: kr...@kr...
Home: http://kronoz.cjb.net
Il coraggio non mi manca.
E` la paura che mi frega...

[Linux-fbdev-devel] Matrox G550, matroxfb: "Signal out of range"

[Stefan K. <sf...@bi...>]

Hello,

I am having a problem with the matroxfb driver which I couldn't solve
by asking Google or reading the docs. I hope it is not too off-topic
here.


The problem:

At bootup my monitor displays a warning sign saying:

       Signal out of range
       125.8 kHz    173Hz

The warning sign is distorted (stretched vertically) and disappears
after 4 seconds. From that moment on the framebuffer works normally
and with the very frequencies I specified in /etc/lilo.conf.
So (from my limited point of view) it seems that the driver disregards
those maximum frequencies for 4 seconds. Or that I have forgotten to
set some vital parameter.


The hardware:

Asus TUSL2-C (i815EP, AGP 4X)
Matrox G550 (with the latest bios)
Monitor CTX VL500 (30-70kHz, 50-120Hz)


Reproduced on:

SuSE 7.3, Debian Woody, LinuxFromScratch 4.0; kernels 2.4.20, 2.4.18


My .config:

[cut]
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FB_RIVA is not set
# CONFIG_FB_CLGEN is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_HGA is not set
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
# CONFIG_FB_MATROX_MILLENIUM is not set
# CONFIG_FB_MATROX_MYSTIQUE is not set
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_G450=y
# CONFIG_FB_MATROX_MULTIHEAD is not set
[cut]


My lilo.conf:

boot    = /dev/hda
vga     = 788
read-only
menu-scheme = Wg:kw:Wg:Wg
lba32
prompt
timeout = 80
message = /boot/message

  image  = /boot/2.4.20-suse-fb
  label  = SuSE
  root   = /dev/hda11
  append = "video=matrox:vesa:788,fh:69,fv:90"

  image  = /boot/2.4.20-lfs
  label  = lfs-4.0
  root   = /dev/hda6
  append = "video=matrox:vesa:0x114,fh:69,fv:90"
[cut]



I have tried other parameters:

video=matrox:vesa:0x114  -->  same problem

video=matrox:vesa:0x114,fh:50,fv:70  -->  same problem

video=matrox:nopan   -->  same problem, but warning sign is *not* distorted
                          and videomode is different

video=matrox:vesa:0x114,maxclk:16025   --> monitor stays black



I have also tried leaving out the vga = 788, then I get the following:

  - initial boot messages are displayed in the large default console font.

  - when the matroxfb kicks in we have the same story: warning sign for
    4 seconds, after that the framebuffer works impeccably, rest of boot
    messages are displayed in framebuffer font.


I'd be grateful for a hint or two.

Regards,

Stefan Krah

Re: [Linux-fbdev-devel] vesafb and too much RAM?

[James S. <jsi...@in...>]

> I guess I shouild have mentioned that this was the first thing I tried. My
> kernel is compiled with support for 4GB of memory.
> 
> Any other ideas?

Do you have ACPI turned on? If you do try turning it off.

Re: [Linux-fbdev-devel] vesafb and too much RAM?

[Matt N. <ma...@if...>]

I guess I shouild have mentioned that this was the first thing I tried. My
kernel is compiled with support for 4GB of memory.

Any other ideas?

Thanks,
Matt N.

On Tue, 28 Jan 2003, James Simmons wrote:

>
> > I was running debian with a 2.4.20(-3 I believe) with vesafb with no
> > problems with 512MB ram. I upgraded to 1GB and immediately I could not
> > boot. I get as far as the LILO prompt, but as soon as I hit enter the
> > screen goes black, the caps lock and scroll lock keyboard LEDs flash, and
> > nothing save hitting the reset switch has any affect.
>
> You have lots oe memory. Try turning on high memory support. This will
> make the problem go away.
>
>
>

Re: [Linux-fbdev-devel] [PATCH] Interlace for rivafb driver

[James S. <jsi...@in...>]

On 26 Jan 2003, Fredrik Noring wrote:

> Attached patch implements interlace for the rivafb driver and
> the hardware that supports it (Riva 128, TNT, TNT2, some GeForce 
> cards and possibly others).
> 
> It's a patch against 2.4.21-pre2 (with polarity and sync patches)
> but it should fit with 2.5.x too skipping riva_hw.c and riva_hw.h 
> which already are adopted from XFree86.

Applied. 


P.S
   To Tony. I applied your patches as well. The only patch I didn't was 
the DIRECTCOLOR patch. The X server freaked out for my card when the video 
mode was in a DIRECTCOLOR state.

Re: [Linux-fbdev-devel] vesafb and too much RAM?

[James S. <jsi...@in...>]

> I was running debian with a 2.4.20(-3 I believe) with vesafb with no
> problems with 512MB ram. I upgraded to 1GB and immediately I could not
> boot. I get as far as the LILO prompt, but as soon as I hit enter the
> screen goes black, the caps lock and scroll lock keyboard LEDs flash, and
> nothing save hitting the reset switch has any affect.

You have lots oe memory. Try turning on high memory support. This will 
make the problem go away.