I said:
>> but if I try to press these settings back into the system, a'la
>>
>> [EMAIL PROTECTED] simple]# fbset --geometry 640 480 640 480 8 \
>> --timings 39721 40 24 32 11 96 2 -rgba 8/0,8/0,8/0,0/0
>>
>> my monitor behaves exactly the same way as it does when running the
>> 'simple' tutorial program -- it seems to drop sync. (Monitor goes into
>> standby mode.)
Sven Neumann replied:
>This could simply be a timing problem. I would suggest you copy the
>file fb.modes from the DirectFB source tree to /etc/fb.modes.
I'd done that previously. Every mode I've tried seems to leave
no sign that anything is amiss in the DFB diagnostics (again using
the 'simple' tutorial program to load the settings, but after a
moment the monitor flips to standby.
I was seeing 'Asserts' in the DFB message stream until I realized
I was uncommenting just one mode at a time in fb.modes, but still
specifying what res to use in the directfbrc. (D'oh.)
I've been trying to use this mode which didn't appear in the
provided fb.modes file (640x480-60). It seemed to agree with the
default 'mode' tucked away in the radeonfb.c file:
mode "640x480-60"
# D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
geometry 640 480 640 480 8
timings 39721 40 24 32 11 96 2
rgba 8/0,8/0,8/0,0/0
endmode
vs.
static struct fb_var_screeninfo radeonfb_default_var = {
640, 480, 640, 480, 0, 0, 8, 0,
{0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
0, 0, -1, -1, 0, 39721, 40, 24, 32, 11, 96, 2,
0, FB_VMODE_NONINTERLACED
};
Andre' suggested:
> don't know which kernel you're using but maybe this patch can help
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/\
> 2.6/2.6.1/2.6.1-mm3/broken-out/radeon-line-length-fix.patch
I'm currently using the 2.4.18-3 kernel from RH7.3. I see there
are much newer versions of the radeonfb driver available. Any idea
whether these might be compatible with this older kernel?
I see in another thread Rick Harris suggesting that config'ing
both the chip-specific and generic Vesa FB support into a kernel
isn't a good idea. I'd have thought that would be OK -- else how
would one make a kernel that could support either HW config? Until
a day or two ago, I was getting both /dev/fb0 (radeon) and /dev/fb1
(Vesa) framebuffer devices created (according to 'fbset -i'.) By
adjusting my kernel boot-line args, I was able to get the Vesa fb
to not be set up at boot time.
It seems particularly distressing that I can't successfully query
the settings with fbset, and feed the reply back in -- it acts like
it does running the 'simple' program -- monitor goes to stand-by
after a moment. Rocking to another console # and back restores
the video.
I'll try rebuilding w/o the other drivers, and will report back if
it helps. Also, I've been cross compiling my kernel, and wonder if
I'm doing something wrong in the course of getting it and the modules
moved over to the target... I may try installing the wherewithall
on the target to build kernels there.
As always, I appreciate the ideas and help.
Benton 15jan04
--
BC&G Holzwarth
[EMAIL PROTECTED]
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-users" as subject.
