You can use "make menuconfig" in /usr/src/multiproto and find the following information:
Empia EM2800/2820/2840 USB video capture support (VIDEO_EM28XX) [N/m/?]
Key the "N".
Last,repeat "make".> From: vdr-request@linuxtv.org> Subject: vdr Digest, Vol 42, Issue 11> To: vdr@linuxtv.org> Date: Sat, 12 Jul 2008 12:00:02 +0200> > Send vdr mailing list submissions to> vdr@linuxtv.org> > To subscribe or unsubscribe via the World Wide Web, visit> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr%3E or, via email, send a message with subject or body 'help' to> vdr-request@linuxtv.org> > You can reach the person managing the list at> vdr-owner@linuxtv.org> > When replying, please edit your Subject line so it is more specific> than "Re: Contents of vdr digest..."> > > Today's Topics:> > 1. Re: multiproto_plus is ancient (Lauri Tischler)> 2. Re: multiproto_plus is ancient (Lauri Tischler)> 3. Re: multiproto_plus is ancient (Artem Makhutov)> 4. Control VDR with RF remote (Michael Stepanov)> 5. Vdr-xine OSD question (Todd Luliak)> 6. Re: Control VDR with RF remote (Peer Oliver Schmidt)> 7. Re: Vdr-xine OSD question ( Antti Sepp?l? )> 8. xine tvtime parameters explained (Lauri Tischler)> > > ----------------------------------------------------------------------> > Message: 1> Date: Fri, 11 Jul 2008 13:14:56 +0300> From: Lauri Tischler lwgt@iki.fi> Subject: Re: [vdr] multiproto_plus is ancient> To: VDR Mailing List vdr@linuxtv.org> Message-ID: 487732A0.6060904@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > VDR User wrote:> > On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler lwgt@iki.fi wrote:> >> What 'FF mod card' are you referring to ?> > > > There's a hardware hack to allow the full transport stream to be> > passed by the Nexus. By default it doesn't so when there's heavy> > load, a lot of packets are dropped.> > > >> I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T> >> cards, in near future I will get some S2 capable card.> >> So, what tree should I use for VDR 1.7.xx ?> > > > For a stock Nexus-s, you can use any tree. V4L with the vdr api> > wrapper patch, or *multiproto*.> > Hmmm.. compile error....> ----> CC [M] /usr/src/multiproto/v4l/em28xx-audio.o> In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39:> include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a > function)> /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > initializer not of integer type> /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization > for 'index')> make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2> make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic'> make[1]: *** [default] Error 2> make[1]: Leaving directory `/usr/src/multiproto/v4l'> ----> > > > ------------------------------> > Message: 2> Date: Fri, 11 Jul 2008 16:13:05 +0300> From: Lauri Tischler lwgt@iki.fi> Subject: Re: [vdr] multiproto_plus is ancient> To: VDR Mailing List vdr@linuxtv.org> Message-ID: 48775C61.3050908@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Lauri Tischler wrote:> > VDR User wrote:> >> On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler lwgt@iki.fi wrote:> >>> What 'FF mod card' are you referring to ?> >> There's a hardware hack to allow the full transport stream to be> >> passed by the Nexus. By default it doesn't so when there's heavy> >> load, a lot of packets are dropped.> >>> >>> I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T> >>> cards, in near future I will get some S2 capable card.> >>> So, what tree should I use for VDR 1.7.xx ?> >> For a stock Nexus-s, you can use any tree. V4L with the vdr api> >> wrapper patch, or *multiproto*.> > > > Hmmm.. compile error....> > ----> > CC [M] /usr/src/multiproto/v4l/em28xx-audio.o> > In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39:> > include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a > > function)> > /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > > initializer not of integer type> > /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization > > for 'index')> > make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> > make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2> > make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic'> > make[1]: *** [default] Error 2> > make[1]: Leaving directory `/usr/src/multiproto/v4l'> > ----> > otoh the v4l-dvb tree compiles just fine but multiproto does not.> > > > ------------------------------> > Message: 3> Date: Fri, 11 Jul 2008 15:30:25 +0200> From: Artem Makhutov artem@makhutov.org> Subject: Re: [vdr] multiproto_plus is ancient> To: VDR Mailing List vdr@linuxtv.org> Message-ID: 20080711133025.GA23628@moelleritberatung.de> Content-Type: text/plain; charset=us-ascii> > Hi,> > On Fri, Jul 11, 2008 at 01:14:56PM +0300, Lauri Tischler wrote:> > VDR User wrote:> > > On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler lwgt@iki.fi wrote:> > >> What 'FF mod card' are you referring to ?> > > > > > There's a hardware hack to allow the full transport stream to be> > > passed by the Nexus. By default it doesn't so when there's heavy> > > load, a lot of packets are dropped.> > > > > >> I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T> > >> cards, in near future I will get some S2 capable card.> > >> So, what tree should I use for VDR 1.7.xx ?> > > > > > For a stock Nexus-s, you can use any tree. V4L with the vdr api> > > wrapper patch, or *multiproto*.> > > > Hmmm.. compile error....> > ----> > CC [M] /usr/src/multiproto/v4l/em28xx-audio.o> > In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39:> > include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a > > function)> > /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > > initializer not of integer type> > /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization > > for 'index')> > make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> > make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2> > make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic'> > make[1]: *** [default] Error 2> > make[1]: Leaving directory `/usr/src/multiproto/v4l'> > ----> > You need this patch:> > http://linuxtv.org/hg/v4l-dvb/raw-diff/b0815101889d/v4l/compat.h%3E > Please take a look at> http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023819.html%3E > > Maybe the patch should be directly merged into the multiproto tree...> > Regards, Artem> > -- > Artem Makhutov> Unterort Str. 36> D-65760 Eschborn> > > > ------------------------------> > Message: 4> Date: Fri, 11 Jul 2008 17:35:36 +0300> From: "Michael Stepanov" michael@stepanoff.org> Subject: [vdr] Control VDR with RF remote> To: vdr@linuxtv.org> Message-ID:> 65922d730807110735o765771f4id685cdd7b6345a9@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"> > Hi,> > Does anybody use RF remote control with VDR instead of IR? How to configure> such remotes?> > Thanks in advance.> > -- > Cheers,> Michael> -------------- next part --------------> An HTML attachment was scrubbed...> URL: http://www.linuxtv.org/pipermail/vdr/attachments/20080711/0ecc1aee/attachmen... > > ------------------------------> > Message: 5> Date: Fri, 11 Jul 2008 10:10:14 -0700 (PDT)> From: Todd Luliak javatodd32@yahoo.com> Subject: [vdr] Vdr-xine OSD question> To: vdr@linuxtv.org> Message-ID: 580290.30275.qm@web39807.mail.mud.yahoo.com> Content-Type: text/plain; charset="us-ascii"> > I am running vdr + vdr-xine plugin + coreavc + xine being output at> 1080i to an HDTV as the only display. Is there a simple way to lock the> OSD to the resolution of the output device such that the OSD is not> rescaled when switching between SD and HD sources? I played with> X-overlay, but that was not what I was after. If not, could it be done> in the source somewhere or is the OSD anti-aliased and overlayed on the> video before being sent to the output device (xine, in my case)? I've> looked around quite a bit on the net but I guess my google-foo is> failing me on this one. I just miss the rock-solid OSD of the FF card> setup...> > Thanks!> > > > > > -------------- next part --------------> An HTML attachment was scrubbed...> URL: http://www.linuxtv.org/pipermail/vdr/attachments/20080711/f6f5c05d/attachmen... > > ------------------------------> > Message: 6> Date: Fri, 11 Jul 2008 21:04:07 +0200> From: Peer Oliver Schmidt pos@theinternet.de> Subject: Re: [vdr] Control VDR with RF remote> To: VDR Mailing List vdr@linuxtv.org> Message-ID: 4877AEA7.1070704@theinternet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Hello Michael,> > > Does anybody use RF remote control with VDR instead of IR? How to > > configure such remotes?> > I used the ATI RemoteWonder with it. LIRC has support for it.> > ps: But you should stay with lmce ;)> -- > Best regards> > Peer Oliver Schmidt> the internet company> PGP Key ID: 0x83E1C2EA> > > > > ------------------------------> > Message: 7> Date: Fri, 11 Jul 2008 22:14:01 +0300> From: " Antti Sepp?l? " a.seppala+vdr@gmail.com> Subject: Re: [vdr] Vdr-xine OSD question> To: "VDR Mailing List" vdr@linuxtv.org> Message-ID:> 5e1d45280807111214x5254127cu3f1f5533e5c23aa4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1> > 2008/7/11 Todd Luliak javatodd32@yahoo.com:> > I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to> > an HDTV as the only display. Is there a simple way to lock the OSD to the> > resolution of the output device such that the OSD is not rescaled when> > switching between SD and HD sources? I played with X-overlay, but that was> > not what I was after. If not, could it be done in the source somewhere or is> > the OSD anti-aliased and overlayed on the video before being sent to the> > output device (xine, in my case)? I've looked around quite a bit on the net> > but I guess my google-foo is failing me on this one. I just miss the> > rock-solid OSD of the FF card setup...> > Thanks!> >> > In an effort to create something to solve such issues with> xineliboutput plugin I came up with an idea of this HUD type OSD.> Basically it means that OSD is rendered to a separate transparent> surface on top of video and then these are blended together by the> display hardware. This way the size of the OSD is bound to the size of> the used window rather than the size of the video stream. In other> words no OSD scaling will be necessary even though the video size> changes.> > The HUD implementation has been integrated into the CVS of> xineliboutput plugin. To operate it requires support for xorg render> extension and presence of composite display manager such as xcompmgr.> It also requires powerful display adapter and drivers with support for> these modern extensions. Maybe you can try it to see if it produces> results that you are hoping for?> > Regards,> > -- > Antti Sepp?l?> a.seppala@gmail.com> > > > ------------------------------> > Message: 8> Date: Sat, 12 Jul 2008 11:23:49 +0300> From: Lauri Tischler lwgt@iki.fi> Subject: [vdr] xine tvtime parameters explained> To: VDR Mailing List vdr@linuxtv.org> Message-ID: 48786A15.30804@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Trying to google for manual, info or article where all parameters for> xine tvtime command are explained, what they do, why, etc.> No luck yet, any pointers ??> > > > ------------------------------> > _______________________________________________> vdr mailing list> vdr@linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr%3E > > End of vdr Digest, Vol 42, Issue 11> *********************************** _________________________________________________________________ 这里好多好玩的视频，用鼠标点到视频看看，有惊喜！ http://cnweb.search.live.com/video/results.aspx?q=%E5%A5%A5%E8%BF%90%E5%9C%A...