Jarod Wilson | 1 Apr 2010 22:26
Favicon

Re: lirc/imon on 2.6.33 ?

On Thu, Mar 25, 2010 at 1:43 PM, Dale E. Pontius <DEPontius@...> wrote:
> On 03/24/10 23:01, Jarod Wilson wrote:
>> On Wed, Mar 24, 2010 at 9:24 PM, Marco Salvagno
>> <marco.salvagno@...> wrote:
>>
>>> On Thu, Mar 25, 2010 at 01:07, Dale Pontius <DEPontius@...> wrote:
>>>
>>>> Is this the same problem as you have, or something else?
>>>>
>>>>
>>> You might want to check your syslog, if you haven't already. I have always
>>> been finding write error messages in it since day 0.
>>>
>>> With the older driver, however display went blank until LCDd was restarted,
>>> the one I'm using now seems to be more tolerant, so no more manual restarts,
>>> although for some reason one of those write errors seems to be turning
>>> backlight on when it should stay off.
>>>
>>> If you're using XBMC, you might try editing the screensaver strings (IIRC it
>>> defaults to a big font clock). I tried that too to no avail, but many people
>>> submitted positive reports.
>>>
>>> For the record I'm using a 0038 LCD device. Hope this helps.
>>>
>> I believe this is a different problem. The gibberish-on-the-screen
>> thing where the display can't be recovered until power is entirely
>> removed seems to be an 0xffdc-device-specific problem. I'm hoping I
>> can reproduce this one on the 0xffdc display someone is kindly sending
>> my way.

(Continue reading)

Jarod Wilson | 1 Apr 2010 22:50
Favicon

Re: lirc/imon on 2.6.33 ?

On Thu, Apr 1, 2010 at 4:26 PM, Jarod Wilson <jarod@...> wrote:
...
> The other interesting bit I've stumbled on to... The ffdc devices do
> NOT support switching ir protocols. Its hard-coded in their firmware
> whether they support the imon ir protocol or mce ir protocol. I
> *think* I've figured out where in the usb device config struct ffdc
> device specifics, like 'has lcd', 'has vfd', 'ir protocol imon', etc
> are stored, but I need to code up some debug patches and collect data
> for more devices to get a better idea.

Don't actually need debug patches (yet). 'lsusb -d 0x15c2: -vvv'
output shows the descriptor I think contains the info about the
device. For example, with my imon knob:

$ lsusb -d 0x15c2: -vvv

Bus 003 Device 004: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x15c2 SoundGraph Inc.
  idProduct          0xffdc iMON PAD Remote Controller
  bcdDevice            0.00
  iManufacturer           0
  iProduct                0
(Continue reading)

Jarod Wilson | 1 Apr 2010 22:59
Favicon

Re: lirc/imon on 2.6.33 ?

On Thu, Apr 1, 2010 at 4:50 PM, Jarod Wilson <jarod@...> wrote:
> On Thu, Apr 1, 2010 at 4:26 PM, Jarod Wilson <jarod@...> wrote:
> ...
>> The other interesting bit I've stumbled on to... The ffdc devices do
>> NOT support switching ir protocols. Its hard-coded in their firmware
>> whether they support the imon ir protocol or mce ir protocol. I
>> *think* I've figured out where in the usb device config struct ffdc
>> device specifics, like 'has lcd', 'has vfd', 'ir protocol imon', etc
>> are stored, but I need to code up some debug patches and collect data
>> for more devices to get a better idea.
>
> Don't actually need debug patches (yet). 'lsusb -d 0x15c2: -vvv'
> output shows the descriptor I think contains the info about the
> device. For example, with my imon knob:
>
> $ lsusb -d 0x15c2: -vvv
>
> Bus 003 Device 004: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
> Device Descriptor:
>  bLength                18
>  bDescriptorType         1
>  bcdUSB               1.10
>  bDeviceClass            0 (Defined at Interface level)
>  bDeviceSubClass         0
>  bDeviceProtocol         0
>  bMaxPacketSize0         8
>  idVendor           0x15c2 SoundGraph Inc.
>  idProduct          0xffdc iMON PAD Remote Controller
>  bcdDevice            0.00
>  iManufacturer           0
(Continue reading)

Daniel Rose | 1 Apr 2010 18:24

MCE USB remote

Hi!

My remote outputs on two different event nodes. 

I: Bus=0003 Vendor=1241 Product=e000 Version=0110
N: Name="HOLTEK     PC receiver "
P: Phys=usb-0000:02:08.0-3/input0
S:
Sysfs=/devices/pci0000:00/0000:00:10.0/0000:02:08.0/usb5/5-3/5-3:1.0/input/input4
U: Uniq=
H: Handlers=kbd event4
B: EV=120013
B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=1241 Product=e000 Version=0110
N: Name="HOLTEK     PC receiver "
P: Phys=usb-0000:02:08.0-3/input1
S:
Sysfs=/devices/pci0000:00/0000:00:10.0/0000:02:08.0/usb5/5-3/5-3:1.1/input/input5
U: Uniq=
H: Handlers=kbd mouse1 event5
B: EV=1f
B: KEY=837fff002c3027 bf00444400000000 1f001f c040a27c000 267bfad941dfed
9e000000000000 0
B: REL=143
B: ABS=7f0100000000
B: MSC=10

