date:20100607

On Mon, Jun 7, 2010 at 9:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 07-06-2010 08:27, v...@helmutauer.de escreveu:
...
 Another problem (after fixing the compile issues) is the IR Part of v4l-dvb 
 which includes an Imon module.
 This module doesn't provide any lirc devices, so how can this oe be used as 
 an IR device ?

 You don't need lirc to use imon, since it now provides a standard input/event 
 interface. So, the driver
 currently can be used with lirc event interface, or alone.

See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the
config I use w/my own imon hardware.

 Til now I am using lirc_imon which fit all my needs.

 Lirc-dev patches are currently being discussed. There are just a few 
 adjustments on it, in order to get it
 finally merged. The kernel-userspace interface will likely need a few 
 changes, so you'll likely need to update
 lirc after the merge. Better to follow the IR threads at linux-media ML, in 
 order to be in-tune with the changes.

I've considered adding lirc_dev support back to the imon driver when
we get it merged, but it really doesn't make a whole lot of sense,
given that the imon devices do all IR decoding in hardware. As long as
the keymap is complete, there's no benefit to wiring up lirc_dev vs.
just using lircd's devinput access method for imon devices.


-- 
Jarod Wilson
ja...@wilsonet.com
--
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: linuxtv.org Wiki pages not found by Google

2010-06-07 Thread Samuel Rakitničan

On Mon, 07 Jun 2010 09:07:24 +0200, Jan-Pascal van Best  
janpas...@vanbest.org wrote:



Hi all,

Not sure if this is the right list, but here it goes: Google does not  
seem

to find pages in the linuxtv.org wiki. Nor does any of the other search


Hi,

I'm not an expert, but I read somewhere that's happening because there's  
to many subbranches. If there's more than tree search engines will not  
look for pages behind it.


I know one site that dealed with it by removing index.php from the wiki  
path and that way allowing search engine to find the pages.



Best regards,
Samuel
--
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: kernel oops with TT S2-3200

Am 23.05.2010 01:15, schrieb dave cunningham:
 I'm running debian testing on an AMD Sempron box, kernel 2.6.32-3amd64, 
 with a TT S2-3200.
 
 I've been setting the box up as a Myth TV backend.
 
 The stock kernel drivers for the S2-3200 appear to work (to the extent 
 that I was able to scan for channels in Myth TV) however I was getting 
 errors during channel scan (fec_inner not supported in the mythtv log) 
 so I updated to v4l-dvb tip to see if this error disappeared.
 
 I now get a kernel oops on loading budget_ci as below.
 
 This is changeset 14873:b576509ea6d2.
 
 I see on the wiki that there is an hg bisect utility that I can use to 
 narrow down where this has been introduced. Would it be useful I do so?
 
 Would any more information be useful?
 
 
 May 22 23:19:31 beta kernel: [   98.394646] IR NEC protocol handler 
 initialized
 May 22 23:19:31 beta kernel: [   98.394857] saa7146: register extension 
 'budget_ci dvb'.
 May 22 23:19:31 beta kernel: [   98.394966] budget_ci dvb :04:05.0: PCI 
 INT A - GSI 20 (level, low) - IRQ 20
 May 22 23:19:31 beta kernel: [   98.395020] IRQ 20/: IRQF_DISABLED is not 
 guaranteed on shared IRQs
 May 22 23:19:31 beta kernel: [   98.395055] saa7146: found saa7146 @ mem 
 c900116f8c00 (revision 1, irq 20) (0x13c2,0x1019).
 May 22 23:19:31 beta kernel: [   98.395069] saa7146 (0): dma buffer size 
 192512
 May 22 23:19:31 beta kernel: [   98.395074] DVB: registering new adapter 
 (TT-Budget S2-3200 PCI)
 May 22 23:19:31 beta kernel: [   98.399843] IR RC5(x) protocol handler 
 initialized
 May 22 23:19:31 beta kernel: [   98.404301] IR RC6 protocol handler 
 initialized
 May 22 23:19:31 beta kernel: [   98.408724] IR JVC protocol handler 
 initialized
 May 22 23:19:31 beta kernel: [   98.413024] IR Sony protocol handler 
 initialized
 May 22 23:19:31 beta kernel: [   98.429164] adapter has MAC addr = 
 00:d0:5c:68:2c:ca
 May 22 23:19:31 beta kernel: [   98.468015] Registered IR keymap 
 rc-budget-ci-old
 May 22 23:19:31 beta kernel: [   98.468261] PGD 0
 May 22 23:19:31 beta kernel: [   98.468479] CPU 0
 May 22 23:19:31 beta kernel: [   98.468549] Modules linked in: 
 rc_budget_ci_old ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder
 ir_nec_decoder budget_ci(+) ir_core budget_core ttpci_eeprom dvb_core saa7146 
 cryptd aes_x86_64 aes_generic xt_mac xt_TCPMSS xt_tcpudp ipt_LOG
 iptable_raw xt_conntrack xt_comment iptable_nat nf_nat xt_MARK ipt_REJECT 
 ipt_addrtype xt_multiport iptable_mangle nf_conntrack_ipv4
 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables fuse 
 nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc pppoatm
 ppp_generic slhc powernow_k8 it87 hwmon_vid loop arc4 ecb ath9k ath9k_common 
 mac80211 ath9k_hw ath snd_hda_codec_realtek amd64_edac_mod shpchp
 cfg80211 i2c_piix4 edac_core k10temp edac_mce_amd i2c_core pci_hotplug rfkill 
 snd_hda_intel parport_pc led_class snd_hda_codec snd_hwdep
 snd_pcm_oss snd_mixer_oss snd_pcm evdev parport snd_timer snd soundcore 
 snd_page_alloc speedtch usbatm pcspkr atm psmouse processor serio_raw
 ext3 jbd mbcache fan ide_gd_mod ata_generic
 May 22 23:19:31 beta kernel: ohci_hcd ide_pci_generic ahci libata atiixp 
 button thermal thermal_sys r8169 mii ehci_hcd scsi_mod ide_core usbcore
 nls_base [last unloaded: scsi_wait_scan]
 May 22 23:19:31 beta kernel: [   98.472002] Pid: 2746, comm: work_for_cpu Not 
 tainted 2.6.32-3-amd64 #1 A760G M2+
 May 22 23:19:31 beta kernel: [   98.472002] RIP: 0010:[a068db7e]  
 [a068db7e] ir_register_class+0x4d/0x18f [ir_core]
 May 22 23:19:31 beta kernel: [   98.472002] RSP: 0018:88007cf67db0  
 EFLAGS: 00010246
 May 22 23:19:31 beta kernel: [   98.472002] RAX:  RBX: 
 88007c1a5400 RCX: a068ee60
 May 22 23:19:31 beta kernel: [   98.472002] RDX:  RSI: 
 a068e94a RDI: 88007c1a5400
 May 22 23:19:31 beta kernel: [   98.472002] RBP:  R08: 
  R09: 0073
 May 22 23:19:31 beta kernel: [   98.472002] R10:  R11: 
 00dc R12: a06c0060
 May 22 23:19:31 beta kernel: [   98.472002] R13: 88007cf4c000 R14: 
 0286 R15: a0698ed3
 May 22 23:19:31 beta kernel: [   98.472002] FS:  7f498d78c6f0() 
 GS:88000180() knlGS:
 May 22 23:19:31 beta kernel: [   98.472002] CS:  0010 DS: 0018 ES: 0018 CR0: 
 8005003b
 May 22 23:19:31 beta kernel: [   98.472002] CR2:  CR3: 
 01001000 CR4: 06f0
 May 22 23:19:31 beta kernel: [   98.472002] DR0:  DR1: 
  DR2: 
 May 22 23:19:31 beta kernel: [   98.472002] DR3:  DR6: 
 0ff0 DR7: 0400
 May 22 23:19:31 beta kernel: [   98.472002] Process work_for_cpu (pid: 2746, 
 threadinfo 88007cf66000, task 88007b67cdb0)
 May 22 23:19:31 beta kernel: [   98.472002]  88007c1a5400

Re: Kernel oops with current hg (ir-sysfs.c ?)

Am 24.05.2010 17:26, schrieb Martin Dauskardt:
 I guess it is a similar problem like the one that was solved a few months ago 
 with this patch:
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14232
 
 I compiled the current v4l-dvb hg against the 2.6.32 Ubuntu 10.04 kernel
 
 
 May 24 13:30:22 ubuntuvdr1 kernel: [5.629408] DVB: registering new 
 adapter (TT-Budget C-1501 PCI)
 May 24 13:30:22 ubuntuvdr1 kernel: [5.646949] tda9887 3-0043: i2c i/o 
 error: rc == -5 (should be 4)
 May 24 13:30:22 ubuntuvdr1 kernel: [5.649823] tda9887 3-0043: i2c i/o 
 error: rc == -5 (should be 4)
 May 24 13:30:22 ubuntuvdr1 kernel: [5.666028] adapter has MAC addr = 
 00:d0:5c:c6:5a:11
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692518] Registered IR keymap 
 rc-tt-1500
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692545] BUG: unable to handle 
 kernel NULL pointer dereference at (null)
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692554] IP: [f825bd7e] 
 ir_register_class+0x3e/0x190 [ir_core]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692566] *pde = 
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692571] Oops:  [#1] SMP
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692575] last sysfs file: 
 /sys/module/ir_core/initstate
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692580] Modules linked in: 
 rc_tt_1500 tda10021 snd_hda_codec_realtek tuner_simple tuner_types tda9887 
 tda8290 tuner msp3400 snd_hda_intel$
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692659]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692663] Pid: 375, comm: modprobe 
 Not tainted (2.6.32-22-generic #33-Ubuntu) M56S-S3
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692669] EIP: 0060:[f825bd7e] 
 EFLAGS: 00010246 CPU: 0
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692677] EIP is at 
 ir_register_class+0x3e/0x190 [ir_core]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692681] EAX:  EBX: f6375000 
 ECX:  EDX: 0100
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692686] ESI: f4fa6000 EDI:  
 EBP: f61d5d78 ESP: f61d5d4c
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692691]  DS: 007b ES: 007b FS: 00d8 
 GS: 00e0 SS: 0068
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692697] Process modprobe (pid: 375, 
 ti=f61d4000 task=f61b6680 task.ti=f61d4000)
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692704] Stack:
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692707]  0246 f825ba47 c24054e0 
 f825ba47 001d5d64 0128 f4fa6000 003f
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692717] 0 faee9068 0027 
 f4fa6000 f61d5db0 f825bb7c 009f  f8ce32ef
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692728] 0 c0588f82 f825cc11 
 0296 f637513c f6375120 f6375000 f6827000 f4fa6000
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692741] Call Trace:
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692750]  [f825ba47] ? 
 __ir_input_register+0x167/0x350 [ir_core]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692759]  [f825ba47] ? 
 __ir_input_register+0x167/0x350 [ir_core]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692769]  [f825bb7c] ? 
 __ir_input_register+0x29c/0x350 [ir_core]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692779]  [c0588f82] ? 
 printk+0x1d/0x23
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692789]  [f8ce1153] ? 
 budget_ci_attach+0x193/0xd80 [budget_ci]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692800]  [f81ffeac] ? 
 saa7146_init_one+0x7dc/0x860 [saa7146]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692811]  [c01078d0] ? 
 dma_generic_alloc_coherent+0x0/0xc0
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692821]  [c0363883] ? 
 local_pci_probe+0x13/0x20
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692827]  [c0364688] ? 
 pci_device_probe+0x68/0x90
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692835]  [c03e688d] ? 
 really_probe+0x4d/0x140
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692843]  [c03ed19e] ? 
 pm_runtime_barrier+0x4e/0xc0
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692850]  [c03e69bc] ? 
 driver_probe_device+0x3c/0x60
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692857]  [c03e6a61] ? 
 __driver_attach+0x81/0x90
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692864]  [c03e5ea3] ? 
 bus_for_each_dev+0x53/0x80
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692871]  [c03e675e] ? 
 driver_attach+0x1e/0x20
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692877]  [c03e69e0] ? 
 __driver_attach+0x0/0x90
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692884]  [c03e6125] ? 
 bus_add_driver+0xd5/0x280
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692890]  [c03645c0] ? 
 pci_device_remove+0x0/0x40
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692897]  [c03e6d5a] ? 
 driver_register+0x6a/0x130
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692903]  [c03648c5] ? 
 __pci_register_driver+0x45/0xb0
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692913]  [f81fed63] ? 
 saa7146_register_extension+0x53/0x90 [saa7146]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692923]  [f8ce700d] ? 
 budget_ci_init+0xd/0xf [budget_ci]
 May 24 13:30:22 ubuntuvdr1 kernel: [5.692929]

RE: Version 2: Tentative agenda for Helsinki mini-summit

