This set intoduces a bunch of helper functions for help drm plane driver writers deal with scaling and other details. Still work in progress, escpecially the last patch.
Some open questions: - In which file should this kind of stuff be placed?
- How should the functions be named?
- Should the scaling factor helpers also perform pre-decimation, by increasing the stride or skipping pixels. OMAP is the only hardware I've seen that can skip pixels horizontally, but increasing the stride should be possible practically on every hardware.
- User space API for the CSC stuff
There is also a bunch of other stuff missing from the API: - interlaced buffers This should be a fairly simple addition to addfb2. I'll try to propose something next week.
- color keying One question here is whether to expose just plain key values or perhaps min+max, or key+mask, or both depending on what the hardware actually supports. I think for now I'll just ignore the fact that color keying may or may not be plane specific.
- alpha blending Constant alpha and per pixel alpha. I don't recall of the v4l2 fourccs had any alpha channel stuff in them, so we may need extra fourccs, or just some extra per-pixel alpha enable bit in the API.
- zorder What's a nice API for this? A signed int with 0 being reserved for the "CRTC plane". Negative values would place the planes below the "CRTC plane", and positive values above it. Setting a plane to a specific zorder would move the existing stack of planes away from zero to make room for the new plane, any holes in the stack would get squashed. Does that sound reasonable?
- gamma correction I've seen three major variations in hardware; selection from a small fixed set of functions, a single curve with some number of points which may or may not be spaced equally, and a full LUT.
- color adjustment My proposal would be something close to what DirectFB uses. Brightness,contrast,saturation,hue adjustments. Valid values 0x0000-0xffff, where 0x8000 means "no change", smaller values mean decrease and larger values increase. The drivers would then map that to hardware specific values however they see fit. I think a good guideline would be to utilize the full range even if the hardware only supports a few adjustment steps. This would allow the users of the API to remain hardware agnostic.
- VC1 range mapping I left this out of the CSC enums for now. I'm not 100% sure, but I think this simply boils down to two small integers which are used to multiply the luma and chroma values before color space conversion. I also don't know what the range of the resulting luma and chroma values is, ie. is it always full range or not, or can that detail still be specified separately.
If no one beats me to it I'll try to come up with some actual code/structs for these things soon. Feel free to propose something if you think I've left something important out.