Christoph Bartelmus wrote:
> A user friendly GUI tool to configure the mapping of the remote
buttons is
> essential for good user experience. I hope noone here considers that
users
> learn command line or bash to configure their remotes.
oh please no
the major, major problem with bluetooth is
Dmitry Torokhov wrote:
> On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
>> Em Thu, 26 Nov 2009 17:06:03 -0200
>> Mauro Carvalho Chehab escreveu:
>>
>>> Krzysztof Halasa wrote:
Mauro Carvalho Chehab writes:
> Technically, it is not hard to port this solution t
Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
[scancode-to-keycode map size]
>> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for
>> scancode that would be out of bounds for the current table (if using
>> table approach)?
[...]
> Let's suppose, for example that instead of usi
On Saturday 28 November 2009, Mauro Carvalho Chehab wrote:
> After deleting 49 keys, you'll need to add the 55 new keys.
> If we do dynamic table resize for each operation, we'll do 104
> sequences of kmalloc/kfree for replacing one table.
Given that kmalloc only does power-of-two allocations, y
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 is on some asus laptop and some medion laptop
It was previously working with this settings (1) card=55
Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.
Signed-off-by: Ondrej Zary
diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig
linux-source-2.6.31/drivers/media/radio/Kconfig
---
Maxim Levitsky writes:
> If we add in-kernel decoding, we still will end up with two different
> decoding, one in kernel and one in lirc.
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
--
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 latest kernel features.
>
> If it ain't broke, don't fix it.
I don't kn
Hi,
This patch fix compilation warning for cxusb mygica d689 and clean up
unused code.
Regards,
David
Signed-off-by: David T. L. Wong
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c b/linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/linux/dr
Hi,
This patch improves ATBM8830 reception by using per card AGC
configuration rather than register default.
Regards,
David
Signed-off-by: David T. L. Wong
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c b/linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/
Matthias Schwarzott a écrit :
> On Freitag, 27. November 2009, Brice Dubost wrote:
>> Benedict bdc091 wrote:
>>> Hi list,
>>>
>>> I'd like to enumerate connected DVB devices from my softawre, based on
>>> DVB API V3.
>
>>> So, I tried to figure out a way to get "ASUS My Cinema U3000 Mini DVBT
>>>
Has anyone been able to make the following device work under Linux: Terratec
Cinergy Hybrid-Stick USB ID=0ccd:00a5 ?
--
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.o
On Sat, Nov 28, 2009 at 1:35 AM, Andy Walls wrote:
> On Fri, 2009-11-27 at 16:11 -0500, Andy Walls wrote:
>
>
>> Steve and Hans,
>>
>> Any ideas?
>>
>> I know on the list I had bantered around a configure, enable, set, get
>> etc v4l2_subdev ops for gpio, but I can't remember the details nor the
>
On Sat, 2009-11-28 at 12:20 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky writes:
>
> > If we add in-kernel decoding, we still will end up with two different
> > decoding, one in kernel and one in lirc.
>
> And that's good. Especially for a popular and simple protocol such as
> RC5.
> Actuall
Maxim Levitsky writes:
>> And that's good. Especially for a popular and simple protocol such as
>> RC5.
>> Actually, it's not about adding the decoder. It's about fixing it.
>> I can fix it.
>
> This is nonsense.
You forgot to say why do you think so.
--
Krzysztof Halasa
--
To unsubscribe from
On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky writes:
>
> >> And that's good. Especially for a popular and simple protocol such as
> >> RC5.
> >> Actually, it's not about adding the decoder. It's about fixing it.
> >> I can fix it.
> >
> > This is nonsense.
>
> You
Maxim Levitsky writes:
> Generic decoder that lirc has is actually much better and more tolerant
> that protocol specific decoders that you propose,
Actually, it is not the case. Why do you think it's better (let alone
"much better")? Have you at least seen my RC5 decoder?
> You claim you 'fix'
On Sat, 2009-11-28 at 16:44 +0100, Krzysztof Halasa wrote:
> Maxim Levitsky writes:
>
> > Generic decoder that lirc has is actually much better and more tolerant
> > that protocol specific decoders that you propose,
>
> Actually, it is not the case. Why do you think it's better (let alone
> "mu
Maxim Levitsky writes:
>> Actually, it is not the case. Why do you think it's better (let alone
>> "much better")? Have you at least seen my RC5 decoder?
> Because userspace decoder is general, it doesn't depend on exact timing,
> as long as pulses vary in size it can distinguish between keys, an
On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
wrote:
> On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
>> Maxim Levitsky writes:
>>
>> >> And that's good. Especially for a popular and simple protocol such as
>> >> RC5.
>> >> Actually, it's not about adding the decoder. It's about fi
Hi Krzysztof and Maxim,
on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky writes:
>> Generic decoder that lirc has is actually much better and more tolerant
>> that protocol specific decoders that you propose,
> Actually, it is not the case. Why do you think it's better (let alone
On Sat, Nov 28, 2009 at 11:47 AM, Christoph Bartelmus wrote:
> @Maxim: I think Mauro is right. We need to find an approach that makes
> everybody happy. We should take the time now to discuss all the
> possibilities and choose the best solution. LIRC has lived so long outside
> the kernel, that we
l...@bartelmus.de (Christoph Bartelmus) writes:
> Nobody here doubts that you can implement a working RC-5 decoder. It's
> really easy. I'll give you an example why Maxim thinks that the generic
> LIRC approach has advantages:
But surely not when compared to an in-kernel decoder _and_ the one
Jon Smirl writes:
> There are two very basic things that we need to reach consensus on first.
>
> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> generic tools (ls, mkdir, echo) for configuration
I think
On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC one
Jon Smirl writes:
>> 1. Merging the lirc drivers. The only stable thing needed is lirc
>> interface.
>
> Doing that locks in a user space API that needs to be supported
> forever. We need to think this API through before locking it in.
Sure, that's why I wrote about the need for it to be "stab
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:
the errors are signalled at the lowest level,
Jon Smirl wrote:
> There are two very basic things that we need to reach consensus on first.
>
> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
> generic tools (ls, mkdir, echo) for configuration
About 2:
On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
> wrote:
> > On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
> >> Maxim Levitsky writes:
> >>
> >> >> And that's good. Especially for a popular and simple protocol such as
> >> >> RC
On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky wrote:
> On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
>> What are other examples of user space IR drivers?
>>
>
> many libusb based drivers?
If these drivers are for specific USB devices it is straight forward
to turn them into kernel based d
On Sat, 28 Nov 2009 08:14:57 +0100
Németh Márton wrote:
> what do you think about the latest version of this patchset?
Hello Márton,
I wonder why you did not include the input functions directly in the
file gspca.c instead of adding new files and changing the Makefile.
Below are more remarks.
On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> There are two very basic things that we need to reach consensus on first.
>>
>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>> 2) Specific tools (xmodmap, setkeycodes, etc or the LIRC ones) or
>
On Tue, 10 Nov 2009, Ian Molton wrote:
> Well if they are only masked they shouldnt stop being asserted. But we
> should unmask them again.
>
> Im not really sure we should mask them anyway, with the card possibly
> being gone... Will need to look into it further.
Hi Ingo
What's the status of t
On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky
> wrote:
> > On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
> >> What are other examples of user space IR drivers?
> >>
> >
> > many libusb based drivers?
>
> If these drivers are for spec
Jon Smirl wrote:
> If these drivers are for specific USB devices it is straight forward
> to turn them into kernel based drivers. If we are going for plug and
> play this needs to happen. All USB device drivers can be implemented
> in user space, but that doesn't mean you want to do that. Putting
>
On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
wrote:
> Jon Smirl wrote:
>> If these drivers are for specific USB devices it is straight forward
>> to turn them into kernel based drivers. If we are going for plug and
>> play this needs to happen. All USB device drivers can be implemented
>> in us
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 1:17 PM, Stefan Richter
> wrote:
>> Jon Smirl wrote:
>>> There are two very basic things that we need to reach consensus on first.
>>>
>>> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
>>> 2) Specific tools (xmodmap, setkeycodes,
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:Sat Nov 28 19:00:06 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13536:9c38704cfd56
gcc version: gcc (
Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
> wrote:
>> Jon Smirl wrote:
>>> If these drivers are for specific USB devices it is straight forward
>>> to turn them into kernel based drivers. If we are going for plug and
>>> play this needs to happen. All USB device drivers ca
Jon Smirl writes:
> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
> codes are over 32b. Christoph posted an example that needs 128b.
This only means that the existing interface is limited.
> This
> is a problem with ioctls, they change size depending on platform and
> end
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 input drivers. (Kernel
>
On Sat, Nov 28, 2009 at 2:55 PM, Krzysztof Halasa wrote:
> Jon Smirl writes:
>
>> EVIOCSKEYCODE is lacking, first parameter is an INT. Some decoded IR
>> codes are over 32b. Christoph posted an example that needs 128b.
>
> This only means that the existing interface is limited.
>
>> This
>> is a
Jon Smirl writes:
> We have one IR receiver device and multiple remotes. How does the
> input system know how many devices to create corresponding to how many
> remotes you have? There is no current mechanism to do that. You need
> an input device for each remote so that you can do the EVIOCSKEYC
Jon Smirl writes:
> Endianess comes into play when send/receiving multibyte integers on
> platforms with different endianess.
It's the case when you're sending this data to a machine with
a different endianness. For example, in a network or to another CPU in
e.g. add-on card.
Ioctls are not affe
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
On Sat, 28 Nov 2009, Hans Verkuil wrote:
> On Friday 27 November 2009 22:40:01 Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > On Friday 27 November 2009, Mauro Carvalho Chehab wrote:
> > > Hi Linus,
> > >
> > > Please pull from:
> > >
> > > ssh://master.kernel.org/pub/scm/linux/kernel/gi
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 create corresponding to how many
>> remotes you have?
>
> If several remotes are to be used on the same receiver, then they
> necessarily need to g
On Sat, Nov 28, 2009 at 3:29 PM, 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 t
Hello,
my new card will not tune, it has a problem with the firmware I am offering.
Does not seem to fit. TV-out with this card works fine.
Here's my log:
Nov 28 15:35:00 vdr kernel: saa7146: register extension 'dvb'.
Nov 28 15:35:00 vdr kernel: dvb :00:0d.0: enabling device (0004 -> 0006)
N
Add automatic probing of ports 0x284 and 0x384 to radio-sf16fmi if no card is
found using PnP.
Signed-off-by: Ondrej Zary
--- linux-source-2.6.31/drivers/media/radio/Kconfig.1 2009-11-28
21:40:32.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
21:32:58.
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 create corresponding to how many
>>> remotes you have?
>> If several remotes are to be use
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 create corresponding to how
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 splitting those 200 scancodes
Hello everyone.
I am trying to build v4l-dvb device drivers according to instruction
on linuxTV wiki
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
but it fails when compiling dvb_frontend.c
This is what I get:
/home/tomislav/src/v4l-dvb-e341e9e85af2/v
Jon,
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> > Jon Smirl writes:
> >
> >> There are two very basic things that we need to reach consensus on first.
> >>
> >> 1) Unification with mouse/keyboard in evdev - put IR on equal fo
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 "modprobe -vr saa7134-alsa saa7134-dvb" and "modprobe -v saa7134 card=16".
And now the card recon
On Sat, Nov 28, 2009 at 4:39 AM, Antonio Ospite
wrote:
> On Tue, 17 Nov 2009 23:04:20 +0100
> Antonio Ospite wrote:
>
>> Hi,
>>
>> this series removes the init() callback from pxa_camera_platform_data, and
>> fixes its users to do initialization statically at machine init time.
>>
> [...]
>> Anto
On Sat, Nov 28, 2009 at 4:31 AM, Antonio Ospite
wrote:
> pxa_camera init() is ambiguous, it's better to configure PXA CIF pins
> statically in machine init function.
>
> Signed-off-by: Antonio Ospite
I'll grab this and get it exposed to next -rc phase.
--
To unsubscribe from this list: send the
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
>
> wrote:
> > Hi Mauro,
> >
> > on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> >> Christoph Bartelmus wrote:
> >
> > [...]
> >
> >>> But I'm still a bit hesitant about the in-kernel dec
On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> > Jon Smirl writes:
> >
> >> There are two very basic things that we need to reach consensus on first.
> >>
> >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing.
On Sat, Nov 28, 2009 at 11:32:01PM -0500, Andy Walls wrote:
> On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> > > Jon Smirl writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
> > >>
> >
On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> >
> > wrote:
> > > Hi Mauro,
> > >
> > > on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> > >> Christoph Bartelmus wrote
On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote:
> Jon,
>
> On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote:
> > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa wrote:
> > > Jon Smirl writes:
> > >
> > >> There are two very basic things that we need to reach consensus on first.
On Sat, Nov 28, 2009 at 05:18:34PM -0500, 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 corres
On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
> On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> > On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> > >
> > > wrote:
> > > > Hi Mauro,
> > > >
> > > > on 26 Nov 09 a
On Sun, Nov 29, 2009 at 04:01:53PM +1030, Mike Lampard wrote:
> On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote:
> > On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> > > On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > > > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmu
On Thu, Nov 26, 2009 at 10:34:55PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
> > This part... Not so wild about. The common thought I'm seeing from people is
> > that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> > this could be abst
On Thu, Nov 26, 2009 at 10:58:59PM -0500, Jon Smirl wrote:
> >
> >> Code is only lightly tested. Encoders and decoders have not been
> >> written for all protocols. Repeat is not handled for any protocol. I'm
> >> looking for help. There are 15 more existing LIRC drivers.
> >
> > And there's the ha
68 matches
Mail list logo