2010-06-07 Thread Hiremath, Vaibhav

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Monday, June 07, 2010 3:20 PM
 To: Guennadi Liakhovetski
 Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org
 Subject: RE: Version 2: Tentative agenda for Helsinki mini-summit

  On Mon, 7 Jun 2010, Hiremath, Vaibhav wrote:

   14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski.

  [Hiremath, Vaibhav] Guennadi,

  Do you have anything in your mind on this? Are you preparing any slides
  for this? Do you want me to have something from OMAP side which we can
  use as a use-case?

  Yes, I will prepare some introduction, maybe a couple of slides. My
  impression is, that we shall be making all topics as short as possible,
  so, I'll try to make it concise, but I don't know exactly yet how much
  time we'd get.

 Concise would be good: the first day will be packed, so I prefer to have
 short presentations, and a QA session afterwards in case there are things
 that need clarification. But I think that on Tuesday we can talk a lot
 more about this. I think this is a very relevant issue for embedded
 systems.

  I can make couple of slides on this.

  In principle - yes, sure, I'd love you to present your use-case, but as I
  said - no idea whether we'll have time for this. So, definitely, would be
  great if you could comment on the topic, if we get time, slides would be
  great too, so, if it's not too complicated for you - please prepare them,
  but unfortunately I do not know yet whether we'll get a chance to go
  through them. In fact, I'm not quite sure how topics without an explicitly
  mentioned presentation should work - there would be some introduction in
  any case, right, Hans? Just not as long as a proper presentation? And
  the mentioned 10 minutes are only for the presentation, the discussion
  comes on top of that? So, I think, we should have time for your slides,
  Vaibhav, Hans can correct me if I'm wrong;)

 For simple topics a presentation is overkill and you can just say what the
 status and/or plan is. For more complex issues a presentation helps to
 understand the problems quicker. And yes, the discussion comes on top of
 the presentation.

 The reason I want to keep the presentations short on Monday is that we
 have some 15 topics or so to go through in, say, 7 hours. And of those 7
 hours one to two hours are reserved for anything to do with memory
 handling. That does not leave a lot of time for the other 14 topics.

 Now, remember that on Tuesday and to a lesser extent on Wednesday we will
 have more time to discuss some of these topics in more depth. And this
 topic is one that deserves to be discussed more extensively. It would be
 interesting to hear the views of several of the companies that have to
 work with the framebuffer API: what are their experiences, ideas on how to
 improve it, building a fb driver on top of a v4l driver, etc.

[Hiremath, Vaibhav] I completely aligned with this, I will prepare the slides 
and if we have time and need for this we can talk about it. Also I will have to 
prepare couple of slide presenting current status of OMAP drivers (for me it is 
Display Driver), should be re-used here.

Thanks,
Vaibhav

 Regards,

 Hans

--
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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-06-07 Thread Hans Verkuil

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:Mon Jun  7 19:00:23 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14886:24ea80f2631f
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: WARNINGS
linux-2.6.35-rc1-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: ERRORS
linux-2.6.33-armv5-davinci: ERRORS
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35-rc1-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: ERRORS
linux-2.6.33-armv5-ixp: ERRORS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35-rc1-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: ERRORS
linux-2.6.33-armv5-omap2: ERRORS
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.20-i686: ERRORS
linux-2.6.26.8-i686: ERRORS
linux-2.6.27.44-i686: ERRORS
linux-2.6.28.10-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30.10-i686: ERRORS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: WARNINGS
linux-2.6.35-rc1-i686: ERRORS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35-rc1-m32r: ERRORS
linux-2.6.32.6-mips: ERRORS
linux-2.6.33-mips: ERRORS
linux-2.6.34-mips: WARNINGS
linux-2.6.35-rc1-mips: ERRORS
linux-2.6.32.6-powerpc64: ERRORS
linux-2.6.33-powerpc64: ERRORS
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.17-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.20-x86_64: ERRORS
linux-2.6.26.8-x86_64: ERRORS
linux-2.6.27.44-x86_64: ERRORS
linux-2.6.28.10-x86_64: ERRORS
linux-2.6.29.1-x86_64: ERRORS
linux-2.6.30.10-x86_64: ERRORS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35-rc1-x86_64: ERRORS
linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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: [PATCH 1/3] IR: add core lirc device interface

On Fri, Jun 04, 2010 at 03:38:35PM -0300, Mauro Carvalho Chehab wrote:
 Em 04-06-2010 12:51, Christoph Bartelmus escreveu:
  Hi Mauro,
  
  on 04 Jun 10 at 01:10, Mauro Carvalho Chehab wrote:
  Em 03-06-2010 19:06, Jarod Wilson escreveu:
  [...]
  As for the compat bits... I actually pulled them out of the Fedora kernel
  and userspace for a while, and there were only a few people who really ran
  into issues with it, but I think if the new userspace and kernel are 
  rolled
  out at the same time in a new distro release (i.e., Fedora 14, in our
  particular case), it should be mostly transparent to users.
  
  For sure this will happen on all distros that follows upstream: they'll
  update lirc to fulfill the minimal requirement at Documentation/Changes.
 
  The issue will appear only to people that manually compile kernel and lirc.
  Those users are likely smart enough to upgrade to a newer lirc version if
  they notice a trouble, and to check at the forums.
  
  Christoph
  wasn't a fan of the change, and actually asked me to revert it, so I'm
  cc'ing him here for further feedback, but I'm inclined to say that if this
  is the price we pay to get upstream, so be it.
  
  I understand Christoph view, but I think that having to deal with compat
  stuff forever is a high price to pay, as the impact of this change is
  transitory and shouldn't be hard to deal with.
  
  I'm not against doing this change, but it has to be coordinated between  
  drivers and user-space.
  Just changing lirc.h is not enough. You also have to change all user-space  
  applications that use the affected ioctls to use the correct types.
  That's what Jarod did not address last time so I asked him to revert the  
  change.
 
 For sure coordination between kernel and userspace is very important. I'm sure
 that Jarod can help with this sync. Also, after having the changes implemented
 on userspace, I expect one patch from you adding the minimal lirc requirement 
 at Documentation/Changes.
 
  And I'd also like to collect all other change request to the API  
  if there are any and do all changes in one go.
 
 You and Jarod are the most indicated people to point for such needs. Also, Jon
 and David may have some comments.

David (who has been absent, sorry about that, life got in the way) 
thinks that the lirc raw decoder should implement the minimum amount of 
ioctl's possible while still being usable by the lirc userspace and 
without going beyond being a raw pulse/space decoder or we'll risk 
having to extend the entire decoder API just to support the lirc 
compatability decoder.

Over time, I hope that rc-core will grow it's own chardev with a clean 
set of ioctls (or sysfs controls, the jury hasn't returned a verdict 
yet). lircd can then be upgraded to support both the in-kernel native 
mode and the legacy lirc mode, and with time, the lirc raw decoder can 
be phased out.


-- 
David Härdeman
--
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 2/4] ir-core: centralize sysfs raw decoder enabling/disabling

On Mon, May 03, 2010 at 04:49:20PM -0300, Mauro Carvalho Chehab wrote:
 Hi David,

Hi, sorry for dropping off the radar...life has been hetic...daughter in 
hospital (she's fine now).

 David Härdeman wrote:
  With the current logic, each raw decoder needs to add a copy of the exact
  same sysfs code. This is both unnecessary and also means that (re)loading
  an IR driver after raw decoder modules have been loaded won't work as
  expected.
  
  This patch moves that logic into ir-raw-event and adds a single sysfs
  file per device.
  
  Reading that file returns something like:
  
  rc5 [rc6] nec jvc [sony]
  
  (with enabled protocols in [] brackets)
  
  Writing either +protocol or -protocol to that file will
  enable or disable the according protocol decoder.
  
  An additional benefit is that the disabling of a decoder will be
  remembered across module removal/insertion so a previously
  disabled decoder won't suddenly be activated again. The default
  setting is to enable all decoders.
  
  This is also necessary for the next patch which moves even more decoder
  state into the central raw decoding structs.
 
 I liked the idea of your redesign, but I didn't like the removal of
 a per-decoder sysfs entry. As already discussed, there are cases where
 we'll need a per-decoder sysfs entry (lirc_dev is probably one of those
 cases - also Jarod's imon driver is currently implementing a modprobe
 parameter that needs to be moved to the driver).

per-decoder or per-decoder-per-receiver sysfs entries? If you want the 
latter, you'll need much more code than what is currently there to not 
break random module load order (which doesn't work with the current 
code).  Additionally, *if* imon and lirc_dev really need something like 
that, those modules should carry the burden.
 
 So, while we can implement some core support at the raw event core, we should
 keep the decoder attributes internally inside the driver.

Why?

 So, each decoder
 may have his own code like:
 
 static struct attribute *decoder_attributes[] = {
dev_attr_enabled.attr,
dev_attr_bar1.attr,
dev_attr_bar2.attr,
dev_attr_bar3.attr,
NULL
 };
 
 static struct attribute_group decoder_attribute_group = {
.name   = foo_decoder,
.attrs  = decoder_attributes,
 };
 
 As the attr_enabled is common to all, maybe we can have a default enable
 code at the .h or inside the core.

Smells like lots of duplicated code with no gain for the current set of 
decoders.


-- 
David Härdeman
--
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/4] ir-core: move decoding state to ir_raw_event_ctrl

On Mon, May 03, 2010 at 05:00:05PM -0300, Mauro Carvalho Chehab wrote:
 David Härdeman wrote:
  This patch moves the state from each raw decoder into the
  ir_raw_event_ctrl struct.
  
  This allows the removal of code like this:
  
  spin_lock(decoder_lock);
  list_for_each_entry(data, decoder_list, list) {
  if (data-ir_dev == ir_dev)
  break;
  }
  spin_unlock(decoder_lock);
  return data;
  
  which is currently run for each decoder on each event in order
  to get the client-specific decoding state data.
  
  In addition, ir decoding modules and ir driver module load
  order is now independent. Centralizing the data also allows
  for a nice code reduction of about 30% per raw decoder as
  client lists and client registration callbacks are no longer
  necessary.
 
 The registration callbacks will likely still be needed by lirc,
 as you need to create/delete lirc_dev interfaces, when the module
 is registered, but I might be wrong. It would be interesting to
 add lirc_dev first, in order to be sure about the better interfaces
 for it.

Or the lirc_dev patch can add whatever interfaces it needs. Anyway, the 
current interfaces are not good enough since it'll break if lirc_dev is 
loaded after the hardware modules.

 Also, from one side, you reduced the code size, but, on the other hand,
 you've increased the memory usage, as now the protocol data will be
 stored even for protocols that weren't compiled/loaded. 

In 4bbf3309.6020...@infradead.org, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
 Encoding pulse vs space with a negative sign, even if now hidden 
 with macros, is still just using a sign instead of a boolean.  
 Memory in modern computers (and now microcontrollers) is cheap and 
 only getting cheaper.  Don't give up readability, flexibility, or 
 mainatainability, for the sake of saving memory.

 That was my point since the beginning: the amount of saved memory 
 doesn't justify the lack of readability.

Are you worried about memory usage now?

 Probably, the code size savings are big enough to justify the runtime 
 memory footprint, at least with the current decoders. Not sure how big 
 this will become when we add lirc_dev and other decoders that might be 
 missing.

Right now, the reasonable default is a user machine with one hardware 
decoder and with all of the rc-core decoders loaded (cause that's how 
his/her distro will set it up).  For that machine, the patch will save a 
lot of memory, not waste it (~380 lines less code...I'll assure you it's 
a net gain).

In addition, random module load order is currently broken (try loading 
decoders first and hardware later and you'll see).  With this patch, it 
works again.

Anyway, I'll post a new patch series this evening and then we can go 
back to our regular arguing :)

-- 
David Härdeman
--
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: tm6000 audio buffer

2010-06-07 Thread Stefan Ringel

Am 06.06.2010 17:19, schrieb Mauro Carvalho Chehab:
 Hi Luis,

 Em 04-06-2010 16:39, Luis Henrique Fagundes escreveu:
   
 Hi,

 I'm sending a patch that hypothetically would allocate a memory buffer
 for the audio and copy the data from urb to buffer. It doesn't work,
 so I'm not putting a [PATCH] in subject and send it just for feedback.
 Am I going on the right way of implementing this? The patch was made
 against the mercurial version at http://linuxtv.org/hg/v4l-dvb.

 I can see the audio packets at tm6000-video.c. Mauro said that the urb
 audio packets had just 4 bytes of relevant data, 2 for each channel,
 but the audio buffer has 128Kb and I see too few packets. Anyway, the
 tm6000_audio_isocirq function receives the size of the packet and now
 is copying everything to the buffer, I guess next step will be to find
 what is relevant in this stream and make sure I have all packets here.

 I haven't applied all the recent patches from Stefan yet.
 
 I found some time to fix several bugs at the alsa driver, and to properly
 add a function to copy the audio data into the buffers. It seems to be
 working, but I found the same problem as you: the number of packages is
 incredibly small. So, or the audio is not properly programmed on the
 device or the routine that decodes the URB packages are wrong. Yet, if you
 wait for enough time (several minutes), with for example:
   $ arecord -D hw:1,0 -r 48000 -c 2 -f S16_LE -M

   
Mauro, if I recorded I have this log with mencoder:

Not enough audio samples!