(Continue reading)

Christoph Bartelmus | 2 Apr 2010 12:30
Picon

Re: Release events being generate twice?

Hi!

Christoph Bartelmus "lirc@..." wrote:

> Mr Big Taco "mrbigtaco@..." wrote:

>> I'm relatively new to configuring lirc, so please forgive me for using
>> lingo incorrectly.  I'm trying to use a sony rm-yd028 remote with
>> huludesktop, which requires the --release argument for lircd.  Watching irw
>> on keypresses it's sending these release events twice.  The remote has no
>> problems working in mythtv and the general function otherwise is correct.
>> So my problem is twofold, I don't understand why lirc is sending the
>> release events twice

> This is a bug in lircd. I think I know what's causing this but don't know
> yet when I'll find the time to make a fix.
> In the meantime it would be helpful if you could send me some mode2 output
> for the remote.

The problem described above should be fixed in latest CVS.

Christoph

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

(Continue reading)

Christoph Bartelmus | 2 Apr 2010 12:34
Picon

Re: MCE USB remote

Hi!

Daniel Rose "drose@..." wrote:

> My remote outputs on two different event nodes.
>
>
> I: Bus=0003 Vendor=1241 Product=e000 Version=0110
[...]
> Event5 is a "mouse", and responds to the volume and mute buttons.
>
> Every other button causes data on event4.
>
> On IRC it was suggested that I don't use the devinput driver, but I
> don't understand how else I can get lirc to work.

> Can anyone guide me a little on how all this is supposed to fit
> together?  I've been working from this document:

You should use the devinput driver. You'll probably want to start a  
separate lircd instance for each input device that you have.

This device is not supported by lirc_mceusb. It looks like it is  
recognised by the kernel's hid driver.

Christoph

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
(Continue reading)

Bob van Loosen | 2 Apr 2010 17:40
Picon

[patch] Print portaudio devices to LOG_INFO

Hi,

A while back I posted a patch to send IR with portaudio and to select a 
custom audio device with the -c flag.
However I discovered a flaw, you have no idea what string to enter to 
select a certain device.
The attached patch prints all found devices to LOG_INFO.

Regards,

Bob van Loosen
Attachment (print_devices.diff): text/x-patch, 3119 bytes
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Daniel Rose | 2 Apr 2010 15:06

Re: MCE USB remote

On 04/02/10 21:34, Christoph Bartelmus wrote:
> Hi!
>
> Daniel Rose "drose@..." wrote:
>
>   
>> My remote outputs on two different event nodes.
>
> You should use the devinput driver. You'll probably want to start a  
> separate lircd instance for each input device that you have.
>
> This device is not supported by lirc_mceusb. It looks like it is  
> recognised by the kernel's hid driver.
>   
As a note for the list, in case anyone didn't know, you chain the two
lircs together, thus:

lircd -d phys=usb*input0 -H devinput -P /var/run/lirc/lircd.pid -l
lircd -d phys=usb*input1  -H devinput -P /var/run/lirc/lircd.pid2 -c
localhost

then irw outputs all the correct stuff.

Thanks Cristoph!

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
(Continue reading)

Daniel Rose | 2 Apr 2010 16:08

Re: MCE USB remote


> On 04/02/10 21:34, Christoph Bartelmus wrote:
>   
>> Hi!
>>
>> Daniel Rose "drose@..." wrote:
>>
>>   
>>     
>>> My remote outputs on two different event nodes.
>>>       
>> You should use the devinput driver. You'll probably want to start a  
>> separate lircd instance for each input device that you have.
>>
>>     
> As a note for the list, in case anyone didn't know, you chain the two
> lircs together, then irw outputs all the correct stuff.
>   

.... but mythtv still only picks up one of the two input streams that go
to the socket.  I don't know how that happens.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

(Continue reading)

Stephan Raue | 3 Apr 2010 04:13
Picon

lirc nct667x support

Hi all,

i am trying to build the lirc driver for nct667 chipsets [1] for any 
other distribution as ubuntu. i am using the lirc driver patch for 
linux-2.6.33 that can be found in the latest fedora rawhide srpm`s. in 
addition to this patch i have crated an patch based on the sources from 
[1] to integrate this nct667 driver also to my kernel sources. here you 
find my patch:

can anyone help me to fix the problems for kernel 2.6.33 and later?

greetings

Stephan

[1] http://www.asrock.com/Nettop/download.asp?Model=ION 330HT&o=Linux
[2] 
http://sources.openelec.tv/tmp/patches/linux-2.6.33-02-add_lirc_driver_nct667x-0.3.diff

errors:

   CC [M]  drivers/input/lirc/lirc_wb677_main.o
In file included from drivers/input/lirc/lirc_wb677.h:47,
                  from drivers/input/lirc/lirc_wb677_main.c:3:
drivers/input/lirc/lirc_wb677_common_extern.h:97: error: expected 
specifier-qualifier-list before 'lirc_t'
In file included from drivers/input/lirc/lirc_wb677_main.c:3:
drivers/input/lirc/lirc_wb677.h:491: error: expected declaration 
specifiers or '...' before 'lirc_t'
drivers/input/lirc/lirc_wb677_main.c: In function 'lirc_set_use_inc':
(Continue reading)


Gmane