Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries
>>>>> "Baruch" == Baruch Siach writes: Hi, >> The link Peter provided seems to be specific to glibc. The main >> point I want to bring is: would this change affect users with >> other setups? There are some users that compile it against FreeBSD >> and Android. Some compile using dietlibc or uclibc. Also, people >> build it against 32-bits and 64-bits on x86, arm and other archs. >> >> So, the question is: are you sure that the above change is also valid for >> *all* other environments? If not, I would be expecting it to be >> attached to some automake test, to be sure that it will be applied >> only to the affected setups. > Buildroot has been carrying this patch since 2012[1] with no one > complaining. Buildroot supports glibc, uClibc, and musl libc on a wide > range of architectures (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://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/System-Services.html -- Bye, Peter Korsgaard
[PATCH] s5p_mfc_enc: fix s/H264/H263/ typo
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
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/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
@@ -61,7 +61,7 @@ static struct s5p_mfc_fmt formats[] = {
.num_planes = 1,
},
{
- .name = H264 Encoded Stream,
+ .name = H263 Encoded Stream,
.fourcc = V4L2_PIX_FMT_H263,
.codec_mode = S5P_FIMV_CODEC_H263_ENC,
.type = MFC_FMT_ENC,
--
1.7.7.1
--
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
Re: [PATCH] Illuminators and status LED controls
Andy == Andy Walls awa...@md.metrocast.net writes: Hi, Andy Given choices I made when I patched up gspca/cpia1.c for my Andy prototype LED API usage, I got these associations Andy By exposed LED name: Andy /sys/class/leds/video0:white:illuminator0 Indeed. But didn't we just decide that illuminators were an integral part of the video handling (similar to gain control), and only use the LED API for status LEDs that don't directly interfere with the video data? Andy The LED API has some shortcomings/annoyances: Andy - The method a driver provides to set the LED brightness cannot sleep, Andy so a workqueue is needed to simply turn a hardware light on and off for Andy USB devices. Andy - The Documentation is not very good for end-users or kernel developers Andy on using the LED API. No? I agree that the documentation is pretty minimalistic, but ok - It's not that complicated. Andy - For an LED trigger not to override a user's desire to inhibit an LED, Andy the user needs to know to cancel all the triggers on an LED before Andy setting the LEDs brightness to 0. Only a single trigger can be active at a time for a given LED. Andy Again, that happens to be the only real compelling use case I see for Andy using the LED API. However, I doubt many users will try to take Andy advantage of it, and I suspect even less will succeed in getting it Andy configured right. Good documentation could go a long way in correcting Andy that. That and using the LED for something else (perhaps with another trigger like I eplained earlier with wlan/hdd activity). Andy If a user configures multiple LED triggers on an LED, those triggers Andy will compete with each other. The net result is the most recent event Andy from the driver, any LED triggers wins, or user manipulation of sysfs Andy brightness. Only a single trigger can be active at a time for a given LED. Andy With indicators that's annoying, but not a failure. With 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
Re: [PATCH] Illuminators and status LED controls
Hans == Hans Verkuil hverk...@xs4all.nl writes: Hi, - the status LED should be controlled by the LED interface. Hans I originally was in favor of controlling these through v4l as Hans well, but people made some good arguments against that. The main Hans one being: why would you want to show these as a control? What is Hans the end user supposed to do with them? It makes little sense. Hans Frankly, why would you want to expose LEDs at all? Shouldn't this Hans be completely hidden by the driver? No generic application will 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 user instead of hardcoding policy in the kernel. -- 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
Re: [PATCH] Illuminators and status LED controls
Hans == Hans Verkuil hverk...@xs4all.nl writes: Hi, Hans But I feel I am missing something: who is supposed to use these LEDs? Hans Turning LEDs in e.g. webcams on or off is a job for the driver, never for Hans a userspace application. Agreed - By default, the driver should just turn on the LED when the device is active and off again when it is not. Hans For that matter, if the driver handles the LEDs, Hans can we still expose the API to userspace? Wouldn't those two interfere Hans with one another? I know nothing about the LED interface in sysfs, but I Hans can imagine that will be a problem. Yes, you expose the LED using the LED class, and add a LED trigger per video device (named something like videoX-active). Furthermore you set the default trigger for that LED to be videoX-active. So the logic of how to turn on/off the LED is seperated from the policy about WHEN it should be turned on/off. Sysfs entry ownership, unix permissions, and ACL permissions consistency with /dev/videoN will be the immediate usability problem for end users in any case. Hans Again, why would 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 body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
Andy == Andy Walls awa...@md.metrocast.net writes: Hi, Andy Incandescent and Halogen lamps that effect an image coming into a Andy camera are *not* LEDs that blink or flash automatically based on Andy driver or system trigger events. They are components of a video Andy capture system with which a human attempts to adjust the Andy appearance of an image of a subject by changing the subject's Andy environment. These illuminators are not some generically Andy connected device, but controlled by GPIO's on the camera's bridge Andy or sensor chip itself. Such an illuminator will essentially be Andy used only in conjunction with the camera. Agreed. Andy Status LEDs integrated into webcam devices that are not generically Andy connected devices but controlled with GPIOs on the camera's bridge or Andy sensor chip will also essentially be used only in conjunction with the Andy camera. Or for any other usage the user envision - E.G. I could imagine using the status led of the webcam in my macbook for hard disk or wifi activity. I'm sure other people can come up with more creative use cases as well. Andy Turning these sorts camera specific illuminators and LEDs on an off Andy should be as simple to implement for an application developer as it is Andy to grasp the concept of turning a light bulb on and off. The point is that the logic rarely needs to be in the v4l applications. The status LEDs should by default go on when the v4l device is active and go off again when not like it used to do. A v4l application developer would normally not want to worry about such things, and only care about the video data. But if a user wants something special / non-standard, then it's just a matter of changing LED trigger in /sys/class/leds/.. Andy The LED interface seems more appropriate to use when the LEDs are Andy connected more generically and will likely be used more generically, Andy such as in an embedded system. The LED subsystem certainly has it uses in embedded, but it's also used on PCs - As an example the ath9k wireless driver exports a number of LEDs. I find the situation with the wlan LEDs pretty comparable to status LEDs on v4l devices. And yes, application developers must use the correct API to control stuff. Why should kernel duplicate interfaces just because user land don't want to use two different interfaces? Doesn't this sound a bit ... strange at least? Andy Why should the kernel push multiple APIs on application developers to Andy control a complex federation of small devices all connected behind a Andy single bridge chip, which the user perceives as a single device? (BTW a Andy USB microscope is such a federation which doesn't work at all without Andy proper subject illumination.) Because that's the only sensible way to create a bunch of incompatible custom interfaces - E.G. a microphone built into a webcam is handled through also, not v4l, so it works with any sound recording program. Andy V4L2 controls are how desktop V4L2 applications currently control Andy aspects of a incoming image. Forcing the use of the LED interface in Andy sysfs to control one aspect of that would be a departure from the norm Andy for the existing V4L2 desktop applications. Andy Forcing the use of the LED interface also brings along the complication Andy of proper association of the illuminator or LED sysfs control node to Andy the proper video capture/control device node. I have a laptop with a Andy built in webcam with a status LED and a USB connected microscope with Andy two illuminators. What are the steps for an application to discover the Andy correct light for the video device and what settings that light is Andy capable of: using V4L2 controls? using the LED interface? Again, for status LEDs I don't see any reason why a standard v4l tool would care. As I mentioned above, illuminators are a different story (comparable to a gain setting imho). Andy How does one go about associating LEDs and Illuminators to video device Andy nodes using the LED sysfs interface? I'm betting it's not as simple for Andy applications that use V4L2 controls. I would imagine each video device would have a (number of) triggers, similar to how it's done for E.G. the wlan stuff - Something like video0-active. The status LED of the video0 device would default to that trigger. Andy I do not see how forcing applications to use a second control Andy API, with no clear video device node-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. Again, I see the sysfs LED interface for status LEDs as more of a user/administrator interface than a programming API. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-media
Re: [PATCH] LED control
Hans == Hans de Goede hdego...@redhat.com writes: Hi, + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LED(s) or illuminator(s) of the device. + The control type and values depend on the driver and may be either + a single boolean (0: off, 1:on) or the index in a menu type./entry + /row Hans I think that using one control for both status leds (which is Hans what we are usually talking about) and illuminator(s) is a bad Hans idea. I'm fine with standardizing these, but can we please have 2 Hans CID's one for status lights and one for the led. Esp, as I can Hans easily see us supporting a microscope in the future where the Hans microscope itself or other devices with the same bridge will have Hans a status led, so then we will need 2 separate controls anyways. 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
