Hi Hans, I'm trying to move to Linux 3.11 and I noticed you've made some significant changes to the SOLO6x10 driver. While I don't yet have the big picture, I can see some regressions here: - the driver doesn't even try to work on big endian systems (I'm using IXP4xx-based system which is BE). For instance, you're now using bitfields for frame headers (struct vop_header) and this is well known to fail (unless you have a different struct for each endianness). This is actually what I have fixed with commit c55564fdf793797dd2740a67c35a2cedc133c9ff in 2011, and you brought the old buggy version back with dcae5dacbce518513abf7776cb450b7bd95d722b. - you removed my dynamic building of MPEG4/H.264 VOP headers (the same commit c55564fdf793797dd2740a67c35a2cedc133c9ff) and replaced it with precomputed static binary headers, one for each PAL/NTSC/D1/CIF combination. While I don't strictly object the precomputed data, perhaps you could consider adding some tool to optionally calculate them, as required by the license. For now, It seems it's practically impossible to make modifications to the header data, without, for example, extracting the code from older driver version. - what was the motivation behind renaming all (C language) files in drivers/staging/media/solo6x10 to solo6x10-* (commits dad7fab933622ee67774a9219d5c18040d97a5e5 and 7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6, essentially a reversion of my commit ae69b22c6ca7d1d7fdccf0b664dafbc777099abe)? I'm under impression that a driver file names don't need (and shouldn't) contain the driver name if the directory is already named after the driver. This is also the case with b3c7d453a00b7dadc2a7435f68b012371ccc3a3e: > [media] solo6x10: rename jpeg.h to solo6x10-jpeg.h > > This header clashes with the jpeg.h in gspca when doing a compatibility > build using the media_build system. What is this media_build system and why is it forcing code in different directories to have unique file names? I appreciate the switch to VB2 and other improvements (though I can't test them yet), but perhaps it could be done without causing major breakage? I'm thinking about a correct course of action now. I need the driver functional so I'll revert the struct vop_header thing again, any thoughts? -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
