Re: New proposed DRM interface design

[Alan Cox]

On Sul, 2004-09-05 at 22:12, Jon Smirl wrote:
> Sure you can use this to get around both fbdev and DRM trying to claim
> the resource. But it doesn't help at all to fix the problem that fbdev
> and DRM are programming the radeon chip in conflicting ways.

Once you have the common structure the rest of the problems go away
rather nicely over time.

> What is so awful about merging the code? I'm the one doing the all of
> the work. I intend to use 95% of the code extracted from fbdev without
> change. I'm not getting rid of fbdev capability in the merged code,
> I'm just coordinating use of the hardware.

It doesn't solve the problem. That is the fundamental part of it. I can
put the code in the same place or in different places, the problem you
have to fix is co-ordination, and when you fix that not suprisingly you
still don't care where the code lives.

Create a top level video device object to hold dri and fb info pointers.
End of problem #1. Make that top level video object the one which is
handling the pci device irrespective of DRI/fb loading first. You've now
solved the load order problem. Make DRI tell fb about display layout in
X and provide sync functions. You've now solved the Oops problem.

After that you can begin to worry about dual head and memory management
which is a *lot* harder than you seem to realise and much of which
cannot be done user space side for performance reasons.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/