Error reading audio: Broken pipe
ALSA xrun!!! (at least 1275923299492.352 ms long)
ALSA Status:
  state   : XRUN
  trigger_time: 13520.253382890
  tstamp  : 13520.253544610
  delay   : 0
  avail   : 77920
  avail_max   : 77920

 You'll see some random data at stdout. So, the alsa code seems to be ok.

 As I'm preparing to travel to V4L mini-summit, I doubt I would have any
 time to touch on the code during the next weeks, but maybe one of you
 may find some time to fix.

 I suggest to use some USB traffic analyzer to see what is happening, 
 comparing the results on Linux and with the original driver, using the 
 same source (for example, you may use one test signal with some audio 
 buzz inside).

 As reference for you, I'm enclosing a patch that adds some additional debug
 code at copy_streams(), plus a trial I did, in order to play with some bits
 related to audio, but it didn't help.

 All the patches are at staging/tm6000 branch, on my tree.

 Cheers,
 Mauro.


 diff --git a/drivers/staging/tm6000/tm6000-alsa.c 
 b/drivers/staging/tm6000/tm6000-alsa.c
 index d31b525..aa38577 100644
 --- a/drivers/staging/tm6000/tm6000-alsa.c
 +++ b/drivers/staging/tm6000/tm6000-alsa.c
 @@ -84,6 +84,8 @@ static int _tm6000_start_audio_dma(struct snd_tm6000_card 
 *chip)
   val |= 0x20;
   tm6000_set_reg(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, val);
  
 + tm6000_set_audio_bitrate(core, 48000);
 +
   tm6000_set_reg(core, TM6010_REQ08_R01_A_INIT, 0x80);
  
   return 0;
 diff --git a/drivers/staging/tm6000/tm6000-core.c 
 b/drivers/staging/tm6000/tm6000-core.c
 index 46b9ec5..1fea5a0 100644
 --- a/drivers/staging/tm6000/tm6000-core.c
 +++ b/drivers/staging/tm6000/tm6000-core.c
 @@ -602,8 +602,17 @@ int tm6000_set_audio_bitrate(struct tm6000_core *dev, 
 int bitrate)
  {
   int val;
  
 + if (dev-dev_type == TM6010) {
 + val = tm6000_get_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, 0);
 + if (val  0)
 + return val;
 + val = (val  0xf0) | 0x1;
 + val = tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, val);
 + if (val  0)
 + return val;
 + }
 +
   val = tm6000_get_reg(dev, REQ_07_SET_GET_AVREG, 0xeb, 0x0);
 - printk(Original value=%d\n, val);
   if (val  0)
   return val;
  
 diff --git a/drivers/staging/tm6000/tm6000-video.c 
 b/drivers/staging/tm6000/tm6000-video.c
 index 34e8ef5..cc4298e 100644
 --- a/drivers/staging/tm6000/tm6000-video.c
 +++ b/drivers/staging/tm6000/tm6000-video.c
 @@ -303,6 +304,15 @@ static int copy_streams(u8 *data, unsigned long len,
   break;
   case TM6000_URB_MSG_AUDIO:
   tm6000_call_fillbuf(dev, TM6000_AUDIO, ptr, 
 cpysize);
 +if (cpysize  pktsize) {
 +printk(Audio[%d] = %02x %02x %02x %02x\n,
 +cpysize,
 +ptr[cpysize],
 +ptr[cpysize+1],
 +ptr[cpysize+2],
 +ptr[cpysize+3]);
 +}
 +
   break;
   case TM6000_URB_MSG_VBI:
   /* Need some code to copy vbi buffer */

 --
 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
   


-- 
Stefan Ringel stefan.rin...@arcor.de

attachment: stefan_ringel.vcf

[PATCH 0/8] rc-core cleanups

The following series is my current patch queue.

The first five patches remove some of the ir-functions.c legacy from hardware
drivers (sadly I don't have the hardware so I can only compile test the
resulting code).

The next two patches are the same sysfs centralization patches I've sent before
(see discussion in that thread).

The last patch merges the two main rc-core (ir-core) headers, which helps
readability for me at least...

Net result - 900 lines less code.

---

David Härdeman (8):
  ir-core: convert mantis to not use ir-functions.c
  ir-core: convert em28xx to not use ir-functions.c
  ir-core: partially convert cx88 to not use ir-functions.c
  ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c
  ir-core: partially convert bt8xx to not use ir-functions.c
  ir-core: centralize sysfs raw decoder enabling/disabling
  ir-core: move decoding state to ir_raw_event_ctrl
  ir-core: merge rc-map.h into ir-core.h


 drivers/media/IR/ir-core-priv.h|   40 +++
 drivers/media/IR/ir-functions.c|   89 ---
 drivers/media/IR/ir-jvc-decoder.c  |  152 +---
 drivers/media/IR/ir-nec-decoder.c  |  151 +---
 drivers/media/IR/ir-raw-event.c|  136 +--
 drivers/media/IR/ir-rc5-decoder.c  |  165 +
 drivers/media/IR/ir-rc6-decoder.c  |  154 +---
 drivers/media/IR/ir-sony-decoder.c |  155 +---
 drivers/media/IR/ir-sysfs.c|  252 
 drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c|2 
 drivers/media/IR/keymaps/rc-apac-viewcomp.c|2 
 drivers/media/IR/keymaps/rc-asus-pc39.c|2 
 drivers/media/IR/keymaps/rc-ati-tv-wonder-hd-600.c |2 
 drivers/media/IR/keymaps/rc-avermedia-a16d.c   |2 
 drivers/media/IR/keymaps/rc-avermedia-cardbus.c|2 
 drivers/media/IR/keymaps/rc-avermedia-dvbt.c   |2 
 .../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c|2 
 drivers/media/IR/keymaps/rc-avermedia.c|2 
 drivers/media/IR/keymaps/rc-avertv-303.c   |2 
 drivers/media/IR/keymaps/rc-behold-columbus.c  |2 
 drivers/media/IR/keymaps/rc-behold.c   |2 
 drivers/media/IR/keymaps/rc-budget-ci-old.c|2 
 drivers/media/IR/keymaps/rc-cinergy-1400.c |2 
 drivers/media/IR/keymaps/rc-cinergy.c  |2 
 drivers/media/IR/keymaps/rc-dm1105-nec.c   |2 
 drivers/media/IR/keymaps/rc-dntv-live-dvb-t.c  |2 
 drivers/media/IR/keymaps/rc-dntv-live-dvbt-pro.c   |2 
 drivers/media/IR/keymaps/rc-em-terratec.c  |2 
 drivers/media/IR/keymaps/rc-empty.c|2 
 drivers/media/IR/keymaps/rc-encore-enltv-fm53.c|2 
 drivers/media/IR/keymaps/rc-encore-enltv.c |2 
 drivers/media/IR/keymaps/rc-encore-enltv2.c|2 
 drivers/media/IR/keymaps/rc-evga-indtube.c |2 
 drivers/media/IR/keymaps/rc-eztv.c |2 
 drivers/media/IR/keymaps/rc-flydvb.c   |2 
 drivers/media/IR/keymaps/rc-flyvideo.c |2 
 drivers/media/IR/keymaps/rc-fusionhdtv-mce.c   |2 
 drivers/media/IR/keymaps/rc-gadmei-rm008z.c|2 
 drivers/media/IR/keymaps/rc-genius-tvgo-a11mce.c   |2 
 drivers/media/IR/keymaps/rc-gotview7135.c  |2 
 drivers/media/IR/keymaps/rc-hauppauge-new.c|2 
 drivers/media/IR/keymaps/rc-imon-mce.c |2 
 drivers/media/IR/keymaps/rc-imon-pad.c |2 
 drivers/media/IR/keymaps/rc-iodata-bctv7e.c|2 
 drivers/media/IR/keymaps/rc-kaiomy.c   |2 
 drivers/media/IR/keymaps/rc-kworld-315u.c  |2 
 .../media/IR/keymaps/rc-kworld-plus-tv-analog.c|2 
 drivers/media/IR/keymaps/rc-manli.c|2 
 drivers/media/IR/keymaps/rc-msi-tvanywhere-plus.c  |2 
 drivers/media/IR/keymaps/rc-msi-tvanywhere.c   |2 
 drivers/media/IR/keymaps/rc-nebula.c   |2 
 .../media/IR/keymaps/rc-nec-terratec-cinergy-xs.c  |2 
 drivers/media/IR/keymaps/rc-norwood.c  |2 
 drivers/media/IR/keymaps/rc-npgtech.c  |2 
 drivers/media/IR/keymaps/rc-pctv-sedna.c   |2 
 drivers/media/IR/keymaps/rc-pinnacle-color.c   |2 
 drivers/media/IR/keymaps/rc-pinnacle-grey.c|2 
 drivers/media/IR/keymaps/rc-pinnacle-pctv-hd.c |2 
 drivers/media/IR/keymaps/rc-pixelview-mk12.c   |2 
 drivers/media/IR/keymaps/rc-pixelview-new.c|2 
 drivers/media/IR/keymaps/rc-pixelview.c|2 
 .../media/IR/keymaps/rc-powercolor-real-angel.c|2 
 drivers/media/IR/keymaps/rc-proteus-2309.c |2 
 drivers/media/IR/keymaps/rc-purpletv.c |2 
 drivers/media/IR/keymaps/rc-pv951.c|2

[PATCH 1/8] ir-core: convert mantis to not use ir-functions.c

Convert drivers/media/dvb/mantis/mantis_input.c to not use ir-functions.c

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/dvb/mantis/mantis_input.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/mantis/mantis_input.c 
b/drivers/media/dvb/mantis/mantis_input.c
index 3d4e466..a99489b 100644
--- a/drivers/media/dvb/mantis/mantis_input.c
+++ b/drivers/media/dvb/mantis/mantis_input.c
@@ -19,7 +19,7 @@
 */
 
 #include linux/input.h
-#include media/ir-common.h
+#include media/ir-core.h
 #include linux/pci.h
 
 #include dmxdev.h
@@ -104,7 +104,6 @@ EXPORT_SYMBOL_GPL(ir_mantis);
 int mantis_input_init(struct mantis_pci *mantis)
 {
struct input_dev *rc;
-   struct ir_input_state rc_state;
char name[80], dev[80];
int err;
 
@@ -120,8 +119,6 @@ int mantis_input_init(struct mantis_pci *mantis)
rc-name = name;
rc-phys = dev;
 
-   ir_input_init(rc, rc_state, IR_TYPE_OTHER);
-
rc-id.bustype  = BUS_PCI;
rc-id.vendor   = mantis-vendor_id;
rc-id.product  = mantis-device_id;

--
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/8] ir-core: convert em28xx to not use ir-functions.c

Convert drivers/media/video/em28xx/em28xx-input.c to not use ir-functions.c

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/video/em28xx/em28xx-input.c |   65 +++--
 drivers/media/video/em28xx/em28xx.h   |1 
 2 files changed, 17 insertions(+), 49 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index dffd026..c4d6027 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -64,17 +64,14 @@ struct em28xx_ir_poll_result {
 struct em28xx_IR {
struct em28xx *dev;
struct input_dev *input;
-   struct ir_input_state ir;
char name[32];
char phys[32];
 
/* poll external decoder */
int polling;
struct delayed_work work;
-   unsigned int last_toggle:1;
unsigned int full_code:1;
unsigned int last_readcount;
-   unsigned int repeat_interval;
 
int  (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
 
@@ -290,7 +287,6 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
 static void em28xx_ir_handle_key(struct em28xx_IR *ir)
 {
int result;
-   int do_sendkey = 0;
struct em28xx_ir_poll_result poll_result;
 
/* read the registers containing the IR status */
@@ -305,52 +301,28 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
ir-last_readcount, poll_result.rc_address,
poll_result.rc_data[0]);
 
-   if (ir-dev-chip_id == CHIP_ID_EM2874) {
+   if (poll_result.read_count  0 
+   poll_result.read_count != ir-last_readcount) {
+   if (ir-full_code)
+   ir_keydown(ir-input,
+  poll_result.rc_address  8 |
+  poll_result.rc_data[0],
+  poll_result.toggle_bit);
+   else
+   ir_keydown(ir-input,
+  poll_result.rc_data[0],
+  poll_result.toggle_bit);
+   }
+
+   if (ir-dev-chip_id == CHIP_ID_EM2874)
/* The em2874 clears the readcount field every time the
   register is read.  The em2860/2880 datasheet says that it
   is supposed to clear the readcount, but it doesn't.  So with
   the em2874, we are looking for a non-zero read count as
   opposed to a readcount that is incrementing */
ir-last_readcount = 0;
-   }
-
-   if (poll_result.read_count == 0) {
-   /* The button has not been pressed since the last read */
-   } else if (ir-last_toggle != poll_result.toggle_bit) {
-   /* A button has been pressed */
-   dprintk(button has been pressed\n);
-   ir-last_toggle = poll_result.toggle_bit;
-   ir-repeat_interval = 0;
-   do_sendkey = 1;
-   } else if (poll_result.toggle_bit == ir-last_toggle 
-  poll_result.read_count  0 
-  poll_result.read_count != ir-last_readcount) {
-   /* The button is still being held down */
-   dprintk(button being held down\n);
-
-   /* Debouncer for first keypress */
-   if (ir-repeat_interval++  9) {
-   /* Start repeating after 1 second */
-   do_sendkey = 1;
-   }
-   }
-
-   if (do_sendkey) {
-   dprintk(sending keypress\n);
-
-   if (ir-full_code)
-   ir_input_keydown(ir-input, ir-ir,
-poll_result.rc_address  8 |
-poll_result.rc_data[0]);
-   else
-   ir_input_keydown(ir-input, ir-ir,
-poll_result.rc_data[0]);
-
-   ir_input_nokey(ir-input, ir-ir);
-   }
-
-   ir-last_readcount = poll_result.read_count;
-   return;
+   else
+   ir-last_readcount = poll_result.read_count;
 }
 
 static void em28xx_ir_work(struct work_struct *work)
@@ -465,11 +437,6 @@ int em28xx_ir_init(struct em28xx *dev)
usb_make_path(dev-udev, ir-phys, sizeof(ir-phys));
strlcat(ir-phys, /input0, sizeof(ir-phys));
 
-   /* Set IR protocol */
-   err = ir_input_init(input_dev, ir-ir, IR_TYPE_OTHER);
-   if (err  0)
-   goto err_out_free;
-
input_dev-name = ir-name;
input_dev-phys = ir-phys;
input_dev-id.bustype = BUS_USB;
diff --git a/drivers/media/video/em28xx/em28xx.h 
b/drivers/media/video/em28xx/em28xx.h
index b252d1b..6216786 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -32,6 +32,7 @@
 #include linux/i2c.h
 #include linux/mutex.h
 #include media/ir-kbd-i2c.h
+#include media/ir-core.h
 #if

[PATCH 3/8] ir-core: partially convert cx88 to not use ir-functions.c

Partially convert drivers/media/video/cx88/cx88-input.c to
not use ir-functions.c

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/video/cx88/cx88-input.c |   46 +++--
 1 files changed, 16 insertions(+), 30 deletions(-)

diff --git a/drivers/media/video/cx88/cx88-input.c 
b/drivers/media/video/cx88/cx88-input.c
index 0de9bdf..e6ecbf8 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -29,6 +29,7 @@
 #include linux/module.h
 
 #include cx88.h
+#include media/ir-core.h
 #include media/ir-common.h
 
 #define MODULE_NAME cx88xx
@@ -38,8 +39,8 @@
 struct cx88_IR {
struct cx88_core *core;
struct input_dev *input;
-   struct ir_input_state ir;
struct ir_dev_props props;
+   u64 ir_type;
 
int users;
 
@@ -50,7 +51,6 @@ struct cx88_IR {
u32 sampling;
u32 samples[16];
int scount;
-   unsigned long release;
 
/* poll external decoder */
int polling;
@@ -124,29 +124,21 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
 
data = (data  4) | ((gpio_key  0xf0)  4);
 
-   ir_input_keydown(ir-input, ir-ir, data);
-   ir_input_nokey(ir-input, ir-ir);
+   ir_keydown(ir-input, data, 0);
 
} else if (ir-mask_keydown) {
/* bit set on keydown */
-   if (gpio  ir-mask_keydown) {
-   ir_input_keydown(ir-input, ir-ir, data);
-   } else {
-   ir_input_nokey(ir-input, ir-ir);
-   }
+   if (gpio  ir-mask_keydown)
+   ir_keydown(ir-input, data, 0);
 
} else if (ir-mask_keyup) {
/* bit cleared on keydown */
-   if (0 == (gpio  ir-mask_keyup)) {
-   ir_input_keydown(ir-input, ir-ir, data);
-   } else {
-   ir_input_nokey(ir-input, ir-ir);
-   }
+   if (0 == (gpio  ir-mask_keyup))
+   ir_keydown(ir-input, data, 0);
 
} else {
/* can't distinguish keydown/up :-/ */
-   ir_input_keydown(ir-input, ir-ir, data);
-   ir_input_nokey(ir-input, ir-ir);
+   ir_keydown(ir-input, data, 0);
}
 }
 
@@ -438,9 +430,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev 
*pci)
snprintf(ir-name, sizeof(ir-name), cx88 IR (%s), core-board.name);
snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci));
 
