Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [HINTS] Re: More radeonfb fixes | From | Benjamin Herrenschmidt <> | Date | 01 May 2003 12:23:23 +0200 |
| |
> > 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 :-).
Good ;)
> 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,
Known. I have to work on this next
> [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 :^).
8 is the default and works fine. 15,16 and 32 work but the cursor isn't properly rendered, this is a known fbdev problem in 2.4, I'll probably fix it by implementing HW cursor support in radeonfb. 24 bpp is a weird mode that isn't really supported by the driver
> * 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.
What is a bug ? the delays ? The fact that some apps leave garbage ? The former is normal when an actual mode switch occurs. The later is a problem with apps that bang the HW (and with X as well in some cases as it will occasionally fuck up the accel engine configuration).
The problem is that currently, the fbcon/fbdev interface doesn't provide a hook for fbdev's to force a restore of the mode & engine setting when an app leaves the KD_GRAPHICS mode.
> [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 ;-).
The "new" consoles aren't initialized, thus the driver do a mode change when switching to them. Well... I can try to fix that... > > 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, -- Benjamin Herrenschmidt <benh@kernel.crashing.org> - 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/
| ![\](/images/icornerr.gif) |