Re: IR remote control autorepeat / evdev
Em 14-05-2011 01:07, Anssi Hannula escreveu: > On 14.05.2011 01:39, Mauro Carvalho Chehab wrote: >> Em 13-05-2011 01:48, Anssi Hannula escreveu: >>> On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: > Em 12-05-2011 02:37, Anssi Hannula escreveu: >> I don't see any other places: >> $ git grep 'REP_PERIOD' . >> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >> d->props.rc.legacy.rc_interval; > > Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we > should change it to something like 125ms, for example, as 33ms is too > short, as it takes up to 114ms for a repeat event to arrive. > IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. >>> >>> It will indeed reduce the amount of ghost events so it brings us in the >>> right direction. >>> >>> I'd still like to get rid of the ghost repeats entirely, or at least >>> some way for users to do it if we don't do it by default. >> >>> Maybe we could replace the kernel softrepeat with native repeats (for >>> those protocols/drivers that have them), while making sure that repeat >>> events before REP_DELAY are ignored and repeat events less than >>> REP_PERIOD since the previous event are ignored, so the users can still >>> configure them as they like? >>> >> >> This doesn't seem to be the right thing to do. If the kernel will >> accept 33 ms as the value or REP_PERIOD, but it will internally >> set the maximum repeat rate is 115 ms (no matter what logic it would >> use for that), Kernel (or X) shouldn't allow the user to set a smaller >> value. >> >> The thing is that writing a logic to block a small value is not easy, since >> the max value is protocol-dependent (worse than that, on some cases, it is >> device-specific). It seems better to add a warning at the userspace tools >> that delays lower than 115 ms can produce ghost events on IR's. > > From what I see, even periods longer than 115 ms can produce ghost events. > > For example with your patch softrepeat period is 125ms, release timeout > 250ms, and a native rate of 110ms: > > There are 4 native events transmitted at > 000 ms > 110 ms > 220 ms > 330 ms > (user stops between 330ms and 440ms) > > This causes these events in the evdev interface: > 000: 1 > 125: 2 > 250: 2 > 375: 2 > 500: 2 > 550: 0 > > So we got 1-2 ghost repeat events. > >>> Or maybe just a module option that causes rc-core to use native repeat >>> events, for those of us that want accurate repeat events without ghosting? >> >> If the user already knows about the possibility to generate ghost effects, >> with low delays, he can simply not pass a bad value to the kernel, instead >> of forcing a modprobe parameter that will limit the minimal value. > > There is no "good value" for REP_PERIOD (as in ghost repeats guaranteed > gone like with native repeats). Sufficiently large values will make > ghost repeats increasingly rare, but the period becomes so long the > autorepeat becomes frustratingly slow to use. > The 250 ms delay used internally to wait for a repeat code is there because shorter periods weren't working on one of the first boards we've added to rc core (it was a saa7134 - can't remember much details... too much time ago). I remember that I added it as a per-board timer (or per protocol?), as it seemed to high for me, but later, David sent a series of patches rewriting the entire stuff and proposing to have just one timer, arguing that later this could be changed. As his series were improving rc-core, I ended by acking with the changes. The fact is that REP_PERIODS shorter than that timer makes non-sense, as that timer is used to actually wait for a repeat message. I suspect we should re-work the code, perhaps replacing the 250 ms fixed value by REP_PERIOD. I can't work on it this weekend, as I'm about to leave Hungary to return back home. I suspect that I'll have lots of fun next week, due to a one-week travel, and due to the .40 merge window (I suspect it will be opened next week). Maybe Jarod can find some time to do such patch and test it. Thanks, Mauro. -- 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: Problems of Pinnacle PCTV Hybrid pro stick in linux
Hello and thanks On Sat, May 14, 2011 at 10:16 PM, Mauro Carvalho Chehab wrote: > Em 14-05-2011 13:19, a baffian escreveu: >> Hello Mauro and thanks for your sentences >> But: >> >> 1- For such experienced programmer as you, it is obvious from > > First of all, if you need some help, please change your tone, as it > seems a little offensive. We all are volunteers, and, while we spend > some of our spare time to help people, we expect that the people > to be nice and answer with technical information that will allow us > to help,. > >> http://daftar.minidns.net/pctv/problem.html#problem2 , that when no >> any software could scan the channels, thus at least one important >> problem is in the kernel side, isn't it? > i excuse you for the first sentence, but i still don't know what was bad during my above paragraph, and i excuse you again. ( i thought that the experienced programmer is a good adjective. ) i provided some of logs you told: the log of dmesg during inserting the Pinnacle's DVB-Stick and output of "scan -v" and some others here: http://daftar.minidns.net/pctv/some-log1.zip . This file has a file named readme-first.txt containing description of its contents. i will try to provide again the afatech-9015 based DVB-stick to find the logs you want about it. >> At end i again tell that, i am in the #linux-tv chat room as dast53 >> for speaking to solving those problems. > > I'm traveling abroad this entire week, and next week I'll be handling > the pending work. Also, as the merge window will probably be opened next > week, I'll be busy submitting the patches we have upstream. So, > unfortunately, it is unlikely that I'll have time soon to help debugging > a driver via irc. > i can wait to you to return from your traveling. thanks -- 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] drm: add overlays as first class KMS objects
On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes wrote: > On Fri, 13 May 2011 18:16:30 +0200 > Daniel Vetter wrote: > >> Hi Jesse, >> >> Discussion here in Budapest with v4l and embedded graphics folks was >> extremely fruitful. A few quick things to take away - I'll try to dig >> through all >> the stuff I've learned more in-depth later (probably in a blog post or two): Hi Daniel, thanks for writing this up >> - embedded graphics is insane. The output routing/blending/whatever >> currently shipping hw can do is crazy and kms as-is is nowhere near up >> to snuff to support this. We've discussed omap4 and a ti chip targeted at >> video surveillance as use cases. I'll post block diagrams and explanations >> some when later. > > Yeah I expected that; even just TVs can have really funky restrictions > about z order and blend capability. > >> - we should immediately stop to call anything an overlay. It's a confusing >> concept that has a different meaning in every subsystem and for every hw >> manufacturer. More sensible names are dma fifo engines for things that >> slurp >> in planes and make them available to the display subsystem. Blend engines >> for blocks that take multiple input pipes and overlay/underlay/blend them >> together. Display subsytem/controller for the aggregate thing including >> encoders/resizers/outputs and especially the crazy routing network that >> connects everything. > > How about just "display plane" then? Specifically in the context of > display output hardware... "display plane" could be a good name.. actually in omap4 case it is a single dma engine that is multiplexing fetches for however many attached video pipes.. that is perhaps an implementation detail, but it makes "display plane" sound nicer as a name > >> 1) Splitting the crtc object into two objects: crtc with associated output >> mode >> (pixel clock, encoders/connectors) and dma engines (possibly multiple) that >> feed it. omap 4 has essentially just 4 dma engines that can be freely >> assigned >> to the available outputs, so a distinction between normal crtcs and overlay >> engines just does not make sense. There's the major open question of where >> to put the various attributes to set up the output pipeline. Also some of >> these >> attributes might need to be changed atomicly together with pageflips on >> a bunch of dma engines all associated with the same crtc on the next vsync, >> e.g. output position of an overlaid video buffer. > > Yeah, that's a good goal, and pretty much what I had in mind here. > However, breaking the existing interface is a non-starter, so either we > need a new CRTC object altogether, or we preserve the idea of a > "primary" plane (whatever that means for a given platform) that's tied > to each CRTC, which each additional plane described in a separate > structure. Z order and blend restrictions will have to be communicated > separately I think... In the cases I can think of, you'll always have a primary plane, so userspace need not explicitly specify it. But I think you want the driver to pick which display plane to be automatically hooked between the primary fb and crtc, or at least this should be the case if some new bit is set in driver_features to indicate the driver supports multiple display planes per crtc. BR, -R > Thanks, > -- > Jesse Barnes, Intel Open Source Technology Center > -- 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 driver for TerraTec H7 - how do I install them?
Update: There is a new / updated driver for the H7 over at TerraTec's site: http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz and this time, it includes instructions. Using these instructions and Xubuntu 10.10 with this kernel: tingo@vm:~$ uname -a Linux vm 2.6.35-28-generic-pae #50-Ubuntu SMP Fri Mar 18 20:43:15 UTC 2011 i686 GNU/Linux I was able to get the H7 recognized. From /var/log/messages: May 14 23:59:26 vm kernel: [ 4226.560048] usb 1-2: new high speed USB device using ehci_hcd and address 3 May 14 23:59:27 vm kernel: [ 4227.007366] az6007: henry :: az6007 usb module init May 14 23:59:27 vm kernel: [ 4227.007551] az6007: usb in operation failed. (-32) May 14 23:59:27 vm kernel: [ 4227.007795] az6007: FW GET_VERSION length: -32 May 14 23:59:27 vm kernel: [ 4227.007796] May 14 23:59:27 vm kernel: [ 4227.007798] az6007: cold: 1 May 14 23:59:27 vm kernel: [ 4227.007798] May 14 23:59:27 vm kernel: [ 4227.007800] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)' in cold state, will try to load a firmware May 14 23:59:27 vm kernel: [ 4227.009825] dvb-usb: downloading firmware from file 'dvb-usb-az6007-03.fw' May 14 23:59:27 vm kernel: [ 4227.084577] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)' in warm state. May 14 23:59:27 vm kernel: [ 4227.084674] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. May 14 23:59:27 vm kernel: [ 4227.302655] DVB: registering new adapter (TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)) May 14 23:59:27 vm kernel: [ 4227.311991] dvb-usb: MAC address: c2:cd:0c:a3:10:00 May 14 23:59:27 vm kernel: [ 4227.312475] az6007: az6007_frontend_poweron adap=f34ee88c adap->dev=f34ee000 May 14 23:59:27 vm kernel: [ 4227.312478] May 14 23:59:28 vm kernel: [ 4227.720338] az6007: az6007_frontend_poweron May 14 23:59:28 vm kernel: [ 4227.720343] May 14 23:59:28 vm kernel: [ 4227.720349] az6007: az6007_frontend_reset adap=f34ee88c adap->dev=f34ee000 May 14 23:59:28 vm kernel: [ 4227.720352] May 14 23:59:28 vm kernel: [ 4228.332027] az6007: reset az6007 frontend May 14 23:59:28 vm kernel: [ 4228.332032] May 14 23:59:28 vm kernel: [ 4228.332036] az6007: az6007_frontend_attach May 14 23:59:28 vm kernel: [ 4228.332038] May 14 23:59:28 vm kernel: [ 4228.332040] az6007: az6007_drxk3913_config_DVBT May 14 23:59:28 vm kernel: [ 4228.332042] May 14 23:59:28 vm kernel: [ 4228.332046] state->frontend.ops = drxk3913_ops_dvbt May 14 23:59:28 vm kernel: [ 4228.332053] mt2063_attach: Attaching MT2063 May 14 23:59:28 vm kernel: [ 4228.332057] az6007: found STB6100 DVB-C/DVB-T frontend @0xc0 May 14 23:59:28 vm kernel: [ 4228.332059] May 14 23:59:28 vm kernel: [ 4228.332066] DVB: registering adapter 0 frontend 0 (DRXK3913 Multistandard DVB_T)... May 14 23:59:28 vm kernel: [ 4228.332278] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:13.5/usb1/1-2/input/input4 May 14 23:59:28 vm kernel: [ 4228.332335] dvb-usb: schedule remote query interval to 400 msecs. May 14 23:59:28 vm kernel: [ 4228.332341] dvb-usb: TerraTec DTV StarBox DVB-T/C USB2.0 (az6007) successfully initialized and connected. May 14 23:59:28 vm kernel: [ 4228.332385] usbcore: registered new interface driver dvb_usb_az6007 Unfortunately, I am not able to test if the driver works just now, because currently the driver only supports DVB-T, and I only have DVB-C. -- Regards, Torfinn Ingolfsen -- 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
[PATCH v2] fm801: clean-up radio-related Kconfig
Remove TEA575X_RADIO define from fm801.c.
Also update Kconfig help text to include all supported cards.
Signed-off-by: Ondrej Zary
--- linux-2.6.39-rc2-/sound/pci/Kconfig 2011-05-14 22:22:11.0 +0200
+++ linux-2.6.39-rc2/sound/pci/Kconfig 2011-05-14 22:24:29.0 +0200
@@ -560,8 +560,8 @@ config SND_FM801_TEA575X_BOOL
depends on VIDEO_V4L2=y || VIDEO_V4L2=SND_FM801
help
Say Y here to include support for soundcards based on the ForteMedia
- FM801 chip with a TEA5757 tuner connected to GPIO1-3 pins (Media
- Forte SF256-PCS-02) into the snd-fm801 driver.
+ FM801 chip with a TEA5757 tuner (MediaForte SF256-PCS, SF256-PCP and
+ SF64-PCR) into the snd-fm801 driver.
config SND_TEA575X
tristate
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-14 22:22:11.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-14 22:26:01.0 +0200
@@ -38,7 +38,6 @@
#ifdef CONFIG_SND_FM801_TEA575X_BOOL
#include
-#define TEA575X_RADIO 1
#endif
MODULE_AUTHOR("Jaroslav Kysela ");
@@ -196,7 +195,7 @@ struct fm801 {
spinlock_t reg_lock;
struct snd_info_entry *proc_entry;
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_TEA575X_BOOL
struct snd_tea575x tea;
#endif
@@ -715,7 +714,7 @@ static int __devinit snd_fm801_pcm(struc
* TEA5757 radio
*/
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_TEA575X_BOOL
/* GPIO to TEA575x maps */
struct snd_fm801_tea575x_gpio {
@@ -1150,7 +1149,7 @@ static int snd_fm801_free(struct fm801 *
outw(cmdw, FM801_REG(chip, IRQ_MASK));
__end_hw:
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_TEA575X_BOOL
snd_tea575x_exit(&chip->tea);
#endif
if (chip->irq >= 0)
@@ -1229,7 +1228,7 @@ static int __devinit snd_fm801_create(st
snd_card_set_dev(card, &pci->dev);
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_TEA575X_BOOL
chip->tea.private_data = chip;
chip->tea.ops = &snd_fm801_tea_ops;
sprintf(chip->tea.bus_info, "PCI:%s", pci_name(pci));
--
Ondrej Zary
--
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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Thursday 12 May 2011, Josh Wu wrote:
> This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
> - Using soc-camera framework with videobuf2 dma-contig allocator
> - Supporting video streaming of YUV packed format
> - Tested on AT91SAM9M10G45-EK with OV2640
>
> Signed-off-by: Josh Wu
This looks like a very well written driver for the most part. I have a few
comments, mainly regarding maintainability that you should probably look
into.
> arch/arm/mach-at91/include/mach/at91_isi.h | 454
> drivers/media/video/Kconfig| 10 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/atmel-isi.c| 1089
>
So you have a mach specific header file that is used by a single driver?
That does not lean itself it code reuse. Better move the header file into
the same directory as the driver, or (better) merge its contents into the
same file.
This is especially important if the driver is possibly shared with avr32
socs.
> +/* Constants for RGB_CFG */
> +#define ISI_RGB_CFG_DEFAULT 0
> +#define ISI_RGB_CFG_MODE_1 1
> +#define ISI_RGB_CFG_MODE_2 2
> +#define ISI_RGB_CFG_MODE_3 3
> +
> +/* Constants for RGB_CFG(ISI_V2) */
> +#define ISI_V2_RGB_CFG_DEFAULT 0
> +#define ISI_V2_RGB_CFG_MODE_11
> +#define ISI_V2_RGB_CFG_MODE_22
> +#define ISI_V2_RGB_CFG_MODE_33
> +
> +/* Bit manipulation macros */
> +#define ISI_BIT(name)\
> + (1 << ISI_##name##_OFFSET)
> +#define ISI_BF(name, value) \
> + (((value) & ((1 << ISI_##name##_SIZE) - 1)) \
> + << ISI_##name##_OFFSET)
> +#define ISI_BFEXT(name, value) \
> + (((value) >> ISI_##name##_OFFSET) \
> + & ((1 << ISI_##name##_SIZE) - 1))
> +#define ISI_BFINS(name, value, old) \
> + (((old) & ~(((1 << ISI_##name##_SIZE) - 1) \
> + << ISI_##name##_OFFSET))\
> + | ISI_BF(name, value))
A much better way to express the above would be to define the constants as
mask values rather than using the macros with bit numbers. There are
conflicting views on how bits are counted, plus the use of macros
makes it harder to grep for the idenfiers.
For example, do
#define ISI_RGB_CFG_DEFAULT 0x0001
#define ISI_RGB_CFG_MODE_1 0x0002
#define ISI_RGB_CFG_MODE_2 0x0004
#define ISI_RGB_CFG_MODE_3 0x0008
For the two examples I quoted, the values are actually the same,
so you might also want to name them so that you don't have to
define multiple versions but can simply reuse the same macros.
Some people also prefer the use of enum over #define, but I
leave that to your judgement
> +/* Register access macros */
> +#define isi_readl(port, reg) \
> + __raw_readl((port)->regs + ISI_##reg)
> +#define isi_writel(port, reg, value) \
> + __raw_writel((value), (port)->regs + ISI_##reg)
Please explain why you use __raw_* instead of the proper
accessors in the comment. Normal drivers should always
use readl/writel.
Better don't concatenate identifiers, in order to make
grep and ctags work on the arguments.
> +
> +#define ATMEL_ISI_VERSIONKERNEL_VERSION(1, 0, 0)
Don't use KERNEL_VERSION() here, it means something else.
Better yet, don't define a version at all. It is not acceptable
to make any user space interface depend on specific versions,
this is a compatibility nightmare.
> +/* Frame buffer descriptor
> + * Used by the ISI module as a linked list for the DMA controller.
> + */
> +struct fbd {
> + /* Physical address of the frame buffer */
> + u32 fb_address;
> +#if defined(CONFIG_ARCH_AT91SAM9G45) ||\
> + defined(CONFIG_ARCH_AT91SAM9X5)
> + /* DMA Control Register(only in HISI2) */
> + u32 dma_ctrl;
> +#endif
> + /* Physical address of the next fbd */
> + u32 next_fbd_address;
> +};
> +
> +#if defined(CONFIG_ARCH_AT91SAM9G45) ||\
> + defined(CONFIG_ARCH_AT91SAM9X5)
> +static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl)
> +{
> + fb_desc->dma_ctrl = ctrl;
> +}
> +#else
> +static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl) { }
> +#endif
Make these runtime checks, not compile-time. Best define different
identifiers for the platform device, then key the differences off
the device, not the platform.
> +struct atmel_isi {
> + /* ISI module spin lock. Protects against concurrent access of variables
> + * that are shared with the ISR */
> + spinlock_t lock;
> + void __iomem*regs;
> +
> + /* If set ISI is in still capture mode */
> + int still_capture;
> + int sequence;
> + /* State of the ISI module in capturing mod
Re: adding dvb-t scan files for New Zealand
Can you please attach the files as files? Christoph 2011/5/13 Jodi the Tigger : > Hello all, > > I want to add dvb-t scan files for New Zealand, as there only seems to > be one (For Waiatarua, Auckland, NZ). > However I have no idea how to actually get the files I created added > to the linux tv project. > > So if someone could either: > 1) point me to a faq / wiki / web site explaining how I can update > dvb-t scan files. > or > 2) Kindly add the files for me. > > I would be most grateful. > > I have pasted the contents of the files below (each comment block is a > new file). > > -Richard Maxwell > > # Waiatarua, Auckland NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 53800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 57000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 66600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Pinehill, Remuera, Sky Tower, Auckland Infill, Auckland NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 53000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 56200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 62600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Te Aroha, Waikato NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 67400 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Hamilton Infill, Waikato NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 69800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 68200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Kopukairua, Tauranga NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 69800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 64200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Mt. Erin, Hawkes Bay NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 52200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 55400 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 65000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Napier Infill, Hawkes Bay NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Wharite, Manawatu NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > > # Kaukau, Wellington NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Fitzherbert, Baxters Knob, Wellington infill, Wellington NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 73000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 76200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Ngarara, Wellington NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 66600 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 73000 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 76200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > > # Sugarloaf, Christchurch NZ > # > # Channel allocation details for NZ can be found at > # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) > # > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > > T 68200 8MHz 3/4 NONE QAM64 8k 1/16 NONE > T 69800 8MHz
Re: New initial dvb-c scan data for Denmark: Aarhus Antenneforening
2011/5/14 Darren Black : > Hi there > > Could somebody add this to the set of scan's initial scanning files? > I'm guessing the name of the file should be something along the lines > of dvb-c/dk-Aarhus-AarhusAntenneforening. > > # freq sr fec mod > C 34600 690 AUTO QAM64 Added (as dk-Aarhus-Antenneforening), thanks. Christoph > Cheers > > /Darren > -- > 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
Re: [PATCHv2] v4l: Add M420 format definition
Hi Andy, On Saturday 14 May 2011 15:31:55 Andy Walls wrote: > On Fri, 2011-05-13 at 16:43 +0200, Laurent Pinchart wrote: > > On Friday 13 May 2011 14:01:32 Guennadi Liakhovetski wrote: > > > Couldn't spot any problems with the patch except: > > > > > > On Fri, 13 May 2011, Laurent Pinchart wrote: > > > > From: Hans de Goede > > > > > > > > M420 is an hybrid YUV 4:2:2 packet/planar format. Two Y lines are > > > > > > Didn't you mean "4:2:0"? > > > > Yep. I'll fix that. Thanks for the review. > > > > > And if I wanted to nit-pick, I think, it should be "a hybrid," I'm not > > > a native-speaker though;) > > Yes, "a hybrid" is the correct form. > > > The use of "a" or "an" is a speech rule; not a spelling rule. If the > word begins with a consonant sound, "a" is used; if the word begins with > a vowel sound, "-n" is appended, so "an" is used. > > The initial sounds of English words that begin with "h", "u", and "y" > can't be determined by the inital letter alone. One has to know how to > pronounce the word to choose the correct form: > > a hint > a unit > a yard > > an hour > an umbrella > an yttrium atom > > The rule for appending "-n" to "a" before a vowel sound allows faster > speech. Without the "-n" before a vowel sound, an English speaker is > going to pronounce the "a" either as a dipthong or with a trailing > glottal stop. Either will slow down speech ever so slightly. > I love your digressions about the English language, please keep them coming :-) -- Regards, Laurent Pinchart -- 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 14 19:00:41 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b 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: Problems of Pinnacle PCTV Hybrid pro stick in linux
Em 14-05-2011 13:19, a baffian escreveu: > Hello Mauro and thanks for your sentences > But: > > 1- For such experienced programmer as you, it is obvious from First of all, if you need some help, please change your tone, as it seems a little offensive. We all are volunteers, and, while we spend some of our spare time to help people, we expect that the people to be nice and answer with technical information that will allow us to help,. > http://daftar.minidns.net/pctv/problem.html#problem2 , that when no > any software could scan the channels, thus at least one important > problem is in the kernel side, isn't it? You told you tested it with two cards, having different results. Without the debug logs from both cards, there's no way to identify what's happening. > If the problems are only in the userspace, at least one of many good > softwares such as mentioned here: > http://daftar.minidns.net/pctv/problem.html#problem1 could find the > channels during scanning, aren't they? No. The scan procedure happens partially on userspace and partially on kernelspace. It is userspace task to decode the MPEG-TS and seek for for the Program Identifiers. > 2- you mentioned "most of the comments and logs there provide not much > help", i can provide any other help and comment and logs and tests of > new changes in driver sources that you want, as i did about 12 days > ago for "Devin Heitmueller" during a chat session in #linux-tv of > irc.freenode.net. Ok. Then please provide the logs for the both cards, showing what happens during the scan. We need "scan -v" log and the kernel logs (the command to get it is: dmesg). Please enable frontend, em28xx and af9015 debug logs, for us to know what the kernel is doing. > 3- you mentioned some about my performance complaints, but if you read > this part of my writings: > http://daftar.minidns.net/pctv/problem.html#c1 you can find the power > of my testing hardware is reasonably very very higher than needed by > tv showing applications, and the Nvidia-G9500-GT graphic card is more > famous than we can relate the problems to its miss functioning, isn't > it? It doesn't matter what Nvidia card you're using. The more expensive process is the MPEG decoding. If that happens on userspace, it is your CPU that will be used. HD streams require too much CPU. With the right software and the right video board driver, this task could be send to the Graphics card (GPU), by using an API (like vdpau), but not all software supports, and it requires a GPU-accelerated codec for the video standard (typically, mpeg2). I'm not sure if Kaffeine currently offers GPU-accelerated mpeg2 codec, and if the nouveau or the Nvidia proprietary driver is compatible with Kaffeine's GPU's codecs. > 4- i inserted the scan result of another DVB-stick that i had, here: > http://daftar.minidns.net/pctv/channels.conf for you , but i had not > that DVB-stick now for testing again. it had the afatech-9015 chip set > and could find my all 25 digital channel in any linux box by any here: > http://daftar.minidns.net/pctv/problem.html#problem1 mentioned > software. It is interesting to see the logs for the af9015 device, and see what is it doing different than the Pinnacle one. > The only problem with that afatech based DVB was 2 : it > could not play the sounds of digital channels except one of digital-TV > channels i explained about it here: > http://daftar.minidns.net/pctv/problem.html#p-h and here: > http://daftar.minidns.net/pctv/problem.html#p-d and here: > http://daftar.minidns.net/pctv/problem.html#p-e and here: > http://daftar.minidns.net/pctv/problem.html#p-g , >From your descriptions, it seems that the program identifiers sent by the TV stations are wrong, or the userspace application is getting it wrong. Basically, each MPEG-TS stream has several PID's. each of them can have an audio or a video stream (there are also other types, but those two are the rellevant ones). The video and audio stream should be associated, otherwise, you won't be able to hear audio. There is another alternative: eventually, your country is using an audio codec that it is currently unsupported (or it requires you to install one additional libarary and re-compile your application). > any second problem: > it was not the analog TV capable. > > 5- and again the above mentioned paragraph (4) prove that most of > problems is in the kernel space not userspace, because that afatech > based DVB-stick could find all 25 digital channels during scan and > play the by all of mentioned software, and only one of problems is the > same as Pinnacle's one: the problem of sounds of that 13 digital tv > channel. Probably, but hard to know without having both logs to compare. > At end i again tell that, i am in the #linux-tv chat room as dast53 > for speaking to solving those problems. I'm traveling abroad this entire week, and next week I'll be handling the pending work. Also, as the merge window will probably be opened next week, I'll be
New initial dvb-c scan data for Denmark: Aarhus Antenneforening
Hi there Could somebody add this to the set of scan's initial scanning files? I'm guessing the name of the file should be something along the lines of dvb-c/dk-Aarhus-AarhusAntenneforening. # freq sr fec mod C 34600 690 AUTO QAM64 Cheers /Darren -- 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 3/3 v5] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Sylwester,
On Wednesday 11 May 2011 17:17:10 Sylwester Nawrocki wrote:
> Add the subdev driver for the MIPI CSIS units available in S5P and
> Exynos4 SoC series. This driver supports both CSIS0 and CSIS1
> MIPI-CSI2 receivers.
> The driver requires Runtime PM to be enabled for proper operation.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
[snip]
> diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
> b/drivers/media/video/s5p-fimc/mipi-csis.c new file mode 100644
> index 000..d50efcb
> --- /dev/null
> +++ b/drivers/media/video/s5p-fimc/mipi-csis.c
> @@ -0,0 +1,722 @@
[snip]
> +static void s5pcsis_enable_interrupts(struct csis_state *state, bool on)
> +{
> + u32 val = s5pcsis_read(state, S5PCSIS_INTMSK);
> +
> + val = on ? val | S5PCSIS_INTMSK_EN_ALL :
> +val & ~S5PCSIS_INTMSK_EN_ALL;
> + s5pcsis_write(state, S5PCSIS_INTMSK, val);
Shouldn't you clear all interrupt flags by writing to S5PCSIS_INTSRC before
enabling interrupts, just in case ?
> +}
[snip]
> +static void s5pcsis_set_hsync_settle(struct csis_state *state, int settle)
> +{
> + u32 val = s5pcsis_read(state, S5PCSIS_DPHYCTRL);
> +
> + val &= ~S5PCSIS_DPHYCTRL_HSS_MASK | (settle << 27);
Do you mean
val = (val & ~S5PCSIS_DPHYCTRL_HSS_MASK) | (settle << 27);
?
> + s5pcsis_write(state, S5PCSIS_DPHYCTRL, val);
> +}
[snip]
> +static int s5pcsis_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_fh
> *fh, + struct v4l2_subdev_format *fmt)
> +{
> + struct csis_state *state = sd_to_csis_state(sd);
> + struct csis_pix_format const *csis_fmt;
> + struct v4l2_mbus_framefmt *mf;
> +
> + mf = __s5pcsis_get_format(state, fh, fmt->pad, fmt->which);
> +
> + if (fmt->pad == CSIS_PAD_SOURCE) {
> + if (mf) {
> + mutex_lock(&state->lock);
> + fmt->format = *mf;
> + mutex_unlock(&state->lock);
> + }
> + return 0;
> + }
> + csis_fmt = s5pcsis_try_format(&fmt->format);
> + if (mf) {
> + mutex_lock(&state->lock);
> + *mf = fmt->format;
> + if (mf == &state->format) /* Store the active format */
I would replace the test by
if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
It's more explicit.
> + state->csis_fmt = csis_fmt;
> + mutex_unlock(&state->lock);
> + }
> + return 0;
> +}
[snip]
> +static int s5pcsis_suspend(struct device *dev)
> +{
> + struct s5p_platform_mipi_csis *pdata = dev->platform_data;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct v4l2_subdev *sd = platform_get_drvdata(pdev);
> + struct csis_state *state = sd_to_csis_state(sd);
> + int ret;
> +
> + v4l2_dbg(1, debug, sd, "%s: flags: 0x%x\n",
> + __func__, state->flags);
> +
> + mutex_lock(&state->lock);
> + if (state->flags & ST_POWERED) {
> + s5pcsis_stop_stream(state);
> + ret = pdata->phy_enable(state->pdev, false);
> + if (ret)
> + goto unlock;
> +
> + if (state->supply && regulator_disable(state->supply))
> + goto unlock;
> +
> + clk_disable(state->clock[CSIS_CLK_GATE]);
> + state->flags &= ~ST_POWERED;
> + }
> + state->flags |= ST_SUSPENDED;
> + unlock:
> + mutex_unlock(&state->lock);
> + return ret ? -EAGAIN : 0;
> +}
> +
> +static int s5pcsis_resume(struct device *dev)
> +{
> + struct s5p_platform_mipi_csis *pdata = dev->platform_data;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct v4l2_subdev *sd = platform_get_drvdata(pdev);
> + struct csis_state *state = sd_to_csis_state(sd);
> + int ret = 0;
> +
> + v4l2_dbg(1, debug, sd, "%s: flags: 0x%x\n",
> + __func__, state->flags);
> +
> + mutex_lock(&state->lock);
> + if (!(state->flags & ST_SUSPENDED))
> + goto unlock;
> +
> + if (!(state->flags & ST_POWERED)) {
If the device wasn't powered before being suspended, it should stay powered
off.
> + if (state->supply)
> + ret = regulator_enable(state->supply);
> + if (ret)
> + goto unlock;
> +
> + ret = pdata->phy_enable(state->pdev, true);
> + if (!ret) {
> + state->flags |= ST_POWERED;
> + } else {
> + regulator_disable(state->supply);
> + goto unlock;
> + }
> + clk_enable(state->clock[CSIS_CLK_GATE]);
> + }
> + if (state->flags & ST_STREAMING)
> + s5pcsis_start_stream(state);
> +
> + state->flags &= ~ST_SUSPENDED;
> + unlock:
> + mutex_unlock(&state->lock);
> + return ret ? -EAGAIN : 0;
> +}
[snip]
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-med
az6027: Terratec S7 has no signal on S2-transponders
Hi all, I use a Terratec S7 MKII with dvb_usb_az6027. DVB-S channels are working fine, but when trying to lock on DVB-S2 channels, the signal level drops to zero. Google and Windows told me this problem is not limited to me, and trying out s2-liplianin, in-kernel drivers of 2.6.38 and media-build.git did not help. As I have this hardware and C-knowledge here, I offer any help that might be needed in tracking down the problem. If there is something like an USB-trace/-sniffing to do (device works fine in Windows-VM), a "RTFM" with an URL would be fine. Furthermore, scanning Astra S19E2 takes ~90min with w_scan, as compared to 3-5min on Windows, so there appears to be also some problem tuning-related for DVB-S. - If this is the wrong place to ask, please ignore the message and direct me somewhere else. - All help is very much appreciated! Thx -- 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: Current status report of mt9p031.
Hi Javier, On Friday 13 May 2011 08:45:28 javier Martin wrote: > On 13 May 2011 07:02, Chris Rodley wrote: > > On 11/05/11 19:15, javier Martin wrote: > > > > On 11 May 2011 06:54, Chris Rodley wrote: > >> Thanks, sorry I should have spotted that. > > > > Got some shots today. So I have caught up to where you were. Had a bit of > > messing around to do as my board connects power via gpio switches and I > > was porting other drivers from 2.6.32. > > > > How are you progressing Javier? > > I'm just waiting for Laurent to clarify an issue about format matching > between mt9p031 and omap3isp. > He claimed to help me this weekend or next week. I have no mt9p031 here, so I've tried an mt9v032 (752x480 10-bit raw bayer) with the latest OMAP3 ISP driver. I had to patch yavta to support 8-bit formats, the patch has been pushed to the repository. Running the following commands captured 4 frames successfully. ./media-ctl -r -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' ./media-ctl -f '"mt9v032 3-005c":0[SGRBG10 752x480 (1,5)/752x480], "OMAP3 ISP CCDC":0[SGRBG8 752x480], "OMAP3 ISP CCDC":1[SGRBG8 752x480]' ./yavta -p -f SGRBG8 -s 752x480 -n 4 --capture=4 --skip 3 -F `./media-ctl -e "OMAP3 ISP CCDC output"` -- Regards, Laurent Pinchart -- 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
[PATCH 2/2] drivers/media/rc/imon.c: Correct call to input_free_device
From: Julia Lawall
ictx->touch is intialied in imon_init_intf1, to the result of calling the
function that contains this code. Thus, in this code, input_free_device
should be called on touch itself.
A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)
//
@r exists@
local idexpression struct input_dev * x;
expression ra,rr;
position p1,p2;
@@
x = input_allocate_device@p1(...)
... when != x = rr
when != input_free_device(x,...)
when != if (...) { ... input_free_device(x,...) ...}
if(...) { ... when != x = ra
when forall
when != input_free_device(x,...)
\(return <+...x...+>; \| return@p2...; \) }
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
cocci.print_main("input_allocate_device",p1)
cocci.print_secs("input_free_device",p2)
//
Signed-off-by: Julia Lawall
---
drivers/media/rc/imon.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 8fc0f08..c400318 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1982,7 +1982,7 @@ static struct input_dev *imon_init_touch(struct
imon_context *ictx)
return touch;
touch_register_failed:
- input_free_device(ictx->touch);
+ input_free_device(touch);
touch_alloc_failed:
return NULL;
--
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: [PATCHv2] v4l: Add M420 format definition
On Fri, 2011-05-13 at 16:43 +0200, Laurent Pinchart wrote: > Hi Guennadi, > > On Friday 13 May 2011 14:01:32 Guennadi Liakhovetski wrote: > > Couldn't spot any problems with the patch except: > > > > On Fri, 13 May 2011, Laurent Pinchart wrote: > > > From: Hans de Goede > > > > > > M420 is an hybrid YUV 4:2:2 packet/planar format. Two Y lines are > > > > Didn't you mean "4:2:0"? > > Yep. I'll fix that. Thanks for the review. > > > And if I wanted to nit-pick, I think, it should be "a hybrid," I'm not a > > native-speaker though;) Yes, "a hybrid" is the correct form. The use of "a" or "an" is a speech rule; not a spelling rule. If the word begins with a consonant sound, "a" is used; if the word begins with a vowel sound, "-n" is appended, so "an" is used. The initial sounds of English words that begin with "h", "u", and "y" can't be determined by the inital letter alone. One has to know how to pronounce the word to choose the correct form: a hint a unit a yard an hour an umbrella an yttrium atom The rule for appending "-n" to "a" before a vowel sound allows faster speech. Without the "-n" before a vowel sound, an English speaker is going to pronounce the "a" either as a dipthong or with a trailing glottal stop. Either will slow down speech ever so slightly. Regards, Andy > I'll fix that too :-) > -- 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
On Sat, 2011-05-07 at 14:46 +0200, Hans Verkuil wrote:
> On Thursday, May 05, 2011 20:49:21 Sakari Ailus wrote:
> >
> >
> > enum v4l2_flash_strobe_whence {
> > V4L2_FLASH_STROBE_WHENCE_SOFTWARE,
> > V4L2_FLASH_STROBE_WHENCE_EXTERNAL,
> > };
>
> Perhaps use 'type' instead of 'whence'? English isn't my native language,
> but it sounds pretty archaic to me.
"SOURCE" is better than "WHENCE" here.
"whence" is certainly very formal and used very little. "whence" likely
still gets some use in English, simply because a terse synonym doesn't
exist.
The problem with using whence is that many English speakers won't know
its correct definition.
"whence" means "from what source, origin, or place"
In your use here, the implicit "from" in the definition of whence is
essential. However, most (American) English speakers that I know think
"whence" simply means "where".
Regards,
Andy
--
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: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 14-05-2011 13:02, Hans Verkuil escreveu: > On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: >> So, based at all I've seen, I'm pretty much convinced that the normal MMAP >> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) >> are not the best way to share data with framebuffers. > > I agree with that, but it is a different story between two V4L2 devices. There > you obviously want to use the streaming ioctls and still share buffers. I don't think so. the requirement for syncing the framebuffer between the two V4L2 devices is pretty much the same as we have with one V4L2 device and one GPU. On both cases, the requirement is to pass a framebuffer between two entities, and not a video stream. For example, imagine something like: V4L2 camera => V4L2 encoder t MPEG2 || LL==> GPU Both GPU and the V4L2 encoder should use the same logic to be sure that they will use a buffer that were filled already by the camera. Also, the V4L2 camera driver can't re-use such framebuffer before being sure that both consumers has already stopped using it. So, it is the same requirement as having four displays receiving such framebuffer. Of course, a GPU endpoint may require some extra information for the blending, but also a V4L node may require some other type of extra information. >> We probably need >> something that it will be an enhanced version of the >> VIDIOC_FBUF/VIDIOC_OVERLAY >> ioctls. Unfortunately, we can't just add more stuff there, as there's no >> reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. > > That will be useful as well to add better support for blending and Z-ordering > between overlays. The old API for that is very limited in that respect. Agreed. Mauro. -- 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: Problems of Pinnacle PCTV Hybrid pro stick in linux
Hello Mauro and thanks for your sentences But: 1- For such experienced programmer as you, it is obvious from http://daftar.minidns.net/pctv/problem.html#problem2 , that when no any software could scan the channels, thus at least one important problem is in the kernel side, isn't it? If the problems are only in the userspace, at least one of many good softwares such as mentioned here: http://daftar.minidns.net/pctv/problem.html#problem1 could find the channels during scanning, aren't they? 2- you mentioned "most of the comments and logs there provide not much help", i can provide any other help and comment and logs and tests of new changes in driver sources that you want, as i did about 12 days ago for "Devin Heitmueller" during a chat session in #linux-tv of irc.freenode.net. 3- you mentioned some about my performance complaints, but if you read this part of my writings: http://daftar.minidns.net/pctv/problem.html#c1 you can find the power of my testing hardware is reasonably very very higher than needed by tv showing applications, and the Nvidia-G9500-GT graphic card is more famous than we can relate the problems to its miss functioning, isn't it? 4- i inserted the scan result of another DVB-stick that i had, here: http://daftar.minidns.net/pctv/channels.conf for you , but i had not that DVB-stick now for testing again. it had the afatech-9015 chip set and could find my all 25 digital channel in any linux box by any here: http://daftar.minidns.net/pctv/problem.html#problem1 mentioned software. The only problem with that afatech based DVB was 2 : it could not play the sounds of digital channels except one of digital-TV channels i explained about it here: http://daftar.minidns.net/pctv/problem.html#p-h and here: http://daftar.minidns.net/pctv/problem.html#p-d and here: http://daftar.minidns.net/pctv/problem.html#p-e and here: http://daftar.minidns.net/pctv/problem.html#p-g , any second problem: it was not the analog TV capable. 5- and again the above mentioned paragraph (4) prove that most of problems is in the kernel space not userspace, because that afatech based DVB-stick could find all 25 digital channels during scan and play the by all of mentioned software, and only one of problems is the same as Pinnacle's one: the problem of sounds of that 13 digital tv channel. At end i again tell that, i am in the #linux-tv chat room as dast53 for speaking to solving those problems. Thanks all On Fri, May 13, 2011 at 12:59 PM, Mauro Carvalho Chehab wrote: > Em 12-05-2011 11:12, a baffian escreveu: >> Hello all >> Is there anyone could find the source of problems described below? >> http://daftar.minidns.net/pctv/problem.html > > Most of the comments and logs there provide not much help. As I told > you before, you're mixing clearly userspace issues or limitations with > kernel-related ones. For example, there's nothing we can do at driver > level to make kaffeine to perform better when decoding an MPEG-2 stream > at full screen mode. This is probably either a performance issue with > your GPU card or it is just that you're using a software decoder for it, > on a slow CPU. Some applications allow, with a few GPU types, to run the > MPEG-2 decoder inside the GPU. > > Yet, there's one relevant information there: > > 3- And even with kaffeine, the only way that i could watch some TV, was in > this manner: Before this DVB-stick i inserted another DVB-USB stick in > another linux computer and scan the channels with kaffeine and after finding > the channels, quit the kaffeine and copy its database files ( > $HOME/.kde/share/apps/kaffeine/* ) into the testing computer for pinnacle > DVB-USB hybrid stick. After that copying, i could run kaffeine on the > pinnacle DVB and without scanning, thus i had a table of channels and in its > main window and when i clicked on a channel, that channel was shown. > > You mentioned that you did another dvb stick worked, but on another computer. > Why such dvb stick didn't work at the computer you tested your Pinnacle > device? > > Also, does the working stick is capable of getting the dvb channels using the > scan tool provided at http://linuxtv.org/hg/dvb-apps? If so, please provide us > the dmesg produced with the working card and the scan results (with -v, in > order > to put dvb scan into verbose mode), and the same info with the broken card. > > Thanks, > Mauro > >> >> On Mon, May 9, 2011 at 3:08 PM, a baffian wrote: >>> Hello all, >>> >>> Can anyone help to solve the problems of linux driver of "Pinnacle >>> PCTV Hybrid pro stick" ? >>> It is an em28xx based hybride (digital and analog TV) USB adapter. >>> >>> i wrote the complete story of my experiences with it, and its problems >>> in http://daftar.minidns.net/pctv/problem.html >>> >>> Good Luck >>> >> -- >> 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
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Friday, May 13, 2011 09:45:51 Guennadi Liakhovetski wrote:
> I've found some more time to get back to this. Let me try to recap, what
> has been discussed. I've looked through all replies again (thanks to
> all!), so, I'll present a summary. Any mistakes and misinterpretations are
> mine;) If I misunderstand someone or forget anything - please, shout!
>
> On Fri, 1 Apr 2011, Guennadi Liakhovetski wrote:
>
> > A possibility to preallocate and initialise buffers of different sizes
> > in V4L2 is required for an efficient implementation of asnapshot mode.
> > This patch adds three new ioctl()s: VIDIOC_CREATE_BUFS,
> > VIDIOC_DESTROY_BUFS, and VIDIOC_SUBMIT_BUF and defines respective data
> > structures.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> > drivers/media/video/v4l2-compat-ioctl32.c |3 ++
> > drivers/media/video/v4l2-ioctl.c | 43
> > +
> > include/linux/videodev2.h | 24
> > include/media/v4l2-ioctl.h|3 ++
> > 4 files changed, 73 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> > b/drivers/media/video/v4l2-compat-ioctl32.c
> > index 7c26947..d71b289 100644
> > --- a/drivers/media/video/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> > @@ -922,6 +922,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
> > int cmd, unsigned long arg)
> > case VIDIOC_DQEVENT:
> > case VIDIOC_SUBSCRIBE_EVENT:
> > case VIDIOC_UNSUBSCRIBE_EVENT:
> > + case VIDIOC_CREATE_BUFS:
> > + case VIDIOC_DESTROY_BUFS:
> > + case VIDIOC_SUBMIT_BUF:
> > ret = do_video_ioctl(file, cmd, arg);
> > break;
> >
> > diff --git a/drivers/media/video/v4l2-ioctl.c
> > b/drivers/media/video/v4l2-ioctl.c
> > index a01ed39..b80a211 100644
> > --- a/drivers/media/video/v4l2-ioctl.c
> > +++ b/drivers/media/video/v4l2-ioctl.c
> > @@ -259,6 +259,9 @@ static const char *v4l2_ioctls[] = {
> > [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
> > [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
> > [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
> > + [_IOC_NR(VIDIOC_CREATE_BUFS)] = "VIDIOC_CREATE_BUFS",
> > + [_IOC_NR(VIDIOC_DESTROY_BUFS)] = "VIDIOC_DESTROY_BUFS",
> > + [_IOC_NR(VIDIOC_SUBMIT_BUF)] = "VIDIOC_SUBMIT_BUF",
> > };
> > #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
> >
> > @@ -2184,6 +2187,46 @@ static long __video_do_ioctl(struct file *file,
> > dbgarg(cmd, "type=0x%8.8x", sub->type);
> > break;
> > }
> > + case VIDIOC_CREATE_BUFS:
> > + {
> > + struct v4l2_create_buffers *create = arg;
> > +
> > + if (!ops->vidioc_create_bufs)
> > + break;
> > + ret = check_fmt(ops, create->format.type);
> > + if (ret)
> > + break;
> > +
> > + if (create->size)
> > + CLEAR_AFTER_FIELD(create, count);
> > +
> > + ret = ops->vidioc_create_bufs(file, fh, create);
> > +
> > + dbgarg(cmd, "count=%d\n", create->count);
> > + break;
> > + }
> > + case VIDIOC_DESTROY_BUFS:
> > + {
> > + struct v4l2_buffer_span *span = arg;
> > +
> > + if (!ops->vidioc_destroy_bufs)
> > + break;
> > +
> > + ret = ops->vidioc_destroy_bufs(file, fh, span);
> > +
> > + dbgarg(cmd, "count=%d", span->count);
> > + break;
> > + }
> > + case VIDIOC_SUBMIT_BUF:
> > + {
> > + unsigned int *i = arg;
> > +
> > + if (!ops->vidioc_submit_buf)
> > + break;
> > + ret = ops->vidioc_submit_buf(file, fh, *i);
> > + dbgarg(cmd, "index=%d", *i);
> > + break;
> > + }
> > default:
> > {
> > bool valid_prio = true;
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index aa6c393..b6ef46e 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -1847,6 +1847,26 @@ struct v4l2_dbg_chip_ident {
> > __u32 revision;/* chip revision, chip specific */
> > } __attribute__ ((packed));
> >
> > +/* VIDIOC_DESTROY_BUFS */
> > +struct v4l2_buffer_span {
> > + __u32 index; /* output: buffers index...index +
> > count - 1 have been created */
> > + __u32 count;
> > + __u32 reserved[2];
> > +};
> > +
> > +/* struct v4l2_createbuffers::flags */
> > +#define V4L2_BUFFER_FLAG_NO_CACHE_INVALIDATE (1 << 0)
>
> 1. An additional flag FLAG_NO_CACHE_FLUSH is needed for output devices.
>
> 2. Both these flags should not be passed with CREATE, but with SUBMIT
> (which will be renamed to PREPARE or something similar). It should be
> possible to prepare the same buffer with different cacheing attributes
> during a running operation. Shall these flags be
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: > Em 18-04-2011 17:15, Jesse Barker escreveu: > > One of the big issues we've been faced with at Linaro is around GPU > > and multimedia device integration, in particular the memory management > > requirements for supporting them on ARM. This next cycle, we'll be > > focusing on driving consensus around a unified memory management > > solution for embedded systems that support multiple architectures and > > SoCs. This is listed as part of our working set of requirements for > > the next six-month cycle (in spite of the URL, this is not being > > treated as a graphics-specific topic - we also have participation from > > multimedia and kernel working group folks): > > > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics > > As part of the memory management needs, Linaro organized several discussions > during Linaro Development Summit (LDS), at Budapest, and invited me and other > members of the V4L and DRI community to discuss about the requirements. > I wish to thank Linaro for its initiative. > > Basically, on several SoC designs, the GPU and the CPU are integrated into > the same chipset and they can share the same memory for a framebuffer. Also, > they may have some IP blocks that allow processing the framebuffer internally, > to do things like enhancing the image and converting it into an mpeg stream. > > The desire, from the SoC developers, is that those operations should be > done using zero-copy transfers. > > This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, > that was used in the old days where CPUs weren't fast enough to process > video without generating a huge load on it. So the overlay mode were created > to allow direct PCI2PCI transfers from the video capture board into the > display adapter, using XVideo extension, and removing the overload at the > CPU due to a video stream. It were designed as a Kernel API for it, and an > userspace X11 driver, that passes a framebuffer reference to the V4L driver, > where it is used to program the DMA transfers to happen inside the > framebuffer. > > At the LDS, we had a 3-day discussions about how the buffer sharing should > be handled, and Linaro is producing a blueprint plan to address the needs. > We had also a discussion about V4L and KMS, allowing both communities to > better > understand how things are supposed to work on the other side. > > From V4L2 perspective, what is needed is to create a way to somehow allow > passing a framebuffer between two V4L2 devices and between a V4L2 device > and GPU. The V4L2 device can either be an input or an output one. > The original idea were to add yet-another-mmap-mode at the VIDIOC streaming > ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed > there, this would leed into sync issues on a shared buffer, causing flip > effects. Also, as the API is generic, it can be used also on generic > computers, > like desktops, notebooks and tablets (even on arm-based designs), and it > may end to be actually implemented as a PCI2PCI transfer. > > So, based at all I've seen, I'm pretty much convinced that the normal MMAP > way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) > are not the best way to share data with framebuffers. I agree with that, but it is a different story between two V4L2 devices. There you obviously want to use the streaming ioctls and still share buffers. > We probably need > something that it will be an enhanced version of the > VIDIOC_FBUF/VIDIOC_OVERLAY > ioctls. Unfortunately, we can't just add more stuff there, as there's no > reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. That will be useful as well to add better support for blending and Z-ordering between overlays. The old API for that is very limited in that respect. Regards, Hans > It seems to me that the proper way to develop such API is to start working > with Xorg V4L driver, changing it to work with KMS and with the new API > (probably porting some parts of the Xorg driver to kernelspace). > > One of the problems with a shared framebuffer is that an overlayed V4L stream > may, at the worse case, be sent to up to 4 different GPU's and/or displays. > > Imagine a scenario like: > > ===+=== > | | | > | D1 +|---+ D2 | > | | V4L| | | > +-|+---|--| > | || | | > | D3 ++---+ D4 | > | | | > === > > > Where D1, D2, D3 and D4 are 4 different displays, and the same V4L > framebuffer is > partially shared between them (the above is an example of a V4L input, > although > the reverse scenario of having one frame buffer divided into
Re: [PATCH 0/2] V4L: Extended crop/compose API
On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote:
> Hi Tomasz and Hans,
>
> First of all, apologies for the late reply.
>
> On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote:
> > 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/2
> > > 8945
> > >
> > > 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)
> > >
> > > Descriptio
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 18-04-2011 17:15, Jesse Barker escreveu: > One of the big issues we've been faced with at Linaro is around GPU > and multimedia device integration, in particular the memory management > requirements for supporting them on ARM. This next cycle, we'll be > focusing on driving consensus around a unified memory management > solution for embedded systems that support multiple architectures and > SoCs. This is listed as part of our working set of requirements for > the next six-month cycle (in spite of the URL, this is not being > treated as a graphics-specific topic - we also have participation from > multimedia and kernel working group folks): > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics As part of the memory management needs, Linaro organized several discussions during Linaro Development Summit (LDS), at Budapest, and invited me and other members of the V4L and DRI community to discuss about the requirements. I wish to thank Linaro for its initiative. Basically, on several SoC designs, the GPU and the CPU are integrated into the same chipset and they can share the same memory for a framebuffer. Also, they may have some IP blocks that allow processing the framebuffer internally, to do things like enhancing the image and converting it into an mpeg stream. The desire, from the SoC developers, is that those operations should be done using zero-copy transfers. This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, that was used in the old days where CPUs weren't fast enough to process video without generating a huge load on it. So the overlay mode were created to allow direct PCI2PCI transfers from the video capture board into the display adapter, using XVideo extension, and removing the overload at the CPU due to a video stream. It were designed as a Kernel API for it, and an userspace X11 driver, that passes a framebuffer reference to the V4L driver, where it is used to program the DMA transfers to happen inside the framebuffer. At the LDS, we had a 3-day discussions about how the buffer sharing should be handled, and Linaro is producing a blueprint plan to address the needs. We had also a discussion about V4L and KMS, allowing both communities to better understand how things are supposed to work on the other side. >From V4L2 perspective, what is needed is to create a way to somehow allow passing a framebuffer between two V4L2 devices and between a V4L2 device and GPU. The V4L2 device can either be an input or an output one. The original idea were to add yet-another-mmap-mode at the VIDIOC streaming ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed there, this would leed into sync issues on a shared buffer, causing flip effects. Also, as the API is generic, it can be used also on generic computers, like desktops, notebooks and tablets (even on arm-based designs), and it may end to be actually implemented as a PCI2PCI transfer. So, based at all I've seen, I'm pretty much convinced that the normal MMAP way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) are not the best way to share data with framebuffers. We probably need something that it will be an enhanced version of the VIDIOC_FBUF/VIDIOC_OVERLAY ioctls. Unfortunately, we can't just add more stuff there, as there's no reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. It seems to me that the proper way to develop such API is to start working with Xorg V4L driver, changing it to work with KMS and with the new API (probably porting some parts of the Xorg driver to kernelspace). One of the problems with a shared framebuffer is that an overlayed V4L stream may, at the worse case, be sent to up to 4 different GPU's and/or displays. Imagine a scenario like: ===+=== | | | | D1 +|---+ D2 | | | V4L| | | +-|+---|--| | || | | | D3 ++---+ D4 | | | | === Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer is partially shared between them (the above is an example of a V4L input, although the reverse scenario of having one frame buffer divided into 4 V4L outputs also seems to be possible). As the same image may be divided into 4 monitors, the buffer filling should be synced with all of them, in order to avoid flipping effects. Also, the shared buffer can't be re-used until all displays finish reading. From what I understood from the discussions with DRI people, the display API's currently has similar issues of needing to wait for a buffer to be completely used before allowing it to be re-used. According to them, this were solved there by dynamically allocating buffers. We may need t
Re: [PATCH RFC] radio-sf16fmr2: convert to generic TEA575x interface
On Saturday, May 14, 2011 00:17:23 Ondrej Zary wrote:
> Hello,
> the SF16-FMR2 radio card is basically a TEA5757 tuner connected to ISA bus but
> the driver currently uses its own implementation. I converted the driver to
> use generic tea575x-tuner implementation (see patch below) and it works fine.
Good!
> But the tea575x-tuner module is located in /sound/i2c/other and the
> corresponding Kconfig in /sound/pci. Should it be moved
> to /drivers/media/radio or better leave it as is?
Good question. It's in a weird place, but moving it may be more trouble than
it is worth. It might be a good idea to just try it and see if that improves
things or not.
> The card can optionally be equipped with PT2254A volume control (equivalent of
> TC9154AP) so I need to extend tea575x-tuner to allow adding additional V4L2
> controls (and add one if the chip is present). Is this OK or should be
> something like v4l2_subdev used somehow?
> (My card does not have the PT2254A chip so that code is untested.)
No, this isn't the right approach. This should be done using the control
framework (see Documentation/video4linux/v4l2-controls.txt).
In order to use that the tea575x-tuner driver needs to be converted to that
framework, and so should any V4L driver that uses it. It's a fair amount of
work, although it is worth doing since it will ensure that these drivers
fully and correctly implement the V4L2 control API.
Thank you for looking into this, BTW! It's been on my TODO list for a long
time but I never had time to actually work on it.
Regards,
Hans
>
>
> --- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
> 19:39:23.0 +0200
> +++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-05-14
> 00:14:23.0 +0200
> @@ -54,6 +54,11 @@ struct snd_tea575x {
> void *private_data;
> u8 card[32];
> u8 bus_info[32];
> + /* card driver can provide additional controls (e.g. volume) */
> + struct v4l2_queryctrl *extra_ctrls; /* array of controls */
> + int num_extra_ctrls;/* number of additional controls */
> + int (*g_extra_ctrl)(struct file *file, void *fh, struct v4l2_control
> *a);
> + int (*s_extra_ctrl)(struct file *file, void *fh, struct v4l2_control
> *a);
> };
>
> int snd_tea575x_init(struct snd_tea575x *tea);
> --- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
> 19:39:23.0 +0200
> +++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-05-13
> 21:35:57.0 +0200
> @@ -269,6 +269,7 @@ static int vidioc_s_audio(struct file *f
> static int vidioc_queryctrl(struct file *file, void *priv,
> struct v4l2_queryctrl *qc)
> {
> + struct snd_tea575x *tea = video_drvdata(file);
> int i;
>
> for (i = 0; i < ARRAY_SIZE(radio_qctrl); i++) {
> @@ -278,6 +279,13 @@ static int vidioc_queryctrl(struct file
> return 0;
> }
> }
> + for (i = 0; i < tea->num_extra_ctrls; i++) {
> + if (qc->id && qc->id == tea->extra_ctrls[i].id) {
> + memcpy(qc, &(tea->extra_ctrls[i]),
> + sizeof(*qc));
> + return 0;
> + }
> + }
> return -EINVAL;
> }
>
> @@ -291,6 +299,10 @@ static int vidioc_g_ctrl(struct file *fi
> ctrl->value = tea->mute;
> return 0;
> }
> +
> + if (tea->g_extra_ctrl)
> + return tea->g_extra_ctrl(file, priv, ctrl);
> +
> return -EINVAL;
> }
>
> @@ -307,6 +319,10 @@ static int vidioc_s_ctrl(struct file *fi
> }
> return 0;
> }
> +
> + if (tea->s_extra_ctrl)
> + return tea->s_extra_ctrl(file, priv, ctrl);
> +
> return -EINVAL;
> }
>
> --- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c2011-04-06
> 03:30:43.0 +0200
> +++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-14
> 00:15:05.0 +0200
> @@ -1,441 +1,206 @@
> -/* SF16FMR2 radio driver for Linux radio support
> - * heavily based on fmi driver...
> - * (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
> +/* SF16-FMR2 radio driver for Linux
> + * Copyright (c) 2011 Ondrej Zary
> *
> - * Notes on the hardware
> - *
> - * Frequency control is done digitally -- ie out(port,encodefreq(95.8));
> - * No volume control - only mute/unmute - you have to use line volume
> - *
> - * For read stereo/mono you must wait 0.1 sec after set frequency and
> - * card unmuted so I set frequency on unmute
> - * Signal handling seem to work only on autoscanning (not implemented)
> - *
> - * Converted to V4L2 API by Mauro Carvalho Chehab
> + * Original driver was (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
> + * but almost nothing remained here after conversion to generic TEA575x
> + * interface
> */
>
> +#include
> #include /* Modules */
> #include
Re: [alsa-devel] [PATCH RFC] radio-sf16fmr2: convert to generic TEA575x interface
At Sat, 14 May 2011 00:17:23 +0200, Ondrej Zary wrote: > > Hello, > the SF16-FMR2 radio card is basically a TEA5757 tuner connected to ISA bus but > the driver currently uses its own implementation. I converted the driver to > use generic tea575x-tuner implementation (see patch below) and it works fine. > > But the tea575x-tuner module is located in /sound/i2c/other and the > corresponding Kconfig in /sound/pci. Should it be moved > to /drivers/media/radio or better leave it as is? That would be a feasible option. Actually no ALSA-specific data / function is used in tea575x-tuner.c, so it'd be more natural to put it to drivers/media/radio. (And remove the inclusion of from relevant files.) thanks, Takashi -- 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: [alsa-devel] [PATCH 1/3] tea575x: remove freq_fixup from struct
At Thu, 12 May 2011 22:17:56 +0200,
Ondrej Zary wrote:
>
> freq_fixup is a constant, no need to hold it in struct snd_tea575x and set in
> each driver.
>
> Signed-off-by: Ondrej Zary
Thanks, applied all three patches.
Takashi
> --- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-10
> 22:31:40.0 +0200
> +++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-05-12
> 21:00:50.0 +0200
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#define TEA575X_FMIF 10700
> +
> #define TEA575X_DATA (1 << 0)
> #define TEA575X_CLK (1 << 1)
> #define TEA575X_WREN (1 << 2)
> @@ -46,7 +48,6 @@ struct snd_tea575x {
> bool mute; /* Device is muted? */
> bool stereo;/* receiving stereo */
> bool tuned; /* tuned to a station */
> - unsigned int freq_fixup;/* crystal onboard */
> unsigned int val; /* hw value */
> unsigned long freq; /* frequency */
> unsigned long in_use; /* set if the device is in use */
> --- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-10
> 22:31:40.0 +0200
> +++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-05-12
> 21:00:37.0 +0200
> @@ -141,9 +141,9 @@ static void snd_tea575x_get_freq(struct
> freq /= 10;
> /* crystal fixup */
> if (tea->tea5759)
> - freq += tea->freq_fixup;
> + freq += TEA575X_FMIF;
> else
> - freq -= tea->freq_fixup;
> + freq -= TEA575X_FMIF;
>
> tea->freq = freq * 16; /* from kHz */
> }
> @@ -156,9 +156,9 @@ static void snd_tea575x_set_freq(struct
> freq /= 16; /* to kHz */
> /* crystal fixup */
> if (tea->tea5759)
> - freq -= tea->freq_fixup;
> + freq -= TEA575X_FMIF;
> else
> - freq += tea->freq_fixup;
> + freq += TEA575X_FMIF;
> /* freq /= 12.5 */
> freq *= 10;
> freq /= 125;
> --- linux-2.6.39-rc2-/sound/pci/es1968.c 2011-05-10 22:31:43.0
> +0200
> +++ linux-2.6.39-rc2/sound/pci/es1968.c 2011-05-10 23:47:32.0
> +0200
> @@ -2794,7 +2794,6 @@ static int __devinit snd_es1968_create(s
>
> #ifdef CONFIG_SND_ES1968_RADIO
> chip->tea.card = card;
> - chip->tea.freq_fixup = 10700;
> chip->tea.private_data = chip;
> chip->tea.ops = &snd_es1968_tea_ops;
> if (!snd_tea575x_init(&chip->tea))
> --- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-10 23:24:39.0
> +0200
> +++ linux-2.6.39-rc2/sound/pci/fm801.c2011-05-10 23:47:43.0
> +0200
> @@ -1231,7 +1231,6 @@ static int __devinit snd_fm801_create(st
>
> #ifdef TEA575X_RADIO
> chip->tea.card = card;
> - chip->tea.freq_fixup = 10700;
> chip->tea.private_data = chip;
> chip->tea.ops = &snd_fm801_tea_ops;
> if ((tea575x_tuner & TUNER_TYPE_MASK) > 0 &&
>
>
> --
> Ondrej Zary
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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: [alsa-devel] [PATCH] fm801: clean-up radio-related Kconfig
At Fri, 13 May 2011 20:26:38 +0200,
Ondrej Zary wrote:
>
> Change the weird SND_FM801_TEA575X_BOOL define in Kconfig to SND_FM801_RADIO
> and remove TEA575X_RADIO define from fm801.c.
Well, this config is used over years, and if it's about only renaming,
it won't be worth enough.
Removing TEA575X_RADIO in fm801.c is fine, though.
thanks,
Takashi
> Also update help text to include all supported cards.
>
> Signed-off-by: Ondrej Zary
>
> --- linux-2.6.39-rc2-/sound/pci/Kconfig 2011-05-13 19:36:27.0
> +0200
> +++ linux-2.6.39-rc2/sound/pci/Kconfig2011-05-13 19:23:00.0
> +0200
> @@ -554,18 +554,18 @@ config SND_FM801
> To compile this driver as a module, choose M here: the module
> will be called snd-fm801.
>
> -config SND_FM801_TEA575X_BOOL
> +config SND_FM801_RADIO
> bool "ForteMedia FM801 + TEA5757 tuner"
> depends on SND_FM801
> depends on VIDEO_V4L2=y || VIDEO_V4L2=SND_FM801
> help
> Say Y here to include support for soundcards based on the ForteMedia
> - FM801 chip with a TEA5757 tuner connected to GPIO1-3 pins (Media
> - Forte SF256-PCS-02) into the snd-fm801 driver.
> + FM801 chip with a TEA5757 tuner (MediaForte SF256-PCS, SF256-PCP and
> + SF64-PCR) into the snd-fm801 driver.
>
> config SND_TEA575X
> tristate
> - depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO
> + depends on SND_FM801_RADIO || SND_ES1968_RADIO
> default SND_FM801 || SND_ES1968
>
> source "sound/pci/hda/Kconfig"
> --- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-13 19:39:23.0
> +0200
> +++ linux-2.6.39-rc2/sound/pci/fm801.c2011-05-13 19:22:20.0
> +0200
> @@ -36,9 +36,8 @@
>
> #include
>
> -#ifdef CONFIG_SND_FM801_TEA575X_BOOL
> +#ifdef CONFIG_SND_FM801_RADIO
> #include
> -#define TEA575X_RADIO 1
> #endif
>
> MODULE_AUTHOR("Jaroslav Kysela ");
> @@ -196,7 +195,7 @@ struct fm801 {
> spinlock_t reg_lock;
> struct snd_info_entry *proc_entry;
>
> -#ifdef TEA575X_RADIO
> +#ifdef CONFIG_SND_FM801_RADIO
> struct snd_tea575x tea;
> #endif
>
> @@ -715,7 +714,7 @@ static int __devinit snd_fm801_pcm(struc
> * TEA5757 radio
> */
>
> -#ifdef TEA575X_RADIO
> +#ifdef CONFIG_SND_FM801_RADIO
>
> /* GPIO to TEA575x maps */
> struct snd_fm801_tea575x_gpio {
> @@ -1150,7 +1149,7 @@ static int snd_fm801_free(struct fm801 *
> outw(cmdw, FM801_REG(chip, IRQ_MASK));
>
>__end_hw:
> -#ifdef TEA575X_RADIO
> +#ifdef CONFIG_SND_FM801_RADIO
> snd_tea575x_exit(&chip->tea);
> #endif
> if (chip->irq >= 0)
> @@ -1229,7 +1228,7 @@ static int __devinit snd_fm801_create(st
>
> snd_card_set_dev(card, &pci->dev);
>
> -#ifdef TEA575X_RADIO
> +#ifdef CONFIG_SND_FM801_RADIO
> chip->tea.private_data = chip;
> chip->tea.ops = &snd_fm801_tea_ops;
> sprintf(chip->tea.bus_info, "PCI:%s", pci_name(pci));
>
>
> --
> Ondrej Zary
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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