-   err = ir_input_init(input_dev, ir-ir, ir_type);
-   if (err  0)
-   goto err_out_free;
+   ir-ir_type = ir_type;
 
input_dev-name = ir-name;
input_dev-phys = ir-phys;
@@ -515,8 +505,6 @@ void cx88_ir_irq(struct cx88_core *core)
}
if (!ir-scount) {
/* nothing to sample */
-   if (ir-ir.keypressed  time_after(jiffies, ir-release))
-   ir_input_nokey(ir-input, ir-ir);
return;
}
 
@@ -552,7 +540,7 @@ void cx88_ir_irq(struct cx88_core *core)
 
if (ircode == 0) { /* key still pressed */
ir_dprintk(pulse distance decoded repeat code\n);
-   ir-release = jiffies + msecs_to_jiffies(120);
+   ir_repeat(ir-input);
break;
}
 
@@ -566,10 +554,8 @@ void cx88_ir_irq(struct cx88_core *core)
break;
}
 
-   ir_dprintk(Key Code: %x\n, (ircode  16)  0x7f);
-
-   ir_input_keydown(ir-input, ir-ir, (ircode  16)  0x7f);
-   ir-release = jiffies + msecs_to_jiffies(120);
+   ir_dprintk(Key Code: %x\n, (ircode  16)  0xff);
+   ir_keydown(ir-input, (ircode  16)  0xff, 0);
break;
case CX88_BOARD_HAUPPAUGE:
case CX88_BOARD_HAUPPAUGE_DVB_T1:
@@ -605,16 +591,16 @@ void cx88_ir_irq(struct cx88_core *core)
if ( dev != 0x1e  dev != 0x1f )
/* not a hauppauge remote */
break;
-   ir_input_keydown(ir-input, ir-ir, code);
-   ir-release = jiffies + msecs_to_jiffies(120);
+   ir_keydown(ir-input, code, toggle);
break;
case CX88_BOARD_PINNACLE_PCTV_HD_800i:
ircode = ir_decode_biphase(ir-samples, ir-scount, 5, 7);
ir_dprintk(biphase decoded: %x\n, ircode);
if ((ircode  0xf000) != 0x3000)
break;
-   ir_input_keydown(ir-input, ir-ir, ircode  0x3f);
-   ir-release = jiffies + msecs_to_jiffies(120);
+   /* Note: bit 0x800 being the toggle is assumed, not checked
+  with real hardware  */
+   ir_keydown(ir-input, ircode  0x3f, ircode  0x0800 ? 1 : 0);
break;
}

[PATCH 4/8] ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c

Partially convert drivers/media/video/ir-kbd-i2c.c to
not use ir-functions.c

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/video/ir-kbd-i2c.c |   14 --
 include/media/ir-kbd-i2c.h   |2 +-
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 29d4397..27ae8bb 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -47,7 +47,7 @@
 #include linux/i2c-id.h
 #include linux/workqueue.h
 
-#include media/ir-common.h
+#include media/ir-core.h
 #include media/ir-kbd-i2c.h
 
 /* --- */
@@ -272,11 +272,8 @@ static void ir_key_poll(struct IR_i2c *ir)
return;
}
 
-   if (0 == rc) {
-   ir_input_nokey(ir-input, ir-ir);
-   } else {
-   ir_input_keydown(ir-input, ir-ir, ir_key);
-   }
+   if (rc)
+   ir_keydown(ir-input, ir_key, 0);
 }
 
 static void ir_work(struct work_struct *work)
@@ -439,10 +436,7 @@ static int ir_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 dev_name(client-dev));
 
/* init + register input device */
-   err = ir_input_init(input_dev, ir-ir, ir_type);
-   if (err  0)
-   goto err_out_free;
-
+   ir-ir_type = ir_type;
input_dev-id.bustype = BUS_I2C;
input_dev-name   = ir-name;
input_dev-phys   = ir-phys;
diff --git a/include/media/ir-kbd-i2c.h b/include/media/ir-kbd-i2c.h
index 0506e45..5e96d7a 100644
--- a/include/media/ir-kbd-i2c.h
+++ b/include/media/ir-kbd-i2c.h
@@ -11,7 +11,7 @@ struct IR_i2c {
struct i2c_client  *c;
struct input_dev   *input;
struct ir_input_state  ir;
-
+   u64ir_type;
/* Used to avoid fast repeating */
unsigned char  old;
 

--
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 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

Partially convert drivers/media/video/bt8xx/bttv-input.c to
not use ir-functions.c.

Since the last user is gone with this patch, also remove a
bunch of code from ir-functions.c.

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/IR/ir-functions.c |   89 +--
 drivers/media/video/bt8xx/bttv-input.c  |   35 ++-
 drivers/media/video/bt8xx/bttv.h|1 
 drivers/media/video/bt8xx/bttvp.h   |   11 ---
 drivers/media/video/cx23885/cx23885-input.c |   51 +--
 drivers/media/video/saa7134/saa7134-input.c |   61 +++
 include/media/ir-common.h   |   22 ---
 include/media/ir-kbd-i2c.h  |1 
 8 files changed, 27 insertions(+), 244 deletions(-)

diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index db591e4..d7f47b2 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -31,67 +31,6 @@
 MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
 MODULE_LICENSE(GPL);
 
-static int repeat = 1;
-module_param(repeat, int, 0444);
-MODULE_PARM_DESC(repeat,auto-repeat for IR keys (default: on));
-
-/* -- 
*/
-
-static void ir_input_key_event(struct input_dev *dev, struct ir_input_state 
*ir)
-{
-   if (KEY_RESERVED == ir-keycode) {
-   printk(KERN_INFO %s: unknown key: key=0x%02x down=%d\n,
-  dev-name, ir-ir_key, ir-keypressed);
-   return;
-   }
-   IR_dprintk(1,%s: key event code=%d down=%d\n,
-   dev-name,ir-keycode,ir-keypressed);
-   input_report_key(dev,ir-keycode,ir-keypressed);
-   input_sync(dev);
-}
-
-/* -- 
*/
-
-int ir_input_init(struct input_dev *dev, struct ir_input_state *ir,
- const u64 ir_type)
-{
-   ir-ir_type = ir_type;
-
-   if (repeat)
-   set_bit(EV_REP, dev-evbit);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(ir_input_init);
-
-
-void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir)
-{
-   if (ir-keypressed) {
-   ir-keypressed = 0;
-   ir_input_key_event(dev,ir);
-   }
-}
-EXPORT_SYMBOL_GPL(ir_input_nokey);
-
-void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
- u32 ir_key)
-{
-   u32 keycode = ir_g_keycode_from_table(dev, ir_key);
-
-   if (ir-keypressed  ir-keycode != keycode) {
-   ir-keypressed = 0;
-   ir_input_key_event(dev,ir);
-   }
-   if (!ir-keypressed) {
-   ir-ir_key  = ir_key;
-   ir-keycode = keycode;
-   ir-keypressed = 1;
-   ir_input_key_event(dev,ir);
-   }
-}
-EXPORT_SYMBOL_GPL(ir_input_keydown);
-
 /* -- 
*/
 /* extract mask bits out of data and pack them into the result */
 u32 ir_extract_bits(u32 data, u32 mask)
@@ -284,12 +223,10 @@ void ir_rc5_timer_end(unsigned long data)
 {
struct card_ir *ir = (struct card_ir *)data;
struct timeval tv;
-   unsigned long current_jiffies, timeout;
u32 gap;
u32 rc5 = 0;
 
/* get time */
-   current_jiffies = jiffies;
do_gettimeofday(tv);
 
/* avoid overflow with gap 1s */
@@ -325,32 +262,10 @@ void ir_rc5_timer_end(unsigned long data)
u32 toggle = RC5_TOGGLE(rc5);
u32 instr = RC5_INSTR(rc5);
 
-   /* Good code, decide if repeat/repress */
-   if (toggle != RC5_TOGGLE(ir-last_rc5) ||
-   instr != RC5_INSTR(ir-last_rc5)) {
-   IR_dprintk(1, ir-common: instruction %x, 
toggle %x\n, instr,
-   toggle);
-   ir_input_nokey(ir-dev, ir-ir);
-   ir_input_keydown(ir-dev, ir-ir, instr);
-   }
-
-   /* Set/reset key-up timer */
-   timeout = current_jiffies +
- msecs_to_jiffies(ir-rc5_key_timeout);
-   mod_timer(ir-timer_keyup, timeout);
-
-   /* Save code for repeat test */
-   ir-last_rc5 = rc5;
+   /* Good code */
+   ir_keydown(ir-dev, instr, toggle);
}
}
 }
 EXPORT_SYMBOL_GPL(ir_rc5_timer_end);
 
-void ir_rc5_timer_keyup(unsigned long data)
-{
-   struct card_ir *ir = (struct card_ir *)data;
-
-   IR_dprintk(1, ir-common: key released\n);
-   ir_input_nokey(ir-dev, ir-ir);
-}
-EXPORT_SYMBOL_GPL(ir_rc5_timer_keyup);
diff --git a/drivers/media/video/bt8xx/bttv-input.c 
b/drivers/media/video/bt8xx/bttv-input.c
index 814fd34..66cdc0d

[PATCH 6/8] ir-core: centralize sysfs raw decoder enabling/disabling

With the current logic, each raw decoder needs to add a copy of the exact
same sysfs code. This is both unnecessary and also means that (re)loading
an IR driver after raw decoder modules have been loaded won't work as
expected.

This patch moves that logic into ir-raw-event and adds a single sysfs
file per device.

Reading that file returns something like:

rc5 [rc6] nec jvc [sony]

(with enabled protocols in [] brackets)

Writing either +protocol or -protocol to that file will
enable or disable the according protocol decoder.

An additional benefit is that the disabling of a decoder will be
remembered across module removal/insertion so a previously
disabled decoder won't suddenly be activated again. The default
setting is to enable all decoders.

