10bit output via KMS

[Christian König]

Am 28.07.2017 um 11:55 schrieb Volker Vogelhuber:
> Hi,
>
>> On 24 July 2017 at 14:56, Volker Vogelhuber
>> <v.vogelhuber at digitalendoscopy.de> wrote:
>>> I wonder if it is possible to have drmModeAddFB2 to handle
>>> 'X', 'R', '3', '0' at all. So is this supported in any way?
>> Secondly, you're correct that you would need (theoretically) to extend
>> drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and
>> DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in
>> the last 10 years. This is the 'XR30' FourCC you mention, so it should
>> already be there and working in the kernel.
> This question probably better fits to the drm mailing list, although the
> discussion started on the mesa list.
>
> I got it working now that my 10bit buffers are correctly displayed
> on a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0'
> fourcc code. Based on the Samsung's datasheet it should support 10bit
> signals, although the EDID does not seem to contain a vendor
> specific data block that would confirm that assumption.
>
> I have connected an Apollo Lake module with a display port cable
> to that display but I'm unsure if it's really 10bit or if there is some
> conversion logic somewhere in between that may downsample my
> 10 bit buffer to 8bit before sending it via displayport to the display.

Well you could just try to display a 10bit image with a gradient going 
from black to white.

The difference between 8bit and 10bit should be obvious even to the 
naked eye.

Christian.

> So far I stumbled over some patches regarding color management
> in the drm part of the kernel, but couldn't figure out how one could
> configure what is really send to the display. It seem to mostly be 
> used to manipulate gamma values and so on. As the only indicator
> what is provided to the display is the buffer format handled by
> drmModeAddFB2 I doubt this is enough to configure the signal.
> Otherwise one could argue that the link speed of the display signal
> would have to toggle every time I send a different buffer format, 
> which is certainly not the case. So what portion of the kms/drm chain 
> do I
> miss currently? The drmModeModeInfo pointer has a clock field, but I 
> guess this is meant to be for the pixel clock not the clock of the 
> serialized signal. Probably that's why I couldn't find modelines for 
> 4k at 60 especially for 10bit compared to 8bit.
>
> Thanks
>    Volker
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel