Hi, On Dienstag, 17. Dezember 2019 15:09:16 CET Keiichi Watanabe wrote: > Hi, > > Thanks Tomasz and Gerd for the suggestions and information. > > On Tue, Dec 17, 2019 at 10:39 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > Hi, > > > > > On the host side, the encode and decode APIs are different as well, so > > > having separate implementation decoder and encoder, possibly just > > > sharing some helper code, would make much more sense. > > > > When going down that route I'd suggest to use two device ids (even when > > specifying both variants in one spec section and one header file due to > > the overlaps) instead of feature flags. > > Sounds good. It makes sense to use different device IDs for different > devices. Does this mean one driver handles both? Or we have two separate drivers? > > > > I don't think using fourcc is a problem, and given that both drm and > > > > v4l2 use fourcc already this would be a good choice I think. > > > > > > Both DRM and V4L2 use two mutually incompatible sets of FourCCs, so > > > I'm not sure how it could be a good choice. At least unless we decide > > > to pick a specific set of FourCC. It doesn't help that Windows/DirectX > > > has its own set of FourCCs that's again slightly different than the > > > two mentioned before. > > > > Ouch, wasn't aware of that. That makes reusing fourcc codes much less > > useful. > > > > > > But the definition should be more specific than just "fourcc". Best > > > > would be to explicitly list and define each format supported by the > > > > spec. > > > > > > Why not be consistent with virtio-gpu and just define new formats as > > > we add support for them as sequential integers? > > > > Yes, lets do that. > > It makes sense. I seems to have overestimated FourCC. This is what was actually done in the driver code already (it is a bit ahead of the spec, but I guess no one has looked at it so far). Regards, Dmitry. > > Best, > Keiichi > > > cheers, > > > > Gerd