This is also necessary for the next patch which moves even more decoder
state into the central raw decoding structs.

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/IR/ir-core-priv.h|3 
 drivers/media/IR/ir-jvc-decoder.c  |   64 -
 drivers/media/IR/ir-nec-decoder.c  |   64 -
 drivers/media/IR/ir-raw-event.c|  112 +---
 drivers/media/IR/ir-rc5-decoder.c  |   64 -
 drivers/media/IR/ir-rc6-decoder.c  |   64 -
 drivers/media/IR/ir-sony-decoder.c |   64 -
 drivers/media/IR/ir-sysfs.c|  252 +---
 8 files changed, 231 insertions(+), 456 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index b79446f..3072e55 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -21,6 +21,7 @@
 struct ir_raw_handler {
struct list_head list;
 
+   u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
int (*raw_register)(struct input_dev *input_dev);
int (*raw_unregister)(struct input_dev *input_dev);
@@ -32,6 +33,7 @@ struct ir_raw_event_ctrl {
ktime_t last_event; /* when last event 
occurred */
enum raw_event_type last_type;  /* last event type */
struct input_dev*input_dev; /* pointer to the 
parent input_dev */
+   u64 enabled_protocols; /* enabled raw 
protocol decoders */
 };
 
 /* macros for IR decoders */
@@ -73,6 +75,7 @@ void ir_unregister_class(struct input_dev *input_dev);
 /*
  * Routines from ir-raw-event.c to be used internally and by decoders
  */
+u64 ir_raw_get_allowed_protocols(void);
 int ir_raw_event_register(struct input_dev *input_dev);
 void ir_raw_event_unregister(struct input_dev *input_dev);
 int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
diff --git a/drivers/media/IR/ir-jvc-decoder.c 
b/drivers/media/IR/ir-jvc-decoder.c
index 0b80494..1055de4 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -41,7 +41,6 @@ enum jvc_state {
 struct decoder_data {
struct list_headlist;
struct ir_input_dev *ir_dev;
-   int enabled:1;
 
/* State machine control */
enum jvc_state  state;
@@ -72,53 +71,6 @@ static struct decoder_data *get_decoder_data(struct  
ir_input_dev *ir_dev)
return data;
 }
 
-static ssize_t store_enabled(struct device *d,
-struct device_attribute *mattr,
-const char *buf,
-size_t len)
-{
-   unsigned long value;
-   struct ir_input_dev *ir_dev = dev_get_drvdata(d);
-   struct decoder_data *data = get_decoder_data(ir_dev);
-
-   if (!data)
-   return -EINVAL;
-
-   if (strict_strtoul(buf, 10, value) || value  1)
-   return -EINVAL;
-
-   data-enabled = value;
-
-   return len;
-}
-
-static ssize_t show_enabled(struct device *d,
-struct device_attribute *mattr, char *buf)
-{
-   struct ir_input_dev *ir_dev = dev_get_drvdata(d);
-   struct decoder_data *data = get_decoder_data(ir_dev);
-
-   if (!data)
-   return -EINVAL;
-
-   if (data-enabled)
-   return sprintf(buf, 1\n);
-   else
-   return sprintf(buf, 0\n);
-}
-
-static DEVICE_ATTR(enabled, S_IRUGO | S_IWUSR, show_enabled, store_enabled);
-
-static struct attribute *decoder_attributes[] = {
-   dev_attr_enabled.attr,
-   NULL
-};
-
-static struct attribute_group decoder_attribute_group = {
-   .name   = jvc_decoder,
-   .attrs  = decoder_attributes,
-};
-
 /**
  * ir_jvc_decode() - Decode one JVC pulse or space
  * @input_dev: the struct input_dev descriptor of the device
@@ -135,7 +87,7 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct 
ir_raw_event ev)
if (!data)
return -EINVAL;
 
-   if (!data-enabled)
+   if (!(ir_dev-raw-enabled_protocols  IR_TYPE_JVC))

[PATCH 7/8] ir-core: move decoding state to ir_raw_event_ctrl

This patch moves the state from each raw decoder into the
ir_raw_event_ctrl struct.

This allows the removal of code like this:

spin_lock(decoder_lock);
list_for_each_entry(data, decoder_list, list) {
if (data-ir_dev == ir_dev)
break;
}
spin_unlock(decoder_lock);
return data;

which is currently run for each decoder on each event in order
to get the client-specific decoding state data.

In addition, ir decoding modules and ir driver module load
order is now independent. Centralizing the data also allows
for a nice code reduction of about 30% per raw decoder as
client lists and client registration callbacks are no longer
necessary.

Out-of-tree modules can still use a similar trick to what
the raw decoders did before this patch until they are merged.

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/IR/ir-core-priv.h|   37 -
 drivers/media/IR/ir-jvc-decoder.c  |   90 ++-
 drivers/media/IR/ir-nec-decoder.c  |   89 +++
 drivers/media/IR/ir-raw-event.c|   48 +++--
 drivers/media/IR/ir-rc5-decoder.c  |  103 +---
 drivers/media/IR/ir-rc6-decoder.c  |   92 ++--
 drivers/media/IR/ir-sony-decoder.c |   93 +++--
 7 files changed, 87 insertions(+), 465 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 3072e55..d19d819 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -23,8 +23,6 @@ struct ir_raw_handler {
 
u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
-   int (*raw_register)(struct input_dev *input_dev);
-   int (*raw_unregister)(struct input_dev *input_dev);
 };
 
 struct ir_raw_event_ctrl {
@@ -34,6 +32,41 @@ struct ir_raw_event_ctrl {
enum raw_event_type last_type;  /* last event type */
struct input_dev*input_dev; /* pointer to the 
parent input_dev */
u64 enabled_protocols; /* enabled raw 
protocol decoders */
+
+   /* raw decoder state follows */
+   struct ir_raw_event prev_ev;
+   struct nec_dec {
+   int state;
+   unsigned count;
+   u32 bits;
+   } nec;
+   struct rc5_dec {
+   int state;
+   u32 bits;
+   unsigned count;
+   unsigned wanted_bits;
+   } rc5;
+   struct rc6_dec {
+   int state;
+   u8 header;
+   u32 body;
+   bool toggle;
+   unsigned count;
+   unsigned wanted_bits;
+   } rc6;
+   struct sony_dec {
+   int state;
+   u32 bits;
+   unsigned count;
+   } sony;
+   struct jvc_dec {
+   int state;
+   u16 bits;
+   u16 old_bits;
+   unsigned count;
+   bool first;
+   bool toggle;
+   } jvc;
 };
 
 /* macros for IR decoders */
diff --git a/drivers/media/IR/ir-jvc-decoder.c 
b/drivers/media/IR/ir-jvc-decoder.c
index 1055de4..8894d8b 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -25,10 +25,6 @@
 #define JVC_TRAILER_PULSE  (1  * JVC_UNIT)
 #defineJVC_TRAILER_SPACE   (35 * JVC_UNIT)
 
-/* Used to register jvc_decoder clients */
-static LIST_HEAD(decoder_list);
-DEFINE_SPINLOCK(decoder_lock);
-
 enum jvc_state {
STATE_INACTIVE,
STATE_HEADER_SPACE,
@@ -38,39 +34,6 @@ enum jvc_state {
STATE_TRAILER_SPACE,
 };
 
-struct decoder_data {
-   struct list_headlist;
-   struct ir_input_dev *ir_dev;
-
-   /* State machine control */
-   enum jvc_state  state;
-   u16 jvc_bits;
-   u16 jvc_old_bits;
-   unsignedcount;
-   boolfirst;
-   booltoggle;
-};
-
-
-/**
- * get_decoder_data()  - gets decoder data
- * @input_dev: input device
- *
- * Returns the struct decoder_data that corresponds to a device
- */
-static struct decoder_data *get_decoder_data(struct  ir_input_dev *ir_dev)
-{
-   struct decoder_data *data = NULL;
-
-   spin_lock(decoder_lock);
-   list_for_each_entry(data, decoder_list, list) {
-   if (data-ir_dev == ir_dev)
-   break;
-   }
-   spin_unlock(decoder_lock);
-   return data;
-}
-
 /**
  * ir_jvc_decode() - Decode one JVC pulse or space
  * @input_dev: the struct input_dev descriptor of the device
@@ -80,12 +43,8 @@ static struct decoder_data *get_decoder_data(struct  
ir_input_dev *ir_dev)
  */
 static int ir_jvc_decode(struct input_dev *input_dev,

[PATCH 8/8] ir-core: merge rc-map.h into ir-core.h

Haven't discussed this patch on the linux-media list yet, but
merging rc-map.h into ir-core.h at least makes it much easier
for me to get a good overview of the entire rc-core subsystem
(and to make sweeping changes). Not sure if everyone agrees?

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c|2 
 drivers/media/IR/keymaps/rc-apac-viewcomp.c|2 
 drivers/media/IR/keymaps/rc-asus-pc39.c|2 
 drivers/media/IR/keymaps/rc-ati-tv-wonder-hd-600.c |2 
 drivers/media/IR/keymaps/rc-avermedia-a16d.c   |2 
 drivers/media/IR/keymaps/rc-avermedia-cardbus.c|2 
 drivers/media/IR/keymaps/rc-avermedia-dvbt.c   |2 
 .../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c|2 
 drivers/media/IR/keymaps/rc-avermedia.c|2 
 drivers/media/IR/keymaps/rc-avertv-303.c   |2 
 drivers/media/IR/keymaps/rc-behold-columbus.c  |2 
 drivers/media/IR/keymaps/rc-behold.c   |2 
 drivers/media/IR/keymaps/rc-budget-ci-old.c|2 
 drivers/media/IR/keymaps/rc-cinergy-1400.c |2 
 drivers/media/IR/keymaps/rc-cinergy.c  |2 
 drivers/media/IR/keymaps/rc-dm1105-nec.c   |2 
 drivers/media/IR/keymaps/rc-dntv-live-dvb-t.c  |2 
 drivers/media/IR/keymaps/rc-dntv-live-dvbt-pro.c   |2 
 drivers/media/IR/keymaps/rc-em-terratec.c  |2 
 drivers/media/IR/keymaps/rc-empty.c|2 
 drivers/media/IR/keymaps/rc-encore-enltv-fm53.c|2 
 drivers/media/IR/keymaps/rc-encore-enltv.c |2 
 drivers/media/IR/keymaps/rc-encore-enltv2.c|2 
 drivers/media/IR/keymaps/rc-evga-indtube.c |2 
 drivers/media/IR/keymaps/rc-eztv.c |2 
 drivers/media/IR/keymaps/rc-flydvb.c   |2 
 drivers/media/IR/keymaps/rc-flyvideo.c |2 
 drivers/media/IR/keymaps/rc-fusionhdtv-mce.c   |2 
 drivers/media/IR/keymaps/rc-gadmei-rm008z.c|2 
 drivers/media/IR/keymaps/rc-genius-tvgo-a11mce.c   |2 
 drivers/media/IR/keymaps/rc-gotview7135.c  |2 
 drivers/media/IR/keymaps/rc-hauppauge-new.c|2 
 drivers/media/IR/keymaps/rc-imon-mce.c |2 
 drivers/media/IR/keymaps/rc-imon-pad.c |2 
 drivers/media/IR/keymaps/rc-iodata-bctv7e.c|2 
 drivers/media/IR/keymaps/rc-kaiomy.c   |2 
 drivers/media/IR/keymaps/rc-kworld-315u.c  |2 
 .../media/IR/keymaps/rc-kworld-plus-tv-analog.c|2 
 drivers/media/IR/keymaps/rc-manli.c|2 
 drivers/media/IR/keymaps/rc-msi-tvanywhere-plus.c  |2 
 drivers/media/IR/keymaps/rc-msi-tvanywhere.c   |2 
 drivers/media/IR/keymaps/rc-nebula.c   |2 
 .../media/IR/keymaps/rc-nec-terratec-cinergy-xs.c  |2 
 drivers/media/IR/keymaps/rc-norwood.c  |2 
 drivers/media/IR/keymaps/rc-npgtech.c  |2 
 drivers/media/IR/keymaps/rc-pctv-sedna.c   |2 
 drivers/media/IR/keymaps/rc-pinnacle-color.c   |2 
 drivers/media/IR/keymaps/rc-pinnacle-grey.c|2 
 drivers/media/IR/keymaps/rc-pinnacle-pctv-hd.c |2 
 drivers/media/IR/keymaps/rc-pixelview-mk12.c   |2 
 drivers/media/IR/keymaps/rc-pixelview-new.c|2 
 drivers/media/IR/keymaps/rc-pixelview.c|2 
 .../media/IR/keymaps/rc-powercolor-real-angel.c|2 
 drivers/media/IR/keymaps/rc-proteus-2309.c |2 
 drivers/media/IR/keymaps/rc-purpletv.c |2 
 drivers/media/IR/keymaps/rc-pv951.c|2 
 drivers/media/IR/keymaps/rc-rc5-hauppauge-new.c|2 
 drivers/media/IR/keymaps/rc-rc5-tv.c   |2 
 .../media/IR/keymaps/rc-real-audio-220-32-keys.c   |2 
 drivers/media/IR/keymaps/rc-tbs-nec.c  |2 
 drivers/media/IR/keymaps/rc-terratec-cinergy-xs.c  |2 
 drivers/media/IR/keymaps/rc-tevii-nec.c|2 
 drivers/media/IR/keymaps/rc-tt-1500.c  |2 
 drivers/media/IR/keymaps/rc-videomate-s350.c   |2 
 drivers/media/IR/keymaps/rc-videomate-tv-pvr.c |2 
 drivers/media/IR/keymaps/rc-winfast-usbii-deluxe.c |2 
 drivers/media/IR/keymaps/rc-winfast.c  |2 
 include/media/ir-core.h|  112 ++-
 include/media/rc-map.h |  121 
 69 files changed, 178 insertions(+), 189 deletions(-)
 delete mode 100644 include/media/rc-map.h

diff --git a/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c 
b/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c
index b172831..8d5655a 100644
--- a/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c
+++ b/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c
@@ -10,7 +10,7 @@
  * (at your option) any later version.
  */
 
-#include media/rc-map.h
+#include media/ir-core.h
 
 /* ADS Tech Instant TV DVB-T PCI Remote */
 
diff

Re: [PATCH 1/3] IR: add core lirc device interface

On Mon, Jun 7, 2010 at 2:44 PM, David Härdeman da...@hardeman.nu wrote:
On Fri, Jun 04, 2010 at 03:38:35PM -0300, Mauro Carvalho Chehab wrote:
Em 04-06-2010 12:51, Christoph Bartelmus escreveu:
Hi Mauro,

on 04 Jun 10 at 01:10, Mauro Carvalho Chehab wrote:
Em 03-06-2010 19:06, Jarod Wilson escreveu:
[...]
As for the compat bits... I actually pulled them out of the Fedora kernel
and userspace for a while, and there were only a few people who really
ran
into issues with it, but I think if the new userspace and kernel are
rolled
out at the same time in a new distro release (i.e., Fedora 14, in our
particular case), it should be mostly transparent to users.

For sure this will happen on all distros that follows upstream: they'll
update lirc to fulfill the minimal requirement at Documentation/Changes.

The issue will appear only to people that manually compile kernel and
lirc.
Those users are likely smart enough to upgrade to a newer lirc version if
they notice a trouble, and to check at the forums.

Christoph
wasn't a fan of the change, and actually asked me to revert it, so I'm
cc'ing him here for further feedback, but I'm inclined to say that if
this
is the price we pay to get upstream, so be it.

I understand Christoph view, but I think that having to deal with compat
stuff forever is a high price to pay, as the impact of this change is
transitory and shouldn't be hard to deal with.

I'm not against doing this change, but it has to be coordinated between
drivers and user-space.
Just changing lirc.h is not enough. You also have to change all user-space
applications that use the affected ioctls to use the correct types.
That's what Jarod did not address last time so I asked him to revert the
change.

For sure coordination between kernel and userspace is very important. I'm
sure
that Jarod can help with this sync. Also, after having the changes
implemented
on userspace, I expect one patch from you adding the minimal lirc requirement
at Documentation/Changes.

And I'd also like to collect all other change request to the API
if there are any and do all changes in one go.

You and Jarod are the most indicated people to point for such needs. Also,
Jon
and David may have some comments.

David (who has been absent, sorry about that, life got in the way)
thinks that the lirc raw decoder should implement the minimum amount of
ioctl's possible while still being usable by the lirc userspace and
without going beyond being a raw pulse/space decoder or we'll risk
having to extend the entire decoder API just to support the lirc
compatability decoder.

Thus far, I can get 100% feature-parity w/lirc_mceusb in my ir-core
mceusb driver by adding only 3 tx-specific callbacks to ir_dev_props,
and they're all callbacks (set output mask, set carrier and ir tx
function) that any rc-core native tx solution is also going to need.
On the receive side, zero modifications were made to enable the bridge
driver, outside of the minimal bits to load and register the
decoder. I definitely don't want to burden {ir,rc}-core with
anything that is lirc-specific. Andy's cx23888 driver seems to have a
whole lot more functionality that it might be desirable to adjust via
userspace than mceusb does, but I think that can still be done w/o any
hooks in the core that are inherently lirc-specific.

For reference, this is the entire diff for what was added to ir-core
to enable tx on the mceusb driver:

http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=commitdiff;h=73d631214ed75003bb73e3303819748b47303fd6

Most of the heavy lifting was done in ir-lirc-codec and mceusb, and
the mceusb parts are all non-lirc-specific (hopefully), and thus ready
to be utilized by a native tx solution as well.

Over time, I hope that rc-core will grow it's own chardev with a clean
set of ioctls (or sysfs controls, the jury hasn't returned a verdict
yet). lircd can then be upgraded to support both the in-kernel native
mode and the legacy lirc mode, and with time, the lirc raw decoder can
be phased out.

Works for me.

--
Jarod Wilson
ja...@wilsonet.com
--
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: Is anybody working on TechniSat CableStar Combo HD CI USB device?

2010-06-07 Thread Jan-Pascal van Best

On 06/07/2010 09:01 AM, Tobias Maier wrote:
 on the card is a Micronas DRX 3913 JKA2 which is a combined analog
 cable, DVB-C and DVB-T Demodulator.
 any chance this device is supported soon? Anything i can do to get
 this going?
   
Hi Tobias,

I'm in the market for a USB DVB-C device, and I've been looking into
this device. I've added it to the linuxtv.org wiki
(http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI).

It seems the Windows drivers for this device are very similar to those
of the (supported) Terratec S7 DVB-S device. No quite sure that to make
of that, though. The Micronas DRX series seems to 'evil' in that there
is only a closed-source driver and the manufacturer doesn't cooperate
with open source developers.

Jan-Pascal



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/4] ir-core: move decoding state to ir_raw_event_ctrl

On Mon, Jun 07, 2010 at 09:00:03PM +0200, David Härdeman wrote:
 On Mon, May 03, 2010 at 05:00:05PM -0300, Mauro Carvalho Chehab wrote:
  David Härdeman wrote:
   This patch moves the state from each raw decoder into the
   ir_raw_event_ctrl struct.
   
   This allows the removal of code like this:
   
   spin_lock(decoder_lock);
   list_for_each_entry(data, decoder_list, list) {
   if (data-ir_dev == ir_dev)
   break;
   }
   spin_unlock(decoder_lock);
   return data;
   
   which is currently run for each decoder on each event in order
   to get the client-specific decoding state data.
   
   In addition, ir decoding modules and ir driver module load
   order is now independent. Centralizing the data also allows
   for a nice code reduction of about 30% per raw decoder as
   client lists and client registration callbacks are no longer
   necessary.
  
  The registration callbacks will likely still be needed by lirc,
  as you need to create/delete lirc_dev interfaces, when the module
  is registered, but I might be wrong. It would be interesting to
  add lirc_dev first, in order to be sure about the better interfaces
  for it.
 
 Or the lirc_dev patch can add whatever interfaces it needs. Anyway, the 
 current interfaces are not good enough since it'll break if lirc_dev is 
 loaded after the hardware modules.

This is something I've been meaning to mention myself. On system boot, if
an mceusb device is connected, it pretty regularly only has the NEC
decoder available to use. I have to reload mceusb, or make sure ir-core is
explicitly loaded, wait a bit, then load mceusb, if I want to have all of
the protocol handlers available -- which includes the needed-by-default
rc6 one. I've only briefly tinkered with trying to fix it, sounds like you
may already have fixage within this patchset.

...
 In addition, random module load order is currently broken (try loading 
 decoders first and hardware later and you'll see).  With this patch, it 
 works again.

Want.

 Anyway, I'll post a new patch series this evening and then we can go 
 back to our regular arguing :)

Hey, at least we're making progress too! :)

-- 
Jarod Wilson
ja...@redhat.com

--
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

Aw: Re: What ever happened to standardizing signal level?

2010-06-07 Thread hermann-pitton

 
Hi Manu,

- Original Nachricht 
Von: Manu Abraham abraham.m...@gmail.com
An:  hermann pitton hermann-pit...@arcor.de
Datum:   07.06.2010 05:04
Betreff: Re: What ever happened to standardizing signal level?

 On Mon, Jun 7, 2010 at 2:01 AM, hermann pitton hermann-pit...@arcor.de
 wrote:
 
  Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User:
  hermann pitton hermann-pit...@arcor.de, you are contributing
  absolutely nothing to this thread aside of annoying people with your
  by trolling and half incoherent nonsense.  It's quite ironic you
  suggest _I_ am the one trolling when this is a thread _I_ created.
  And further, several people have posted legitimate responses to --
  clearly you are the only one suffering from your delusion.
 
  Dream on.
 
  The question never was, if you are trolling from time to time, but only
  if you are a duplicate of another troll or on your own.
 
  I have talked with Mauro about that and since then I ask you to provide
  your full name or point at least to a patch from you, where you have to
  agree to provide your real name in your SOB line.
 
  There was none and you also did not point to somebody else, to confirm
  for us, that you are known and on kernel development not only as a
  troll.
 
  You did not give an sufficient answer during the last two years.
 
  Additionally you've been stalking me in email as well.  Your behavior
  is not only uncalled for, it's abusive of both this mailing list and
  the people willingly participating in the discussion.  As I understand
  it, this is not the first time you've been the source of harassment.
 
  The opposite again is true, you stalked me by private e-mail and
  therefor my reply went as copy also to Mauro and Manu. If even Manu does
  not have your contact data, who else? Please provide them at least to
  him or someone else you trust and you are free for rants, within
  limitations.
 
 
 Sorry, that I could not reply in-time. I had been traveling and hence.
 Also, with little free time in between additionally. Hermann, what's
 going on ? I don't see the reason for such a long thread, nor can't
 believe that time is so cheap ..
 
 Anyway ... He doesn't do much of coding, or maybe next to nothing. But
 he does test hardware and drivers, from what I know, for quite a long
 time from the time of the FF cards. I know his real name as Derek
 Kelly and on IRC as hotwings. Well, I do appreciate the time he puts
 into testing, as it helps to make realize code better, or identify
 hardware bugs etc. At least a couple of times, I was able to find bugs
 in my own code, thanks to him. But the other side, unlike most people,
 he seemed to not have a taste for taking credits at all (don't know
 why, eventhough I had pointed out to him a few times) ..
 
 Regards,
 Manu

many thanks for your time and help.

Ah. Derek please take some credits.

I suspected him to be a troll only, since for more than two years
he refused to provide at least a full name. There was also no single patch with 
a valid SOB.

This has changed now and there should be no reasons for any further clashes.

His temper and harshness, when me was insisting on a full name, 
did always remind me on Uwe, who is using multiple email accounts 
on his attempts to improve development.

If you trust him, I'll trust him too.

Derek, sorry for have being preemptive on you.

Thanks,
Hermann
















Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im 
Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events
--
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: v4l-dvb - Is it still usable for a distribution ?

Hi
 ...
 Another problem (after fixing the compile issues) is the IR Part of v4l-dvb 
 which includes an Imon module.
 This module doesn't provide any lirc devices, so how can this oe be used as 
 an IR device ?

 You don't need lirc to use imon, since it now provides a standard 
 input/event interface. So, the driver
 currently can be used with lirc event interface, or alone.
 
 See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the
 config I use w/my own imon hardware.
 
Tanks for the hint !

 Til now I am using lirc_imon which fit all my needs.

 Lirc-dev patches are currently being discussed. There are just a few 
 adjustments on it, in order to get it
 finally merged. The kernel-userspace interface will likely need a few 
 changes, so you'll likely need to update
 lirc after the merge. Better to follow the IR threads at linux-media ML, in 
 order to be in-tune with the changes.
 
 I've considered adding lirc_dev support back to the imon driver when
 we get it merged, but it really doesn't make a whole lot of sense,
 given that the imon devices do all IR decoding in hardware. As long as
 the keymap is complete, there's no benefit to wiring up lirc_dev vs.
 just using lircd's devinput access method for imon devices.
 
You're right, also inputlircd can do the job.

Is your imon driver fully compatible with the lirc_imon in the display part ?

It would be very helpful to add a parameter for disabling the IR Part, I have 
many users which
are using only the display part.

-- 
Helmut Auer, hel...@helmutauer.de
--
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

zvbi-atsc-cc Time-stamps?

2010-06-07 Thread Santino Chianti

Hi everyone,

I need help figure out a way to get accurate time stamps on my closed
captioning files using zvbi-atsc-cc.

I have Hauppauge HVR-1850 cards working in digital mode.  I need
separate recordings of the video/audio file (mpeg2) and the closed
captioning (plain text).  I can capture a plain mpeg stream by issuing
this in one console:

* azap -r KOCE-HD

And this in a second console:

* cat /dev/dvb/adapter0/dvr0  test-cat3.mpeg

I tested this file and it plays fine.  To generate the closed
captioning, I feed this file into zvbi-atsc-cc:

* zvbi-atsc-cc --atsc -c KCAL-HD -T  test-cat3.mpeg

KCAL-HD being the the channel in my channels.conf that I captured from.


The problem: I need accurate time stamps.  Normally, I add the time
stamps during capture, so they match reality. If I get the closed
captioning from a file, the information is still in the file (I just
need to set the start time), but how do I get that information out?

Our system relies on the time stamps in the closed captioning to cue
the video, so they need to be accurate.  One-second accuracy is
adequate, so if I can get the STT information from the PSIP info, that
would be good enough. I'm using an off-air signal, so these are ATSC
8VSB channels:

LA18.8:49700:8VSB:161:164:8
KBEH-DT:53300:8VSB:49:52:1
KCET-HD:55700:8VSB:49:52:1

A typical closed captioning file should end up looking like this:

2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:02
% Communication Studies Archive, UCLA
% 87e70c70-5614-11df-b2f7-00e0815fe826
% Video length 0:59:54.024
% Christiane Amanpour
2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:12
2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:22
A HIGH STAKES INVESTIGATION
IS STARTED AFTER A CAR BOMB IS 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:32
FOUND IN NEW YORK'S TIMES
SQUARE.
WHO WANTED TO ATTACK THE
CROSSROADS OF THE WORLD AND WHY.
PRESIDENT OBAMA HEADS TO THE
GULF COAST FOR A FIRSTHAND LOOK 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:42
AT DESPERATE EFFORTS TO MAINTAIN
AN OIL SPILL.

-- in other words, a time stamp every ten seconds, which is then used
by our search engine to link to the video. The header (%) is added
afterward. Ideally for us, then, I would get the STT stamp at
ten-second intervals inserted into the closed captioning file. Are
there command-line Linux tools for reading PSIP?

(There are also other possible uses of PSIP. xds information is too
unreliable and inconsistent for us to use, but if PSIP is reliable,
I'd like to use it to verify that I'm getting the recording I intended
to get (channel and program name). I could potentially use this
information to crop the video to the exact program -- but it would
have to be reliable enough to be automated, I don't have staff to do
anything manual with individual recordings.)

Alternatively, Devin Heitmueller tells us that there is also the PTS
(presentation timestamp), which should be pretty easy to modify
zlib-atsc-cc to show.  Since the PTS can be used to synchronize the
video to the CC info is it possible to make a small modification to
zvbi-atsc-cc to log the CC info with the PTS, and then write a really
simple utility to seek to a given PTS and play the video?

Could someone help me out with accurate timestamps in relation to PSIP
info and PTS?

Warm wishes,
Santino
--
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: v4l-dvb - Is it still usable for a distribution ?

Hello

 Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't 
 compile.
 
 Douglas returned from this 2 week trip abroad and he is backporting the 
 upstream stuff. Yesterday, he
 reported to me that the tree is now compiling with 2.6.34.
 
Ok - I also got it compiling, but budget-ci is causing kernel oops (see other 
ML thread)
 
 The final question for me:
 Does it make any sense anymore to stay with v4l-dvb or do I have to change 
 to the kernel drivers ?
 The major disadvantage of the kernel drivers is the fact that I cannot 
 switch to newer dvb drivers, I am stuck to the ones included in the kernel.
 
 Well, this is something that you need to answer by yourself ;)
 
