Hi Gerd,
on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]
>> To sum it up: I don't think this information will be useful at all for
>> lircd or anyone else.
[...]
> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings. Thats why I think there will alway
Hi,
on 25 Nov 09 at 12:44, Jarod Wilson wrote:
[...]
> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
> be this:
[...]
> [*] assuming, of course, that it was actually agreed upon that in-kernel
> decoding was the right way, the only way, all others will be shot on sight
On Thu, Nov 26, 2009 at 09:01:00AM +0100, Christoph Bartelmus wrote:
> Hi,
>
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
> > Ah, but the approach I'd take to converting to in-kernel decoding[*] would
> > be this:
> [...]
> > [*] assuming, of course, that it was actually agreed upon that i
> Hi,
>
> After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
> 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
> appeared to be ok, but I have now noticed certain channels in Australia
> are showing corruption which manifest themselves as blockiness a
On 11/26/09 08:28, Christoph Bartelmus wrote:
Hi Gerd,
on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]
To sum it up: I don't think this information will be useful at all for
lircd or anyone else.
[...]
I know that lircd does matching instead of decoding, which allows to
handle unknown encod
Hi Magnus
> So now I've done some testing of the mt9t112 sensor hooked up to CEU0
> on the ecovec board. I tried 16-bit RGB and NV12 in various
> resolutions with mplayer. My only comment is that it seems to take a
> bit of time to setup the sensor initially, but that may be something
> related t
On 11/26/09 07:23, Jarod Wilson wrote:
Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.
lirc predates the input layer IR drivers by years, maybe even the input
layer itself.
The main reason for the input layer I
Hi Rob
would you mind very much posting a patch that implements these two reversions,
so I can try it easily? My hg-fu is somewhat lacking...
I have the same hardware and noticed what I think is the same issue,
just with Channel 9.
Another manifestation is huge BER and nonzero REC in the output fr
On 11/26/09, Vincent McIntyre wrote:
> Another manifestation is huge BER and nonzero REC in the output from
> 'tzap'.
doh! I meant huge BER and nonzero UNC.
Apologies also for the top-post.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majo
Hello,
this is a proposed implementation for mem-to-mem memory device framework.
Previous discussion and RFC on this topic:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both source and destination. This is
different from existing drivers that use memory buffers for only one
of those at once.
In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type.
Although
Signed-off-by: Pawel Osciak
Signed-off-by: Marek Szyprowski
Reviewed-by: Kyungmin Park
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mem2mem_testdev.c | 1050 +
3 files changed, 1058 insert
This is an example application for testing mem-to-mem framework using
mem2mem-testdev device.
It is intended to be executed multiple times in parallel to test multi-instance
operation and scheduling. Each process can be configured differently using
command-line arguments.
The application opens vi
Hi!
I posted yesterday the following message to the mythtv-users mailing
list, but they answered me it's more suitable to post it in your mailing
list.
Alan
Hi!
I REALLY need some help with the Hauppauge WinTV HVR-4000
(http://www.hauppauge.it/site/products/data_hvr4000.html).
Days ago I insta
> Hi Rob
>
> would you mind very much posting a patch that implements these two
> reversions,
> so I can try it easily? My hg-fu is somewhat lacking...
> I have the same hardware and noticed what I think is the same issue,
> just with Channel 9.
> Another manifestation is huge BER and nonzero REC i
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>>> (This is no recommendation for lirc. I have no idea whether a
>>> pulse/space -> scancode -> keycode translation would be practical
>>> there.)
>
> It would, but not exactly in the present shape.
>
>> For example, there are several
On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:
>
> > On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
> >> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> >>> Czesc Krzysztof,
> >>>
> >>> on 23 Nov 09 at 15:
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> If you see patch 3/3, of the lirc submission series, you'll notice a driver
>> that has hardware decoding, but, due to lirc interface, the driver generates
>> pseudo pulse/space code for it to work via lirc interface.
>
> IOW the drive
I am now playing around with the available code for quite some time now
with mixed success, but no solution comes near the term “stable”.
• kernel: nothing in there. Well, reasonable.
• v4l-dvb: nothing in there.
• s2-liplianin: mantis available, but obviously not under
development/bugfixing. IR s
From: Krzysztof Helt
This is recreated driver for the FM module found on Miro
PCM20 sound cards. This driver was removed around the 2.6.2x
kernels because it relied on the removed OSS module. Now, it
uses a current ALSA module (snd-miro) and is adapted to v4l2
layer.
It provides only basic funct
On Thu, Nov 26, 2009 at 6:12 AM, Alan Ferrero wrote:
> Hi!
>
> I posted yesterday the following message to the mythtv-users mailing
> list, but they answered me it's more suitable to post it in your mailing
> list.
>
> Alan
>
> Hi!
>
> I REALLY need some help with the Hauppauge WinTV HVR-4000
> (h
Andy Walls wrote:
> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception).
> Regards,
> Andy "LIRC Fan-Boy" Walls
This is not a lirc love or hate thread. We're simply discussing the better
API's for IR, from the technical standpoint,
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab writes:
> PS.: For those following those discussions that want to know more about
> IR protocols, a good reference is at:
> http://www.sbprojects.com/knowledge/ir/ir.htm
>
>
Andy Walls wrote:
> On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
>> l...@bartelmus.de (Christoph Bartelmus) writes:
>>
I think we shouldn't at this time worry about IR transmitters.
>>> Sorry, but I have to disagree strongly.
>>> Any interface without transmitter support would be
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
> >> l...@bartelmus.de (Christoph Bartelmus) writes:
> >>
> I think we shouldn't at this time worry about IR transmitters.
> >>> Sorry, but I have
Jarod Wilson wrote:
> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> ...
>> I generally don't understand the LIRC aversion I perceive in this thread
>> (maybe I just have a skewed perception). Aside for a video card's
>> default
Krzysztof Halasa wrote:
> Andy Walls writes:
>
>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>> developed by Philips, but Microsoft has some sort of licensing interest
>> in it and it is almost surely encumbered somwhow:
>
> I don't know about legal problems in some count
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore w
Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>
>> l...@bartelmus.de (Christoph Bartelmus) writes:
>>
>>> I'm not sure what two ways you are talking about. With the patches posted
>>> by Jarod, nothing has to be changed in userspace.
>>> Everything works, no code ne
Hi Guennadi,
Just two things really:
1) Can you move v4l2_mbus_packing and v4l2_mbus_order to a soc-mediabus.h
header or something similar? It's now soc-specific, so it doesn't belong
in the public header.
2) What are your plans for documenting the mediabus pixel codes?
Otherwise it looks great
Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>> wrote:
>>> Took me a minute to figure out exactly what you were talking
>>> about. You're referring to the current in-kernel decoding done on
>>> an ad-hoc basis for assorted remot
At Thu, 26 Nov 2009 13:50:17 +0100,
Krzysztof Helt wrote:
>
> From: Krzysztof Helt
>
> This is recreated driver for the FM module found on Miro
> PCM20 sound cards. This driver was removed around the 2.6.2x
> kernels because it relied on the removed OSS module. Now, it
> uses a current ALSA modu
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
wrote:
> Gerd Hoffmann wrote:
>> On 11/25/09 19:20, Devin Heitmueller wrote:
>>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson
>>> wrote:
Took me a minute to figure out exactly what you were talking
about. You're referring to the cur
On Wed, Nov 25, 2009 at 11:21 AM, Laurent Pinchart
wrote:
> Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers.
>
> Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb-
> cleanup/rev/7a762df57149 ? The patch should be committed to v4l-dvb in time
> for 2.6
BTW, we used to have device specific user space interfaces for mouse
and keyboard. These caused all sort of problems. A lot of work went
into unifying them under evdev. It will be years until the old,
messed up interfaces can be totally removed.
I'm not in favor of repeating the problems with a d
Jarod Wilson wrote:
>> I guess the question is what is the interface we want the regular
>> userspace (i.e. not lircd) to use. Right now programs has to use 2
>> intercfaces - one lirc for dealing with remotes that are not using
>> the standard event interface and evdev for remotes using it as wel
Christoph Bartelmus wrote:
> Hi,
>
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
>> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
>> be this:
> [...]
>> [*] assuming, of course, that it was actually agreed upon that in-kernel
>> decoding was the right way, the o
Andy Walls wrote:
> On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
>> I'm not sure if all the existing hardware for TX currently supports only
>> raw pulse/code sequencies, but I still think that, even on the Tx case,
>> it is better to send scancodes to the driver, and let it do
Gerd Hoffmann writes:
> Why not? With RC5 remotes applications can get the device address
> bits for example, which right now are simply get lost in the ir code
> ->
> keycode conversion step.
Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think t
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.
Bye,
Matthias
--
"Programming today is a race between software engineers striving to buil
On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:
On 11/26/09 07:23, Jarod Wilson wrote:
Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.
lirc predates the input layer IR drivers by years, maybe even the input
layer it
>From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski
Date: Thu, 26 Nov 2009 18:20:45 +0100
Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev pixel and
frame formats
Video subdevices, like cameras, decoders, connect to video bridg
On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
Jarod Wilson wrote:
On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
...
I generally don't understand the LIRC aversion I perceive in this thread
(maybe I just have a skewed perce
At Thu, 26 Nov 2009 18:38:27 +0100,
Krzysztof Helt wrote:
>
> On Thu, 26 Nov 2009 16:43:15 +0100
> Takashi Iwai wrote:
>
> > At Thu, 26 Nov 2009 13:50:17 +0100,
> > Krzysztof Helt wrote:
> > >
> > > From: Krzysztof Helt
> > >
> > > This is recreated driver for the FM module found on Miro
> >
Dmitry Torokhov writes:
> In what way the key interface is unsufficient for delivering button
> events?
At present: 128 different keys only (RC5: one group). One remote per
device only.
The protocol itself doesn't have the above limitations, but has others,
with are acceptable for key input.
--
Jarod Wilson wrote:
> On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
>> Jarod Wilson wrote:
>>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>>>
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> ...
I generally don't understand the LIRC aversion I perceive in this
Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
>> In what way the key interface is unsufficient for delivering button
>> events?
>
> At present: 128 different keys only (RC5: one group). One remote per
> device only.
>
> The protocol itself doesn't have the above limitations, but has other
Mauro Carvalho Chehab writes:
> 1) the developer that adds the hardware also adds the IR code. He has
> the hardware and the IR for testing, so it means a faster development
> cycle than waiting for someone else with the same hardware and IR to
> recode it on some other place. You should remember
Mauro Carvalho Chehab writes:
> Technically, it is not hard to port this solution to the other
> drivers, but the issue is that we don't have all those IR's to know
> what is the complete scancode that each key produces. So, the hardest
> part is to find a way for doing it without causing regress
Mauro Carvalho Chehab writes:
> The issue I see is to support at the same time NEC and RC5 protocols. While
> this may work with some devices, for others, the hardware won't allow.
Sure. We can handle it for the "simple" devices at least.
>> I think the mapping should be: key = proto + group +
Maxim Levitsky writes:
> But devices that send raw pulse/space data should be handled in lirc
> that will feed the data back to the kernel via uinput.
I still do want the in-kernel RCx decoding. And lirc pulse/space.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscri
Dmitry Torokhov writes:
> Why would sysfs write be slower than ioctl?
Sysfs is generally one-value, one-file. open, read/write, close.
ioctl() OTOH does everything (e.g. a whole key table) in one syscall.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-med
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> 1) the developer that adds the hardware also adds the IR code. He has
>> the hardware and the IR for testing, so it means a faster development
>> cycle than waiting for someone else with the same hardware and IR to
>> recode it on some
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Technically, it is not hard to port this solution to the other
>> drivers, but the issue is that we don't have all those IR's to know
>> what is the complete scancode that each key produces. So, the hardest
>> part is to find a way for
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The issue I see is to support at the same time NEC and RC5 protocols. While
>> this may work with some devices, for others, the hardware won't allow.
>
> Sure. We can handle it for the "simple" devices at least.
>
>>> I think the mapp
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Andy Walls writes:
> >
> >> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >> developed by Philips, but Microsoft has some sort of licensing interest
> >> in it and it is almost sur
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:Thu Nov 26 19:00:02 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13520:74ad936bcca2
gcc version: gcc (
This series of patches provide support for the TVP7002 decoder in DM365.
Support includes:
* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support
This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidha
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/
This series of patches provide support for the TVP7002 decoder in DM365.
Support includes:
* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support
This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidha
From: Santiago Nunez-Corrales
This patch provides the required definitions for the TVP7002 driver
in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002_reg.h | 150 +
include/media/tvp7002.h | 57 ++
2 file
From: Santiago Nunez-Corrales
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Signed-off-by: Santiag
From: Santiago Nunez-Corrales
This patch provides menu configuration options for the TVP7002
decoder driver in DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/Kconfig | 41 +
drivers/media/video/Makefile |3 +++
2 files chang
Mauro Carvalho Chehab writes:
> The removal of the existing keymaps from kernel depends on having an
> application
> to be called from udev to load the proper keymaps when a device is probed.
>
> After having it for a while, we should deprecate the in-kernel keymaps
> and move them to userspace.
Mauro Carvalho Chehab writes:
> see include/linux/input.h:
>
> struct input_event {
> struct timeval time;
> __u16 type;
> __u16 code;
> __s32 value;
> };
>
> extending the value to more than 32 bits require some changes at the
> input layer, probably breaking kern
Hi Mauro,
on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
[...]
> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> that support only pulse/space raw mode and devices that generate scan
> codes via the raw mode interface. It does it by generating artificial
> pulse co
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
> [...]
>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>> that support only pulse/space raw mode and devices that generate scan
>> codes via the raw mode interface. It does
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> see include/linux/input.h:
>>
>> struct input_event {
>> struct timeval time;
>> __u16 type;
>> __u16 code;
>> __s32 value;
>> };
>>
>> extending the value to more than 32 bits require some changes at the
Mauro Carvalho Chehab writes:
> No. All the other API functions there work with 32 bits for scancodes.
We don't need them, do we? We need a new ioctl for changing key mappings
anyway (a single ioctl for setting the whole table I think), and we can
have arbitrary length of scan codes there.
> (w
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>>
>> After having it for a while, we should deprecate the in-kernel keyma
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:Thu Nov 26 20:48:58 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13527:b3695bd384cc
gcc version: gcc (
On Thursday 26 November 2009 21:04:25 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides the implementation of the TVP7002 decoder
> driver for DM365. Implemented using the V4L2 DV presets API.
> Removed shadow register values. Testing shows that the device
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa wrote:
Dmitry Torokhov writes:
In what way the key interface is unsufficient for delivering button
events?
At present: 128 different keys only (RC5: one group).
Where did this limitation come from? We have more than 256 keycodes
already _de
Hi Mauro,
on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>>> that support only pulse/space raw mode and devices that generate scan
>>> codes via the raw mode interface. It does it
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the whole table I think), and we can
> have arbitr
Christoph Bartelmus wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
>> Christoph Bartelmus wrote:
> [...]
lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes
On Thursday 26 November 2009 22:37:12 Hans Verkuil wrote:
> 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:Thu Nov 26 20:48:58 CET 2009
> path:http://www.l
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> See above. Also, several protocols have a way to check if a keystroke were
> >> properly received. When handling just one protocol, we can use this to
> >> double
> >> check the key. However, on a multiprotocol mode, we'll need to disable this
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> >> that support only pulse/space raw mode and devices that generate scan
> >> codes via the raw mode interface. It does it by generating artificial
> >> pulse codes.
>
On Thu, Nov 26, 2009 at 07:05:01PM -0200, Mauro Carvalho Chehab wrote:
>
> For example, the two ioctls to replace a scancode x key code are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04
On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > No. All the other API functions there work with 32 bits for scancodes.
>
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the who
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>
> > On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
> >> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
> >>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Hal
On Thu, Nov 26, 2009 at 07:40:01PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> > Why would sysfs write be slower than ioctl?
>
> Sysfs is generally one-value, one-file. open, read/write, close.
> ioctl() OTOH does everything (e.g. a whole key table) in one syscall.
There are bi
>> Hi Rob
>>
>> would you mind very much posting a patch that implements these two
>> reversions,
>> so I can try it easily? My hg-fu is somewhat lacking...
>> I have the same hardware and noticed what I think is the same issue,
>> just with Channel 9.
>> Another manifestation is huge BER and nonze
On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote:
>
> (1) ir code (say rc5) -> keycode conversion looses information.
>
> I think this can easily be addressed by adding a IR event type to the
> input layer, which could look like this:
>
> input_event->type = EV_IR
> input_event-
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>
> Dmitry,
>
> While lirc is basically a series of input drivers, considering that they have
> lots
> in common with the input drivers at V4L/DVB and that we'll need to work on
> some glue to merge both, do you mind if I add
Dmitry Torokhov writes:
>> One remote per
>> device only.
>
> Why would you want more? One physical device usually corresponds to a
> logical device. If you have 2 remotes create 2 devices.
I meant "per receiver device".
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsub
Mauro Carvalho Chehab writes:
> Why do you want to replace everything into a single shot?
Why not? It seems simpler to me. We need to change this anyway.
If we change the whole table in a single ioctl, we can easily enumerate
protocols requested and enable then selectively.
But I think it's a m
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov writes:
>
> >> One remote per
> >> device only.
> >
> > Why would you want more? One physical device usually corresponds to a
> > logical device. If you have 2 remotes create 2 devices.
>
> I meant "per receiver
Dmitry Torokhov writes:
> There are binary sysfs attributes.
Aren't they to be used for things like ROMs and EEPROMs exclusively?
> For ioctl you also need to open and
> close the device.
Sure, but I do it once.
> Plus, how often do you expect to perform this
> operation? Don't you think you
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > Why do you want to replace everything into a single shot?
>
> Why not? It seems simpler to me. We need to change this anyway.
ioctls with a variable argument length are a pain for 32 bit
emulation
Dmitry Torokhov writes:
> There is nothing in input layer that precludes you from creating
> multiple input devices per *whatever*.
Of course. I though it was obvious I mean present situation with the
media drivers but I can see now it was far from being obvious.
--
Krzysztof Halasa
--
To unsub
Trent Piepho writes:
> Then you use the protocol that fits best. For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode. Clearly then the latter is
> most likely to be correct.
Right.
> It also
This is a repost of the LIRC input patch series I wrote a year ago.
Many of the ideas being discussed in the currect "Should we create a
raw input interface for IR's?" thread have already been implemented
in this code.
---
All of this kernel code i
Minimal changes to the core input system. The bulk of IR support loads as a
module. These changes are passive if the rest of IR isn't loaded.
Jon Smirl
---
drivers/input/input.c | 17 +
include/linux/input.h | 75 +++
include/l
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 input queue.
IR messages are sent using an input IOCTL.
---
drivers/i
Now uses configfs to build mappings from remote buttons to key strokes. When
ir-core loads it creates /config/remotes. Make a directory for each remote you
have; this will cause a new input devices to be created. Inside these
directories make a directory for each key on the remote. In the key di
GPT is a GPIO pin that is cable able of measuring the lenght of pulses.
GPTs are common on embedded systems
---
drivers/input/ir/Kconfig |6 +
drivers/input/ir/Makefile |3 +
drivers/input/ir/ir-gpt.c | 184 +
3 files changed, 193 insertions(+)
USB device commonly found on Microsoft Media Center boxes.
Hardware can send and recieve at all common IR frequencies - 36K, 38K, 40K, 56K
---
drivers/input/ir/Kconfig |6
drivers/input/ir/Makefile |1
drivers/input/ir/ir-mceusb2.c | 745 +++
---
arch/powerpc/boot/dts/dspeak01.dts | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/dspeak01.dts
b/arch/powerpc/boot/dts/dspeak01.dts
index 429bb2f..50cc247 100644
--- a/arch/powerpc/boot/dts/dspeak01.dts
+++ b/arch/powerpc/boo
1 - 100 of 114 matches
Mail list logo
