lkml.org 
[lkml]   [2006]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OpenGL-based framebuffer concepts
Jon Smirl wrote:
> On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
>> Jon Smirl wrote:
>> In Linux, the lowlevel driver registers irq handlers, so your simple
>> problem has the simple and obvious answer. Further, reviewing my
>> statement above, if fbdev/DRM are aware of each other, and if they both
>> are layered on top of the lowlevel driver, then it should also be
>> obvious that they are cooperatively sharing resources, not competing
>> against one another.
>>
>>
>> > I would instead start by making fbdev the low level driver. DRM could
>> > then bind to it and redundant code in DRM could be removed. 90% of the
>> > code in fbdev is always needed. Hopefully X could be convinced to use
>>
>> Take your pick. An fbdev driver is nothing but a PCI driver that
>> registers itself with the fbdev subsystem. Ditto a DRM driver, though
>> the DRM and agpgart layering is royally screwed up ATM. Regardless, he
>> who codes, wins.
>
> There is significant architectural difference between the two schemes.
> Is the base driver an absolute minimal driver that only serves as a
> switch to route into the other drivers, or does the base driver
> contain all the common code? I'm in the common code camp, DaveA is in
> the minimal switch camp.

You are missing that both are the same camp. It's just different paths
to get to the same destination. Common code will inevitably result.


> Take memory management for example. I think the memory manager should
> go into the base driver. The other strategy is for each driver to have
> their own memory manager and then the base provides a way to select
> which one is active. (Note that in all cases the complex part of
> memory management is running in user space).

That's an implementation detail that will naturally fall out of
fbdev/DRM cooperation. Don't worry, it will solve itself.


>> > the services offered by the fbdev/DRM pair. New memory management code
>>
>> No "hopefully." X must be forced to use this driver, otherwise the
>> system is unworkable.
>
> I have had no success in making this happen.

If the code is merged into the Linux kernel, X will follow. Its axiomatic.

Jeff


-
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/

\
 
 \ /
  Last update: 2006-05-26 01:22    [W:0.188 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site