IR remote control autorepeat / evdev
Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; "holding down" a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP sent when the key is surely released (e.g. 250ms without native repeat events or another key got pressed, i.e. like the simulated keyup now). + Simple to implement, works as expected with most userspace apps with no changes to them; and if an app wants to know the repeatness of an event or held-down-ness of a key, it can do that. - Repeatness of the event is hidden behind a new API. What do you think? Or any other ideas? 2 and 4 seem nicest to me. (I don't know how feasible 2 would be on X server side, though) -- Anssi Hannula -- 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat May 7 19:00:35 CEST 2011 git hash:966825c2a416a7ca3950e35e60fa8720f1251e37 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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: [RFC v4] V4L2 API for flash devices
Hi Hans, On 05/07/2011 02:46 PM, Hans Verkuil wrote: On Thursday, May 05, 2011 20:49:21 Sakari Ailus wrote: Hi, This is a fourth proposal for an interface for controlling flash devices on the V4L2/v4l2_subdev APIs. I want to thank everyone who have participated to the development of the flash interface. Comments and questions are very, very welcome as always. Changes since v3 [12] = - V4L2_CID_FLASH_STROBE changed to button control, V4L2_CID_FLASH_STROBE_STOP button control added, V4L2_CID_FLASH_STROBE_STATUS boolean control added. - No reason to say xenon flashes can't use V4L2_CID_FLASH_STROBE. - V4L2_CID_FLASH_STROBE_WHENCE changed to V4L2_CID_FLASH_STROBE_MODE. - V4L2_CID_TORCH_INTENSITY renamed to V4L2_CID_FLASH_TORCH_INTENSITY and V4L2_CID_INDICATOR_INTENSITY renamed to V4L2_CID_FLASH_INDICATOR_INTENSITY. - Moved V4L2_CID_FLASH_EXTERNAL_STROBE_MODE under "Possible future extensions". [snip] 3. Sensor metadata on frames It'd be useful to be able to read back sensor metadata. If the flash is strobed (on sensor hardware) while streaming, it's difficult to know otherwise which frame in the stream has been exposed with flash. I wonder if it would make sense to have a V4L2_BUF_FLAG_FLASH buffer flag? That way userspace can tell if that particular frame was taken with flash. This looks more as a workaround for the problem rather than a good long term solution. It might be tempting to use the buffer flags which seem to be be more or less intended for buffer control. I'd like much more to see a buffer flags to be used to indicate whether an additional plane of (meta)data is carried by the buffer. There seem to be many more parameters, than a single flag indicating whether the frame has been exposed with flash or not, needed to be carried over to user space. But then we might need some standard format of the meta data, perhaps control id/value pairs and possibly a per plane configurable memory type. Also as Sakari indicated some sensors adopt custom meta data formats so maybe we need to introduce standard fourcc like IDs for meta data formats? I am not sure whether it is possible to create common description of an image meta data that fits all H/W. -- Regards, Sylwester -- 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: DVB nGene CI : TS Discontinuities issues
On 03/05/11 12:59, Sébastien RAILLARD (COEXSI) wrote: > Dear all, > > I'm doing some tests with the CI interface of the "Linux4Media cineS2 DVB-S2 > Twin Tuner (v5)" card. > I notice some TS discontinuities during my tests. > > My setup: > - Aston Viaccess Pro CAM > - Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card > - Latest git media_build source with DF_SWAP32 patch > - DVB-S source from ASTRA 19.2E / 12285.00-V-27500 > > Test #1: (idle) > Reading from sec0 (without CI init or sec0 input stream) using "dd" give me > a stream of NULL TS packets of roughly 62mbps or 7.8MB/s (seems normal > behavior) > Command line: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 > count=1 > > Test #2: (CAM removal) > After CAM initialization and some tests, if CAM is removed, the output sec0 > bandwidth isn't anymore 62mbps of NULL TS packets > Same command line as Test #1 is used. > It seems that the CI is badly reacting after hot remove of CAM. > After rebooting, everything is fine again. > > Test #3: (Test dvr0 stream) > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Dumping the dvr0 output: dd if=/dev/dvb/adapter14/dvr0 of=/root/test.ts > bs=1880 count=1000 > => The dvr0 output bandwidth is roughly 300kB/s (normal for one filtered > channel) > => The resulting TS file is correct (no sync missing, no continuity error) > > Test #4: (Loop mode - No CAM inserted) > - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 > of=/dev/dvb/adapter14/sec0 bs=1880 > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts > bs=18800 count=1 > => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is > always 62mbps) > => The resulting TS file is filled at 96% by NULL TS packets (normal, > regarding the input stream bandwidth of 300kB/S) > => All the input PID seem to present in the output file > => But, there are some discontinuities in the TS packets (a lot and for all > the PID) > > Test #5: (Trough CAM - CAM is inserted) > - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 > of=/dev/dvb/adapter14/sec0 bs=1880 > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Waiting for CAM initialization (the CAM is correctly initialized and the > PMT packet is send to the CAM) > - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts > bs=18800 count=1 > => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is > always 62mbps) > => The resulting TS file is filled at 96% by NULL TS packets (normal, > regarding the input stream bandwidth of 300kB/S) > => All the input PID seem to present in the output file > => The stream isn't decoded (normal as the CAT table isn't outputted by > gnutv) > => But, there are some discontinuities in the TS packets (a lot and for all > the PID) > > So, in summary, I'm observing discontinues when stream is going through the > sec0 device, if CAM is present or not. > Also, the CI adapter doesn't seem to react correctly when the CAM is hot > removed. > I can provide the TS files (from dvr0, from sec0 with CAM and without CAM) > if someone is interested. > > Does someone has a setup that show no discontinuities when a TS stream is > going through sec0? (with an input TS file) > I would like to test it as for me the CI interface doesn't seem to work for > the nGene cards. > > Best regards, > Sebastien. Ralph, Could you please take a look at the cxd2099 issues ? I have attached a version with my changes. I have tested a lot of different settings with the help of the chip datasheet. Scrambled programs are not handled correctly. I don't know if it is the TICLK/MCLKI which is too high or something, or the sync detector ? Also, as we have to set the TOCLK to max of 72MHz, there are way too much null packets added. Is there a way to solve this ? Thx -- Issa /* * cxd2099.c: Driver for the CXD2099AR Common Interface Controller * * Copyright (C) 2010 DigitalDevices UG * * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 only, as published by the Free Software Foundation. * * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
Re: [RFC v4] V4L2 API for flash devices
On Thursday, May 05, 2011 20:49:21 Sakari Ailus wrote: > Hi, > > This is a fourth proposal for an interface for controlling flash devices > on the V4L2/v4l2_subdev APIs. > > I want to thank everyone who have participated to the development of the > flash interface. > > Comments and questions are very, very welcome as always. > > > Changes since v3 [12] > = > > - V4L2_CID_FLASH_STROBE changed to button control, > V4L2_CID_FLASH_STROBE_STOP button control added, > V4L2_CID_FLASH_STROBE_STATUS boolean control added. > > - No reason to say xenon flashes can't use V4L2_CID_FLASH_STROBE. > > - V4L2_CID_FLASH_STROBE_WHENCE changed to V4L2_CID_FLASH_STROBE_MODE. > > - V4L2_CID_TORCH_INTENSITY renamed to V4L2_CID_FLASH_TORCH_INTENSITY and > V4L2_CID_INDICATOR_INTENSITY renamed to V4L2_CID_FLASH_INDICATOR_INTENSITY. > > - Moved V4L2_CID_FLASH_EXTERNAL_STROBE_MODE under "Possible future > extensions". > > > Changes since v2 [9] > > > - Rearranged proposed controls. V4L2_CID_FLASH_LED_MODE is now the first > control. > > - Added an open question on naming of indicator and torch controls. > > - V4L2_CID_FLASH_STROBE_MODE renamed to V4L2_CID_FLASH_STROBE_WHENCE. > V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE renamed to > V4L2_CID_FLASH_EXTERNAL_STROBE_MODE. > > - Removed CID_ from V4L2_CID_FLASH_EXTERNAL_STROBE_MODE values. > > - Added a new use case based on [11]: Synchronised LED flash (hardware > strobe, timed exposure). > > - Added section on possible future extensions. > > - Complemented the open question on units. > > > Changes since v1 [7] > > > - V4L2_FLASH_STROBE_MODE_EXT_STROBE renamed to > V4L2_FLASH_STROBE_MODE_EXTERNAL. > > - V4L2_CID_FLASH_STROBE control changed from button to bool. > > - Removed suggestion of adding V4L2_CID_FLASH_DURATION. > V4L2_CID_FLASH_TIMEOUT is used as hardware timeout. > > - Added control access info (ro/rw). > > - V4L2_FLASH_MODE_NONE added, V4L2_FLASH_LED_MODE_FLASH no longer forced > as 1 in enum. > > - Bits use (1 << x) instead of 0x00... format. > > - Added an open question on flash LED mode controls. > > - Added an open question on a new control: > V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE. > > - Added an open question on control units. > > > Scope > = > > This RFC is focused mostly on the ADP1653 [1] and similar chips [2, 3] > which provides following functionality. [2, 3] mostly differ on the > available faults --- for example, there are faults also for the > indicator LED. > > - High power LED output (flash or torch modes) > - Low power indicator LED output (a.k.a. privacy light) > - Programmable flash timeout > - Software and hardware strobe > - Fault detection > - Overvoltage > - Overtemperature > - Short circuit > - Timeout > - Programmable current (both high-power and indicator LEDs) > > If anyone else is aware of hardware which significantly differs from > these and does not get served well under the proposed interface, please > tell about it. > > This RFC does NOT address the synchronisation of the flash to a given > frame since this task is typically performed by the sensor through a > strobe signal. The host does not have enough information for this --- > exact timing information on the exposure of the sensor pixel array. In > this case the flash synchronisation is visible to the flash controller > as the hardware strobe originating from the sensor. > > Flash synchronisation requires > > 1) flash control capability from the sensor including a strobe output, > 2) strobe input in the flash controller, > 3) (optionally) ability to program sensor parameters at given frame, > such as flash strobe, and > 4) ability to read back metadata produced by the sensor related to a > given frame. This should include whether the frame is exposed with > flash, i.e. the sensor's flash strobe output. > > Since we have little examples of both in terms of hardware support, > which is in practice required, it was decided to postpone the interface > specification for now. [6] > > Xenon flash controllers exist but I don't have a specific example of > those. Typically the interface is quite simple. Gpio pins for charge and > strobe. The length of the strobe signal determines the strength of the > flash pulse. The strobe is controlled by the sensor as for LED flash if > it is hardware based. > > See "Possible future extensions" section below for more. > > > Known use cases > === > > The use case listed below concentrate on using a flash in a mobile > device, for example in a mobile phone. The use cases could be somewhat > different in devices the primary use of which is camera. > > Unsynchronised LED flash (software strobe) > -- > > Unsynchronised LED flash is controlled directly by the host as the > sensor. The flash must be enabled by the host before the exposure of the > image starts and disabled once it ends. The
Re: [PATCH 0/2] V4L: Extended crop/compose API
On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote:
> Hello everyone,
>
> This patch-set introduces new ioctls to V4L2 API. The new method for
> configuration of cropping and composition is presented.
>
> This is the third version of extended crop/compose RFC. List of applied
> changes:
> - reduced number of hints and its semantics to be more practical and less
> restrictive
> - combined EXTCROP and COMPOSE ioctls into VIDIOC_{S/G}_SELECTION
> - introduced crop and compose targets
> - introduced try flag that prevents passing configuration to a hardware
> - added usage examples
>
>
> RFC
>
>
> 1. Introduction
>
> There is some confusion in understanding of cropping in current version of
> V4L2. In a case of Capture Devices, cropping refers to choosing only a part of
> input data stream, and processing it, and storing it in a memory buffer. The
> buffer is fully filled by data. There is now generic API to choose only a part
> of an image buffer for being updated by hardware.
>
> In case of OUTPUT devices, the whole content of a buffer is passed to hardware
> and to output display. Cropping means selecting only a part of an output
> display/signal. It is not possible to choose only a part of the image buffer
> to
> be processed.
>
> The overmentioned flaws in cropping API were discussed in post:
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/28945
>
> A solution was proposed during brainstorming session in Warsaw.
>
> At first, the distinction between cropping and composing was stated. The
> cropping operation means choosing only part of input data by bounding it by a
> cropping rectangle. All data outside cropping area must be discarded. On the
> other hand, composing means pasting processed data into rectangular part of
> data sink. The sink may be output device, user buffer, etc.
>
> Two concepts were introduced:
>
> Cropping rectangle: a) for input devices, a part of input data selected by
> hardware from input stream and pasted to an image buffer b) for output
> devices,
> a part of image buffer to be passed by hardware to output stream
>
> Composing rectangle: a) for input devices, a part of a image buffer that is
> filled by hardware b) for output devices, an area on output device where image
> is inserted
>
> The configuration of composing/cropping areas is the subject of this document.
>
> 2. Data structures.
>
> The structure v4l2_crop used by current API lacks any place for further
> extensions. Therefore new and more generic structure is proposed.
>
> struct v4l2_selection {
> u32 type;
> u32 target;
> u32 flags;
> struct v4l2_rect r;
> u32 reserved[9];
> };
>
> Where,
> type - type of buffer queue: V4L2_BUF_TYPE_VIDEO_CAPTURE,
>V4L2_BUF_TYPE_VIDEO_OUTPUT, etc.
> target - choose one of cropping/composing rectangles
> flags - control over coordinates adjustments
> r - selection rectangle
> reserved - place for further extensions, adjust struct size to 64 bytes
>
> 3. Crop/Compose ioctl.
> New ioctls are added to V4L2.
>
> Name
> VIDIOC_G_SELECTION - get crop/compose rectangles from a driver
>
> Synopsis
> int ioctl(fd, VIDIOC_G_SELECTION, struct v4l2_selection *s)
>
> Description:
> The ioctl is used to query selection rectangles. Currently, it involves
> only cropping and composing ones. To query cropping rectangle application must
> fill selection::type with respective stream type from V4L2_BUF_TYPE_VIDEO_*
> family. Next, v4l2_selection::target must be field with desired target type.
> Please refer to section Target for details. On success the rectangle is
> returned in v4l2_selection::r field. Field v4l2_selection::flags and
> v4l2_selection::reserved are ignored and they must be filled with zeros.
>
> Return value
> On success 0 is returned, on error -1 and the errno variable is set
> appropriately:
> EINVAL - incorrect buffer type, incorrect/not supported target
Looks fine.
>
> -
>
> Name
> VIDIOC_S_SELECTION - set cropping rectangle on an input of a device
>
> Synopsis
> int ioctl(fd, VIDIOC_S_SELECTION, struct v4l2_selection *s)
>
> Description:
> The ioctl is used to configure a selection rectangle. An application
> fills v4l2_selection::type field to specify an adequate stream type. Next,
> the
> v4l2_selection::field target is filled. Basically, an application choose
> between cropping or composing rectangle. Please refer to section Targets for
> more details. Finally, structure v4l2-selection::r is filled with suggested
> coordinates. The coordinates are expressed in driver-dependant units. The only
> exception are rectangles for images in raw formats, which coordinates are
> expressed in pixels.
>
> Drivers are free to adjust selection rectangles on their own. The suggested
> behaviour is to choose a rec
Alert From AntiVirus For PME Mail
=== System Generated Message - DO NOT REPLY TO THIS ! === AntiVirus for PME Mail has processed the mail detailed below and has generated this alert for your reference. Message Details: --- Message ID: <20110507085919.63b646970...@prm-mx.qlc.co.in> Message From : linux-media@vger.kernel.org Message To: Smita Bhartu Message Subject : Returned mail: Data format error Message Rcvd Date : Sat May 07 14:28:01 GMT+05:30 2011 --- AntiVirus for PME Mail has found that the following file(s) / attachment(s) have infected or malicious content : -- File Scanned : attachment.zip Virus Found : Suspected Virus AntiVirus for PME Mail is configured to delete file(s) / attachment(s) if attempt at cleaning infection fails. Accordingly the following action has been taken : -- File Deleted : attachment.zip Virus Found : Suspected Virus IEEMA, Mumbai, India -- 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
