Re: Native mode handling

> Ben also went down the path of trying to add full mode support to the radeon
> fbdev driver. He may want to comment on that. I'm doing the mode code in user
> space and the shared object for it is going to be at least a 100K in size. In
> Linux 2.7 user space is going to be enabled very early in the boot process, at
> that point you could switch from the BIOS console to a DRM based one with mode
> support

I'm half-way approx. in radeonfb (basically, I do probing on both heads,
but I driver really only one CRTC for now) and without counting all of
the i2c and EDID parsing support code, radeonfb in my tree is already
+60Kb. (Though the PowerMac specific PM code is a significant bit in
there, probably around 15k)

The biggest problem we have currently imho, with things like a userland
2D rending lib, DRM doing 3D, somebody calling the fbdev to switch
modes, etc... is the almost complete lack of arbitration.

Even fbdev alone, in the kernel, currently lacks proper locking and an
accelerated fbdev is a very "fragile" beast especially if you start
having printk racing with a userland triggered mode change etc...

At first, I wanted the mode setting to be in the kernel, maybe because I
wanted something around the lines of the NDRV interface old MacOSes
provided :) (MacOS X keeps something similar for the basic monitor
probing & mode setting part of the video driver btw).

But I think that's wrong. After trying to deal with all of the races
properly in there, I've had to go back to horrible mdelay based timing 
loops, thus causing in-kernel large latencies which aren't acceptable in
the long term and things like that, mostly because properly dealing with
a video card requires such long delays, and the way the fbdev locking is
currently done (or rather not done) makes any kind of scheduling in
there almost impossible.

In the end, it seems all better in userland. If we end up designing a
non-linux specific new video driver model that isn't tied 100% to XFree,
but that do take advantage of what linux provides (typically via kernel
modules when necessary, proper PCI management, etc...), then I'll
probably manage to move the powermac architecture completely to this
model in the future (PPC and especially PowerMac is one of the
architecure on linux that relies the most heavily on fbdevs at the
moment).

Ben.