Le mardi 17 janvier 2017 à 20:46 +0800, herman.chen@xxxxxxxxxxxxxx a écrit : > If we move parser or part of DPB management mechanism into kernel we > will face a issue as follows: > One customer requires dpb management do a flush when stream occurs in > order to keep output frame clean. > While another one requires output frame with error to keep output > frame smooth. > And when only one field has a error one customer wants to do a simple > field copy to recover. The driver should send all frames and simply mark the corrupted frames using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their own decision. It is also important to keep track and cleanup the buffers meta's (which are application specific). If the driver silently drops frame, it makes that management much harder. About flushing and draining operation, they are respectively signalled to the driver using STREAMOFF and CMD_STOP. > > These are some operation related to strategy rather then mechanism. > I think it is not a good idea to bring such kind of flexible process > to kernel driver. > > So here is the ultimate challenge that how to reasonably move the > parser and flexible process > which is encapsuled in firmware to a userspace - kernel stateless > driver model. Moving the parsers in the kernel (on the main CPU) is not acceptable. This is too much of a security threat. Userspace should parse the data into structures, doing any validation required before end. My main question and that should have an impact decision, is if those structures can be made generic. PDB handling is not that trivial (my reference is VAAPI here, maybe they are doing it wrong) and with driver specific structures, we would have this code copy-pasted over and over. So with driver specific structures, it's probably better to keep all the parsing and reordering logic outside (hence together). That remains, that some driver will deal with reordering on the firmware side (even the if they don't parse), hence we need to take this into consideration. regards, Nicolas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
