Re: nuvoton-cir on Intel DH67CL
On Mon, 19 Mar 2012 17:00:11 -0400 Jarod Wilson wrote: > On Wed, Mar 14, 2012 at 10:32:43PM +0100, Steffen Barszus wrote: > > Anything to be activated to wakeup on S3/S5 ? I.e. the key to wake > > it up ? I'm using RC6 remote - operation as already said is without > > any issues, just not wakeup. > > It occurs to me that the box I've got had Windows on it at one point, > and its possible wake via IR works only because someone set a wake > key pattern under Windows. And that your box doesn't wake, because it > hasn't had a wake key pattern set yet. We don't have any UI for > setting a wake key pattern just yet... (Or if we do, I'm just not > familiar with it). Anything i can do to help getting it going ? (Except writing a driver) I could not find any reference to a tool either - so i guess it just doesnt exist :) -- 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: nuvoton-cir on Intel DH67CL
On Wed, 14 Mar 2012 16:41:01 -0400 Jarod Wilson wrote: > On Wed, Mar 14, 2012 at 07:10:37AM +0100, Steffen Barszus wrote: > > Hi ! > > > > I'm using above board which has a nuvoton-cir onboard (as most Intel > > Media boards) - It shows itself as NTN0530. > > > > The remote function works without a problem (loaded RC6 MCE > > keytable). > > > > What doesn't work is wake from S3 and wake from S5. There are some > > rumors that installing Windows 7 and corresponding drivers has a > > positive effect (for some it seems to be enough to do it one time, > > others need to redo this from time to time (power loss?). This > > leads me to believe, that some hardware initialization is missing. > > > > I'm about to try latest linux-media tree next days, but i believe > > there hasn't been any change on this driver. > > > > My questions: > > - any idea of what i should look at ? > > - any change on the driver i could try ? > > - *IF* i go to install Win7 and drivers - anything i could to to > > help tracking down what this does in order to make the driver work > > out of the box on linux ? > > > > As a lot of Sandy Bridge Boards to have this chip lately - it would > > be nice if this could just work or is my impression, that this is a > > general problem in this hardware wrong ? > > My only nuvoton hardware works perfectly w/resume via IR after commit > 3198ed161c9be9bbd15bb2e9c22561248cac6e6a, but its possible what > you've got is a newer hardware variant with some slightly different > registers to tweak. What does the driver identify your chip as in > dmesg? I'm on Linux 3.2.0-18-generic #29-Ubuntu SMP (Ubuntu Precise) > As of commit 362d3a3a9592598cef1d3e211ad998eb844dc5f3, the driver will > bind to anything with the PNP ID of NTN0530, but will spew a warning > in dmesg if its not an explicitly recognized chip. > >From dmesg it seems to be fine. [0.553258] system 00:02: [io 0x0290-0x029f] has been reserved [0.553261] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active) [0.553504] pnp 00:03: [io 0x0240-0x024f] [0.553513] pnp 00:03: [irq 3] [0.553515] pnp 00:03: [io 0x0250-0x025f] [0.553534] pnp 00:03: Plug and Play ACPI device, IDs NTN0530 (active) [0.553544] pnp 00:04: [dma 4] [0.553545] pnp 00:04: [io 0x-0x000f] [0.553547] pnp 00:04: [io 0x0081-0x0083] [0.553549] pnp 00:04: [io 0x0087] [0.553550] pnp 00:04: [io 0x0089-0x008b] [0.553552] pnp 00:04: [io 0x008f] [0.553553] pnp 00:04: [io 0x00c0-0x00df] Anything to be activated to wakeup on S3/S5 ? I.e. the key to wake it up ? I'm using RC6 remote - operation as already said is without any issues, just not wakeup. More from dmesg: [2.722598] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/pnp0/00:03/rc/rc0/input2 [2.722659] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/pnp0/00:03/rc/rc0 [2.726726] nuvoton_cir: driver has been successfully loaded [2.772201] IR NEC protocol handler initialized [2.786605] IR RC5(x) protocol handler initialized [2.806280] IR RC6 protocol handler initialized [2.840479] IR JVC protocol handler initialized [2.854668] IR Sony protocol handler initialized [2.891067] lp: driver loaded but no devices found [2.895757] ngene: Loading firmware file ngene_18.fw. [2.917163] ngene :04:00.0: irq 50 for MSI/MSI-X [2.918618] error in i2c_read_reg [2.918620] No CXD2099 detected at 40 [2.925856] input: MCE IR Keyboard/Mouse (nuvoton-cir) as /devices/virtual/input/input3 [2.925990] IR MCE Keyboard/mouse protocol handler initialized [2.936180] lirc_dev: IR Remote Control driver registered, major 250 [2.944124] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 [2.944127] IR LIRC bridge handler initialized [2.958002] usbcore: registered new interface driver usbhid [2.958005] usbhid: USB HID core driver [3.005172] w83627ehf: Found NCT6775F chip at 0x290 Looking at the kernel source for 3.2 i should be fine i think. (the commits you mentioned) -- 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
nuvoton-cir on Intel DH67CL
Hi ! I'm using above board which has a nuvoton-cir onboard (as most Intel Media boards) - It shows itself as NTN0530. The remote function works without a problem (loaded RC6 MCE keytable). What doesn't work is wake from S3 and wake from S5. There are some rumors that installing Windows 7 and corresponding drivers has a positive effect (for some it seems to be enough to do it one time, others need to redo this from time to time (power loss?). This leads me to believe, that some hardware initialization is missing. I'm about to try latest linux-media tree next days, but i believe there hasn't been any change on this driver. My questions: - any idea of what i should look at ? - any change on the driver i could try ? - *IF* i go to install Win7 and drivers - anything i could to to help tracking down what this does in order to make the driver work out of the box on linux ? As a lot of Sandy Bridge Boards to have this chip lately - it would be nice if this could just work or is my impression, that this is a general problem in this hardware wrong ? -- 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: femon signal strength
On Sun, 6 Nov 2011 10:01:49 -0500 Devin Heitmueller wrote: > On Sunday, November 6, 2011, Steffen Barszus > wrote: > > On Sat, 5 Nov 2011 15:38:50 -0400 > > Devin Heitmueller wrote: > > > >> On Saturday, November 5, 2011, Steffen Barszus > >> wrote: > >> > On Wed, 26 Oct 2011 15:58:32 -0400 > >> > James wrote: > >> >> How about adding switches to femon, it won't be automatic? > >> >> > >> >> I'm going to make femon work for my card, anyways. :-) > >> > > >> > This is no solution - drivers should be patched to deliver > >> > result in common format. femon is not the only application > >> > reading this values. And every application carrying its own set > >> > of correction tables doesn't help in any way. Shouldn't be to > >> > hard to agree on one scale and scale whatever value to that in > >> > reporting the signal strength. > >> > >> You would think this would be relatively simple to get a consensus > >> on. You would be wrong though. I would suggest doing a search of > >> the ML for "SNR" so you can see all. the history of the debate > >> amongst the driver developers. > > > > I don't need to read the history of this and i am not even > > interested in doing so. No matter what "The right solution" is, > > showing the inability of acting as a team and putting the conflict > > to the user is the worst solution you can achieve. Any uniform > > scale is better, then whats there at the moment. > > > > Being ignorant in this respect is and was intended. > > Yes, as a team the Linux v4l-dvb team very much resembles > dysfunctional family. And saying this as one of the developers, it > is pretty embarrassing that we haven't been able to agree on a > standard (and I've said on numerous occasions when discussing this > issue that any standard that is uniform is better than no standard at > all). "Perfect is the enemy of good" i know that and i didn't mention with any word _you_ should fix that. However it needs to be fixed. > That said, when random users show up and berate the developers for not > thinking of the user experience, my knee-jerk reaction is to think, > "Fuck you. You don't pay my salary and it's not my job to work on > the things you think are important. Submit you own patches if you > think you can do better.". Obviously I don't say that because it > isn't polite, but the core sentiment is accurate. First i did not berate anyone. Second i don't care if you think about user experience. I said don't put your conflicts to the user. Third I don't tell you what to do. I just stated the obvious. Let me rephrase what i tried to say initially: No please don't start patching femon for a single card, there are other applications using this interface, which would possibly need to go the same route, once this get started. Then there are applications which wont do this (which i can understand, because its wrong). Suggestion will be to patch/fix the driver - which in the end means that the fight will be done at the back of the end user or people who try to make life easier for them and for example putting together specialized linux distributions. So from my perspective it means that beside this patches: ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/ It will start to become more patches for the different cards, which i get asked for to include it in my dkms package, or people start making patches for vdr and other applications to do the same as suggested here, which also end up at the same side. This is frustrating. Has my frustration been visible in my mail ? Not impossible. But where else than on this list i could plead for help in getting this fixed at the right place ? Devin i'm not asking you to fix it, i'm writing to linux-media as i did in my initial mail. -- 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: femon signal strength
On Sat, 5 Nov 2011 15:38:50 -0400 Devin Heitmueller wrote: > On Saturday, November 5, 2011, Steffen Barszus > wrote: > > On Wed, 26 Oct 2011 15:58:32 -0400 > > James wrote: > >> How about adding switches to femon, it won't be automatic? > >> > >> I'm going to make femon work for my card, anyways. :-) > > > > This is no solution - drivers should be patched to deliver result in > > common format. femon is not the only application reading this > > values. And every application carrying its own set of correction > > tables doesn't help in any way. Shouldn't be to hard to agree on > > one scale and scale whatever value to that in reporting the signal > > strength. > > You would think this would be relatively simple to get a consensus on. > You would be wrong though. I would suggest doing a search of the ML > for "SNR" so you can see all. the history of the debate amongst the > driver developers. I don't need to read the history of this and i am not even interested in doing so. No matter what "The right solution" is, showing the inability of acting as a team and putting the conflict to the user is the worst solution you can achieve. Any uniform scale is better, then whats there at the moment. Being ignorant in this respect is and was intended. -- 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: femon signal strength
On Wed, 26 Oct 2011 15:58:32 -0400 James wrote: > On 10/26/11 15:49, Devin Heitmueller wrote: > > On Wed, Oct 26, 2011 at 3:45 PM, James wrote: > >> How many different formats are there (do I have to go through the > >> archive)? Would it be feasable to change femon to handle different > >> formats? > > There are three or four common formats, and there is no real way for > > an application to know which format was used unless it perhaps > > hard-codes some table of demodulator driver names into the source > > (which by the way will cause breakage if efforts are made to change > > the demods to use a common format). > > > > Devin > > > I was thinking of a table. :-) > > How about adding switches to femon, it won't be automatic? > > I'm going to make femon work for my card, anyways. :-) This is no solution - drivers should be patched to deliver result in common format. femon is not the only application reading this values. And every application carrying its own set of correction tables doesn't help in any way. Shouldn't be to hard to agree on one scale and scale whatever value to that in reporting the signal strength. -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Hi ! >From a users point of view i would like to have some clarification on this discussion. Lets take a (now real world) example. Having /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/net0 /dev/dvb/adapter1/demux0 /dev/dvb/adapter1/dvr0 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/frontend1 /dev/dvb/adapter1/net0 for a C/T card, where one fe is C and the other is T , connector is only one per adapter. How is the logic to handle this ? Two big issues i don't properly understand at the moment. 1.) VDR does not know that frontend1 is related to demux0. since no application changes magically on its own, can someone provide some information of what an application is expected to do, to handle this properly. With this information it could be discussed at i.e. vdr mailing list. 2.) How does an application/user/whatever know what can be used ? I mean there is only C connected OR T - how can the application know what fe can be used (assumed point 1. has been fixed). How would the user know, which is which and how one should specify what is connected ? 3.) ca/caio device handling - is this something an application should implement ... and how. Please help me to understand these points as this is something which pops up regular in discussion with our (yavdr.org) users. For 1 and 2 the only proper solution i see would be 1 frontend instead of 2 with a possibility to specifiy the transport in one way or another. (which -> to be discussed) Regards Steffen On Sat, 16 Jul 2011 17:40:53 +0200 Oliver Endriss wrote: > On Saturday 16 July 2011 16:54:50 Mauro Carvalho Chehab wrote: > > Em 16-07-2011 11:16, Antti Palosaari escreveu: > > > On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: > > >> Em 15-07-2011 20:41, Antti Palosaari escreveu: > > >>> On 07/15/2011 08:01 PM, Andreas Oberritter wrote: > > On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: > > > Em 15-07-2011 05:26, Ralph Metzler escreveu: > > >> At the same time I want to add delivery system properties to > > >> support everything in one frontend device. > > >> Adding a parameter to select C or T as default should help > > >> in most cases where the application does not support > > >> switching yet. > > > > > > If I understood well, creating a multi-delivery type of > > > frontend for devices like DRX-K makes sense for me. > > > > > > We need to take some care about how to add support for them, > > > to avoid breaking userspace, or to follow kernel deprecating > > > rules, by adding some legacy compatibility glue for a few > > > kernel versions. So, the sooner we add such support, the > > > better, as less drivers will need to support a "fallback" > > > mechanism. > > > > > > The current DVB version 5 API doesn't prevent some userspace > > > application to change the delivery system[1] for a given > > > frontend. This feature is actually used by DVB-T2 and DVB-S2 > > > drivers. This actually improved the DVB API multi-fe support, > > > by avoiding the need of create of a secondary frontend for > > > T2/S2. > > > > > > Userspace applications can detect that feature by using > > > FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow > > > other types of changes like from/to DVB-T/DVB-C or from/to > > > DVB-T/ISDB-T. So, drivers that allow such type of delivery > > > system switch, using the same chip ended by needing to add > > > two frontends. > > > > > > Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to > > > fe_caps_t, and add a way to query the type of delivery > > > systems supported by a driver. > > > > > > [1] > > > http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM > > > > I don't think it's necessary to add a new flag. It should be > > sufficient to add a property like > > "DTV_SUPPORTED_DELIVERY_SYSTEMS", which should be read-only > > and return an array of type fe_delivery_system_t. > > > > Querying this new property on present kernels hopefully fails > > with a non-zero return code. in which case FE_GET_INFO should > > be used to query the delivery system. > > > > In future kernels we can provide a default implementation, > > returning exactly one fe_delivery_system_t for unported > > drivers. Other drivers should be able to override this default > > implementation in their get_property callback. > > >>> > > >>> One thing I want to say is that consider about devices which > > >>> does have MFE using two different *physical* demods, not > > >>> integrated to same silicon. > > >>> > > >>> If you add such FE delsys switch mechanism it needs some more > > >>> glue to bind two physical FEs to one virtual FE. I see much > > >>> easier to keep all FEs as own - just re
Re: [PATCH] Add support for PCTV452E.
On Fri, 23 Sep 2011 17:03:04 -0300
Mauro Carvalho Chehab wrote:
> >
> > Attached is the 'new' version of the patch with the mentioned
> > changes.
>
> For it to be applied, we need the SOB's of the patch authors:
>
> +MODULE_AUTHOR("Dominik Kuhlen ");
> +MODULE_AUTHOR("Andre Weidemann ");
> +MODULE_AUTHOR("Michael H. Schimek ");
>
> Also, the patch needs some adjustments to be applied. See bellow for
> my quick review:
Another note - for the move of remote to rc-core (as suggested by
you) there is another patch waiting in your Inbox 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: [PATCH] Add support for PCTV452E.
On Fri, 23 Sep 2011 17:03:04 -0300
Mauro Carvalho Chehab wrote:
> Em 05-09-2011 18:27, Oliver Freyermuth escreveu:
> > Got it working with kernel 3.0!
> >
> > For me, some more changes on the current patchset appeared to be
> > necessary. In short, I had to change all a->fe to a->fe[0] (because
> > of 3.0-kernel) and I had to add lnbp22 to Kconfig (it would
> > otherwise have been disabled and not been built, although other
> > modules depended on it...).
> >
> > I also had to add the additional
> > "EXPORT_SYMBOL(ttpci_eeprom_decode_mac);" as mentioned by Doychin
> > Dokov.
> >
> > Attached is the 'new' version of the patch with the mentioned
> > changes.
>
> For it to be applied, we need the SOB's of the patch authors:
>
> +MODULE_AUTHOR("Dominik Kuhlen ");
> +MODULE_AUTHOR("Andre Weidemann ");
> +MODULE_AUTHOR("Michael H. Schimek ");
I tried to ping Dominik Kuhlen at least a couple of times - without a
reply. Is this a must or nice to have ? Is there a workaround or is
this driver at dead end then ? I can only confirm that the driver is
working with the mentioned changes.
--
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 support for PCTV452E.
On Wed, 15 Jun 2011 18:44:35 +0300 "Igor M. Liplianin" wrote: > From my point of view we can count the beginning was here: > > http://www.spinics.net/lists/linux-dvb/msg26431.html > > The later history is difficult to restore, but possible. > After some searching it looks like this is the first occurrence of the driver: http://www.linuxtv.org/pipermail/linux-dvb/2007-October/021403.html Further it looks like Dominik Kuhlen is not responding at that mail (as he has been on copy on one of the last mails. So looks like we cant get the signed-off-by from him. Does that mean the patch can't be applied and needs to be rewritten from scratch even if the author put the code under GPL2 back then ? Is there any rule for this ? See comment of Oliver Freyermuth - the driver seems to work (after altering it to make it work with current kernel), also got some postive feedback for it for kernel 2.6.38 and current 3.2 media_tree. Does someone have a definitive answer on how to go ahead ? What else is missing ? Thanks :) Steffen -- 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: patches missing in git ? - TT S2 1600
On Fri, 29 Apr 2011 10:48:15 -0300 Mauro Carvalho Chehab wrote: > Em 06-03-2011 10:20, Steffen Barszus escreveu: > > I have one patch lying around which will fix a kernel oops if more > > than one TT S2 1600 is build into the same computer. > > I think that the bug with two TT S2 devices at the same computer were > fixed, but I don't remember what were the adopted solution. > > I think that the change were inside tuner_sleep() callback, where > tuner_priv is actually used. > > So, as far as I know, this patch is obsolete. I'll mark it as > rejected on patchwork. Please test it without this patch and the > latest tree, pinging us if the error is still there. Late follow up - but i only _now_ have 2 of these card. Situation now is that it doesn't oops anymore - however its not fixed in the end. Problem which still exists: When one card is recording in vdr, the second card possibly doesnt get a lock anymore. if second "receiver" is live tv, switching back and forward a couple of times makes tuning possible in the end, but it can also break recording. So from overall picture its seems there are ressources which are not guarded against use at multiple devices. The fix for the oops has only fixed the immediate crash but did not solve the common use of ressources. Can you let me know how to start tracking this down ? Beside me i know a couple of others having more than one of these cards, and - if its the best/easiest way i could also imagine to organize temporary 2 of this cards for a developer able to fix it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T issues w/ kernel 3.0
Am 27. Juli 2011 16:37 schrieb Devin Heitmueller : > 2011/7/27 Toralf Förster : >> Hello, >> >> I'm wondering, whether there are known issues with the new kernel version >> just >> b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and >> https://bugs.kde.org/show_bug.cgi?id=278561 > > Hello Toralf, > > I don't think you're the first person to report this issue. That > said, I don't think any developers have seen it, so it would be a very > useful exercise if you could bisect the kernel and figure out which > patch introduced the problem. > > Once we know what patch introduced the problem we will have a much > better idea what action needs to be taken to address it. It's about dib0700 driver also reported here: http://www.spinics.net/lists/linux-media/msg35763.html few days ago. Quote: "The drivers from 2011-02-05 does not run, but the drivers from 2010-10-16 runs perfectly. " should give at least a startingpoint/timeframe for bisecting ... allthough would be more usefull if based linuxtv git. -- 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 support for PCTV452E.
On Tue, 24 May 2011 21:51:22 +0200
Hans Petter Selasky wrote:
> NOTES:
>
> Sources were taken from the following repositorium as of today:
> http://mercurial.intuxication.org/hg/s2-liplianin/
>
> And depend on the zig-zag fix posted today.
Did a first test on the patch.
[ 96.780040] usb 1-8: new high speed USB device using ehci_hcd and address 5
[ 97.376058] dvb_usb_pctv452e: Unknown symbol ttpci_eeprom_decode_mac (err 0)
Looks like this patch didn't make it into patchwork - Mauro can you
check that ?
I think the patch for ttpci-eeprom.c is missing this:
--- linux/drivers/media/dvb/ttpci/ttpci-eeprom.c.orig 2011-07-23
11:00:49.0 +
+++ linux/drivers/media/dvb/ttpci/ttpci-eeprom.c2011-07-23
11:04:00.0 +
@@ -165,6 +165,7 @@ int ttpci_eeprom_parse_mac(struct i2c_ad
}
EXPORT_SYMBOL(ttpci_eeprom_parse_mac);
+EXPORT_SYMBOL(ttpci_eeprom_decode_mac);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Ralph Metzler, Marcus Metzler, others");
--
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: RTL2831U driver updates
On Wed, 22 Jun 2011 07:34:31 +0200 Jan Hoogenraad wrote: > Thanks. Do you know more about this subject ? > > We do have specs about the chipset, but > > http://linuxtv.org/downloads/v4l-dvb-apis/remote_controllers.html#Remote_controllers_Intro > > only mentions lirc, not rc-core. > This is about where my knowledge stops, however. > > rc-core is only mentioned shortly in: > http://linuxtv.org/wiki/index.php/Remote_Controllers I think/hope Jarod can comment on this - i just know that new remotes should use rc-core, as this is the "new thing" for this. I'm no developer whatsoever :) > > Steffen Barszus wrote: > > 2011/6/21 Jan Hoogenraad: > >> and add the IR remote interface, based > >> on the LIRC framework. > >> It actually should yield little code, and mainly requires a) > >> understanding of LIRC and b) comparing code tables to that the > >> in-kernel code tables can be re-used. > > > > > > sorry for the noise , but i guess you mean rc-core not Lirc > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-media" in the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL2831U driver updates
2011/6/21 Jan Hoogenraad : > and add the IR remote interface, based > on the LIRC framework. > It actually should yield little code, and mainly requires a) understanding > of LIRC and b) comparing code tables to that the in-kernel code tables can > be re-used. sorry for the noise , but i guess you mean rc-core not Lirc -- 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: stb0899/stb6100 tuning problems
On Sat, 23 Apr 2011 22:55:27 +0200 Issa Gorissen wrote: > Hi, > > Running kernel 2.6.39rc4. I've got trouble with tuning some > transponders on Hotbird 13°E with a TT S2-3200. > The transponders have been emitting DVB-S until end of march when they > now emit DVB-S2 signals. They are: > - 11681.00H 27500 3/4 8psk nid:319 tid:15900 on Hotbird 6 > - 12692.00H 27500 3/4 8psk nid:319 tid:9900 on Hotbird 9 > > > [1] https://patchwork.kernel.org/patch/244201/ > [2] > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html > > 1) Patch [2] is merged into kernel 2.6.39rc4. Using scan-s2, I get no > service available. > > 2) I applied patch [1] and still could not get any service with > scan-s2 from those transponders. > > 3) I *reverted* patch[2] and now scan-s2 returns partial results. > scan-s2 can tune onto the transponder on Hotbird 6 really quick and > gives back the full services list. > But I have to run scan-s2 with scan iterations count set to as high as > 100 to be able to get results from the transponder on Hotbird 9. > > When those transponders were emitting in DVB-S, I had no problem at > all. > > Can someone try the same thing on those transponders and report > please ? As mentioned before, try to use [1] + [2] + following patch. I would expect this to be working. Please confirm. --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-02-26 06:44:11.0 + +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-04-24 07:39:06.0 + @@ -1426,9 +1426,9 @@ static void stb0899_set_iterations(struc if (iter_scale > config->ldpc_max_iter) iter_scale = config->ldpc_max_iter; - reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); + reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); - stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); + stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); } static enum dvbfe_search stb0899_search(struct dvb_frontend *fe, struct dvb_frontend_parameters *p) -- 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] Fixes stb0899 not locking
On Mon, 04 Apr 2011 14:02:31 +0200 Lutz Sammer wrote: > Fixes stb0899 not locking. > See http://www.spinics.net/lists/linux-media/msg30486.html ... > > When stb0899_check_data is entered, it could happen, that the data is > already locked and the data search looped. stb0899_check_data fails > to lock on a good frequency. stb0899_search_data uses an extrem big > search step and fails to lock. > > The new code checks for lock before starting a new search. > The first read ignores the loop bit, for the case that the loop bit is > set during the search setup. I also added the msleep to reduce the > traffic on the i2c bus. Any updates on this one, or does this really need to be discussed. Its proven now, that here is a bug, there was enough discussion before. Can this PLEASE get applied. What proofs are needed, anything wrong with it , at least ANY comment on it ? I'm starting to hate that its hidden trough v4l development causing that DVB development is dead. This sucks ... Is there any DVB developer on this list ? Someone who can check and comment or approve this patch ? 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: [PATCH] Fixes stb0899 not locking
On Mon, 04 Apr 2011 14:02:31 +0200 Lutz Sammer wrote: > Fixes stb0899 not locking. > See http://www.spinics.net/lists/linux-media/msg30486.html ... > > When stb0899_check_data is entered, it could happen, that the data is > already locked and the data search looped. stb0899_check_data fails > to lock on a good frequency. stb0899_search_data uses an extrem big > search step and fails to lock. > > The new code checks for lock before starting a new search. > The first read ignores the loop bit, for the case that the loop bit is > set during the search setup. I also added the msleep to reduce the > traffic on the i2c bus. > Thanks Lutz for getting down to the problem :) ! Manu, Mauro, Any comments ? Let's have that finally sorted. I think its proven now that its a bug. We have a fix. --- A few test result on 2.6.39-rc3 from vdr-portal(thx to jrie, hope its ok for him). This is tuning a pre defined channel list until we have a lock and then tune the next. Astra_only.txt + Original TOT: lok_errs =172, runs=1136 of sequ=1135, multi=56032, multi_max=931 real 101m40.777s user 0m0.083s sys 0m19.039s Astra_only.txt + stb0899_not_locking_fix.diff TOT: lok_errs =0, runs=1136 of sequ=1135, multi=289, multi_max=99 real 17m15.636s user 0m0.007s sys 0m9.445s -- 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On Tue, 05 Apr 2011 13:00:14 +0200 "Issa Gorissen" wrote: > Hi, > > Eutelsat made a recent migration from DVB-S to DVB-S2 (since > 31/3/2011) on two transponders on HB13E > > - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 > Msymb/s 0.2 Pilot off Polar H > > - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 > Msymb/s 0.2 Pilot off Polar H > > > Before those changes, with my TT S2 3200, I was able to watch TV on > those transponders. Now, I cannot even tune on those transponders. I > have tried with scan-s2 and w_scan and the latest drivers from git. > They both find the transponders but cannot tune onto it. > > Something noteworthy is that my other card, a DuoFlex S2 can tune > fine on those transponders. > > My question is; can someone try this as well with a TT S2 3200 and > post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen -- 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: Skystar 2 2.6 broken in kernel 2.6.38
On Sun, 3 Apr 2011 17:41:42 +0200 Patrick Boettcher wrote: > Hi, > > On Saturday 02 April 2011 21:30:53 Steffen Barszus wrote: > > Hi > > > > I just installed natty and found that one of the drivers i use is > > broken. Is this a known issue ? > > > > > > [6.115925] [ cut here ] > > [6.115931] WARNING: at > > /build/buildd/linux-2.6.38/fs/proc/generic.c:323 > > __xlate_proc_name+0xbb/0xd0() [6.115933] Hardware name: > > EP45T-UD3LR > > Actually the driver is not broken as it still works. This is a > warning issued by the core because the driver is using a bad string. > There have been a lot of attempts to fix it in the past, but they > have been lost somewhere on the road. > > I hope this time it will make it. Cool, thx, so its not as bad as i thought :) Also have seen your pull request. Thanks for taking care ! Kind Regards Steffen -- 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
Skystar 2 2.6 broken in kernel 2.6.38
Hi I just installed natty and found that one of the drivers i use is broken. Is this a known issue ? [6.115925] [ cut here ] [6.115931] WARNING: at /build/buildd/linux-2.6.38/fs/proc/generic.c:323 __xlate_proc_name+0xbb/0xd0() [6.115933] Hardware name: EP45T-UD3LR [6.115934] name 'Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver' [6.115935] Modules linked in: videobuf_dvb(+) b2c2_flexcop_pci(+) videobuf_core joydev v4l2_common b2c2_flexcop snd(+) dvb_core cx24123 cx24113 videodev btcx_risc soundcore s5h1420 tveeprom snd_page_alloc serio_raw sunrpc(+) lp parport hid_gyration usbhid hid r8169 pata_jmicron [6.115953] Pid: 518, comm: modprobe Tainted: P2.6.38-7-generic #39-Ubuntu [6.115955] Call Trace: [6.115959] [] ? warn_slowpath_common+0x72/0xa0 [6.115962] [] ? __xlate_proc_name+0xbb/0xd0 [6.115964] [] ? __xlate_proc_name+0xbb/0xd0 [6.115967] [] ? warn_slowpath_fmt+0x33/0x40 [6.115970] [] ? __xlate_proc_name+0xbb/0xd0 [6.115973] [] ? __proc_create+0x61/0x110 [6.115975] [] ? proc_mkdir_mode+0x26/0x60 [6.115978] [] ? proc_mkdir+0x14/0x20 [6.115981] [] ? register_handler_proc+0xeb/0x110 [6.115984] [] ? __setup_irq+0x1a7/0x2f0 [6.115987] [] ? kmem_cache_alloc_trace+0xdd/0x100 [6.115989] [] ? request_threaded_irq+0x79/0x120 [6.115992] [] ? request_threaded_irq+0x79/0x120 [6.116012] [] ? flexcop_pci_isr+0x0/0x140 [b2c2_flexcop_pci] [6.116015] [] ? request_threaded_irq+0xbc/0x120 [6.116018] [] ? pci_iomap+0x9e/0xb0 [6.116021] [] ? flexcop_pci_init+0xc4/0x120 [b2c2_flexcop_pci] [6.116025] [] ? flexcop_pci_probe+0xa5/0x1d0 [b2c2_flexcop_pci] [6.116028] [] ? local_pci_probe+0x47/0xb0 [6.116030] [] ? pci_device_probe+0x68/0x90 [6.116034] [] ? really_probe+0x4d/0x150 [6.116036] [] ? pm_runtime_barrier+0x4b/0xb0 [6.116039] [] ? driver_probe_device+0x3c/0x60 [6.116041] [] ? __driver_attach+0x81/0x90 [6.116043] [] ? __driver_attach+0x0/0x90 [6.116046] [] ? bus_for_each_dev+0x48/0x70 [6.116048] [] ? pci_device_remove+0x0/0xf0 [6.116050] [] ? driver_attach+0x1e/0x20 [6.116052] [] ? __driver_attach+0x0/0x90 [6.116054] [] ? bus_add_driver+0xb8/0x250 [6.116057] [] ? pci_device_remove+0x0/0xf0 [6.116059] [] ? driver_register+0x66/0x110 [6.116062] [] ? __pci_register_driver+0x45/0xb0 [6.116065] [] ? flexcop_pci_module_init+0x17/0x1000 [b2c2_flexcop_pci] [6.116068] [] ? do_one_initcall+0x35/0x170 [6.116070] [] ? flexcop_pci_module_init+0x0/0x1000 [b2c2_flexcop_pci] [6.116074] [] ? sys_init_module+0xdb/0x230 [6.116077] [] ? syscall_call+0x7/0xb [6.116079] ---[ end trace ea1b091448ed01ea ]--- -- 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: S2-3200 switching-timeouts on 2.6.38
2011/3/24 Julian Scheel : > Hi, > > Am 23.03.2011 19:19, schrieb H. Ellenberger: >> >> @Manu: Your argumentation is inconsistent and lacks any proof. >> >> Running a full scan of Astra 19.2 E with Kaffeine together with cards >> model >> Skystar HD and Twinhan/Azurewave VP-1041 results in a channel list of >> approx >> 400 stations only. When I apply my patch then almost all stations are >> found: >> >> patch in tuner: 400 stations found, not usable, > > With KNC TV-Station DVB-S2 (which is stb0899 as well) I can't confirm this > issue. Channel search finds > 1000 channels at any time. > >> patch in tuner + demod: 1127 stations found, better but less than without >> tuner patch. >> patch in demod only: 1145 stations found, slightly more than with tuner >> patch. > > Have you done both searches at (almost) same time? On astra network there > are quite some channels, which are only available and announced at certain > time, which can make a noticable difference in the amount of channels found. It has been done some work (and effort), to prove its having positive effect. you should allways have more then 1000 stations at any time on that SAT, if you see that maximum number of stations is somewhere at 1600. everything around 400 is broken hardware or driver. Please dont consider his post as single experience of a single user. The general perception was more like "Wow i can finally use that card and don't throw it away." from 10+ Users which i know of. So no matter if its considered done right or not. The tuning patch is out of question of improving the usability of the affected cards. The request has been, to prove that the changes at the stb6100 is not enough to actually fix the problem. This prove has been done now . The changes on the stb6100 is not enough, the changes at the stb0899 still has quite positive effect. So taking into account that the patch improves situation and doesn't have negative side effects for others, it might be wise to consider inclusion of the patch, even if it might not be the perfect solution from technical/theoretical perspective. I dont want to complain until the patch is in, its just: We have a problem, we have a solution. Lets use it and make this hardware useful for the people and lets do it right when time permits. There is still a handful of other patches for the same hardware floating around to improve other parts of that driver. I mean this hardware is known to work "less then perfect" since years, really. So please do something about it. Accept the helping hands. 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: Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
On Mon, 7 Mar 2011 17:22:39 -0600 Scott wrote: > > Same problem. I purged both linux-headers-2.6.35-27-generic, > linux-source-2.6.35, then reinstalled them, and did an apt-get > update/upgrade. I then deleted media_build and ran... linux-headers should be enough, no need for linux-source, and you need never both IMHO. > git clone git://linuxtv.org/media_build.git > cd media_build > ./build.sh > Compile breaks > vi vrl/.config changed CONFIG_DVB_FIREDTV=m to =n should not be necessary anymore, at least its not needed here. > ./build.sh You might want to try my dkms package - not sure if it works on maverick (its build on/for lucid) - but in theory it should (except if the number of modules differs for different kernel). If not you get atleast the latest source which compiles fine here. https://launchpad.net/~yavdr/+archive/testing-vdr/+packages?field.name_filter=v4l-dvb-dkms&field.status_filter=published&field.series_filter= Just uploaded new version with media_build and media_tree as of now. Let me know if it works. Steffen -- 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
patches missing in git ? - TT S2 1600
I have one patch lying around which will fix a kernel oops if more than
one TT S2 1600 is build into the same computer.
It still applies and compiles - does someone know if this has been
obsoleted by another patch or if that means it is still missing ?
Thanks !
Kind Regards
Steffen
diff -r 7c0b887911cf linux/drivers/media/dvb/frontends/stv090x.c
--- a/linux/drivers/media/dvb/frontends/stv090x.c Mon Apr 05 22:56:43
2010 -0400
+++ b/linux/drivers/media/dvb/frontends/stv090x.c Sun Apr 11 13:46:43
2010 +0200
@@ -4664,7 +4664,7 @@
if (stv090x_i2c_gate_ctrl(state, 1) < 0)
goto err;
- if (state->config->tuner_sleep) {
+ if (fe->tuner_priv && state->config->tuner_sleep) {
if (state->config->tuner_sleep(fe) < 0)
goto err_gateoff;
}
--
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: Patches an media build tree
On Sun, 6 Mar 2011 17:23:11 +0530 Manu Abraham wrote: > Hi Steffen, Hi Manu , thx for the reply :) > On Sat, Mar 5, 2011 at 9:13 PM, Steffen Barszus > > Manu , Mauro please comment ! Thanks ! > > > > Avoid unnecessary data copying inside dvb_dmx_swfilter_204() > > function 2010-08-07 Marko Ristola Under Review > > Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt > > 2010-08-07 Marko Ristola Under Review > > > I had tried this patch a while back, but due to some reason it was > causing a complete freeze at my side: it could have been due to a > different version of the bridge or so, But it wasn't really easy on my > side to ascertain that. That time looking at the patch it wasn't easy > to identify the reason as well. I need to retry the same again, with a > cooler head as to see what happens. That would be good, as far as i remember - the issue is, without these patches the driver crashes after a while caused by vdr's excessive use by EIT scanner. So it can only be used without EPG scan enabled. With that it was running stable. There have been a few different patches floating around to address this issue. > > [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod > > 2010-10-10 Tuxoholic Under Review > > > > I was under the assumption that this issue was fixed in the right way, > with the fix being applied to the stb6100 driver sometime back. Was > your test with that fix in ? Think i did not put it into relation. Let me get to the users of the cards, to test the current dkms [1] w/o any patches and confirm back to you whats current situation It was this one: commit f14bfe94e459cb070a489e1786f26d54e9e7b5de Author: Manu Abraham Date: Sun Nov 14 15:52:10 2010 -0300 [media] stb6100: Improve tuner performance right ? Kind Regards Steffen [1] Test version of the dkms, need to remove above named patches tomorrow. Will remove the above patches again for testing, then its except for a small fix for more then on TT S2 1600 plain media_tree. https://launchpad.net/~yavdr/+archive/testing-vdr/+packages?field.name_filter=v4l-dvb-dkms&field.status_filter=published&field.series_filter= -- 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
NCT 677x lirc driver for Asrock 330HT and others
Hi ! Note sure where exactly to put it. Here is an lirc driver provided by Nuovoton as it seems, which can be downloaded from the vendors site: http://www.asrock.com/Nettop/download.asp?Model=ION%20330HT&o=Linux It adds an lirc driver for the receiver as used in the Asrock 330HT and newer models from Asrock. Can this go into lirc, or better, can something be done to integrate it "somehow" ? Kind Regards Steffen -- 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: Patches an media build tree
On Sun, 16 Jan 2011 16:37:38 -0200 Mauro Carvalho Chehab wrote: > Em 15-01-2011 11:46, Helmut Auer escreveu: > > Hello List > > > > How long does it usually take til patches are integrated into the > > media build tree ( after posting these here ) ? I'm just wondering > > because I miss some patches posted here. > > It takes as much it needs for the driver maintainer to look into it, > and for me to have time to handle them. > > The pending patches are always at: > > https://patchwork.kernel.org/project/linux-media/list/ > > Please note that, by default, Patchwork filters the patches to > display only the ones marked as New or Under Review. If you want to > see all patches, you need to change the state filter to show all > patches: > https://patchwork.kernel.org/project/linux-media/list/?state=* > > If the patch you're waiting are marked as Under Review, you should > ping the driver maintainer, as I'm waiting for his review. If it is > new, that means that I didn't have time yet to dig into it. Can you please check these patches ? What is missing ? Something to be corrected ? What happens to orphaned drivers ? Manu are you still working on this ? Manu , Mauro please comment ! Thanks ! Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function 2010-08-07 Marko Ristola Under Review Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt 2010-08-07 Marko Ristola Under Review [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod 2010-10-10 Tuxoholic Under Review -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cron job] v4l-dvb daily build: ERRORS
On Thu, 3 Mar 2011 10:11:35 +0100 Hans Verkuil wrote: > On Thursday, March 03, 2011 09:44:17 Steffen Barszus wrote: > > home/hans/work/build/media_build/v4l/cx23885-cards.c:28:28: fatal > > error: staging/altera.h: No such file or directory > > > > This is true :) Any commit waiting, or any commit missing ? > > I hope I can work on this this weekend. Thx ! Its working now if i put #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 36) #define usleep_range(_min, _max)msleep((_max) / 1000) #endif in compat.h - not sure how it gets there - but you might know :) > > @Hans: one idea to improve your mail would be to show the git hash > > of the media tree instead of media build (i assume this is what is > > in your mails) > > Oops, that's a bug in my script. I made some changes some time ago > and my script tried to get the hash of a no longer existing branch. > Fixed. 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: [cron job] v4l-dvb daily build: ERRORS
On Wed, 2 Mar 2011 19:37:45 +0100 (CET) "Hans Verkuil" wrote: > 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: > 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: ERRORS > linux-2.6.35.3-i686: ERRORS > linux-2.6.36-i686: ERRORS > linux-2.6.37-i686: 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: ERRORS > linux-2.6.35.3-x86_64: ERRORS > linux-2.6.36-x86_64: ERRORS > linux-2.6.37-x86_64: ERRORS > spec-git: ERRORS > sparse: ERRORS > home/hans/work/build/media_build/v4l/cx23885-cards.c:28:28: fatal error: staging/altera.h: No such file or directory This is true :) Any commit waiting, or any commit missing ? @Hans: one idea to improve your mail would be to show the git hash of the media tree instead of media build (i assume this is what is in your mails) Other than that its really useful to see in beforehand what you can expect :) 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
