Bitfield WTF
-
I'm tweaking a Linux graphics output for an embedded device. It uses a framebuffer device to access the graphics memory, and a V4L2 (Video for Linux 2) device to set the output resolution. This mixture of devices is only a minor wtf due to the way the hardware is structured. But then I found this:
#define V4L2_STD_480P_60_16_9 ((v4l2_std_id)0x04000000) #define V4L2_STD_480P_60_4_3 ((v4l2_std_id)0x05000000) #define V4L2_STD_576P_50_16_9 ((v4l2_std_id)0x06000000) #define V4L2_STD_576P_50_4_3 ((v4l2_std_id)0x07000000) #define V4L2_STD_720P_60 ((v4l2_std_id)0x08000000) #define V4L2_STD_720P_50 ((v4l2_std_id)0x09000000) /* And so on, up to 0x12000000 */
The original V4L2_STD values form a bitfield, with the largest value being 0x02000000. Although the v4l2_std_id type is 64-bit, comments state that using values beyond the low 32 bits would require fixing some generic handler code. So perhaps the vendor didn't want to spend time figuring out what needs to be fixed and chose to extend the list with non-bitfield values. Nevermind that they also ended up overlapping the last two core values. Or perhaps they were just clueless. Then I found this:
/* part of an array of struct v4l2_output */ { .index = 5, .name = "Digital HDMI(YCbCr)", .type = V4L2_OUTPUT_TYPE_HDMI, .audioset = 2, .modulator = 0, .std = V4L2_STD_480P_60_16_9 | V4L2_STD_480P_60_16_9 | V4L2_STD_720P_60 | V4L2_STD_720P_50 }So now they're actually using the non-bitfield values as a bitfield. Yup, definitely clueless.
-
If your posted code is an exact copy, then they are also or-ing V4L2_STD_480P_60_16_9 with itself.
-
It is. I can only guess that they meant the second one to be V4L2_STD_576P_50_16_9. Fortunately this is not critical for what I'm doing so I can just ignore it for now.
