Re: cron job: media_tree daily build: WARNINGS
On Friday, July 05, 2013 05:52 PM, Hans Verkuil wrote: On Fri July 5 2013 10:10:32 Chris Ruehl wrote: Hans, I like to work with the linux-git-arm-mx but cannot find any repository. Can you give me a hint? I'm just cross-compiling the kernel from the media_tree.git repository, nothing else. You probably want a complete rootfs as well to work with. Guennadi may know where to find something like that. But if you indeed just want to cross-compile the kernel, then let me know and I can give you pointers. Hans if it just a cross compile, :-) thats not the problem at all, I work on a imx27 board I though it just a repos only for the arm .. I will pull the media_tree and have and work a bit with it. thanks and sorry for the noise. Chris Thanks. Chris On Friday, July 05, 2013 02:29 AM, Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jul 4 19:00:26 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API 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 -- 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 -- 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 -- GTSYS Limited RFID Technology Unit 958 , KITEC - 1 Trademart Drive - Kowloon Bay - Hong Kong Fax (852) 8167 4060 - Tel (852) 3598 9488 Disclaimer: http://www.gtsys.com.hk/email/classified.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: cron job: media_tree daily build: WARNINGS
On Friday, July 05, 2013 06:04 PM, Guennadi Liakhovetski wrote: On Fri, 5 Jul 2013, Hans Verkuil wrote: On Fri July 5 2013 10:10:32 Chris Ruehl wrote: Hans, I like to work with the linux-git-arm-mx but cannot find any repository. Can you give me a hint? I'm just cross-compiling the kernel from the media_tree.git repository, nothing else. You probably want a complete rootfs as well to work with. Guennadi may know where to find something like that. just as well as many other ARM developers on the list. I personally use ARM Debian, which you can debootstrap on your PC, I think. Or you should be able to get something like yocto or tizen too. Barebone busybox, Open Embedded are further possibilities. Thanks Guennadi Thanks for the answer ,, that is exactly what I did. I tried with an installation on in a kvm but its gives me no benefit. I use the Debian bootstrap when compile apps or when I work on the kernel I usually source a script with sets path to the cross compiler and add the environment (which is much faster on my core7). Thanks again. Chris But if you indeed just want to cross-compile the kernel, then let me know and I can give you pointers. Hans Thanks. Chris On Friday, July 05, 2013 02:29 AM, Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jul 4 19:00:26 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API 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 -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- GTSYS Limited RFID Technology Unit 958 , KITEC - 1 Trademart Drive - Kowloon Bay - Hong Kong Fax (852) 8167 4060 - Tel (852) 3598 9488 Disclaimer: http://www.gtsys.com.hk/email/classified.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
DVBSKY T680C (USB DVB-C / DVB-T/T2 box) confirmed working, added Wiki-Page
Hi, I recently purchased a DVBSKY T680C from Amazon to replace mc Technotrend CT-3650 (overheated). The device works pretty well. I added a linuxtv.org wiki page for it including installation steps and comparison with my old CT-3650 and a GRUNDIG television. FyI. http://www.linuxtv.org/wiki/index.php/DVBSKY_T680C Best regards, Martin -- 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: pctv452e
Hi guys, I was able to got that device, just because of you, and I cannot reproduce that error. I ran it many hours against signal from modulator yesterday and it didn't hang. I used szap mplayer. Also I ran w_scan. Only problem I saw was these I2C errors printed. So you make tests, likely using szap, and say how I can make it hang? regards Antti On 07/02/2012 07:33 PM, Steve Hill wrote: I've been using a Technotrend TT 3600 USB DVB-S2 receiver for a couple of years, which has (largely) been working fine under the S2-liplianin pctv452e driver. I've been aware of a lot of documented problems with running this receiver under the 3.x kernel, so I've stuck with the 2.6 series kernels. Unfortunately I've now had to upgrade to the 3.2.0 kernel for other unrelated reasons, and it seems that the device is more or less unusable under this kernel. With the stock 3.2.0 kernel, the driver produces numerous I2C errors and is quite unreliable. The I2C errors seem to be produced exclusively as a result of stb_6100_read_reg() reading register F, and notably all calls to stb6100_read_regs() seem to succeed, so I've replaced the stb_6100_read_reg() function with a call to stb6100_read_regs(), so it reads all the registers and then returns the requested one, rather than reading just the requested register. This seems to make the I2C errors disappear. However, the card is still very unreliable - after about 5 minutes of receiving a channel (using MythTV), it breaks. No errors logged in dmesg, but MythTV logs: DevRdB(/dev/dvb/adapter0/frontend0) Error: Poll giving up DVBSH(/dev/dvb/adapter0/frontend0) Error: Device error detected DVBRec(7:/dev/dvb/adapter0/frontend0) Error: Stream handler died unexpectedly. Can anyone give me any pointers that might help? I've searched and searched and all I can see if people saying that it won't work since the DVB-S2 code was integrated into the kernel tree, but I've not seen anyone try to figure out _why_ it won't work. Thanks. -- http://palosaari.fi/ -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Jul 6 19:00:23 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 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 Media Infrastructure API 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: width and height of JPEG compressed images
Hi Thomas, Cc: Sakari and Laurent On 07/05/2013 10:22 AM, Thomas Vajzovic wrote: Hello, I am writing a driver for the sensor MT9D131. This device supports digital zoom and JPEG compression. Although I am writing it for my company's internal purposes, it will be made open-source, so I would like to keep the API as portable as possible. The hardware reads AxB sensor pixels from its array, resamples them to CxD image pixels, and then compresses them to ExF bytes. The subdevice driver sets size AxB to the value it receives from v4l2_subdev_video_ops.s_crop(). To enable compression then v4l2_subdev_video_ops.s_mbus_fmt() is called with fmt-code=V4L2_MBUS_FMT_JPEG_1X8. fmt-width and fmt-height then ought to specify the size of the compressed image ExF, that is, the size specified is the size in the format specified (the number of JPEG_1X8), not the size it would be in a raw format. In VIDIOC_S_FMT 'sizeimage' specifies size of the buffer for the compressed frame at the bridge driver side. And width/height should specify size of the re-sampled (binning, skipping ?) frame - CxD, if I understand what you are saying correctly. I don't quite what transformation is done at CxD - ExF. Why you are using ExF (two numbers) to specify number of bytes ? And how can you know exactly beforehand what is the frame size after compression ? Does the sensor transmit fixed number of bytes per frame, by adding some padding bytes if required to the compressed frame data ? Is it something like: sensor matrix (AxB pixels) - binning/skipping (CxD pixels) - - JPEG compresion (width = C, height = D, sizeimage ExF bytes) ? This allows the bridge driver to be compression agnostic. It gets told how many bytes to allocate per buffer and it reads that many bytes. It doesn't have to understand that the number of bytes isn't directly related to the number of pixels. So how does the user tell the driver what size image to capture before compression, CxD? I think you should use VIDIOC_S_FMT(width = C, height = D, sizeimage = ExF) for that. And s_frame_desc sudev op could be used to pass sizeimage to the sensor subdev driver. (or alternatively, if you disagree and think CxD should be specified by s_fmt(), then how does the user specify ExF?) 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: Samsung i2c subdev drivers that set sd-name
Hi Laurent, On 07/05/2013 01:30 PM, Laurent Pinchart wrote: On Thursday 04 July 2013 22:19:20 Sylwester Nawrocki wrote: On 07/04/2013 01:13 PM, Hans Verkuil wrote: On Thu 4 July 2013 00:49:36 Laurent Pinchart wrote: On Thursday 27 June 2013 11:53:15 Sylwester Nawrocki wrote: On 06/27/2013 08:43 AM, Hans Verkuil wrote: On Wed June 26 2013 11:00:51 Sakari Ailus wrote: On Tue, Jun 25, 2013 at 06:55:49PM +0200, Sylwester Nawrocki wrote: On 06/24/2013 10:54 AM, Hans Verkuil wrote: [snip] Before we start messing with those drivers it would be nice to have defined rules of the media entity naming. I2C bus number and address is not something that's useful in the media entity name. And multiple Isn't it? Why not? As long as the format is strictly adhered to then I see no reason not to use it. Not only does it make the name unique, it also tells you where the device is in the hardware topology. It's a shame that entities don't have a bus info field in addition to their name, but we have to live with that. Userspace needs a way to distinguish between multiple identical subdevs. We can't rely on IDs only, as they're not guaranteed to be stable. We thus need to use names and possibly connection information. Two identical sensors connected to separate receivers could be distinguished by checking which receiver they're connected to. Unfortunately this breaks when the two sensors are connected to the same receiver, in which case we can only rely on the name. Media entity names thus need to be unique when connection information can't help distinguishing otherwise identical subdevs, which implies that subdev names must be unique. We could make the simple rule that the driver name is the first word of the name. So it would be easy to provide a function that matches just the first word and ignores the bus info (if there is any). Yes, and that's basically all I needed before fixing those affected drivers. No matter what exact rules, if there are any, user space could handle various hardware configurations without issues. Besides, the drivers would need to strip/replace with something else any spaces when initializing subddev name, as that character would be used as the bus info delimiter ? Or we could decide that the bus info can't contain any space, in which case the last space would be the delimiter. Sounds reasonable as well. Frankly, I don't think either should contain a space :-) Today nobody is using spaces anywhere to the best of my knowledge. OK, then there would be spaces neither inname nor inbus-info. From a quick grep I can't see any driver currently using spaces in its subdev name. In case of multi-subdev sensors (when the sensor includes a scaler for instance) the subdev names will likely be made of the sensor name (or driver name) and a subdev description. Something like x pixel array and xx scaler. We could use a dash or underscore to replace spaces though. Yes, I guess dash or underscore could be well used instead of spaces. But my feeling is that 32 characters might be often not enough to hold longer names and bus info. Also it would be good to denote what sort of bus we refer to, i2c, spi, usb, platform, etc. I doesn't look like we can always fit that information in 32 characters. [...] How should bus info be retrieved if it's not part of the media entity name ? If that subdev name is also going to be used in the MC, then yes, it should contain the i2c bus info. At the moment the v4l2 core makes no assumptions on the subdev name, other than that it must be unique. which is generally achieved by appending the i2c bus info. But some platform subdevs (non-i2c) may not have any bus info since that doesn't apply in all cases. I would propose a guideline for the subdev naming like this: name bus-info wherebus-info is optional and neither string contains spaces. Hmm, it might be inconvenient for platform subdevs. E.g. it could mean something like: currently |name bus-info --+-- s5p-mipi-csis.0 | s5p-mipi-csis 1180.csis s5p-mipi-csis.1 | s5p-mipi-csis 1181.csis FIMC-LITE.0 | FIMC-LITE 1204.fimc-lite FIMC-LITE.0 | FIMC-LITE 1205.fimc-lite The register window addresses can vary across various SoCs and it doesn't sound very clever to expose that to user space, when a device is exactly same from the user point of view. Presumably the .index part in the names in the above cases should be kept, and user space could just ignore bus-info, e.g. s5p-mipi-csis.0 | s5p-mipi-csis.0 1180.csis FIMC-LITE.0 | FIMC-LITE.0 1205.fimc-lite If the bus info is too long it would get truncated. We're limited to 32 characters, which isn't much to store both the name and bus info. Indeed, it's a pretty serious limitation IMHO. While we are at it, how about v4l2_i2c_subdev_init() ? It initializes sd-name with SPI driver
Re: [RFC] Support for events with a large payload
On 07/03/2013 09:34 PM, Laurent Pinchart wrote: On Wednesday 03 July 2013 02:01:59 Sakari Ailus wrote: On Mon, Jun 24, 2013 at 03:40:14PM +0200, Hans Verkuil wrote: ... Since the payloads are larger I am less concerned about speed. There is one problem, though: if you dequeue the event and the buffer that should receive the payload is too small, then you have lost that payload. You can't allocate a new, larger, buffer and retry. So this approach can only work if you really know the maximum payload size. The advantage is also that you won't lose payloads. Forgot to answer this one --- I think it's fair to assume the user knows the maximum size of the payload. What we also could do in such a case is to return the error (e.g. ENOSPC) and put the required size to the large event size field. But first someone must come up with a variable size event without well defined maximum size for this to make much sense. And while we're discussing use cases, Hans, what are you current use cases for 64 bytes event payloads ? One of the use cases could be face detection events. A face marker would contain at least 4 rectangle data structures (face, left/right eye, mouth,...), which is itself 64 bytes. Plus Euler angle information, confidence, smile/blink level etc. We could add an object detection specific ioctl(s) (I'm not sure if such won't be needed anyway), but the event API looks like a good infrastructure to handle this kind of data. -- 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
