Re: R: [linux-dvb] How to handle multiple frontends?
Ralph Metzler wrote: In the HVR3000 case, do both frontends then use the same demux0? So, if one can open only one at the same time, both should use demux0? please, NO! it will be a hell to support in applications. Please, do it simple and bind frontendN to demuxN and dvrN (and netN) If one can open them at the same time, frontend 0 should use demux0 and the other demux1? At least the latter is how I am doing it on dual-tuner cards with independent inputs. Ralph -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Problemi di Liquidità? Con Logos Finanziaria 30.000 in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi, clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2911d=15-1 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to handle multiple frontends?
On 1/15/07, Ralph Metzler [EMAIL PROTECTED] wrote: Klaus Schmidinger writes: I'm wondering how an application is supposed to handle devices with multiple frontends. Let's assume a device that provides dvb/adapter0/frontend0DVB-S dvb/adapter0/frontend1DVB-T so that it can receive both DVB-S and DVB-T. Does this mean that it can simultaneously receive one DVB-S transponder and one DVB-T transponder? Or can it receive either a DVB-S *or* a DVB-T transponder, but not both at the same time? Hmmm, good question. I only have some devices which can do simultaneous reception. But I think there are some with different tuners sharing TS outputs as well. Since the open is not handled by the driver itself we also cannot lock the frontend accesses against each other. There are 2 different cases (1) multiple frontends sharing the same TS interface (2) multiple frontends, each having it's own TS interface. Maybe those should be handled like one multi-protocol frontend? Not sure if Manu's multi-proto stuff would also handle this across different tuners. We would need another layer of abstraction. Or should just the demuxes lock against each other? So, if one demux has filters set, the other one will not accept any. I guess the frontends themselve work at the same time, they just share the same TS input? for (1), they just share the same TS interface which is already implemented, but when we have a derivative of (2) multiple frontends, we can have say for example 4 frontends with 2 TS interfaces or 3 TS interfaces. in this case the frontends could be handled by either of the TS interfaces, depending on how you configure it. We'll definitely need some better input handling for those new cards. E.g. if you have 2 demuxes connected to 2 frontends or data from the PC, 1 or 2 decoders on the card, one or more of those new USB CAMs serving one of several cards, etc. I'm starting to do some hacking with something like modified V4 API + multi-proto frontends + other goodies ... I was thinking in the lines of the adapter object that i worked upon earlier, adding functionality to the same such that device functionality is abstracted by the user application through the adapter object. Currently i have some small functionality like bus reset, sync word setup etc associated with the adapter object, but can be extended for others as well. Another advantage of this method is that it makes the integration of hybrid devices as well into the existing framework without having workarounds. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Improved picture quality on HVR3000 + analog TV
Hi list, Just thought I'd say that I applied the patch suggested here (http://linuxtv.org/v4lwiki/index.php/Color_problem_patch) to the drivers from Steven Toths tree and it seems to have made a noticeable improvement to the picture quality of analog TV on my HVR3000. Robert. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] genlock
Hi everyone,Any I am developing a dvb s1 transmitter. Its input is a MPEG TS from a mpeg encoder and its output is a DVB S1 stream to the RF satellite. I am having problems synchronizing the input bit rate to the output baud rate and I was wondering if anyone could help me out on this list ( or suggest me a better one =) ). The transmitter works for 7 to 8 minutes, but then its output buffer overflows ( showing that there is a small difference from the input rate to the necessary output rate ). Thanks for your attention, Cya, Sam -- f u cn rd ths u cn b a gd prgmr ! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] genlock
Hi Morgan ! thanks for your quick reply =) On 1/15/07, Morgan Tørvolt [EMAIL PROTECTED] wrote: Sending this to the list also, for future reference... -- Forwarded message -- From: Morgan Tørvolt [EMAIL PROTECTED] Date: 15-Jan-2007 17:33 Subject: Re: [linux-dvb] genlock To: Samuel Goto [EMAIL PROTECTED] Hi Sam What you are making is basically a mux? You put audio and video together to one TS stream? In that case, my only advice would be to use stuffing. Lower the combined bitrate from your sources to less than the output bitrate, and insert stuffing TS packets to compensate so that you get the correct output bitrate. I believe there really is no other way of doing it, as it is close to impossible to get a 100% stable raw mpeg datarate. There is also a possibility that your mpeg-encoder does some stuffing to get the correct bitrate. You could remove these first if you want... I am writing the DVB S1 modulator itself, following the EN 300 421 standard. It is already working (meaning that the encoder is working : it receives a mpeg ts and transmits a valid dvb s1 stream ), but I am suffering from occasional overflows during this process. The reason is that, like you said, the mpeg encoder is not sending a 100% stable raw mpeg datarate. It is probably sending a little bit more, which is causing an output overflow after 7 to 8 minutes of transmission. Bit by bit, after some time, it accumulates and overflows my output buffer. The DVB encoder has to have a fixed and perfectly stable output data rate ( baud rate ), which implies that it has to receive a perfectly stable and fixed input mpeg rate ( bitrate ). Any excess or loss will cause either an overflow or an underflow over time. Is this correct ? Depending on the mux, professional muxes does different things when fed with too much data. Some just drops random packages (BAD!, i can mention certain brands, some does this even when the total is less than the muxrate, as long as one service is higher than configured), others drop packages from the one with too high bitrate, others allow for the higher bitrate, but starts dropping from the service with too high bitrate when the total exceeds the mux-rate. How you want to implement this is your choice, but I would suggest to allow for some excessive datarate to keep clients happy =) From what I have read, this process is common to video applications and is called rate adaption. From this document ( http://www.newtec.be/fileadmin/webfolder/Training/Basics_of_rate_adaption.pdf), the options are : o upward adaption : null packet insertion, in the case the transmitter runs out of data o downward adaption : excessing stuffing frames are removed. in any case, the PCR has to be updated to compensate the delay caused by the rate adaption. Is this correct ? -Morgan- On 15/01/07, Samuel Goto [EMAIL PROTECTED] wrote: Hi everyone,Any I am developing a dvb s1 transmitter. Its input is a MPEG TS from a mpeg encoder and its output is a DVB S1 stream to the RF satellite. I am having problems synchronizing the input bit rate to the output baud rate and I was wondering if anyone could help me out on this list ( or suggest me a better one =) ). The transmitter works for 7 to 8 minutes, but then its output buffer overflows ( showing that there is a small difference from the input rate to the necessary output rate ). Thanks for your attention, Cya, Sam -- f u cn rd ths u cn b a gd prgmr ! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- f u cn rd ths u cn b a gd prgmr ! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] genlock
On Mon, 15 Jan 2007, Samuel Goto wrote: Hi everyone,Any Hi Samuel, I am developing a dvb s1 transmitter. Its input is a MPEG TS from a mpeg encoder and its output is a DVB S1 stream to the RF satellite. OK. I am having problems synchronizing the input bit rate to the output baud rate and I was wondering if anyone could help me out on this list ( or suggest me a better one =) ). The transmitter works for 7 to 8 minutes, but then its output buffer overflows ( showing that there is a small difference from the input rate to the necessary output rate ). The simplest way, I can think of, is to implement some kind of handshaking between the transmitter and your transmitting applikation. You should give the transmitter a chance to say please stop sending data, until I am ready to receive more. It has been done on telephone modems in the past. Thanks for your attention, Cya, Sam Regards, Rainer -- Rainer Schubert - Linux TV User Amateur Radio Call DL6HBO ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Alle 15:25, giovedì 4 gennaio 2007, Giorgio Moscardi ha scritto: Hi, I've just subscribed to this mailing list, in the hope of getting my TV card working. It's a Terratec Cinergy HT PCI, I've set up a page on the wiki for it: http://linuxtv.org/v4lwiki/index.php/Terratec_Cinergy_HT_PCI. It's a hybrid card, and it supports both analog and DVB-T. I will also provide pictures of it. Well, I must say I was expecting some replies to my mail... Nobody is interested in adding support for this new card with what - I figure - will just be a little effort? -- Giorgio Slackware GNU/Linux 11.0 user - ICQ: 10238408 MSN: [EMAIL PROTECTED] Web: http://www.sukkology.net ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] genlock
Hi On 15/01/07, Rainer Schubert [EMAIL PROTECTED] wrote: On Mon, 15 Jan 2007, Samuel Goto wrote: Hi everyone,Any Hi Samuel, I am developing a dvb s1 transmitter. Its input is a MPEG TS from a mpeg encoder and its output is a DVB S1 stream to the RF satellite. OK. I am having problems synchronizing the input bit rate to the output baud rate and I was wondering if anyone could help me out on this list ( or suggest me a better one =) ). The transmitter works for 7 to 8 minutes, but then its output buffer overflows ( showing that there is a small difference from the input rate to the necessary output rate ). The simplest way, I can think of, is to implement some kind of handshaking between the transmitter and your transmitting applikation. You should give the transmitter a chance to say please stop sending data, until I am ready to receive more. It has been done on telephone modems in the past. I think this is different from a modem. A modem does not often transmit live data. A mpeg encoder does. You cannot easily discard a part of an mpeg stream eighter. The number of bits required to encode a picture is very dependent upon the picture, and it is not possible to determine that exactly in advance. This means that you would require a large buffer if the bitrate goes too high for a moment, and this causes several problems. Firstly the PCR does not arrive at the correct time, reeking havoc with the internal clock of the reciever (which syncs on this), secondly, the decoder is supposed to get PES packets from the mpeg stream according to the DTS (decoding timestamp in the PES stream) which also get alot of jitter in this case. The result would be that most receivers would probably fail miserably at decoding the stream. My approach would be to lower the bitrate of the mpeg encoder to something that can fit within the transmitted carrier (ex. bandwidth - 100Kbit), then let the transmitting application request packets when it needs to send one (this makes sure that you get the exact right output bandwidth). If there is none available in the buffer from the encoder, it should get a stuffing packet instead. This would slightly increase the bandwidth of the stream, but would not cause any problems with eighter PCR, DTS, PTS or any other timestamps. Regards -Morgan- Thanks for your attention, Cya, Sam Regards, Rainer -- Rainer Schubert - Linux TV User Amateur Radio Call DL6HBO ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to handle multiple frontends?
Manu Abraham wrote: ... There are 2 different cases (1) multiple frontends sharing the same TS interface (2) multiple frontends, each having it's own TS interface. Maybe those should be handled like one multi-protocol frontend? Not sure if Manu's multi-proto stuff would also handle this across different tuners. We would need another layer of abstraction. Or should just the demuxes lock against each other? So, if one demux has filters set, the other one will not accept any. I guess the frontends themselve work at the same time, they just share the same TS input? for (1), they just share the same TS interface which is already implemented, but when we have a derivative of (2) multiple frontends, we can have say for example 4 frontends with 2 TS interfaces or 3 TS interfaces. So I guess for VDR it will be ok to assume that a device with several frontends can only actually use one frontend at a time. Otherwise there would have to be some way of querying the device how many of the frontends can be used in parallel. But AFAIK there is no such facility in the current DVB driver API, or is there? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to handle multiple frontends?
On 1/15/07, Klaus Schmidinger [EMAIL PROTECTED] wrote: Manu Abraham wrote: ... There are 2 different cases (1) multiple frontends sharing the same TS interface (2) multiple frontends, each having it's own TS interface. Maybe those should be handled like one multi-protocol frontend? Not sure if Manu's multi-proto stuff would also handle this across different tuners. We would need another layer of abstraction. Or should just the demuxes lock against each other? So, if one demux has filters set, the other one will not accept any. I guess the frontends themselve work at the same time, they just share the same TS input? for (1), they just share the same TS interface which is already implemented, but when we have a derivative of (2) multiple frontends, we can have say for example 4 frontends with 2 TS interfaces or 3 TS interfaces. So I guess for VDR it will be ok to assume that a device with several frontends can only actually use one frontend at a time. Otherwise there would have to be some way of querying the device how many of the frontends can be used in parallel. But AFAIK there is no such facility in the current DVB driver API, or is there? If we have a 1:1 mapping, ie the the number of TS interfaces is the same as the number of frontend devices, it could be a simple map of adapter0/ frontend0 -- dvr0/demux0 frontend1 -- dvr1/demux1 frontend2 -- dvr2/demux2 in this case the hardware is capable of providing 3 simultaneous streams This could be made quite simple ie, the user application just needs to find how many devices that are present on the adpater, this abstraction is one that i was mentioning with the adapter object. Another case is that adapter0/ frontend0 -- dvr0/demux0 frontend1 -- dvr1/demux1 frontend2 -- dvr2/demux2 in this case the hardware has just one TS interface, ie can provide only one stream, eventhough there are 3 frontends (A similar implementation exists currently) Another case is that adapter0/ frontend0 -- dvr0/demux0 frontend1 -- dvr1/demux1 frontend2 -- dvr2/demux2 in this case the hardware has 2 TS interfaces, with 3 frontends. In this case, there needs to be control over who gets controls of the TS interface. In this case not only you will need a hardware abstraction, but also a way to control the same. this was why i was thinking in the lines of the adapter object. Currently, one of the case is handled with the DVB API driver, ie one TS interface with multiple frontends. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Hartmut Hackmann wrote: Hi, Giorgio Giorgio Moscardi schrieb: Alle 15:25, giovedì 4 gennaio 2007, Giorgio Moscardi ha scritto: Hi, I've just subscribed to this mailing list, in the hope of getting my TV card working. It's a Terratec Cinergy HT PCI, I've set up a page on the wiki for it: http://linuxtv.org/v4lwiki/index.php/Terratec_Cinergy_HT_PCI. It's a hybrid card, and it supports both analog and DVB-T. I will also provide pictures of it. Well, I must say I was expecting some replies to my mail... Nobody is interested in adding support for this new card with what - I figure - will just be a little effort? This might be a task for me but sorry, i am currently very busy. Hartmut, I helped a user with this card in irc, and I had him apply this patch: http://linuxtv.org/~mkrufky/pending/terratec-cinergy-ht-pci.patch ...It seemed to work for him correctly, except that the user had some trouble scanning for digital channels. The user had full functionality in analog mode, but no dvb, yet. (I think it was his signal, because he couldn't make it work in windows, either) I didn't want to commit the patch without knowing for sure. Maybe Georgio would be willing to test this. Unfortunately, I don't recall the name of the original tester. If this works for Georgio, then I suggest removing the PCMCIA from the text name of card #105 --- the card setup *seems* to be identical, but there is only so much that I can tell without trying myself. If you decide to apply this patch, Hartmut, then here is my sign-off: Signed-off-by: Michael Krufky [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Hi, Michael, Giorgio Michael Krufky schrieb: Hartmut Hackmann wrote: Hi, Giorgio Giorgio Moscardi schrieb: Alle 15:25, giovedì 4 gennaio 2007, Giorgio Moscardi ha scritto: Hi, I've just subscribed to this mailing list, in the hope of getting my TV card working. It's a Terratec Cinergy HT PCI, I've set up a page on the wiki for it: http://linuxtv.org/v4lwiki/index.php/Terratec_Cinergy_HT_PCI. It's a hybrid card, and it supports both analog and DVB-T. I will also provide pictures of it. Well, I must say I was expecting some replies to my mail... Nobody is interested in adding support for this new card with what - I figure - will just be a little effort? This might be a task for me but sorry, i am currently very busy. Hartmut, I helped a user with this card in irc, and I had him apply this patch: http://linuxtv.org/~mkrufky/pending/terratec-cinergy-ht-pci.patch ...It seemed to work for him correctly, except that the user had some trouble scanning for digital channels. The user had full functionality in analog mode, but no dvb, yet. (I think it was his signal, because he couldn't make it work in windows, either) I didn't want to commit the patch without knowing for sure. Maybe Georgio would be willing to test this. Unfortunately, I don't recall the name of the original tester. If this works for Georgio, then I suggest removing the PCMCIA from the text name of card #105 --- the card setup *seems* to be identical, but there is only so much that I can tell without trying myself. If you decide to apply this patch, Hartmut, then here is my sign-off: Signed-off-by: Michael Krufky [EMAIL PROTECTED] Thanks for the info, Michael! Giorgio can you please test and report? Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Giorgio Moscardi wrote:
Alle 00:15, martedì 16 gennaio 2007, Hartmut Hackmann ha scritto:
Thanks for the info, Michael!
Giorgio can you please test and report?
Sure! Thanks a lot! I'll do that straight tomorrow. I guess I should apply it
to the mercurial tree, right?
Yes, but you might also want to try the various eeprom init sequences pointed
out by Hermann, if the patch doesnt work as-is.
I didnt see your original message when I had written that email with the
patch...
I suspect that you will encounter the same exact problem as you had before. If
this is the case, you may want to play around with the following info:
hermann pitton wrote:
static int cinergy_ht_tuner_init(struct dvb_frontend *fe)
{
struct saa7134_dev *dev = fe-dvb-priv;
static u8 data[] = { 0x3c, 0x33, 0x62};
struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = sizeof
(data)};
if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
return -EIO;
return 0;
}
but reportedly Giogio uses philips_tiger_tuner_init on the medion quad.
static int philips_tiger_tuner_init(struct dvb_frontend *fe)
{
struct saa7134_dev *dev = fe-dvb-priv;
static u8 data[] = { 0x3c, 0x33, 0x6a};
struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = sizeof
(data)};
if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
return -EIO;
return 0;
}
... you might want to swap the tuner init sequences between those two... If it
works, then we'll need for you to generate a diff, to illustrate exactly what
changes you made. ( hg diff the.patch )
I hope this helps.
-Mike Krufky
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Alle 01:30, martedì 16 gennaio 2007, Giorgio Moscardi ha scritto: Sure! Thanks a lot! I'll do that straight tomorrow. I guess I should apply it to the mercurial tree, right? OK, I couldn't resist and tried it right now. - Installed Mercurial. - Downloaded linuxtv Mercurial tree. - Downloaded and applied Michael's patch. - Compiled and installed new modules. - Rebooted. Result: as far as I can guess, Michael's patch only adds automatic recognition for my card as type 105: saa7133[0]: found at :00:09.0, rev: 209, irq: 11, latency: 32, mmio: 0xfa020 000 saa7133[0]: subsystem: 153b:1175, board: Terratec Cinergy HT PCMCIA [card=105,au todetected] saa7133[0]: board init: gpio is 0 saa7133[0]: i2c eeprom 00: 3b 15 75 11 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff 00 01 50 32 79 01 3c ca 50 saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 00 06 ff 00 94 02 51 96 2b saa7133[0]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c saa7133[0]: i2c eeprom 40: ff 21 00 c0 96 10 03 32 15 10 fd 79 44 9f c2 8f saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 1-004b: chip found @ 0x96 (saa7133[0]) tuner 1-004b: setting tuner address to 60 tuner 1-004b: type set to tda8290+75a tuner 1-004b: setting tuner address to 60 tuner 1-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 Firmware upload also succeeds: DVB: registering new adapter (saa7133[0]). DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision 29 -- ok Unfortunately, the problem goes further, as the situation is exactly the same as when i forced the 105 card type, which basically means analog TV is ok, DVB does not work. Please see my previous mail for details. UPDATE: OK, I just got back Michael's mail expecting this exact situation :). I'll try swapping the tuner init sequencies as suggested. BTW, I'm a programmer, so I can make some sensed changes, but I have no knowledge on this GPIO stuff. I'll keep you posted, thanks for the help so far. -- Giorgio Slackware GNU/Linux 11.0 user - ICQ: 10238408 MSN: [EMAIL PROTECTED] Web: http://www.sukkology.net ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Patch: USBVision - Replacement of vmalloc_32 with vmalloc_32_user
This patch replaces vmalloc_32 with vmalloc_32_user. Allocating virtually
contiguous memory (32bit addressable) which is zeroed so it can be mapped to
userspace without leaking data.
Signed-off-by: Dwaine P. Garden [EMAIL PROTECTED]
diff -U 3 -H -d -r -N -- a/linux/drivers/media/video/usbvision/usbvision-core.c b/linux/drivers/media/video/usbvision/usbvision-core.c
--- a/linux/drivers/media/video/usbvision/usbvision-core.c 2007-01-15 19:11:11.0 -0500
+++ b/linux/drivers/media/video/usbvision/usbvision-core.c 2007-01-15 20:32:06.0 -0500
@@ -131,7 +131,7 @@
unsigned long adr;
size = PAGE_ALIGN(size);
- mem = vmalloc_32(size);
+ mem = vmalloc_32_user(size);
if (!mem)
return NULL;
@@ -414,7 +414,7 @@
int usbvision_scratch_alloc(struct usb_usbvision *usbvision)
{
- usbvision-scratch = vmalloc_32(scratch_buf_size);
+ usbvision-scratch = vmalloc_32_user(scratch_buf_size);
scratch_reset(usbvision);
if(usbvision-scratch == NULL) {
err(%s: unable to allocate %d bytes for scratch,
@@ -525,7 +525,7 @@
int usbvision_decompress_alloc(struct usb_usbvision *usbvision)
{
int IFB_size = MAX_FRAME_WIDTH * MAX_FRAME_HEIGHT * 3 / 2;
- usbvision-IntraFrameBuffer = vmalloc_32(IFB_size);
+ usbvision-IntraFrameBuffer = vmalloc_32_user(IFB_size);
if (usbvision-IntraFrameBuffer == NULL) {
err(%s: unable to allocate %d for compr. frame buffer, __FUNCTION__, IFB_size);
return -ENOMEM;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Patch: USBVision - Replacement of vmalloc_32 with vmalloc_32_user
Please ignore the first submitted patch. I forgot to remove the memset(mem, 0,
size); statement. Please use this patch instead. Sorry about that
This patch replaces vmalloc_32 with vmalloc_32_user. Allocating
virtually contiguous memory (32bit addressable) which is zeroed so it
can be mapped to userspace without leaking data.
Signed-off-by: Dwaine P. Garden [EMAIL PROTECTED]
diff -U 3 -H -d -r -N -- a/linux/drivers/media/video/usbvision/usbvision-core.c b/linux/drivers/media/video/usbvision/usbvision-core.c
--- a/linux/drivers/media/video/usbvision/usbvision-core.c 2007-01-15 19:11:11.0 -0500
+++ b/linux/drivers/media/video/usbvision/usbvision-core.c 2007-01-15 21:38:31.0 -0500
@@ -131,11 +131,10 @@
unsigned long adr;
size = PAGE_ALIGN(size);
- mem = vmalloc_32(size);
+ mem = vmalloc_32_user(size);
if (!mem)
return NULL;
- memset(mem, 0, size); /* Clear the ram out, no junk to the user */
adr = (unsigned long) mem;
while (size 0) {
SetPageReserved(vmalloc_to_page((void *)adr));
@@ -414,7 +413,7 @@
int usbvision_scratch_alloc(struct usb_usbvision *usbvision)
{
- usbvision-scratch = vmalloc_32(scratch_buf_size);
+ usbvision-scratch = vmalloc_32_user(scratch_buf_size);
scratch_reset(usbvision);
if(usbvision-scratch == NULL) {
err(%s: unable to allocate %d bytes for scratch,
@@ -525,7 +524,7 @@
int usbvision_decompress_alloc(struct usb_usbvision *usbvision)
{
int IFB_size = MAX_FRAME_WIDTH * MAX_FRAME_HEIGHT * 3 / 2;
- usbvision-IntraFrameBuffer = vmalloc_32(IFB_size);
+ usbvision-IntraFrameBuffer = vmalloc_32_user(IFB_size);
if (usbvision-IntraFrameBuffer == NULL) {
err(%s: unable to allocate %d for compr. frame buffer, __FUNCTION__, IFB_size);
return -ENOMEM;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-T not working on Terratec Cinergy HT PCI
Alle 01:58, martedì 16 gennaio 2007, Michael Krufky ha scritto: I suspect that you will encounter the same exact problem as you had before. If this is the case, you may want to play around with the following info: OK, it seems I managed to solve the problem. More info tomorrow! -- Giorgio Slackware GNU/Linux 11.0 user - ICQ: 10238408 MSN: [EMAIL PROTECTED] Web: http://www.sukkology.net ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
