Yeandle https://goo.gl/Fp94bb
Chris Rankin
On 16 January 2017 at 23:40, Antti Palosaari wrote:
> Chris and Håkan, test please without Kconfig CONFIG_GPIOLIB option. I cannot
> test it properly as there seems to quite many drivers selecting this option
> by default.
Works here :-)
Tested-by: Chris Rankin
[ 125.162762] usb
Hi,
This oops has appeared for my PCTV T2 290e adapter when I switched to
the 4.9.x kernel. It does not happen with the 4.8.x kernel.
I believe the problem is that "priv" is NULL in cxd2820r_gpio().
Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM ID = 26 00 01 00,
EEPROM hash = 0x1eb936d2
Jan
Hi,
This oops has appeared for my PCTV T2 290e adapter when I switched to
the 4.9.x kernel. It does not happen with the 4.8.x kernel.
Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM ID = 26 00 01 00,
EEPROM hash = 0x1eb936d2
Jan 13 11:19:45 endgame kernel: em28174 #0: EEPROM info:
Jan 13 11:19
hiya linux
http://wdentertainmentinc.com/manner.php?sets=xkwqz2nzt03eb59
Chris
--
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
Hi,
I've bought a VRC-110 MCE IR remote control (USB IDs 05a4:9881) to
replace a broken Hauppauge RC5 remote, and have *finally* managed to
get it working with VDR. However, this has involved doing things like
writing a userspace "muxing" device to unify the IR's separate
keyboard and mouse device
resses, please?
Thanks,
Chris
On Sun, Nov 15, 2015 at 10:46 PM, Mauro Carvalho Chehab
wrote:
> Em Sun, 15 Nov 2015 22:18:48 +
> Chris Rankin escreveu:
>
>> > How are you "switching back to RC5"?
>>
>> I use the command "ir-keytable -p rc-5"
> How are you "switching back to RC5"?
I use the command "ir-keytable -p rc-5" or "ir-keytable -p rc-6" to
switch between IR protocols, which does seem to invoke the
em2874_ir_change_protocol() function. I'm not sure that I have a
suitable RC6 keymap for this IR, and was expecting to have to creat
Hi,
I've dug a bit deeper and discovered that the reason the
em28xx_info(...) lines that I'd added to em2874_polling_getkey()
weren't appearing is because I'd loaded the wrong version of the
em28xx-rc module! (Doh!)
The polling function *is* being called regularly, but
em28xx_ir_handle_key() isn'
Hi,
My Hauppauge RC5 remote control finally broke, and the PCTV T2 290e's
native RC5 remote control isn't suitable for VDR, and so I bought a
cheap RC6 remote as a replacement. The unit I chose was the Ortek
VRC-1100 Vista MCE Remote Control, USB ID 05a4:9881. I've been able to
switch the PCTV dev
tro hasn't updated.
>
> I did a pull request into this github repo
> <https://github.com/oliv3r/dtv-scan-tables>
>
> Si.
On 17 March 2014 23:44, Chris Rankin wrote:
>
>Hi,
>
>The DVB-T initial tuning information for Crystal Palace in the UK is
>
Hi,
The DVB-T initial tuning information for Crystal Palace in the UK is completely
obsolete - despite my two attempts to submit an updated version over the YEARS.
Where is the best place to send this information, please?
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubsc
On Friday, 21 February 2014, 9:47, Hans de Goede wrote:
> This is likely caused by the camera being plugged into a usb-bus which
> already is used
> by other reserved-bandwidth devices such as mice, keyboard, usb soundcards,
> etc.
> If possible USB-3 ports are preferred over USB-2 ports or co
Hi,
I have an old Logitech webcam, with USB IDs 046d:08b3. When I try to use this
camera now, I see this error in the dmesg log:
[ 2883.852464] pwc: isoc_init() submit_urb 0 failed with error -28
This error is apparently ENOSPC, which made me suspect that I was trying to use
a mode that wou
Hi,
I have just tested my PCTV 290e DVB-T2 adapter with 3.12.5 and discovered that
it fails with logs of messages like these:
[11720.780975] __tda18271_write_regs: [7-0060|M] ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -19
[11720.788726] tda18271_init: [7-0060|M] error -19 on line 832
[
- Original Message -
From: Devin Heitmueller
>The amount of output is not inconsistent with most other linuxtv drivers
>though.
It's the EEPROM dump that really caught my eye: 16+ lines of pure "WTF?".
Cheers,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-me
Hi,
I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and
found this message in the dmesg log.
[ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci
[ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f,
interface 0, class 0
- Original Message -
> No, just because it didn't change it isn't automatically correct. ;)
It's Fedora 18's "haupp" keytable - so it must be correct :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More
- Original Message -
> If I had to guess, I would say you should check your rc_maps.cfg / keytable.
> ;)
This is unchanged between 3.8.x and 3.9.x, and so is correct by definition.
Kernel Upgrades Do Not Break Userspace.
Cheers,
Chris
--
To unsubscribe from this list: send the line "u
- Original Message -
>> And this is me calling ir-keytable:
>>
>> [ 2183.812407] em28xx #0: Changing protocol: rc_type=1
> So with 3.8 the same happens as with 3.9.
Yes, that does appear to be part of the RC core ABI.
> Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get
> } else {
> *rc_type = ir->rc_type;
> return -EINVAL;
>
> This is against 3.9.3.
>
> Signed-off-by: Chris Rankin
> No, this patch is wrong.
> Updating ir->rc_type with the new value of *rc_type is correct.
Well, it restores 3.8 behaviour,
*rc_type = RC_BIT_UNKNOWN;
+ return 0;
} else {
*rc_type = ir->rc_type;
return -EINVAL;
This is against 3.9.3.
Signed-off-by: Chris Rankin
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.k
- Original Message -
> What happens with kernel 3.8 ? Does ir-keytable trigger an
> em28xx_ir_change_protocol() call there, too, but with type=8 ? Or is this
> call missing ?
This is the dmesg output from 3.8, with an extra ex28xx_info() call at the
start of em28xx_ir_change_protocol():
- Original Message -
>> And this seems to reset the protocol back to "unknown". (But I need to use
>> this other remote control to use VDR - the PCTV one just doesn't have enough
>> buttons).
> Ok, then it seems to be no em28xx issue.
> What happens with kernel 3.8 ? Does ir-keytable tr
- Original Message -
> Hmm... that's weird. Are you sure about that ? Is this really a 3.9.2 vanilla
> kernel ?
Quite sure, although it turns out that there's a bit more to it. Here is the
dmesg output with my debugging messages in:
[ 6263.496794] em28174 #0: Calling em28xx_ir_change_p
- Original Message -
> em28xx_ir_change_protocol() should be called at least twice:
> First from em28xx_ir_init() with RC_BIT_UNKNOWN (initial configuration)
> and later from the RC core with RC_BIT_RC5.
> Can you confirm that ?
Yes, it does appear to be called twice: first with *rc_type
- Original Message -
> For the em28xx driver: em28xx-input.c:
> em28xx_ir_work() is called every 100ms
> calls em28xx_ir_handle_key()
> - calls ir->get_key() which is em2874_polling_getkey() in case of
> your device
> - reports the detected key via rc_keydown() through
- Original Message -
> For the em28xx driver: em28xx-input.c:
> em28xx_ir_work() is called every 100ms
> calls em28xx_ir_handle_key()
> - calls ir->get_key() which is em2874_polling_getkey() in case of your
>device
> - reports the detected key via rc_keydown() through the
- Original Message -
>> Am 18.05.2013 15:57, schrieb Chris Rankin:
>> I have a PCTV 290e DVB2 adapter (em28xx, em28xx_dvb, em28xx_rc, cxd2820r),
>> and I have just discovered that the IR remote control has stopped working
>> with VDR when using a vanilla 3.9.2 ke
Hi,
Further to my original email, here is the dmesg log from 3.9.2 when inserting
my 290e adapter:
[ 1273.581835] usb 10-4: new high-speed USB device number 6 using ehci-pci
[ 1273.704508] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f,
interface 0, class 0)
[ 1273.712167] em2
Hi,
I have a PCTV 290e DVB2 adapter (em28xx, em28xx_dvb, em28xx_rc, cxd2820r), and
I have just discovered that the IR remote control has stopped working with VDR
when using a vanilla 3.9.2 kernel. Downgrading the kernel to 3.8.12 fixes
things again. (Switching to my old DVB NOVA-T2 device fix
Hi,
The Crystal Palace transmitter has now completed its digital
switch-over, so here's the updated tuning file.
Cheers,
Chris
#--
# file automatically generated by w_scan
# (http://wirbel.htpc-forum.de/w_scan/index2.h
I've had a closer look at the commit which caused the regression and it looks
like there were two places where fepriv->parameters_in was assigned to
fepriv->parameters_out. So I've updated my patch accordingly.
Cheers,
Chris
Signed-off-by: Chris Rankin
--- linux-3.3/drive
In fact, the following patch works for me.
Signed-off-by: Chris Rankin
--- linux-3.3/drivers/media/dvb/dvb-core/dvb_frontend.c.orig 2012-04-06 20:16:02.0 +0100
+++ linux-3.3/drivers/media/dvb/dvb-core/dvb_frontend.c 2012-04-06 21:17:38.0 +0100
@@ -1831,6 +1831,13 @@
return
Hi,
The following commit has broken the DVB ABI for xine:
http://git.linuxtv.org/linux-2.6.git/commitdiff/e399ce77e6e8f0ff2e0b8ef808cbb88fc824c610
author: Mauro Carvalho Chehab
Sun, 1 Jan 2012 19:11:16 + (16:11 -0300)
committer: Mauro Carvalho Chehab
Wed, 4 Jan 2012 19:30:02 + (17:3
The problem is that the following line was deleted from the FE_SET_FRONTEND
ioctl logic:
fepriv->parameters_out = fepriv->parameters_in;
The following dirty little patch restores the correct behaviour:
--- dvb_frontend.c.orig 2012-04-06 13:28:43.0 +0100
+++ dvb_frontend.c
> Before LOCK you cannot know many parameters at all and frequency also
> can be changed a little bit during tuning process (ZigZag tuning algo).
But surely the point of calling poll() on the front end's descriptor is either
to be notified once the tuning algorithm has locked, or to be told that
The reason that DVB playback with xine is broken in 3.3 is that the userspace
semantics of FE_GET_EVENT have changed. Xine tunes into a DVB channel as follows:
* discards stale frontend events by calling FE_GET_EVENT until there is none
left.
* calls FE_SET_FRONTEND with the new frequency.
* st
> Does this happen in any resolution ?
All resolutions except 960x720: in this resolution I only get a tiny strip of
image across the top of the window.
Cheers,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.or
Hi,
I have a UVC video device, which lsusb describes as:
046d:0992 Logitech, Inc. QuickCam Communicate Deluxe
With the 3.3.1 kernel, the bottom 3rd of the video window displayed by
guvcview is completely black. This happens whenever I select either
BGR3 or RGB3 as the video output format. Howeve
I have just checked the 3.2.14 kernel, and it seems unaffected by this
issue. So I'm guessing it was introduced recently in the 3.3 kernel.
Cheers,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordom
Hi,
Is anyone else having difficulty watching DVB-T with xine and a 3.3.1 kernel? I
have tried the following with several different USB adapters:
1) Plug in the device
2) Launch xine.
3) Select DVB-T channel.
and each time, the results are the same. Namely, xine refuses to acknowledge
any of
Gianluca,
One quick comment about your patch; I've noticed that you've declared two new
"GPL only" symbols:
EXPORT_SYMBOL_GPL(em28xx_capture_start);
EXPORT_SYMBOL_GPL(em28xx_alloc_isoc);
I'm not sure what the exact policy is with GPL symbols, but I do know what Al
Viro posted recently on the
Hi,
The UK's Crystal Palace transmitter supports DVB-T2, so here's an updated
tuning file.
Cheers,
Chris
#--
# file automatically generated by w_scan
# (http://wirbel.htpc-forum.de/w_scan/index2.html)
#! 20120112 1 0 T
Subject: em28xx leaks
Date: Fri, 27 Jan 2012 13:21:50 -0600
From: Todd Squires
Organisation: Core Technologies
To: ranki...@yahoo.com
Hi Chris,
I've recently started using an em28xx, and have run into a memory
leak in the 3.2.1 kernel.
Poking around the Internet, I found that you've been recen
Hi,
As someone who also owns a PCTV 290e device, I must agree that the remote
control that it ships with is useless for VDR. Its biggest flaw is a lack of
red, green, yellow and blue buttons, unlike the very nice remote control that
ships with the Hauppauge NOVA-T2.
Are you suggesting that t
But this has
always been the case anyway.
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-25 22:51:59.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-25 23:24:06.0 +0100
@@ -3005,
--- On Sun, 25/9/11, Mauro Carvalho Chehab wrote:
> Yes. Just after creating a device, udev tries to access it.
> This bug is more sensitive on multi-CPU machines, as udev may run on
> another CPU.
Heh, I have a hyper-threaded quad-core here. I suspect that counts as
"multi-CPU" :-).
However, I
--- On Sun, 25/9/11, Mauro Carvalho Chehab wrote:
> Ok, I've applied it, but it doesn't sound a good idea to me
> to do:
>
> + mutex_unlock(&dev->lock);
> em28xx_init_extension(dev);
> + mutex_lock(&dev->lock);
>
Yes, I suppose it's the logical equivalent of moving the
em28xx_init_e
Mauro,
This patch just removes the prototypes for the two functions that I've already
deleted in my previous patches.
Cheers,
Chris
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx.h.orig 2011-09-25 14:46:02.0 +0100
+++ linux/drivers/media/video/e
On 25/09/11 14:00, Mauro Carvalho Chehab wrote:
Hmm... This would probably work better (not tested). Could you please test it
on your hardware?
Hmm, I don't understand this. The deadlock isn't about taking
em28xx_devlist_mutex, but happens because em28xx_dvb_init() tries to retake
dev->lock w
On 25/09/11 13:49, Mauro Carvalho Chehab wrote:
Ok, I've applied it, but it doesn't sound a good idea to me to do:
+ mutex_unlock(&dev->lock);
em28xx_init_extension(dev);
+ mutex_lock(&dev->lock);
I'll later test it with some hardware and see how well this behaves
in practic
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-24 21:42:43.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 21:48:56.0 +0100
either a device or an extension to the respective lists. (Because
em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin
- Original Message -
>> BTW, did you implement a different solution for the DVB module trying to
>> retake the dev->lock mutex?
>> Because it looks as if both em28xx_dvb_init() and em28xx_usb_probe() are
>> still calling mutex_lock().
> No, I didn't find any time to look into it. Too mu
extension list.
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx-core.c.orig 2011-09-24 14:56:05.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-core.c 2011-09-24 15:01:23.0 +0100
@@ -1184,18 +1184,6 @@
static DEFINE_MUTEX(em28x
This line was probably missed in the merge.
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig.0 2011-09-24 15:30:02.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 15:19:28.0 +0100
@@ -3114,7 +3114,6 @@
em28xx_err
Mauro,
I am resending the two patches for the em28xx driver which seem to have been
missed for 3.2. The first one simply removes a stray bit operation on
em28xx_devused, whereas the second tidies up the device/extension list handling.
It is possible that the first patch has been applied alrea
Hi Stuart,
On 23/09/11 09:52, Stuart Morris wrote:
I have a PCTV 290e and have been watching closely the updates to the Linux media
tree for this device. Thanks for addressing the issues with the 290e driver, I
am
now able to use my 290e for watching UK FreeviewHD with a good degree of
success
On 13/09/11 21:04, Antti Palosaari wrote:
On 08/21/2011 03:32 PM, Chris Rankin wrote:
It occurred to me this morning that since we're no longer supposed to be
holding the device lock when taking the device list lock, then the
em28xx_usb_disconnect() function needs changing too.
Signed-o
On 05/09/11 14:57, Mauro Carvalho Chehab wrote:
Could you please provide me a patch for it? I'll merge with your original one
when submitting it upstream.
Here you go. Did you also pick up the other merge fix and the (separate) memory
leak fix, please?
Cheers,
Chris
Signed-off-by:
On 05/09/11 01:24, Antti Palosaari wrote:
If you select em28xx-cards.c blob link you give you can see it is there still
for some reason.
It's a merge issue. This lingering reference must have been added after I posted
my original patch. Fortunately, it's easily fixed: the
list_add_tail(&
On 05/09/11 00:46, Antti Palosaari wrote:
Moikka,
Current linux-media make gives error. Any idea what's wrong?
Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 1907 modules
ERROR: "em28xx_add_into_devlist" [drivers/media/video/em28xx/em28xx.ko]
undefined!
WARNING:
On 05/09/11 00:46, Antti Palosaari wrote:
Moikka,
Current linux-media make gives error. Any idea what's wrong?
Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 1907 modules
ERROR: "em28xx_add_into_devlist" [drivers/media/video/em28xx/em28xx.ko]
undefined!
WARNING:
Mauro,
This patch seems to have been missed, so I'm resending it.
Release the dev->alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-04 20:30:14.0 +0100
+++ linux/drivers/media/vide
On 04/09/11 00:49, Mauro Carvalho Chehab wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] em28xx: use atomic bit operations for devices-in-use mask
Author: Chris Rankin
Date
--- On Fri, 26/8/11, Andreas Oberritter wrote:
> I first thought that you were talking about a
> regression in Linux 3.0.x.
Heh, yes and no. I am talking about a regression that I am definitely seeing in
3.0.x. However, I cannot say which kernel the problem first appeared in.
> This initial eve
--- On Fri, 26/8/11, Andreas Oberritter wrote:
> can you please test whether https://patchwork.kernel.org/patch/1036132/
> restores the old behaviour?
>
> These three pending patches are also related to frontend events:
>
> https://patchwork.kernel.org/patch/1036112/
> https://patchwork.kernel.or
Hi,
As far as I understand it, the FE_SET_FRONTEND ioctl is supposed to tell a DVB
device to tune itself, and will send a poll() event when it completes. The
"frequency" parameter of this event will be the frequency of the newly tuned
channel, or 0 if tuning failed.
http://www.linuxtv.org/docs
It occurred to me this morning that since we're no longer supposed to be holding
the device lock when taking the device list lock, then the
em28xx_usb_disconnect() function needs changing too.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-
Here's the new patch for the deadlock problem, which releases the device mutex
before calling em28xx_init_extension() and then reacquires it afterwards. The
locking in dvb_init() is now left alone.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig
Here's the updated patch that checks whether the frontend exists before
disabling the sleep operations.
Cheers,
Chris
--- linux-3.0/drivers/media/common/tuners/tda18271-fe.c.orig2011-08-20
18:53:48.0 +0100
+++ linux-3.0/drivers/media/common/tuners/tda18271-fe.c 2011-08-20
19:21:34
--- On Sat, 20/8/11, Mauro Carvalho Chehab wrote:
> No. The extension load can happen after the usb probe
> phase. In practice, the only case where the extension init will happen
> together with the usb probe phase is when the em28xx modules are
> compiled builtin
It also happens when someone plu
--- On Sat, 20/8/11, Mauro Carvalho Chehab wrot
>
> This will cause an OOPS if dvb->fe[n] == NULL.
>
OK, that's trivially fixable. I'll send you an updated patch. Is it safe to
assume that dvb->fe[0] at least will always be non-NULL?
Cheers,
Chris
--
To unsubscribe from this list: send the l
e new situation is a definite improvement :-).
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c.orig 2011-08-19 00:50:41.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c 2011-08-19 00:51:03.0 +0100
@@ -542,7 +542,6 @@
dev->dvb = dv
list must have been initialised for every extension in the extension list.
Signed-of-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-19 00:23:17.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c 2011-08-19 00:32:40.0 +0100
@@
s I2C write failures with error -19 from appearing occasionally in
the dmesg log.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/common/tuners/tda18271-fe.c.orig 2011-08-18 16:55:53.0 +0100
+++ linux-3.0/drivers/media/common/tuners/tda18271-fe.c 2011-08-18 23:12:55.0
There's no reason to still be holding the device list mutex for either of these
printk statements.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-18 23:05:50.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-core.c 2011-08-
This patch ensures that the em28xx_init_dev() function cleans up after itself,
in the event that it fails. This isimportant because the struct em28xx will be
deallocated if em28xx_init_dev() returns an error.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx
Use atomic bit operations for the em28xx_devused mask, to prevent an unlikely
race condition should two adapters be plugged in simultaneously. The operations
also clearer than explicit bit manipulation anyway.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx
Release the dev->alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-video.c.orig 2011-08-18 17:20:10.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-video.c 2011-08-18 17:20:33.0 +0100
@@ -2202,6 +220
snprintf()'s size parameter includes space for the terminating '\0' character.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-17 08:52:19.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c 2011-08-18 22:
e new situation is a definite improvement :-).
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c.orig 2011-08-19 00:50:41.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c 2011-08-19 00:51:03.0 +0100
@@ -542,7 +542,6 @@
dev->dvb = dv
extension list.
Signed-of-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-19 00:23:17.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c 2011-08-19 00:32:40.0 +0100
@@ -2738,9 +2738,9 @@
#endif /*
ks by nulling out the function pointers that the DVB framework
would otherwise try to call. I have therefore declared the structs in the
tda18271 and cxd2820r modules to be "const", so that we know that they are
supposed only to be templates.
Signed-off-by: Chris Rankin
--- linux-3.0/drive
Two more patches:
a) clean up resources more reliably if em28xx_init_dev() fails,
b) move two printk() statements outside the mutex lock
Cheers,
Chris
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-18 22:42:03.0 +0100
+++ linux-3.0
em28xx_devused.
- use the correct amount of memory for snprintf().
Cheers,
Chris
Signed-of-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-18 22:24:12.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c 2011-08-18 22:22:14.0 +0100
On 18/08/11 19:43, Devin Heitmueller wrote:
You would be well served to break this into a patch series, as it tends to be
difficult to review a whole series of changes in a single patch. You seem to
be mixed in a bunch of "useless" changes alongside functional changes. For
example, if you're tr
Hi,
Here's my latest patch for the em28xx / em28xx-dvb modules, which addresses the
following problems:
a) Locking problem when unplugging and then replugging USB adapter.
b) Race conditions between adding/removing devices from the devlist, while
simultaneously loading/unloading extension mod
Hi,
This is my third draft at fixing the em28xx modules for the PCTV 290e DVB
adapter. The highlights are:
- resolve the locking issue when replugging the USB adapter,
- remove race condition when initialising an adapter and simultaneously loading
the em28xx-dvb module,
- more reliable relea
Hi,
Here's the latest draft of my patch (against 3.0). Any feedback greatly
appreciated.
Cheers,
Chris
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-16 19:49:58.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-core.c 2011-08-16 21:46:35.0 +0100
@@ -
Hi,
I've been looking deeper into the em28xx and em28xx-dvb modules, and I'm
concerned that there are some races and resource leaks inherent in the current code:
a) Shouldn't em28xx_init_extension() and em28xx_add_into_devlist() be unified
into a single function? Otherwise, consider someone p
use locked bits should be as brief as possible and neither printk()
does anything that needs the lock.
A new patch is attached, for review.
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-16 09:15:46.0 +0100
+++ linux-3.0/drivers/media/vi
Hi,
I've been "plugging away" at the locking issue in the em28xx / em28xx-dvb
modules, and I think I've found the reason. Basically, we're trying to acquire
the dev->lock mutex again in dvb_init() when we've already acquired it in
em28xx_init_dev().
The exact sequence is:
em28xx_init
--- On Mon, 15/8/11, Steve Kerrison wrote:
> It depends on whether the problem is a weak signal or a too strong
> signal.
I suspect that the HD signal is too weak where I am, because I am in the
transmitter's "green area". So it's possible that I'll have to wait until April
before getting a dec
>> INFO: task khubd:1100 blocked for more than 120 seconds.
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> khubd D 0 1100 2 0x
>> 8801a694e930 0046 8801a691ffd8 8162b020
>> 00010280 f
--- On Mon, 15/8/11, Antti Palosaari wrote:
> T 55400 8MHz + auto auto auto etc.
> is enough.
Hmm, not here it isn't:
$ scandvb -u -vvv uk-CrystalPalace
scanning uk-CrystalPalace
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 55400 0 9 9 6 2 4 4
>
Another thing I've noticed - a successful hotplug outputs the following
messages into the dmesg log:
DVB: registering new adapter (em28xx #0)
DVB: registering adapter 0 frontend 0 (Sony CXD2820R (DVB-T/T2))...
DVB: registering adapter 0 frontend 1 (Sony CXD2820R (DVB-C))...
em28xx #0: Successfull
Hi,
I've been experimenting with my new PCTV 290e DVB-T2 device this weekend, and
have a couple of observations. For example, the device sometimes has trouble
initialising itself:
usb 4-2: new high speed USB device number 4 using ehci_hcd
em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (20
Hi,
The following patch adds the IR code for the missing "OK" key to the Pinnacle
PCTV HD map. This map is now used by the PCTV 290e DVB-T2 device, whose remote
control has 26 buttons.
Cheers,
Chris
Signed-off-by: Chris Rankin
--- linux-3.0/drivers/media/rc/keymaps/rc-pin
1 - 100 of 103 matches
Mail list logo
