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

[Juha-Pekka Heikkila]

On 17.05.2018 00:07, Rémi Denis-Courmont wrote:
> Le tiistaina 15. toukokuuta 2018, 23.07.07 EEST Juha-Pekka Heikkilä a écrit :
>>> 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.
> 
> You can only have one pool at a time - that returned by the pool callback.
> 
>> 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.
> 
> Uh? You need to release the picture when you no longer need it, but no sooner
> than the display callback.
> 
>> ..or you mean I should have only one picture buffer? But how about
>> double buffering with hardware buffers then?
> 
> I don't know KMS well enough to answer that question.
> 

I made version which is implemented in similar way as FB plugin has had 
its double buffering. Will be one pool and one picture. Currently to me 
it look like FB plugin will not be able to do double buffering though.

There are things with the format juggling I still need to look into but 
once I get all things fixed I'll post V2 for commenting.

>> 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.
> 
> Again, I don't know VT and KMS well enough to answer that question. I don't
> even know why you need to use VT here.

Terminal normally draw into same buffers provided by kernel so I was 
expecting I need to at minimum declare "KD_GRAPHICS". Now I was going 
through what really is needed and turn out with KMS apis there is no 
interference, while I have planes on screen which I asked through KMS 
they will not get messed. This might need to be fixed at later time as I 
have no possibility to try this with other hw but with Intel Graphics 
all seems to go ok. I just chopped out all the TTY codes, it also 
followed I have no need to detect terminal type anymore.

> 
> (...)
>>> 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.
> 
> Uh? There are RGB masks in the video output format for that.
> 
>> 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.
> 

Once I have something done on this I'll send v2. I'm hoping I can still 
keep commandline parameters for forcing those chromas, otherwise I'll 
end up always patching my own VLC as this is what I use for my own testing.

/Juha-Pekka