Hello! I have a StarTech.com USB 2.0 Video Capture Cable SVID2USB2
device. I have yet to get the device working for me under Fedora 12. I
found the request to send an email with the log, so I thought I'd pass
it along. I tried several card= insmod options (0, 1, and 8) with
no luck. I would like to
hermann pitton a écrit :
Hi Thomas,
Hi Hermann,
thanks for informations ...
This card is not mine so physically inspect it is not possible and the
owner is at 700 kms from me...
However, it seems there is only one hybrid tuner. The card is referenced as
AR307 rev N (seen on p
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
> wrote:
>>> In the code I posted there is one evdev device for each configured
>>> remote. Mapped single keycodes are presented on these devices for each
>>> IR burst. There is no device for the IR
On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote:
> On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa wrote:
>
>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>> least?
>>
>> 2. Is there any problem with lirc kernel-user interface?
>>
>> If the answer for #1 is "yes"
On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls wrote:
>> If decoding can *only* be sanely handled in user-space, that's one
>> thing. If it can be handled in kernel, then that would be better.
>
> Why does the address space in which decoding is performed make the
> decoding process better or worse?
Hi Dominic,
Am Samstag, den 28.11.2009, 17:30 -0800 schrieb Dominic Fernandes:
> Hi Hermann,
>
> I'm getting closer!!!
>
> I'm using ubuntu 9.10, unloading saa7134 alsa wasn't working for me so I put
> it into the blacklist which prevented it from loading and then I was able to
> do the "mod
Am Samstag, den 28.11.2009, 11:55 +0100 schrieb tomloh...@gmail.com:
> hermann pitton a écrit :
> > Hi Tom,
> >
> > Am Mittwoch, den 18.11.2009, 14:06 +0100 schrieb tomloh...@gmail.com:
> >
> >> Hello list,
> >>
> >> looking from saa7134.h, this board 5168:0307 is not included
> >> This cars
On Sun, 2009-11-29 at 21:27 +0100, Krzysztof Halasa wrote:
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>least?
Yes. Honestly, I'm just waiting on lirc_dev for the IR devices I work
with. With that I can get those new devices supported for both IR Rx
and Tx right
On Sun, 2009-11-29 at 20:49 +0100, Christoph Bartelmus wrote:
> Hi,
>
> on 29 Nov 09 at 14:16, Jon Smirl wrote:
> > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote:
> >>> Jon is asking for an architecture discussion, y'know, with use cases.
> [...]
> > So we're just back to the status quo of last
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky
> wrote:
> > This has zero advantages besides good developer feeling that "My system
> > has one less daemon..."
>
> Surely it's clear that having an unnecessary daemon is introducing
> another po
On Nov 29, 2009, at 1:47 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is
needed at
least
Mike Lampard wrote:
> an example I have a VDR instance running in the background on my desktop
> machine outputting to a TV in another room via a pci mpeg decoder - I
> certainly don't want the VDR remote control interacting with my X11 desktop
> in
> any way unless I go out of my way to set it
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/
for the following 9 changesets:
v4l: Add video_device_node_name function
v4l: Use the new video_device_node_name function
v4l: Remove video_device::num usage
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
wrote:
> On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
>
>> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote:
>>>
>>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
>>> least?
>>>
>>> 2. Is there any problem with l
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
the Jarod's lirc patches (at le
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote:
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa
wrote:
1. Do we agree that a lirc (-style) kernel-user interface is needed
at
least?
2. Is there any problem with lirc kernel-user interface?
Can you consider sending the raw IR data as a
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote:
> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
> least?
>
> 2. Is there any problem with lirc kernel-user interface?
Can you consider sending the raw IR data as a new evdev message type
instead of creating a new
1. Do we agree that a lirc (-style) kernel-user interface is needed at
least?
2. Is there any problem with lirc kernel-user interface?
If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge
the Jarod's lirc patches (at least the core) so at least the
non-controversial part is d
Hi,
since I've been having problems with not seeing my IR remote in recent
kernelsx any more (starting at least with 2.6.30) I tried the current
version of the v4l-dvb tree (revision 13538) and 2.6.32-rc7 on my amd64
with a Hauppauge HVR1300.
With that version I get a kernel bug upon module l
Signed-off-by: Thiago Farina
---
drivers/media/video/cpia2/cpia2_v4l.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/cpia2/cpia2_v4l.c
b/drivers/media/video/cpia2/cpia2_v4l.c
index 0b4a8f3..6c5fcd8 100644
--- a/drivers/me
Hi,
on 29 Nov 09 at 14:16, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote:
>>> Jon is asking for an architecture discussion, y'know, with use cases.
[...]
> So we're just back to the status quo of last year which is to do
> nothing except some minor clean up.
>
> We'll be back
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:
date:Sun Nov 29 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13538:e0cd9a337600
gcc version: gcc (
> So we're just back to the status quo of last year which is to do
> nothing except some minor clean up.
Which in itself is vastly preferable to some grandiose scheme that turns
out to be wrong.
And no it's not a back to the status quo, it's a request to discuss the
actual problems and options no
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote:
>> Jon is asking for an architecture discussion, y'know, with use cases.
>> Maxim seems to be saying it's obvious that what we have today works
>> fine. Except it doesn't appear that we have a consensus that
>> everything is fine, nor an obvious win
On Sun, Nov 29, 2009 at 12:41:22PM -0500, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 12:17 PM, Greg KH wrote:
> >> +static ssize_t ir_raw_show(struct device *dev,
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device_attribute *attr, char *buf)
> >> +{
> >> + ? ? struct input_dev *input_dev = to_input
On Sun, Nov 29, 2009 at 12:37:36PM -0500, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 12:14 PM, Greg KH wrote:
> > On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
> >> Changes to core input subsystem to allow send and receive of IR messages.
> >> Encode and decode state machines are pro
> Jon is asking for an architecture discussion, y'know, with use cases.
> Maxim seems to be saying it's obvious that what we have today works
> fine. Except it doesn't appear that we have a consensus that
> everything is fine, nor an obvious winner for how to reduce the
> complexity here and keep t
> Half of the drivers are in user space and there are two different
> classes of kernel driver - LIRC and V4L.
> A lot of the hardware doesn't identify itself.
> There are two types of IR data in use - pulse timing and decoded protocol.
>
> IR is an input device. We have a nice evdev input subsy
On Sun, Nov 29, 2009 at 10:13 AM, Alan Cox wrote:
>> If decoding can *only* be sanely handled in user-space, that's one
>> thing. If it can be handled in kernel, then that would be better.
>
> Why ?
>
> I can compute fast fourier transforms in the kernel but that doesn't make
> it better than doin
On Sun, Nov 29, 2009 at 7:40 AM, Alan Cox wrote:
>> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
>
> Correct X11 just talked to the serial ports. In fact that is still the
> way to configure it if you want any sanity in life.
>
>> and serial connected IRs. It's also to
> If decoding can *only* be sanely handled in user-space, that's one
> thing. If it can be handled in kernel, then that would be better.
Why ?
I can compute fast fourier transforms in the kernel but that doesn't make
it better than doing it in user space. I can write web servers in the
kernel and
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky wrote:
> This has zero advantages besides good developer feeling that "My system
> has one less daemon..."
Surely it's clear that having an unnecessary daemon is introducing
another point of failure? Reducing complexity is not just its own
reward in
On Sun, Nov 29, 2009 at 12:17 PM, Greg KH wrote:
>> +static ssize_t ir_raw_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct input_dev *input_dev = to_input_dev(dev);
>> + unsigned int i, count = 0;
>> +
>> + for (i =
On Sun, Nov 29, 2009 at 12:14 PM, Greg KH wrote:
> On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
>> Changes to core input subsystem to allow send and receive of IR messages.
>> Encode and decode state machines are provided for common IR porotocols such
>> as Sony, JVC, NEC, Philips,
On Sun, 2009-11-29 at 12:40 +, Alan Cox wrote:
> > BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
>
> Correct X11 just talked to the serial ports. In fact that is still the
> way to configure it if you want any sanity in life.
>
> > and serial connected IRs. It's a
> +static ssize_t ir_raw_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct input_dev *input_dev = to_input_dev(dev);
> + unsigned int i, count = 0;
> +
> + for (i = input_dev->ir->raw.tail; i != input_dev->ir->raw.head; )
On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote:
> Changes to core input subsystem to allow send and receive of IR messages.
> Encode and decode state machines are provided for common IR porotocols such
> as Sony, JVC, NEC, Philips, etc.
>
> Received IR messages generate event in the i
On Sun, 29 Nov 2009 13:15:37 +0100
Németh Márton wrote:
> I think that the return value of the usb_control_msg() is to be
> evaluated. If other drivers also not evaluating the usb_control_msg()
> *they* has to be fixed.
>
> The benefit would be that the userspace program can recognise error
> co
This was found with a static checker and has not been tested, but it seems
pretty clear that the mutex_lock() was supposed to be mutex_unlock()
This is a 2.6.32 candidate.
Hi,
On 11/29/2009 01:15 PM, Jean-Francois Moine wrote:
On Sun, 29 Nov 2009 12:19:46 +0100
Németh Márton wrote:
Is there any subdriver where the isoc_nego() is implemented? I
couldn't find one. What would be the task of the isoc_nego()
function? Should it set the interface by calling usb_set_i
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter
> wrote:
>> Jon Smirl wrote:
>>> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
>>> wrote:
Jon Smirl wrote:
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to
Jon Smirl wrote:
> I'm looking at a Sony multi-function remote right now. It has five
> devices and forty keys. Each of the five devices can transmit 0-9,
> power, volume, etc. It transmits 5*40 = 200 unique scancodes.
>
> I want the five devices to correspond to five apps. What's the plan
> for s
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
> wrote:
>> Jon Smirl wrote:
>>> Also, how do you create the devices for each remote? You would need to
>>> create these devices before being able to do EVIOCSKEYCODE to them.
>> The input subsystem creates devices on behalf of inp
Hello,
I did a smatch static checker run and found a double unlock in
bttv-driver.c.
drivers/media/video/bt8xx/bttv-driver.c +3203 bttv_poll() error: double unlock
'&fh->cap.vb_lock'
I would fix it myself, but I don't know if the poll_wait() is supposed
to be protected by mutex_unlock(&fh->cap.v
On Thu, 2009-11-26 at 17:43 +0100, Matthias Fechner wrote:
> Hi Andy,
>
> Andy Walls wrote:
> > I will inspect and test these with my HVR-1850 (CX23888) loaner board
> > this weekend (hopefully).
> >
>
> if you want me to test something on the Tevii S470 card, please let me know.
MAtthias,
N
> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around
Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.
> and serial connected IRs. It's also too convenient to access USB IR
> hardware from existing use
Hi All,
I am trying to configure a Winfast PxDVR3200 H on Ubuntu
9.10 (Karmic). Although the card seems to be detected, there is no
signal when I try to scan for channels either using scan or a variety
of software interfaces (me tv, kaffeine, myth tv). All give a signal
strength of 0. Any help at a
Jean-Francois Moine wrote:
> On Sat, 28 Nov 2009 08:13:05 +0100
> Németh Márton wrote:
>
>> what do you think about this patch?
>
> Hi Márton,
>
> There are many other drivers where the usb_control_msg() errors are not
> tested nor propagated to higher levels. Generally, this does not matter:
>
On Sun, 29 Nov 2009 12:19:46 +0100
Németh Márton wrote:
> Is there any subdriver where the isoc_nego() is implemented? I
> couldn't find one. What would be the task of the isoc_nego()
> function? Should it set the interface by calling usb_set_interface()
> as the get_ep() does? Should it create U
Hi Krzysztof,
on 28 Nov 09 at 18:21, Krzysztof Halasa wrote:
[...]
>> This remote uses RC-5. But some of the developers must have thought that
>> it may be a smart idea to use 14 bits instead the standard 13 bits for
>> this remote. In LIRC you won't care, because this is configurable and
>> irrec
Hi Stefan,
on 28 Nov 09 at 21:29, Stefan Richter wrote:
> Jon Smirl wrote:
>> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter
>> wrote:
>>> Jon Smirl wrote:
Also, how do you create the devices for each remote? You would need to
create these devices before being able to do EVIOCSKEYCODE
Hi Mauro,
on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote:
> Hi Christoph,
>
> Christoph Bartelmus wrote:
>>> Maybe we decide to take the existing LIRC system as is and not
>>> integrate it into the input subsystem. But I think there is a window
>>> here to update the LIRC design to use the la
Hi Jon,
on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]
> Christoph, take what you know from all of the years of working on LIRC
> and design the perfect in-kernel system. This is the big chance to
> redesign IR support and get rid of any past mistakes. Incorporate any
> useful chunks of code and kn
Hello list
I try to build latest s2-liplianin drivers but make shows severals
warnings and module not load after build driver:
WARNING: "ir_input_keydown" [s2-liplianin/v4l/mantis.ko] undefined!
WARNING: "ir_codes_mantis_vp1041_table" [s2-liplianin/v4l/mantis.ko] undefined!
WARNING: "ir_input_no
Jean-Francois Moine wrote:
> On Sun, 29 Nov 2009 11:24:31 +0100
> Németh Márton wrote:
>
>> From: Márton Németh
>>
>> Eliminate redundant code by reorganizing the loop.
>>
>> Signed-off-by: Márton Németh
>> ---
>> diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
>> --- a/linux/drive
On Sun, 29 Nov 2009 11:24:31 +0100
Németh Márton wrote:
> From: Márton Németh
>
> Eliminate redundant code by reorganizing the loop.
>
> Signed-off-by: Márton Németh
> ---
> diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
> --- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26
From: Márton Németh
Calling gspca_set_alt0() in gspca_dev_probe() is not needed as gspca_set_alt0()
will do nothing because gspca_dev->alt is always zero at that time.
Signed-off-by: Márton Németh
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/g
From: Márton Németh
Eliminate redundant code by reorganizing the loop.
Signed-off-by: Márton Németh
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26 19:36:40 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun
58 matches
Mail list logo