Thats not what I wanted to hear ;)

 I don't recommend using a random snapshot of the tree on a distro package, as 
 regressions may
 happen during the development period.
 
 Also, the backports are done at best efforts. There are no warranties, no QA 
 and generally no 
 tests with real hardware when a backport is done. So, while we hope that the 
 backport will work, 
 you may have a bug introduced on the backport stuff that may affect your 
 card, not present
 upstream.
 
 IMHO, the better is to just upgrade to the next stable kernel. 
 
Ok -  that what I also thought
formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 
Versions behind.
Now the kernel drivers are often the newer ones, so I have to switch.

 Another alternative is to manually apply on your distro the patches that you 
 need there.
 All patches with c/c to sta...@kernel.org are bug fixes that needs to be 
 backported to older
 (stable) kernels. So, a good hint is to check for those stable patches. 
 Unfortunately, not all
 developers remind to add a c/c to stable. I try to do my best to re-tag those 
 emails when
 sending the patches upstream, but I generally opt to trust on the developers, 
 since a fix may
 apply only at the latest upstream kernel.
 
Thats surely an option, but an average user of my distri can't compile a kernel 
;)
Emerging v4l-dvb is much easier ;)

-- 
Helmut Auer, hel...@helmutauer.de
--
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: v4l-dvb - Is it still usable for a distribution ?

