Kernel Traffic #198 For 30 Dec 2002

I totally understand. I do not suggest to break fbdev in it's current form, too much stuff uses it.

My main point was, don't be surprised the X servers, like the ATI driver, don't use fbdev and instead just mmap the device and simply program it directly.

fbdev is nice, in the specific cases where the device fits the fbdev model, because once you have the kernel bits you have X support :)

It seems the fbdev framework is stable enough, and already in the development tree. So, I'm submitting a driver for the Intel 810/815 for review and perhaps inclusion to your tree (to get more testing), and hopefully merge with Linus's tree.

The patch is against linux-2.5.51, but will not work yet because of 2 reasons:

1. agpgart is not working for the i810
2. support for early agp initialization needs to be added.

Once #1 is fixed, the driver should work as a module. And once #2 gets included, the driver can be compiled statically. Dave Jones (thanks for the help, by the way) has already #2 in his tree (tested and works), and is currently working on #1 (I have a hacked version at home).

The driver should be compliant with fbdev-2.5, and should support most if not all features that are to be expected (modularity, state saving and restoring, full hardware support, etc). One thing also that's very important for many people is that the driver will work with XFree86 with its native i810 drivers without further modification, and quite stably too.

The patch is at http://i810fb.sourceforge.net/linux-2.5.51-i810fb.diff.gz

Here is a patch which updates chipsfb.c to the new 2.5 framebuffer API. It simplifies the driver quite a bit, partly because the new API is simpler and partly because the driver really can only handle one 65550 chip, since we access the chip via inb/outb to fixed I/O port numbers.

I have tested it on a powerbook 3400, which has a C&T 65550 video chip with 1MB of VRAM, and it seems to work just fine, at least in 8 bit mode. I guess I still need to add the pseudo_palette stuff for 16 bit mode. Unfortunately I can't test it under X at the moment because the X server I have installed on the 3400 is Xpmac, which doesn't work any more because the VC_GETMODE etc. ioctls have been removed. The 3400 is an old and slow machine with a small hard disk and an old Linux/PPC installation on it, and I don't really want to compile up XFree86 on it.

Can you please make your patches be rooted the "standard" way, ie do

diff -ruN linux-old-dir linux-new-dir

so that they apply cleanly with a "patch -p1" and the diff headers say something like

        --- xxxx/arch/v850/vmlinux.lds.S
        +++ yyyy/arch/v850/vmlinux.lds.S

because that's how all my tools are set up to take patches.

I've done it by hand now, but it's somewhat tedious, and if I'm lazy (most of the time) it ends up meaning that I normally just drop patches that don't apply cleanly.

That's exactly the reason we have 'newbies' in the name: to keep the 1337 f01kz out and have a place where we can talk without having 1337 f01kz laugh at you.

People who are interested in learning about kernel hacking, you're always welcome at:

irc.kernelnewbies.org / #kernelnewbies