Dear diary, on Fri, Apr 11, 2003 at 02:03:13PM CEST, I got a letter,
where Benjamin Herrenschmidt <benh@kernel.crashing.org> told me, that...
> Here's a new patch against 2.4.20 and 2.4.21-pre7 which brings more
> fixes to radeonfb:
>
> - Fix the M6 video RAM workaround
> - Some bits in the PM code were flipped, fix that.
> - RB2D_DSTCACHE_MODE shouldn't be cleared on r300 (and
> maybe not on others according to a comment in XFree, but
> we keep working code for now).
> - Re-change the pitch workaround. We now align the pitch
> when accel is enabled for a given mode, and we don't when
> accel is disabled. That should properly deal with all cases
> and allows us to remove the "special case" accel code
> - Bring in XFree workaround to not write the same value to
> the PLL (can cause blanking of some panels)
> - Bring in some of Peter Horton fixes (accel reset, cleanups)
> still some more to get in though...
> - Properly reset accel engine on each console switch so
> we work around switching from XFree leaving it in a weird
> state. Also extend the comparison of values causing us to
> reload the mode on console switch.
thanks a lot, this patch solved my quite annoying framebuffer problems with the
stock 2.4.21rc1 radeonfb driver on ATI Radeon 7000 w/ 64MB RAM :-).
If you are interested in some bugreports and don't want to read the following
semi-minihowto, please just look for the [PERHAPS-BUGREPORT] string.
In order to give advice to the fellow googlers possibly seeing this in
archives: if you have annoying long delays when switching between consoles or
the video mode you specify on the cmdline carefully results in just an ugly
mess,
* before trying anything out, something about modes and refresh rates (does NOT
cover interlaced modes):
- fbset excepts modes in the format of <X>x<Y>-<refreshrate>, while kernel
excepts the modes in the format of <X>x<Y>[-<depth>][@<refreshrate>. Beware
this difference. More about modes on commandline below.
- the kernel and fbset modes database is not in sync. You may find it useful
to add
mode "1024x768-85"
# D: 98.902 MHz, H: 70.243 kHz, V: 85.454 Hz
geometry 1024 768 1024 768 8
timings 10111 192 32 34 14 160 6
endmode
to your /etc/fb.modes --- it is the highest refresh rate my monitor
supports for this resolution.
- when you want to convert a modedb record from kernel to fb.modes format,
look into the modedb database at drivers/video/modedb.c, the structure
format is described in include/linux/fb.h. Probably the easiest way is to
do variation of
fbset -xres 1024 -yres 768 -depth 24 -match -left .... -hslen ....
with the values filled accordingly to the structure. Then run
fbset
and insert the output (ONLY the lines shown above in the example) to
/etc/fb.modes.
- the most common refresh rates appear to be 60,70,85 ; kernel has also 76,
while fbset knows about 75 ; obviously not all rates can be used with all
resolutions, this is basically what I use with 1024x768 --- I think at
least 60 should work with almost everything, though.
* try this patch
* be careful when including any vga=... parameters; if it doesn't work, try to
remove them
* when something does not work, try to login blindly and type
fbset 800x600-60
(or some other mode known to work). If nothing does happen, try to switch to
some other console and back (however that probably means you are still using
the old and broken driver).
* be careful when specifying the mode string at the kernel (lilo) commandline:
- generally, the parameter will look like
video=radeon:<mode>
(some more flags can follow, comma-separated)
- you should always specify the refresh rate, otherwise the highest possible
one could be used and your monitor may not handle it.
[PERHAPS-BUGREPORT]
- BE CAREFUL when specifying depth! This is basically where I was most burnt,
I kept specifying 24 but for some strange reason, this did very strange
things here. If you will specify some other depth (8,15,16,32,...), you may
experience problems with cursor (or it just won't work at all ;) --- it
could have different colors (which will change by time), eventually
disappearing completely (this could mean it just went black..?).
The best solution is probably not to specify the depth at all. Apparently,
24 is used by default, but it seems to work when chosen defaultly :^).
- this is what I use:
video=radeon:1024x768@85
* don't try to use anything svgalibish. SvgaLib appears not to play well with
Radeon's framebuffer w/ default configuration (I've managed to run zgv along
nvidia fb) (or maybe it cannot handle Radeon at all..?) and it will complain
about some register not being set high enough (admittelly, I didn't yet
attempt to fix that and see what happens). The main thing is though that it
leaves the card in some unknown mode and monitor goes sleep. See below.
* when you will have your Radeon in some weird state (after trying to run some
svgalibish application or naively selecting vesa video output in mplayer or
so..), you can either:
[PERHAPS-BUGREPORT]
- startx or switch to X and back if you have it already running. This will
repair it, but it won't reset all the flags (ie. accel), so you will get
delays when switching to the affected console caused by video mode changes.
- fbset on the affected console, which will also properly reset all these
flags. You can obviously first get usable console by letting X to reset it
and then running fbset on it, if you like to see what are you typing. Note
that you should reset the console to the same mode you are running on the
other consoles, otherwise you won't get rid of that delays.
[PERHAPS-BUGREPORT]
* you will have that ugly video mode change also the first time you switch to
some console. This appears to be a bug, I think it could be fixed quite
easily. You can either live with it or fix it or workaround it by doing
something smart with for, seq and chvt in your rc scripts (let this be a
homework ;-).
It is just a mix of generic fb usage advices and Radeon-specific ones... well,
what I had to discover by myself in the last few hours ;-). Perhaps it could
find a comfortable place in Documentation/fb/, dunno.
Kind regards,
-- Petr "Pasky" Baudis . A man once asked Mozart how to write a symphony. Mozart told him to study at the conservatory for six or eight years, then apprentice with a composer for four or five more years, then begin writing a few sonatas, pieces for string quartets, piano concertos, etc. and in another four or five years he would be ready to try a full symphony. The man said, "But Mozart, didn't you write a symphony at age eight?" Mozart replied, "Yes, but I didn't have to ask how." . Stuff: http://pasky.ji.cz/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/