2010-06-07 Thread Mauro Carvalho Chehab

Em 07-06-2010 18:33, Helmut Auer escreveu:
 Hello
 
 Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't 
 compile.

 Douglas returned from this 2 week trip abroad and he is backporting the 
 upstream stuff. Yesterday, he
 reported to me that the tree is now compiling with 2.6.34.

 Ok - I also got it compiling, but budget-ci is causing kernel oops (see other 
 ML thread)

There's already a patch for it at -git, but I suspect that Douglas didn't have 
time to backport the newer
87 patches that were committed there.

 The final question for me:
 Does it make any sense anymore to stay with v4l-dvb or do I have to change 
 to the kernel drivers ?
 The major disadvantage of the kernel drivers is the fact that I cannot 
 switch to newer dvb drivers, I am stuck to the ones included in the kernel.

 Well, this is something that you need to answer by yourself ;)

 Thats not what I wanted to hear ;)

:)

 I don't recommend using a random snapshot of the tree on a distro package, 
 as regressions may
 happen during the development period.

 Also, the backports are done at best efforts. There are no warranties, no QA 
 and generally no 
 tests with real hardware when a backport is done. So, while we hope that the 
 backport will work, 
 you may have a bug introduced on the backport stuff that may affect your 
 card, not present
 upstream.

 IMHO, the better is to just upgrade to the next stable kernel. 

 Ok -  that what I also thought
 formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 
 Versions behind.
 Now the kernel drivers are often the newer ones, so I have to switch.

There's still a delay if you're getting the latest stable kernel, that ranges 
from 1 to 2 versions
for improvements, and a few weeks, for bug fixes. Eventually, you may provide 
-rc kernels as an 
alternative for those that needs the bleeding edge kernels and are brave enough 
;)

 Another alternative is to manually apply on your distro the patches that you 
 need there.
 All patches with c/c to sta...@kernel.org are bug fixes that needs to be 
 backported to older
 (stable) kernels. So, a good hint is to check for those stable patches. 
 Unfortunately, not all
 developers remind to add a c/c to stable. I try to do my best to re-tag 
 those emails when
 sending the patches upstream, but I generally opt to trust on the 
 developers, since a fix may
 apply only at the latest upstream kernel.

 Thats surely an option, but an average user of my distri can't compile a 
 kernel ;)
 Emerging v4l-dvb is much easier ;)

Yes, but you may manually apply those patches from my git tree on your distro 
kernels. User will need to
emerge the kernel package. It will require you a little more work, or some 
magic script.

You may also keep using the -hg backport tree, but the delay is higher than 
before, since the
patches go first to -git.

Cheers,
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

[PATCH] Add the viafb video capture driver

2010-06-07 Thread Jonathan Corbet

Hi, Mauro,

Linus has quietly ignored a couple of pull requests for this driver; I
guess he's gotten tired of me this time around or something.  There's
little profit in pushing the issue, so, can you just send it up through
your tree (for 2.6.36 at this point) instead? 

Thanks,

jon
---
Add the viafb video capture driver

Add a driver for the video capture port on VIA integrated chipsets.  This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.

This work was supported by the One Laptop Per Child project.

Signed-off-by: Jonathan Corbet cor...@lwn.net
---
 drivers/media/video/Kconfig  |   10 +
 drivers/media/video/Makefile |2 +
 drivers/media/video/via-camera.c | 1368 ++
 drivers/media/video/via-camera.h |   93 +++
 drivers/video/via/accel.c|2 +-
 drivers/video/via/via-core.c |   16 +-
 include/linux/via-core.h |4 +-
 include/media/v4l2-chip-ident.h  |4 +
 8 files changed, 1495 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/video/via-camera.c
 create mode 100644 drivers/media/video/via-camera.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..a26ded1 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -853,6 +853,16 @@ config VIDEO_CAFE_CCIC
  CMOS camera controller.  This is the controller found on first-
  generation OLPC systems.
 
+config VIDEO_VIA_CAMERA
+   tristate VIAFB camera controller support
+   depends on FB_VIA
+   select VIDEOBUF_DMA_SG
+   select VIDEO_OV7670
+   help
+  Driver support for the integrated camera controller in VIA
+  Chrome9 chipsets.  Currently only tested on OLPC xo-1.5 systems
+  with ov7670 sensors.
+
 config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2  HAS_DMA  I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..47fa0c0 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -126,6 +126,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
 
 obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
 
+obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
+
 obj-$(CONFIG_USB_DABUSB)+= dabusb.o
 obj-$(CONFIG_USB_OV511) += ov511.o
 obj-$(CONFIG_USB_SE401) += se401.o
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
new file mode 100644
index 000..7b1ff0c
--- /dev/null
+++ b/drivers/media/video/via-camera.c
@@ -0,0 +1,1368 @@
+/*
+ * Driver for the VIA Chrome integrated camera controller.
+ *
+ * Copyright 2009,2010 Jonathan Corbet cor...@lwn.net
+ * Distributable under the terms of the GNU General Public License, version 2
+ *
+ * This work was supported by the One Laptop Per Child project
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/list.h
+#include linux/pci.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/videobuf-dma-sg.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/pm_qos_params.h
+#include linux/via-core.h
+#include linux/via-gpio.h
+#include linux/via_i2c.h
+
+#include via-camera.h
+
+MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
+MODULE_DESCRIPTION(VIA framebuffer-based camera controller driver);
+MODULE_LICENSE(GPL);
+
+static int flip_image;
+module_param(flip_image, bool, 0444);
+MODULE_PARM_DESC(flip_image,
+   If set, the sensor will be instructed to flip the image 
+   vertically.);
+
+#ifdef CONFIG_OLPC_XO_1_5
+static int override_serial;
+module_param(override_serial, bool, 0444);
+MODULE_PARM_DESC(override_serial,
+   The camera driver will normally refuse to load if 
+   the XO 1.5 serial port is enabled.  Set this option 
+   to force the issue.);
+#endif
+
+/*
+ * Basic window sizes.
+ */
+#define VGA_WIDTH  640
+#define VGA_HEIGHT 480
+#define QCIF_WIDTH 176
+#defineQCIF_HEIGHT 144
+
+/*
+ * The structure describing our camera.
+ */
+enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
+
+static struct via_camera {
+   struct v4l2_device v4l2_dev;
+   struct video_device vdev;
+   struct v4l2_subdev *sensor;
+   struct platform_device *platdev;
+   struct viafb_dev *viadev;
+   struct mutex lock;
+   enum viacam_opstate opstate;
+   unsigned long flags;
+   /*
+* GPIO info for power/reset management
+*/
+   int power_gpio;
+   int reset_gpio;
+   /*
+* I/O memory stuff.
+*/
+   void __iomem *mmio; /* Where the registers live */
+   void __iomem *fbmem;/* Frame buffer

cam max width and height

2010-06-07 Thread linux newbie

Hi,

I am using linux 2.6.26.3. I connected microsoft live cam and its
max supported resolution is 1280x800. If I use VIDIOC_G_FMT,
fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480.

How to get the maximum supported resolution??

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: [Linux-uvc-devel] cam max width and height

2010-06-07 Thread Natalia Portillo

Hi,

El 08/06/2010, a las 01:09, linux newbie escribió:

 Hi,
 
 I am using linux 2.6.26.3. I connected microsoft live cam and its
 max supported resolution is 1280x800. If I use VIDIOC_G_FMT,
 fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480.
 
 How to get the maximum supported resolution??

You should check in Microsoft's webpage or included documentation that 1280x800 
is a video resolution and not only a still image resolution.

It is common for many cameras to do that.

 Thanks
 ___
 Linux-uvc-devel mailing list
 linux-uvc-de...@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/linux-uvc-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: [PATCH] Add the viafb video capture driver

2010-06-07 Thread Laurent Pinchart

Hi Jonathan,

On Tuesday 08 June 2010 01:26:15 Jonathan Corbet wrote:
 Hi, Mauro,
 
 Linus has quietly ignored a couple of pull requests for this driver; I
 guess he's gotten tired of me this time around or something.  There's
 little profit in pushing the issue, so, can you just send it up through
 your tree (for 2.6.36 at this point) instead?

If it's not too late for review, here are some comments. I've reviewed the 
code from bottom to top, so comments might be a bit inconsistent sometimes.

[snip]

 diff --git a/drivers/media/video/via-camera.c
 b/drivers/media/video/via-camera.c new file mode 100644
 index 000..7b1ff0c
 --- /dev/null
 +++ b/drivers/media/video/via-camera.c

[snip]

 +/*
 + * Basic window sizes.
 + */
 +#define VGA_WIDTH640
 +#define VGA_HEIGHT   480

That's already defined in include/linux/via-core.h (ugly defines though). It 
would be better to define constants such as VIA_SENSOR_WIDTH, 
VIA_xxx_MIN_WIDTH, VIA_xxx_MAX_WIDTH, ...

 +#define QCIF_WIDTH   176
 +#define  QCIF_HEIGHT 144
 +
 +/*
 + * The structure describing our camera.
 + */
 +enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
 +
 +static struct via_camera {
 + struct v4l2_device v4l2_dev;
 + struct video_device vdev;
 + struct v4l2_subdev *sensor;
 + struct platform_device *platdev;
 + struct viafb_dev *viadev;
 + struct mutex lock;
 + enum viacam_opstate opstate;
 + unsigned long flags;
 + /*
 +  * GPIO info for power/reset management
 +  */
 + int power_gpio;
 + int reset_gpio;
 + /*
 +  * I/O memory stuff.
 +  */
 + void __iomem *mmio; /* Where the registers live */
 + void __iomem *fbmem;/* Frame buffer memory */
 + u32 fb_offset;  /* Reserved memory offset (FB) */
 + /*
 +  * Capture buffers and related.  The controller supports
 +  * up to three, so that's what we have here.  These buffers
 +  * live in frame buffer memory, so we don't call them DMA.
 +  */
 + unsigned int cb_offsets[3]; /* offsets into fb mem */
 + u8 *cb_addrs[3];/* Kernel-space addresses */
 + int n_cap_bufs; /* How many are we using? */
 + int next_buf;
 + struct videobuf_queue vb_queue;
 + struct list_head buffer_queue;  /* prot. by reg_lock */
 + /*
 +  * User tracking.
 +  */
 + int users;
 + struct file *owner;
 + /*
 +  * Video format information.  sensor_format is kept in a form
 +  * that we can use to pass to the sensor.  We always run the
 +  * sensor in VGA resolution, though, and let the controller
 +  * downscale things if need be.  So we keep the real*
 +  * dimensions separately.
 +  */
 + struct v4l2_pix_format sensor_format;
 + struct v4l2_pix_format user_format;
 +} via_cam_info;

Don't define device structures as static object. You must kmalloc the 
via_camera structure in probe and set the pointer as driver private data to 
access it later in V4L2 operations and device core callbacks. Otherwise Bad 
Things (TM) will happen if the device is removed while the video device node 
is opened.

[snip]

 +/*
 + * Configure the sensor.  It's up to the caller to ensure
 + * that the camera is in the correct operating state.
 + */
 +static int viacam_configure_sensor(struct via_camera *cam)
 +{
 + struct v4l2_format fmt;
 + int ret;
 +
 + fmt.fmt.pix = cam-sensor_format;
 + ret = sensor_call(cam, core, init, 0);
 + if (ret == 0)
 + ret = sensor_call(cam, video, s_fmt, fmt);
 + /*
 +  * OV7670 does weird things if flip is set *before* format...

What if the user sets vflip using VIDIOC_S_CTRL directly before setting the 
format ?

 +  */
 + if (ret == 0)
 + ret = viacam_set_flip(cam);
 + return ret;
 +}

[snip]

 +/*
 + * The threaded IRQ handler.
 + */
 +static irqreturn_t viacam_irq(int irq, void *data)
 +{
 + int bufn;
 + struct videobuf_buffer *vb;
 + struct via_camera *cam = data;
 + struct videobuf_dmabuf *vdma;
 +
 + /*
 +  * If there is no place to put the data frame, don't bother
 +  * with anything else.
 +  */
 + vb = viacam_next_buffer(cam);
 + if (vb == NULL)
 + goto done;
 + /*
 +  * Figure out which buffer we just completed.
 +  */
 + bufn = (viacam_read_reg(cam, VCR_INTCTRL)  VCR_IC_ACTBUF)  3;
 + bufn -= 1;
 + if (bufn  0)
 + bufn = cam-n_cap_bufs - 1;
 + /*
 +  * Copy over the data and let any waiters know.
 +  */
 + vdma = videobuf_to_dma(vb);
 + viafb_dma_copy_out_sg(cam-cb_offsets[bufn], vdma-sglist, vdma-sglen);

Ouch that's going to hurt performances !

What are the hardware restrictions regarding the memory it can capture images 
to ? Does it just have to be physically contiguous, or does the memory need to 
come from a specific memory area ? In the first case you could use 
videobuf_dma_contig and

Re: cam max width and height

2010-06-07 Thread Laurent Pinchart

Hi,

On Tuesday 08 June 2010 02:09:39 linux newbie wrote:
 Hi,
 
 I am using linux 2.6.26.3. I connected microsoft live cam and its
 max supported resolution is 1280x800. If I use VIDIOC_G_FMT,
 fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480.
 
 How to get the maximum supported resolution??

You can use VIDIOC_ENUM_FRAMESIZES to enumeration all the supported 
resolutions.

-- 
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

Re: [PATCH] Add the viafb video capture driver

2010-06-07 Thread Jonathan Corbet

On Tue, 8 Jun 2010 03:03:14 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

 If it's not too late for review, here are some comments. I've reviewed the 
 code from bottom to top, so comments might be a bit inconsistent sometimes.

Never too late to make the code better.  These are good comments, thanks.
Mauro, I guess I've got another version coming...:)  It will take me a bit,
I've got another ocean to cross tomorrow.

Specific responses below.  I've snipped out a fair number of comments; that
means you're right, I'll fix it.

 Don't define device structures as static object. You must kmalloc the 
 via_camera structure in probe and set the pointer as driver private data to 
 access it later in V4L2 operations and device core callbacks. Otherwise Bad 
 Things (TM) will happen if the device is removed while the video device node 
 is opened.

I understand the comment...but this device is blasted onto the system's
base silicon.  It's not going to be removed in a way which leaves a
functioning computer.  Still, dynamic allocation is easy enough to do.

  +/*
  + * Configure the sensor.  It's up to the caller to ensure
  + * that the camera is in the correct operating state.
  + */
  +static int viacam_configure_sensor(struct via_camera *cam)
  +{
  +   struct v4l2_format fmt;
  +   int ret;
  +
  +   fmt.fmt.pix = cam-sensor_format;
  +   ret = sensor_call(cam, core, init, 0);
  +   if (ret == 0)
  +   ret = sensor_call(cam, video, s_fmt, fmt);
  +   /*
  +* OV7670 does weird things if flip is set *before* format...
 
 What if the user sets vflip using VIDIOC_S_CTRL directly before setting the 
 format ?

All is well; we remember the setting and set the flip properly afterward.

  +   /*
  +* Copy over the data and let any waiters know.
  +*/
  +   vdma = videobuf_to_dma(vb);
  +   viafb_dma_copy_out_sg(cam-cb_offsets[bufn], vdma-sglist, vdma-sglen);
 
 Ouch that's going to hurt performances !
 
 What are the hardware restrictions regarding the memory it can capture images 
 to ? Does it just have to be physically contiguous, or does the memory need 
 to 
 come from a specific memory area ? In the first case you could use 
 videobuf_dma_contig and avoid the memcpy completely. In the second case you 
 should still mmap the memory to userspace when using kernel-allocated buffers 
 instead of memcpying the data. If you really need a memcpy, you should then 
 probably use videobuf_vmalloc instead of videobuf_dma_sg.

It's a DMA copy, so performance is actually not a problem.

The video capture engine grabs frames into a three-buffer ring stored in
viafb framebuffer memory.  I *could* let user space map that memory
directly, but it would be an eternal race with the engine and would not end
well.  We really do have to do the copy.  In a sense, the framebuffer
memory is just part of the capture device; the DMA operation is how we make
data available to the rest of the system.

[Incidentally, the biggest cost here, I think, is setting up 150 DMA
descriptors for each transfer.  That's an artifact of the page-at-a-time
memory allocation used by videobuf_dma_sg.  I have a branch with an SG
variant which tries to allocate the largest contiguous buffers possible
without going over; it reduces the number of descriptors to about five.  It
didn't change my life a whole lot, so I back-burnered it, but I might
send that patch out one of these days.]

  +   viacam_write_reg(cam, VCR_CAPINTC, ~VCR_CI_ENABLE);
  +   viacam_write_reg(cam, VCR_CAPINTC, ~(VCR_CI_ENABLE|VCR_CI_CLKEN));
 
 I don't know how the VCR_CAPINTC register works, but did you really mean to 
 write all bits to 1 except VCR_CI_ENABLE and VCR_CI_CLKEN ?

Ouch, no, I don't; that's meant to be a mask operation.

  +   /*
  +* Disable a bunch of stuff.
  +*/
  +   viacam_write_reg(cam, VCR_HORRANGE, 0x06200120);
  +   viacam_write_reg(cam, VCR_VERTRANGE, 0x01de);
 
 Any idea what that bunch of stuff is ? Replacing the magic numbers by 
 #define'd constants would be nice.

It's 640x480, modulo weird VIA magic.  I got it straight from them.  I can
add a comment, though.

  +   (void) viacam_read_reg(cam, VCR_CAPINTC); /* Force post */
 
 Why a (void) cast ?

It's my way of saying that I meant to ignore the return value of a function
whose purpose is to return a value.

  +static int viacam_vb_buf_setup(struct videobuf_queue *q,
  +   unsigned int *count, unsigned int *size)
  +{
  +   struct via_camera *cam = q-priv_data;
  +
  +   *size = cam-user_format.sizeimage;
  +   if (*count == 0 || *count  6)  /* Arbitrary number */
  +   *count = 6;
 
 Shouldn't the limit should be computed from the available fb memory ?

That would always be three, but user space might well want more buffering
than that.  I don't quite see why the two need to be tied.

  +static void viacam_vb_buf_queue(struct videobuf_queue *q,
  +   struct videobuf_buffer *vb)
  +{
  +   struct via_camera *cam = q-priv_data;
  +
  +

Re: v4l-dvb - Is it still usable for a distribution ?

On Mon, Jun 7, 2010 at 5:25 PM, Helmut Auer v...@helmutauer.de wrote:
...
 Is your imon driver fully compatible with the lirc_imon in the display part ?

Yes, works perfectly fine with the exact same lcdproc setup here --
both vfd and lcd tested.

 It would be very helpful to add a parameter for disabling the IR Part, I have 
 many users which
 are using only the display part.

Hm. I was going to suggest that if people aren't using the receiver,
there should be no need to disable IR, but I guess someone might want
to use an mce remote w/an mce receiver, and that would have
interesting results if they had one of the imon IR receivers
programmed for mce mode. I'll keep it in mind for the next time I'm
poking at the imon code in depth. Need to finish work on some of the
other new ir/rc bits first (you'll soon be seeing the mceusb driver
ported to the new infra also in v4l-dvb hg, as well as an lirc bridge
driver, which is currently my main focal point).

-- 
Jarod Wilson
ja...@wilsonet.com
--
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] libv4l1: move VIDIOCGAUDIO,VIDIOCSAUDIO,VIDIOCGVBIFMT,VIDIOCSVBIFMT

2010-06-07 Thread huzaifas

From: Huzaifa Sidhpurwala huzai...@redhat.com

merged two previous patches, now uses v4l2_set_control and
v4l2_get_control

Signed-of-by: Huzaifa Sidhpurwala huzai...@redhat.com
---
 lib/libv4l1/libv4l1-priv.h |7 ++
 lib/libv4l1/libv4l1.c  |  172 
 2 files changed, 179 insertions(+), 0 deletions(-)

diff --git a/lib/libv4l1/libv4l1-priv.h b/lib/libv4l1/libv4l1-priv.h
index 11f4fd0..11ee57a 100644
--- a/lib/libv4l1/libv4l1-priv.h
+++ b/lib/libv4l1/libv4l1-priv.h
@@ -60,6 +60,13 @@ extern FILE *v4l1_log_file;
 #define min(a, b) (((a)  (b)) ? (a) : (b))
 #endif
 
+#define DIV_ROUND_CLOSEST(x, divisor)(  \
+{   \
+   typeof(divisor) __divisor = divisor;\
+   (((x) + ((__divisor) / 2)) / (__divisor));  \
+}   \
+)
+
 struct v4l1_dev_info {
int fd;
int flags;
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 2981c40..830ed6b 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -983,6 +983,178 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
 
break;
}
+
+   case VIDIOCSAUDIO: {
+   struct video_audio *aud = arg;
+   struct v4l2_audio aud2 = { 0, };
+   struct v4l2_tuner tun2 = { 0, };
+
+   aud2.index = aud-audio;
+   result = v4l2_ioctl(fd, VIDIOC_S_AUDIO, aud2);
+   if (result  0)
+   break;
+
+   v4l2_set_control(fd, V4L2_CID_AUDIO_VOLUME,
+   aud-volume);
+   v4l2_set_control(fd, V4L2_CID_AUDIO_BASS,
+   aud-bass);
+   v4l2_set_control(fd, V4L2_CID_AUDIO_TREBLE,
+   aud-treble);
+   v4l2_set_control(fd, V4L2_CID_AUDIO_BALANCE,
+   aud-balance);
+   v4l2_set_control(fd, V4L2_CID_AUDIO_MUTE,
+   !!(aud-flags  VIDEO_AUDIO_MUTE));
+
+   result = v4l2_ioctl(fd, VIDIOC_G_TUNER, tun2);
+   if (result  0)
+   break;
+   if (result == 0) {
+   switch (aud-mode) {
+   default:
+   case VIDEO_SOUND_MONO:
+   case VIDEO_SOUND_LANG1:
+   tun2.audmode = V4L2_TUNER_MODE_MONO;
+   break;
+   case VIDEO_SOUND_STEREO:
+   tun2.audmode = V4L2_TUNER_MODE_STEREO;
+   break;
+   case VIDEO_SOUND_LANG2:
+   tun2.audmode = V4L2_TUNER_MODE_LANG2;
+   break;
+   }
+   result = v4l2_ioctl(fd, VIDIOC_S_TUNER, tun2);
+   }
+   break;
+   }
+
+   case VIDIOCGAUDIO: {
+   int i;
+   struct video_audio *aud = arg;
+   struct v4l2_queryctrl qctrl2;
+   struct v4l2_audio aud2 = { 0, };
+   struct v4l2_tuner tun2;
+
+   result = v4l2_ioctl(fd, VIDIOC_G_AUDIO, aud2);
+   if (result  0)
+   break;
+
+   memcpy(aud-name, aud2.name,
+   min(sizeof(aud-name), sizeof(aud2.name)));
+   aud-name[sizeof(aud-name) - 1] = 0;
+   aud-audio = aud2.index;
+   aud-flags = 0;
+   i = v4l2_get_control(fd, V4L2_CID_AUDIO_VOLUME);
+   if (i = 0) {
+   aud-volume = i;
+   aud-flags |= VIDEO_AUDIO_VOLUME;
+   }
+   i = v4l2_get_control(fd, V4L2_CID_AUDIO_BASS);
+   if (i = 0) {
+   aud-bass = i;
+   aud-flags |= VIDEO_AUDIO_BASS;
+   }
+   i = v4l2_get_control(fd, V4L2_CID_AUDIO_TREBLE);
+   if (i = 0) {
+   aud-treble = i;
+   aud-flags |= VIDEO_AUDIO_TREBLE;
+   }
+   i = v4l2_get_control(fd, V4L2_CID_AUDIO_BALANCE);
+   if (i = 0) {
+   aud-balance = i;
+   aud-flags |= VIDEO_AUDIO_BALANCE;
+   }
+   i = v4l2_get_control(fd, V4L2_CID_AUDIO_MUTE);
+   if (i = 0) {
+   if (i)
+   aud-flags |= VIDEO_AUDIO_MUTE;
+
+   aud-flags |= VIDEO_AUDIO_MUTABLE;
+   }
+   aud-step = 1;
+   qctrl2.id = V4L2_CID_AUDIO_VOLUME;
+   if (v4l2_ioctl(fd, VIDIOC_QUERYCTRL, qctrl2) == 0 
+   !(qctrl2.flags  V4L2_CTRL_FLAG_DISABLED))
+   aud-step = qctrl2.step;
+   aud-mode = 0;
+
+   result

Re: [PATCH] Add the viafb video capture driver

2010-06-07 Thread Mauro Carvalho Chehab

Em 07-06-2010 23:31, Jonathan Corbet escreveu:
 On Tue, 8 Jun 2010 03:03:14 +0200
 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
 
 If it's not too late for review, here are some comments. I've reviewed the 
 code from bottom to top, so comments might be a bit inconsistent sometimes.
 
 Never too late to make the code better.  These are good comments, thanks.
 Mauro, I guess I've got another version coming...:)

Ok, I'll be waiting for it ;)

Cheers,
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: v4l-dvb - Is it still usable for a distribution ?