On 16 January 2017 at 23:40, Antti Palosaari <cr...@iki.fi> 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 <
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
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
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
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
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()
> 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
ease?
Thanks,
Chris
On Sun, Nov 15, 2015 at 10:46 PM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> Em Sun, 15 Nov 2015 22:18:48 +
> Chris Rankin <ranki...@googlemail.com> escreveu:
>
>> > How are you "switching back to RC5"?
>>
your distro 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 ranki...@yahoo.com wrote:
Hi,
The DVB-T initial tuning information for Crystal Palace in the UK is
completely obsolete - despite my
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
On Friday, 21 February 2014, 9:47, Hans de Goede hdego...@redhat.com 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
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
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
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
- Original Message -
From: Devin Heitmueller dheitmuel...@kernellabs.com
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
-EINVAL;
This is against 3.9.3.
Signed-off-by: Chris Rankin ranki...@yahoo.com
No, this patch is wrong.
Updating ir-rc_type with the new value of *rc_type is correct.
Well, it restores 3.8 behaviour, i.e. em28xx not clobbering its RC5
configuration when RC core subsequently calls
- 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
- 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
- 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 -
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=1
- 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
- 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 trigger an
- 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():
;
+ return 0;
} else {
*rc_type = ir-rc_type;
return -EINVAL;
This is against 3.9.3.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info
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
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]
- 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 kernel.
Downgrading the kernel
- 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 RC
- 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
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
#
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.
*
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 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
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 mche...@redhat.com
Sun, 1 Jan 2012 19:11:16 + (16:11 -0300)
committer: Mauro Carvalho Chehab mche...@redhat.com
In fact, the following patch works for me.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
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 ranki...@yahoo.com
--- linux-3.3/drivers
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.org
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
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 majordomo
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.
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)
#! w_scan
Subject: em28xx leaks
Date: Fri, 27 Jan 2012 13:21:50 -0600
From: Todd Squires squir...@ct0.com
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
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
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 practice.
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
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 ranki...@yahoo.com
--- linux/drivers/media/video/em28xx/em28xx.h.orig 2011-09-25 14:46:02.0 +0100
+++ linux/drivers/media
the case anyway.
Signed-off-by: Chris Rankin ranki...@yahoo.com
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,10 +3005,6 @@
goto fail
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
This line was probably missed in the merge.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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(em28xx_devlist_mutex
- 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 much work
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 ranki
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin ranki...@yahoo.com
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
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
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-off
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: Chris
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
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 ranki...@yahoo.com
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-04 20:30:14.0 +0100
+++ linux/drivers
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:
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
--- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org 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/
--- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org 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.
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.
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx
snprintf()'s size parameter includes space for the terminating '\0' character.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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:03
Release the dev-alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video
There's no reason to still be holding the device list mutex for either of these
printk statements.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
write failures with error -19 from appearing occasionally in
the dmesg log.
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
been initialised for every extension in the extension list.
Signed-of-by: Chris Rankin ranki...@yahoo.com
--- 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
situation is a definite improvement :-).
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com 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
--- On Sat, 20/8/11, Mauro Carvalho Chehab mche...@redhat.com 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
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
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx
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
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
for em28xx_devused.
- use the correct amount of memory for snprintf().
Cheers,
Chris
Signed-of-by: Chris Rankin ranki...@yahoo.com
--- 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
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-08-18 22:42:03.0
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 ranki...@yahoo.com
--- linux-3.0
.
Signed-of-by: Chris Rankin ranki...@yahoo.com
--- 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 /* CONFIG_MODULES
situation is a definite improvement :-).
Signed-off-by: Chris Rankin ranki...@yahoo.com
--- 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
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
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig 2011-08-16 09:15:46.0 +0100
+++ linux-3.0/drivers
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
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
@@
--- On Mon, 15/8/11, Steve Kerrison st...@stevekerrison.com 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
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:
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 ranki...@yahoo.com
--- linux-3.0/drivers/media/rc/keymaps/rc
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
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:
--- On Mon, 15/8/11, Antti Palosaari cr...@iki.fi 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
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
Hi,
I've just acquired a PCTV 290e nanostick, and have successfully tuned it into a
DVB-T2 MUX. Yay! :-).
However, before declaring total victory, I have noticed that no-one has yet
wired up the device's IR support in the em28xx driver. The adapter ships with a
tiny RC with only 26 buttons,
--- On Sat, 13/8/11, Antti Palosaari cr...@iki.fi wrote:
Remote is already supported, but from the 3.1 or maybe 3.2
(I am not sure if Mauro was hurry to sent it 3.1).
Hi,
This appears to be the diff from 3.1 that adds RC support:
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig
Hi,
The rc-pinnacle-pctv-hd keymap is missing the definition of the OK key:
--- linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c.orig
2011-08-14 02:42:01.0 +0100
+++ linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c2011-08-14
02:12:45.0 +0100
@@ -20,6
100 matches
Mail list logo
