rchitectures (x86, ARM, MIPS, PowerPC, Sparc, xtensa, arc, and
> more) both 32-bit and 64-bit.
Indeed. I believe these comes from the single UNIX specification:
http://www.unix.org/version2/whatsnew/lfs20mar.html#3.3
And these defines are what the AC_SYS_LARGEFILE autoconf macro uses:
https://
Signed-off-by: Peter Korsgaard
---
drivers/media/video/s5p-mfc/s5p_mfc_enc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
index 1e8cdb7..dff9dc7 100644
--- a/drivers/media/video
th illuminators,
Andy> that is a failure.
Again, I don't think we should use the LED API for something as integral
to the video signal as illuminators.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d end users or application need or want to manipulate such
Hans> LEDs in any case?
In most cases they don't - Not using the LED sysfs or v4l. But if they
do, then they CAN.
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bod
Hans> ever do anything with status LEDs anyway. So it should be the
Hans> driver that operates them and in that case the LEDs do not need
Hans> to be exposed anywhere.
It's not that it *HAS* to be exposed - But if we can, then it's nice to do
so as it gives flexibility to the u
->led sysfs node association
Andy> semantics, reduces application complexity, when those
Andy> applications already support the V4L2 control API from which
Andy> application can generically discover controls and their metadata
Andy> and automatically know the associated video device.
ays.
Why does this need to go through the v4l2 api and not just use the
standard LED (sysfs) api in the first place?
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html