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

[Rémi Denis-Courmont]

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.

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

(...)
> > 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.

-- 
Реми Дёни-Курмон
http://www.remlab.net/