[vlc-devel] [PATCH] linux: kernel mode setting (KMS) vout plugin

[Juha-Pekka Heikkilä]

Rémi Denis-Courmont kirjoitti 15.5.2018 klo 20.16:
> 	Päivää,

Iltaa :)

> 
> Le tiistaina 15. toukokuuta 2018, 15.09.59 EEST Juha-Pekka Heikkila a écrit :
>> I made vout plugin for Linux which uses kernel mode setting API. This plugin
>> mostly recreates what FB plugin does with following highlights:
>>
>> * FB could only do RGB but with KMS plugin one get access to all kernel
>>    enabled video modes. I have successfully ran through all packed and planar
>> YUV modes I found from my HW -- as well as all RGB modes.
>> * No tearing (I hope) I used two hw buffers and kernel plane handling
>>    takes care of the flipping for me. Only way I see tearing could happen is
>>    if VLC is decoding video frames faster than hardware video refresh rate.
> 
> There is something fishy with the multiple pools containing one picture each.
> AFAICT, only one pool and thus only one picture buffer will ever be used.
> 

This is something where I was hoping someone who knows how the pooling 
really works would comment. I was earlier asking on irc about this and 
someone mentioned I'd have one pool with two pictures and to get my 
double buffering working I'd release picture where I want next frame. 
Alas all variations I wrote ended up either in deadlock when use only 
two pictures or the second picture just never was used. This is how I 
end up putting two pools in use with each containing one picture.

..or you mean I should have only one picture buffer? But how about 
double buffering with hardware buffers then?

On side note, can we have these code related comments on the patch 
itself? I think it will be easier to follow.

>> * libFB to my knowledge is in maintenance mode, no more new features.
>> * My plugin can be run over ssh.
> 
> Special-casing pseudo-terminals by device name is a bit questionable. For
> instance, it won't work with a serial console, which would be potentially
> useful for embedded debugging/development.
> 

You have suggestion on how to reasonably do it more vlc style? Would 
command line parameter be considered better way for this? Detecting ssh 
connection is for embedded debugging for me.

>> Then the other things:
>> * I am employee of Intel Corporation thus I have to have special disclaimer
>>    on top of my plugin. I developed this plugin as part of my work when
>>    playing with KMS, this can be used to test video modes where it doesn't
>>    need to be totally boring all the time :)
> 
> If, or rather when, the terminal handling code has been moved to a "window"
> module for a yet to-be-defined window type, you can assert Intel copyrights
> and license terms on the whole file.
> 
> But in the mean time, you cannot strip the copyright and relax the license of
> that code which seems to be copied from the existing fb.c.
> 

You are correct, I seem to have forgotten this part of code. I'll just 
rewrite it, it's not the most special part.

>> * I have had access only to Intel hardware but I'm wishful my plugin works
>>    equally on other manufacturer's hardware. I tried to use only simple
>>    features to be able to maintain functionality on other platforms too.
>> * VLC and libdrm has some FourCC codes which are equal on both worlds but
>>    then there are others which have different names while seemingly same
>>    functionality. By default my plugin asks for XR24 type framebuffer from
>>    DRM and at the same time tells VLC it is RV32. Then again things like YUYV
>> or NV12 are the same in both worlds. If VLC is run in verbose mode one can
>> see my plugin listing all modes which KMS advertises. I didn't go write
>> match making table for these.
> 
> Expecting the user to select the chroma is really peculiar.
> Normally, the display tries to take an exact match. If there is none, it
> either tries to negotiate with the hardware abstraction layer or iterates
> through vlc_fourcc_GetYUVFallback/vlc_fourcc_GetRGBFallback.

I considered these settings to be part of "I know what I'm doing", there 
are commonly working defaults in place. Reason for not doing matching 
table for these is purely because while XR24 on Intel HW look similar as 
RV32 they're not the same. It is not impossible situation where on 
different hardware with different byte ordering RV32 actually is more 
like XB24 or even something totally different. With YUV formats there is 
no this problem though, they're more strictly defined.

I'll check out vlc_fourcc_GetYUVFallback and vlc_fourcc_GetRGBFallback 
to see if they can help on this.

/Juha-Pekka