Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" <alexdeucher@xxxxxxxxx> wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API. The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul. Why create
>>> a new modern fb interface that's largely the same as DRM KMS? What if
>>> we just consider the KMS API as the new fb API? If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
> http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API. The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul. Why create
>>> a new modern fb interface that's largely the same as DRM KMS? What if
>>> we just consider the KMS API as the new fb API? If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
> http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
