[edit] there are important appended notes at the bottom. please read the entire post before deciding to attempt. [/edit]
i was able to fix radeonfb for 2.6. i had to tweak the support for the M9 (mobility 9000. it's the Lf version, which i think we all have, correct me if i'm wrong). it's fast, and a lot better than vesafb. unfortunately, i can't really help the people using 2.4; the stuff in 2.4 is old, and only has pci definitions up to M4 or something. but you might want to check out this patch for 2.4.20, which was the one that got me started editing 2.6:
http://hypermail.idiosynkrasia.net/l...ek04/0104.html
but on to fixing 2.6:
assuming that /usr/src/linux is your dev kernel's source directory, the file we want to edit is
/usr/src/linux/include/linux/pci_ids.h
in this file, there are a crapload of defines for various pci devices. scroll down, and near the top is the large ati section. you can't miss it; everything starts with PCI_DEVICE_ID_ATI. it's divided into sections based on chip generation. the first one to edit is under '/* Radeon R250 (9000) */'. find the line that reads
#define PCI_DEVICE_ID_ATI_If 0x4966
and change '0x4966' to '0x4c66'. scroll down a little more to the section labeled '/* Radeon M7 */', and find the line
#define PCI_DEVICE_ID_ATI_Lf 0x4966
and likewise, change that '0x4966' to '0x4c66'.
compile and install that kernel, and pass the 'video=' option as a kernel parameter. for example, mine is
video=radeonfb:1600x1200@60
(if you're a 2.4 user, that would be 'radeon' instead of 'radeonfb')
do _not_ pass the 'vga=' option. that's vesafb only, and will automatically switch the console to that driver.
another note: _make sure_ that the mode you choose is listed in /usr/src/linux/drivers/video/modedb.c, or else it won't work. and choose from the first set of resolutions under
static const struct fb_videomode modedb[] __initdata
and not from the second group,
const struct fb_videomode vesa_modes[]
since obviously, we're not using vesa.
reboot with that video option, and it should work.
for people like me who have lots of memory in their comps (as in 1gig system ram, 128M video ram), you'll probably run into an error with something like 'radeonfb: cannot map FB'. this is similar to the vesafb problem, where booting with the same amount of memory would make vesafb just give a blank screen. they fixed that for vesa by adding some code to limit the framebuffer to 16 megs, but i don't really know how to do that with radeonfb. (i'll leave that up to Ani Joshi, the radeonfb maintainer) so i just limited the amount of ram for the system, by passing
mem=840M
as a kernel parameter. i don't use highmem since it has more overhead; so i'm limited to 896 megs of ram anyway. giving up 56 more is not a big deal, and it's not like i ever use that much.
that should work. it detected my lcd from the bios correctly, so it probably should for you too. if not, i can give you the options to force the dfp size.
so now that i have a nice accelerated framebuffer, i guess the next thing i'll do is get xdirectfb up...
[edit] unfortunately, after some more usage, i'm finding that there are a couple problems. there are visual artifacts appearing every now and then. directfb programs have some weird tracking glitches on the right side of the screen. when switching modes, sometimes it gets messed up and displays incorrectly. (it has a vertical interleaving effect and is a lot larger than the chosen resolution... kind of like looking very closely at a tv) and when listing files, there are newline and spacing problems. everything is still there, but it's not neatly arranged in columns...
i don't know whether this is an effect of this little hack, or if it's a problem with radeonfb itself, or what. i'm trying to track these problems down and fix them. in the meantime, you might not want to try this hack if you're looking for a perfectly working framebuffer...[/edit]
[edit] i found out that you only have to change the one line under 'Radeon M7', the 'Lf' one. if you change both, it will detect the R250 first (the 'If' one) since it's farther up the list and will set it up as that. while that should technically work because that's what the M9 is - an R250 - that's the setting for a desktop R250. if you leave the If one alone and just change Lf, it will detect it correctly as a radeon M9, and will set up the correct parameters for that card, like sync rates and clock frequencies, which is better. (i have no clue why it's filed under M7 if it's for the M9) the visual artifact problem still persists, though... [/edit]
[edit] the visual glitches were fixed by moving /etc/fb.modes to somewhere else. directfb checks that file for resolutions and chooses the first one on the list that applies. but while it may choose the correct native resolution, the timings and sync rates in there are for desktop CRT's. if directfb can't find that file, it will use the mode that the framebuffer is currently set at - the one with correct timings set up by radeonfb for the LCD. so i moved fb.modes, used fbset -i to see what settings radeonfb had set my buffer at, and re-created fb.modes with that setting. it's glitch-free now. however, xdirectfb is being a pain - it doesn't want to start up my programs and gives me all sorts of crap. it'll go into the server, but fluxbox or gkrellm won't start up. and besides, it's still slower than the 2d accelerated fglrx driver, so it's really not worth it. i switched back to normal xfree, but radeonfb is still a lot nicer for framebuffer apps than vesafb. [/edit]
i was able to fix radeonfb for 2.6. i had to tweak the support for the M9 (mobility 9000. it's the Lf version, which i think we all have, correct me if i'm wrong). it's fast, and a lot better than vesafb. unfortunately, i can't really help the people using 2.4; the stuff in 2.4 is old, and only has pci definitions up to M4 or something. but you might want to check out this patch for 2.4.20, which was the one that got me started editing 2.6:
http://hypermail.idiosynkrasia.net/l...ek04/0104.html
but on to fixing 2.6:
assuming that /usr/src/linux is your dev kernel's source directory, the file we want to edit is
/usr/src/linux/include/linux/pci_ids.h
in this file, there are a crapload of defines for various pci devices. scroll down, and near the top is the large ati section. you can't miss it; everything starts with PCI_DEVICE_ID_ATI. it's divided into sections based on chip generation. the first one to edit is under '/* Radeon R250 (9000) */'. find the line that reads
#define PCI_DEVICE_ID_ATI_If 0x4966
and change '0x4966' to '0x4c66'. scroll down a little more to the section labeled '/* Radeon M7 */', and find the line
#define PCI_DEVICE_ID_ATI_Lf 0x4966
and likewise, change that '0x4966' to '0x4c66'.
compile and install that kernel, and pass the 'video=' option as a kernel parameter. for example, mine is
video=radeonfb:1600x1200@60
(if you're a 2.4 user, that would be 'radeon' instead of 'radeonfb')
do _not_ pass the 'vga=' option. that's vesafb only, and will automatically switch the console to that driver.
another note: _make sure_ that the mode you choose is listed in /usr/src/linux/drivers/video/modedb.c, or else it won't work. and choose from the first set of resolutions under
static const struct fb_videomode modedb[] __initdata
and not from the second group,
const struct fb_videomode vesa_modes[]
since obviously, we're not using vesa.
reboot with that video option, and it should work.
for people like me who have lots of memory in their comps (as in 1gig system ram, 128M video ram), you'll probably run into an error with something like 'radeonfb: cannot map FB'. this is similar to the vesafb problem, where booting with the same amount of memory would make vesafb just give a blank screen. they fixed that for vesa by adding some code to limit the framebuffer to 16 megs, but i don't really know how to do that with radeonfb. (i'll leave that up to Ani Joshi, the radeonfb maintainer) so i just limited the amount of ram for the system, by passing
mem=840M
as a kernel parameter. i don't use highmem since it has more overhead; so i'm limited to 896 megs of ram anyway. giving up 56 more is not a big deal, and it's not like i ever use that much.
that should work. it detected my lcd from the bios correctly, so it probably should for you too. if not, i can give you the options to force the dfp size.
so now that i have a nice accelerated framebuffer, i guess the next thing i'll do is get xdirectfb up...
[edit] unfortunately, after some more usage, i'm finding that there are a couple problems. there are visual artifacts appearing every now and then. directfb programs have some weird tracking glitches on the right side of the screen. when switching modes, sometimes it gets messed up and displays incorrectly. (it has a vertical interleaving effect and is a lot larger than the chosen resolution... kind of like looking very closely at a tv) and when listing files, there are newline and spacing problems. everything is still there, but it's not neatly arranged in columns...
i don't know whether this is an effect of this little hack, or if it's a problem with radeonfb itself, or what. i'm trying to track these problems down and fix them. in the meantime, you might not want to try this hack if you're looking for a perfectly working framebuffer...[/edit]
[edit] i found out that you only have to change the one line under 'Radeon M7', the 'Lf' one. if you change both, it will detect the R250 first (the 'If' one) since it's farther up the list and will set it up as that. while that should technically work because that's what the M9 is - an R250 - that's the setting for a desktop R250. if you leave the If one alone and just change Lf, it will detect it correctly as a radeon M9, and will set up the correct parameters for that card, like sync rates and clock frequencies, which is better. (i have no clue why it's filed under M7 if it's for the M9) the visual artifact problem still persists, though... [/edit]
[edit] the visual glitches were fixed by moving /etc/fb.modes to somewhere else. directfb checks that file for resolutions and chooses the first one on the list that applies. but while it may choose the correct native resolution, the timings and sync rates in there are for desktop CRT's. if directfb can't find that file, it will use the mode that the framebuffer is currently set at - the one with correct timings set up by radeonfb for the LCD. so i moved fb.modes, used fbset -i to see what settings radeonfb had set my buffer at, and re-created fb.modes with that setting. it's glitch-free now. however, xdirectfb is being a pain - it doesn't want to start up my programs and gives me all sorts of crap. it'll go into the server, but fluxbox or gkrellm won't start up. and besides, it's still slower than the 2d accelerated fglrx driver, so it's really not worth it. i switched back to normal xfree, but radeonfb is still a lot nicer for framebuffer apps than vesafb. [/edit]
