lirc_imon lcd_write errors

[Jeremy Yoder]

I haven't bothered to try my LCD in forever, but based on a complaint in
one of the Ubuntu forums I just tried.

I'm getting the following in my syslog when I try to runLCDproc 0.5.3
(released a couple weeks ago):
Sep 17 15:54:59 mediapc kernel: [155668.900548] display port opened
Sep 17 15:54:59 mediapc kernel: [155668.930996] lirc_imon: send_packet:
packet tx failed (-32)
Sep 17 15:54:59 mediapc kernel: [155668.931005] lirc_imon: lcd_write:
send packet failed!
....
Sep 17 15:55:08 mediapc kernel: [155677.722318] lirc_imon: send_packet:
task interrupted
Sep 17 15:55:08 mediapc kernel: [155677.722357] lirc_imon: send_packet:
error submitting urb(-22)
Sep 17 15:55:08 mediapc kernel: [155677.722361] lirc_imon: lcd_write:
send packet failed!

I'm using the imonlcd driver added in LCDproc 0.5.3.

Any idea where I should start with this?

For reference, when I start lircd I get the following:
Sep 17 15:50:07 mediapc kernel: [155376.687584] lirc_dev: IR Remote
Control driver registered, major 61
Sep 17 15:50:07 mediapc kernel: [155376.694544] lirc_imon: Driver for
SoundGraph iMON MultiMedia IR/Display, v0.6
Sep 17 15:50:07 mediapc kernel: [155376.694595] lirc_dev:
lirc_register_driver: sample_rate: 0
Sep 17 15:50:07 mediapc kernel: [155376.695082] lirc_imon: Registered
iMON driver (lirc minor: 0)
Sep 17 15:50:07 mediapc kernel: [155376.695745] input: iMON PAD IR Mouse
(15c2:0038) as
/devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2:1.0/input/input7
Sep 17 15:50:07 mediapc kernel: [155376.732294] lirc_imon: iMON device
(15c2:0038, intf0) on usb<6:2> initialized
Sep 17 15:50:07 mediapc kernel: [155376.734317] lirc_imon: iMON device
(15c2:0038, intf1) on usb<6:2> initialized
Sep 17 15:50:07 mediapc kernel: [155376.734379] usbcore: registered new
interface driver lirc_imon
Sep 17 15:50:07 mediapc lircd-0.8.6[19634]: lircd(default) ready, using
/var/run/lirc/lircd


Thanks!
Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 17, 2009, at 4:01 PM, Jeremy Yoder wrote:

> I haven't bothered to try my LCD in forever, but based on a  
> complaint in
> one of the Ubuntu forums I just tried.
>
> I'm getting the following in my syslog when I try to runLCDproc 0.5.3
> (released a couple weeks ago):
> Sep 17 15:54:59 mediapc kernel: [155668.900548] display port opened
> Sep 17 15:54:59 mediapc kernel: [155668.930996] lirc_imon:  
> send_packet:
> packet tx failed (-32)
> Sep 17 15:54:59 mediapc kernel: [155668.931005] lirc_imon: lcd_write:
> send packet failed!
> ....
> Sep 17 15:55:08 mediapc kernel: [155677.722318] lirc_imon:  
> send_packet:
> task interrupted
> Sep 17 15:55:08 mediapc kernel: [155677.722357] lirc_imon:  
> send_packet:
> error submitting urb(-22)
> Sep 17 15:55:08 mediapc kernel: [155677.722361] lirc_imon: lcd_write:
> send packet failed!
>
> I'm using the imonlcd driver added in LCDproc 0.5.3.
>
> Any idea where I should start with this?

> For reference, when I start lircd I get the following:
...
> (15c2:0038)
...

Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd driver  
is trying to write using the old ffdc lcd protocol. Your device is  
functionally identical to my 0045, which works perfectly with current  
lirc_imon and lcdproc 0.5.3.

--
Jarod Wilson
jarod@...




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

I even manually changed it to 2 (before I sent the email :) ) and I get
the same results.  Here's the output from a debug run that says it
overrode it to 2:

Sep 17 16:17:59 mediapc kernel: [157049.429052] usbcore: deregistering
interface driver lirc_imon
Sep 17 16:17:59 mediapc kernel: [157049.429245] imon
usb_rx_callback_intf1: status(-108): ignored
Sep 17 16:17:59 mediapc kernel: [157049.429296] imon_disconnect: iMON
device (intf1) disconnected
Sep 17 16:17:59 mediapc kernel: [157049.430223] imon
usb_rx_callback_intf0: status(-108): ignored
Sep 17 16:18:00 mediapc kernel: [157049.462554] lirc_imon: Deregistered
iMON driver (minor:0)
Sep 17 16:18:00 mediapc kernel: [157049.462566] lirc_imon:
free_imon_context: iMON context freed
Sep 17 16:18:00 mediapc kernel: [157049.462571] imon_disconnect: iMON
device (intf0) disconnected
Sep 17 16:18:00 mediapc kernel: [157049.462960] lirc_imon: module
removed. Goodbye!
Sep 17 16:18:14 mediapc kernel: [157063.772964] lirc_dev: IR Remote
Control driver registered, major 61
Sep 17 16:18:14 mediapc kernel: [157063.779671] lirc_imon: Driver for
SoundGraph iMON MultiMedia IR/Display, v0.6
Sep 17 16:18:14 mediapc kernel: [157063.779714] lirc_imon: imon_probe:
overriding display type to 2 via modparam
Sep 17 16:18:14 mediapc kernel: [157063.779722] lirc_imon: imon_probe:
found iMON device (15c2:0038, intf0)
Sep 17 16:18:14 mediapc kernel: [157063.779727] lirc_imon: imon_probe:
found IR endpoint
Sep 17 16:18:14 mediapc kernel: [157063.779732] lirc_imon: imon_probe:
device uses control endpoint, not interface OUT endpoint
Sep 17 16:18:14 mediapc kernel: [157063.779737] lirc_imon: imon_probe:
ir_onboard_decode: 1
Sep 17 16:18:14 mediapc kernel: [157063.779741] lirc_imon: imon_probe:
vfd_proto_6p: 0
Sep 17 16:18:14 mediapc kernel: [157063.779748] lirc_dev:
lirc_register_driver: sample_rate: 0
Sep 17 16:18:14 mediapc kernel: [157063.779824] lirc_imon: Registered
iMON driver (lirc minor: 0)
Sep 17 16:18:14 mediapc kernel: [157063.779922] input: iMON PAD IR Mouse
(15c2:0038) as
/devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2:1.0/input/input9
Sep 17 16:18:14 mediapc kernel: [157063.813166] lirc_imon: imon_probe:
Registering iMON display with sysfs
Sep 17 16:18:14 mediapc kernel: [157063.814183] lirc_imon: Configuring
IR receiver for iMON protocol
Sep 17 16:18:14 mediapc kernel: [157063.820687] lirc_imon: iMON device
(15c2:0038, intf0) on usb<6:2> initialized
Sep 17 16:18:14 mediapc kernel: [157063.820718] lirc_imon: imon_probe:
overriding display type to 2 via modparam
Sep 17 16:18:14 mediapc kernel: [157063.820726] lirc_imon: imon_probe:
found iMON device (15c2:0038, intf1)
Sep 17 16:18:14 mediapc kernel: [157063.820731] lirc_imon: imon_probe:
found IR endpoint
Sep 17 16:18:14 mediapc kernel: [157063.820735] lirc_imon: imon_probe:
device uses control endpoint, not interface OUT endpoint
Sep 17 16:18:14 mediapc kernel: [157063.820740] lirc_imon: imon_probe:
ir_onboard_decode: 1
Sep 17 16:18:14 mediapc kernel: [157063.820744] lirc_imon: imon_probe:
vfd_proto_6p: 0
Sep 17 16:18:14 mediapc kernel: [157063.820757] lirc_imon: Configuring
IR receiver for iMON protocol
Sep 17 16:18:14 mediapc kernel: [157063.822170] lirc_imon: iMON device
(15c2:0038, intf1) on usb<6:2> initialized
Sep 17 16:18:14 mediapc kernel: [157063.822228] usbcore: registered new
interface driver lirc_imon
Sep 17 16:18:14 mediapc lircd-0.8.6[21941]: lircd(default) ready, using
/var/run/lirc/lircd
Sep 17 16:19:06 mediapc kernel: [157115.929477] display port opened
Sep 17 16:19:06 mediapc kernel: [157115.930935] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.932931] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.934930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.936930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.938930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.940930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.942930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.944930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.947930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.950022] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.951930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.954041] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.955930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.958031] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.959930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.962048] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.963930] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:19:06 mediapc kernel: [157115.966102] lirc_imon: send_packet:
packet tx failed (-32)
Sep 17 16:19:06 mediapc kernel: [157115.966110] lirc_imon: lcd_write:
send packet failed!


and so on...

I'm not actually in front of the machine right now so I don't know if
the LCD is actually displaying something or not.  I can check that when
I get home.

Jeremy


Jarod Wilson wrote the following on 9/17/2009 4:06 PM:

> On Sep 17, 2009, at 4:01 PM, Jeremy Yoder wrote:
>
>> I haven't bothered to try my LCD in forever, but based on a complaint in
>> one of the Ubuntu forums I just tried.
>>
>> I'm getting the following in my syslog when I try to runLCDproc 0.5.3
>> (released a couple weeks ago):
>> Sep 17 15:54:59 mediapc kernel: [155668.900548] display port opened
>> Sep 17 15:54:59 mediapc kernel: [155668.930996] lirc_imon: send_packet:
>> packet tx failed (-32)
>> Sep 17 15:54:59 mediapc kernel: [155668.931005] lirc_imon: lcd_write:
>> send packet failed!
>> ....
>> Sep 17 15:55:08 mediapc kernel: [155677.722318] lirc_imon: send_packet:
>> task interrupted
>> Sep 17 15:55:08 mediapc kernel: [155677.722357] lirc_imon: send_packet:
>> error submitting urb(-22)
>> Sep 17 15:55:08 mediapc kernel: [155677.722361] lirc_imon: lcd_write:
>> send packet failed!
>>
>> I'm using the imonlcd driver added in LCDproc 0.5.3.
>>
>> Any idea where I should start with this?
>
>> For reference, when I start lircd I get the following:
> ...
>> (15c2:0038)
> ...
>
> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd driver
> is trying to write using the old ffdc lcd protocol. Your device is
> functionally identical to my 0045, which works perfectly with current
> lirc_imon and lcdproc 0.5.3.
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 17, 2009, at 4:22 PM, Jeremy Yoder wrote:

>>>
>>> (15c2:0038)
>> ...
>>
>> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd  
>> driver
>> is trying to write using the old ffdc lcd protocol. Your device is
>> functionally identical to my 0045, which works perfectly with current
>> lirc_imon and lcdproc 0.5.3.

> I even manually changed it to 2 (before I sent the email :) ) and I  
> get
> the same results.  Here's the output from a debug run that says it
> overrode it to 2:
...
> Sep 17 16:18:14 mediapc kernel: [157063.820718] lirc_imon: imon_probe:
> overriding display type to 2 via modparam


Wrong place. Not talking about a modparam, I'm talking about an  
lcdproc config file option. By default, the imonlcd driver uses the  
protocol for the ffdc lcd. You have to manually adjust the LCDd.conf  
file, telling it you actually have one of the newer lcd models.

(Side bar: it really ought to be fixed such that this is set  
automatically by lcdproc...)

--
Jarod Wilson
jarod@...




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

Jarod Wilson wrote the following on 9/17/2009 4:39 PM:

> On Sep 17, 2009, at 4:22 PM, Jeremy Yoder wrote:
>
>>>>
>>>> (15c2:0038)
>>> ...
>>>
>>> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd driver
>>> is trying to write using the old ffdc lcd protocol. Your device is
>>> functionally identical to my 0045, which works perfectly with current
>>> lirc_imon and lcdproc 0.5.3.
>
>> I even manually changed it to 2 (before I sent the email :) ) and I get
>> the same results.  Here's the output from a debug run that says it
>> overrode it to 2:
> ...
>> Sep 17 16:18:14 mediapc kernel: [157063.820718] lirc_imon: imon_probe:
>> overriding display type to 2 via modparam
>
>
> Wrong place. Not talking about a modparam, I'm talking about an
> lcdproc config file option. By default, the imonlcd driver uses the
> protocol for the ffdc lcd. You have to manually adjust the LCDd.conf
> file, telling it you actually have one of the newer lcd models.
>

Doh!  Yeah, no, I didn't have that  :)

Okay, I set Protocol=1 and I'm getting the same errors.
Sep 17 16:50:44 mediapc kernel: [159014.365809] display port opened
Sep 17 16:50:44 mediapc kernel: [159014.366425] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:50:44 mediapc kernel: [159014.368438] lirc_imon: lcd_write:
write 8 bytes to LCD
Sep 17 16:50:44 mediapc kernel: [159014.370438] lirc_imon: send_packet:
packet tx failed (-32)
Sep 17 16:50:44 mediapc kernel: [159014.370446] lirc_imon: lcd_write:
send packet failed!


Hmmm...



> (Side bar: it really ought to be fixed such that this is set
> automatically by lcdproc...)
>

I'd be willing to try to fix this if there's a fairly easy way to have
it detect the protocol.

Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 17, 2009, at 5:52 PM, Jeremy Yoder wrote:

> Jarod Wilson wrote the following on 9/17/2009 4:39 PM:
>> On Sep 17, 2009, at 4:22 PM, Jeremy Yoder wrote:
>>
>>>>>
>>>>> (15c2:0038)
>>>> ...
>>>>
>>>> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd  
>>>> driver
>>>> is trying to write using the old ffdc lcd protocol. Your device is
>>>> functionally identical to my 0045, which works perfectly with  
>>>> current
>>>> lirc_imon and lcdproc 0.5.3.
>>
>>> I even manually changed it to 2 (before I sent the email :) ) and  
>>> I get
>>> the same results.  Here's the output from a debug run that says it
>>> overrode it to 2:
>> ...
>>> Sep 17 16:18:14 mediapc kernel: [157063.820718] lirc_imon:  
>>> imon_probe:
>>> overriding display type to 2 via modparam
>>
>>
>> Wrong place. Not talking about a modparam, I'm talking about an
>> lcdproc config file option. By default, the imonlcd driver uses the
>> protocol for the ffdc lcd. You have to manually adjust the LCDd.conf
>> file, telling it you actually have one of the newer lcd models.
>>
>
> Doh!  Yeah, no, I didn't have that  :)
>
> Okay, I set Protocol=1 and I'm getting the same errors.
> Sep 17 16:50:44 mediapc kernel: [159014.365809] display port opened
> Sep 17 16:50:44 mediapc kernel: [159014.366425] lirc_imon: lcd_write:
> write 8 bytes to LCD
> Sep 17 16:50:44 mediapc kernel: [159014.368438] lirc_imon: lcd_write:
> write 8 bytes to LCD
> Sep 17 16:50:44 mediapc kernel: [159014.370438] lirc_imon:  
> send_packet:
> packet tx failed (-32)
> Sep 17 16:50:44 mediapc kernel: [159014.370446] lirc_imon: lcd_write:
> send packet failed!
>
>
> Hmmm...

I ASSume that you bounced LCDd after making that change, but want to  
be 100% certain... :)

>> (Side bar: it really ought to be fixed such that this is set
>> automatically by lcdproc...)
>>
>
> I'd be willing to try to fix this if there's a fairly easy way to have
> it detect the protocol.

It can be done simply based on usb device ID. All the old 15c2:ffdc  
devices use Protocol=0 (the default), all the newer ones use  
Protocol=1. I'm not sure offhand how one programmatically obtains the  
usb device ID for a /dev/lcdX device in userspace though. It shouldn't  
be hard at all, its just that nobody has done it yet.

--
Jarod Wilson
jarod@...





------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

On Thu, 17 Sep 2009 19:44:17 -0400, Jarod Wilson <jarod@...>
wrote:

> On Sep 17, 2009, at 5:52 PM, Jeremy Yoder wrote:
>
>> Jarod Wilson wrote the following on 9/17/2009 4:39 PM:
>>> On Sep 17, 2009, at 4:22 PM, Jeremy Yoder wrote:
>>>
>>>>>>
>>>>>> (15c2:0038)
>>>>> ...
>>>>>
>>>>> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd  
>>>>> driver
>>>>> is trying to write using the old ffdc lcd protocol. Your device is
>>>>> functionally identical to my 0045, which works perfectly with  
>>>>> current
>>>>> lirc_imon and lcdproc 0.5.3.
>>>
> ...
> I ASSume that you bounced LCDd after making that change, but want to  
> be 100% certain... :)
>

Okay, just to be certain I:
1. Stopped LCDd
2. Stopped lirc
3. modprobe -r imon_lcd
4. Started lirc
5. Started LCDd

And I just did it again except I removed LCDd completely and re-installed
making the Protocol=1 change to a fresh config file.  Just to be sure :)

I also tried the following, which I found in a blog post a while ago:
perl -e 'print pack "H*", "80000000091e0088"' > /dev/lcd0
and
perl -e 'print pack "H*", "4000000000000088"' > /dev/lcd0

Results of the Perl commands in the syslog:
Sep 17 21:18:56 mediapc kernel: [175105.857941] display port opened
Sep 17 21:18:56 mediapc kernel: [175105.865042] lirc_imon: lcd_write: write
8 bytes to LCD
Sep 17 21:18:56 mediapc kernel: [175105.865553] display port closed
Sep 17 21:19:10 mediapc kernel: [175120.103689] display port opened
Sep 17 21:19:10 mediapc kernel: [175120.111963] lirc_imon: lcd_write: write
8 bytes to LCD
Sep 17 21:19:10 mediapc kernel: [175120.112454] display port closed

Both do the expected (the first displays the time, the second clears the
screen)


Then I tried LIRCd again after that and still the same results:
Sep 17 21:23:57 mediapc kernel: [175406.491764] display port opened
Sep 17 21:23:57 mediapc kernel: [175406.493236] lirc_imon: lcd_write: write
8 bytes to LCD
Sep 17 21:23:57 mediapc kernel: [175406.495232] lirc_imon: send_packet:
packet tx failed (-32)
Sep 17 21:23:57 mediapc kernel: [175406.495240] lirc_imon: lcd_write: send
packet failed!
...
Sep 17 21:24:02 mediapc kernel: [175412.012715] lirc_imon: send_packet:
task interrupted
Sep 17 21:24:02 mediapc kernel: [175412.012723] lirc_imon: send_packet:
packet tx failed (-32)
Sep 17 21:24:02 mediapc kernel: [175412.012728] lirc_imon: lcd_write: send
packet failed!
Sep 17 21:24:02 mediapc kernel: [175412.012761] lirc_imon: send_packet:
error submitting urb(-22)
Sep 17 21:24:02 mediapc kernel: [175412.012765] lirc_imon: lcd_write: send
packet failed!


Strange...

Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On 09/17/2009 09:28 PM, Jeremy Yoder wrote:

>
> On Thu, 17 Sep 2009 19:44:17 -0400, Jarod Wilson<jarod@...>
> wrote:
>> On Sep 17, 2009, at 5:52 PM, Jeremy Yoder wrote:
>>
>>> Jarod Wilson wrote the following on 9/17/2009 4:39 PM:
>>>> On Sep 17, 2009, at 4:22 PM, Jeremy Yoder wrote:
>>>>
>>>>>>>
>>>>>>> (15c2:0038)
>>>>>> ...
>>>>>>
>>>>>> Do you have Protocol=1 set in LCDd.conf? Otherwise, the imonlcd
>>>>>> driver
>>>>>> is trying to write using the old ffdc lcd protocol. Your device is
>>>>>> functionally identical to my 0045, which works perfectly with
>>>>>> current
>>>>>> lirc_imon and lcdproc 0.5.3.
>>>>
>> ...
>> I ASSume that you bounced LCDd after making that change, but want to
>> be 100% certain... :)
>>
>
> Okay, just to be certain I:
> 1. Stopped LCDd
> 2. Stopped lirc
> 3. modprobe -r imon_lcd
> 4. Started lirc
> 5. Started LCDd
>
> And I just did it again except I removed LCDd completely and re-installed
> making the Protocol=1 change to a fresh config file.  Just to be sure :)
>
> I also tried the following, which I found in a blog post a while ago:
> perl -e 'print pack "H*", "80000000091e0088"'>  /dev/lcd0
> and
> perl -e 'print pack "H*", "4000000000000088"'>  /dev/lcd0
>
> Results of the Perl commands in the syslog:
> Sep 17 21:18:56 mediapc kernel: [175105.857941] display port opened
> Sep 17 21:18:56 mediapc kernel: [175105.865042] lirc_imon: lcd_write: write
> 8 bytes to LCD
> Sep 17 21:18:56 mediapc kernel: [175105.865553] display port closed
> Sep 17 21:19:10 mediapc kernel: [175120.103689] display port opened
> Sep 17 21:19:10 mediapc kernel: [175120.111963] lirc_imon: lcd_write: write
> 8 bytes to LCD
> Sep 17 21:19:10 mediapc kernel: [175120.112454] display port closed
>
> Both do the expected (the first displays the time, the second clears the
> screen)
>
>
> Then I tried LIRCd again after that and still the same results:
> Sep 17 21:23:57 mediapc kernel: [175406.491764] display port opened
> Sep 17 21:23:57 mediapc kernel: [175406.493236] lirc_imon: lcd_write: write
> 8 bytes to LCD
> Sep 17 21:23:57 mediapc kernel: [175406.495232] lirc_imon: send_packet:
> packet tx failed (-32)
> Sep 17 21:23:57 mediapc kernel: [175406.495240] lirc_imon: lcd_write: send
> packet failed!
> ...
> Sep 17 21:24:02 mediapc kernel: [175412.012715] lirc_imon: send_packet:
> task interrupted
> Sep 17 21:24:02 mediapc kernel: [175412.012723] lirc_imon: send_packet:
> packet tx failed (-32)
> Sep 17 21:24:02 mediapc kernel: [175412.012728] lirc_imon: lcd_write: send
> packet failed!
> Sep 17 21:24:02 mediapc kernel: [175412.012761] lirc_imon: send_packet:
> error submitting urb(-22)
> Sep 17 21:24:02 mediapc kernel: [175412.012765] lirc_imon: lcd_write: send
> packet failed!
>
>
> Strange...

Indeed. I got nothin. :\ I keep firing all sorts of junk at mine with no
problems to speak of. Not sure what to look at next.

--
Jarod Wilson
jarod@...

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

On Thu, 17 Sep 2009 22:16:31 -0400, Jarod Wilson <jarod@...>
wrote:
> Indeed. I got nothin. :\ I keep firing all sorts of junk at mine with no
> problems to speak of. Not sure what to look at next.

Ok, running "LCDd -f" I get a whole lot of this:
imon: error writing to file descriptor: -1

I haven't started digging into the imonlcd code to see why yet, but I
thought I'd mention it.

ALSO, sitting and watching the LCD while LCDd -f is churning away indicates
that SOMETHING is getting through.  The display dims/brightens/changes time
and so forth.  It just never stops complaining and it never displays
anything I'm expecting from LCDd.

I also need to try powering down the machine to hard-reboot the LCD
panel...  But it's 3am so I'll do that after work tomorrow ;)

Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 18, 2009, at 3:13 AM, Jeremy Yoder wrote:

>
> On Thu, 17 Sep 2009 22:16:31 -0400, Jarod Wilson <jarod@...>
> wrote:
>> Indeed. I got nothin. :\ I keep firing all sorts of junk at mine  
>> with no
>> problems to speak of. Not sure what to look at next.
>
> Ok, running "LCDd -f" I get a whole lot of this:
> imon: error writing to file descriptor: -1
>
> I haven't started digging into the imonlcd code to see why yet, but I
> thought I'd mention it.
>
> ALSO, sitting and watching the LCD while LCDd -f is churning away  
> indicates
> that SOMETHING is getting through.  The display dims/brightens/
> changes time
> and so forth.  It just never stops complaining and it never displays
> anything I'm expecting from LCDd.
>
> I also need to try powering down the machine to hard-reboot the LCD
> panel...  But it's 3am so I'll do that after work tomorrow ;)

Heh, I know the feeling...

I had one last thought late last night while poking at my own LCD  
(working on MythTV patches to enable use of the assorted icons for  
audio and video codec, audio channels, TV/Movie/Music, etc):

Where exactly did you put that Protocol=1 inside LCDd.conf?

i.e., did you put it just after Driver=imonlcd, or further down in the  
imonlcd driver config section?

Relevant sections from my setup:

[server]
Driver=imonlcd

...

[imonlcd]
Device=/dev/lcd0
Contrast=200
OnExit=2
Protocol=1

--
Jarod Wilson
jarod@...




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

Jarod Wilson wrote the following on 9/18/2009 9:00 AM:

>
> On Sep 18, 2009, at 3:13 AM, Jeremy Yoder wrote:
>
>>
>> On Thu, 17 Sep 2009 22:16:31 -0400, Jarod Wilson <jarod@...>
>> wrote:
>>> Indeed. I got nothin. :\ I keep firing all sorts of junk at mine
>>> with no
>>> problems to speak of. Not sure what to look at next.
>>
>> Ok, running "LCDd -f" I get a whole lot of this:
>> imon: error writing to file descriptor: -1
>>
>
> Where exactly did you put that Protocol=1 inside LCDd.conf?
>
> i.e., did you put it just after Driver=imonlcd, or further down in the
> imonlcd driver config section?
>
> Relevant sections from my setup:
>
> [server]
> Driver=imonlcd
>
> ...
>
> [imonlcd]
> Device=/dev/lcd0
> Contrast=200
> OnExit=2
> Protocol=1
>

I wish that were it :)  Unfortunately I put it in the right place.

More info today (I'm starting to strongly suspect hardware).  I added
some print statements to the imonlcd driver and now I get:
send_command_data: '4000000000000088'
send_packet: '4000000000000088'
send_command_data: '000000000000008a'
send_packet: '000000000000008a'
send_command_data: '080a5800ffffff03'
send_packet: '080a5800ffffff03'
send_command_data: '0000000000000002'
send_packet: '0000000000000002'
send_command_data: '0000000000000001'
send_packet: '0000000000000001'
send_command_data: '0000000000000010'
send_packet: '0000000000000010'
send_command_data: '0000000000000011'
send_packet: '0000000000000011'
send_command_data: '0000000000000012'
send_packet: '0000000000000012'
send_command_data: '0000000000000001'
send_packet: '0000000000000001'
send_command_data: '0000000000000010'
send_packet: '0000000000000010'
send_command_data: '0000000000000011'
send_packet: '0000000000000011'
send_command_data: '0000000000000012'
send_packet: '0000000000000012'
send_packet: 'ffffffffffffff20'
send_packet: 'ffffffffff000021'
send_packet: '00000000007c8222'
send_packet: '82824400fe828223'
send_packet: '827c003f22222224'
send_packet: '1c00221e22201025'
send_packet: '001c2222221c0026'
send_packet: '1c22222214000027'
send_packet: '0000000000649228'
send_packet: '92924c001c2a2a29'
send_packet: '2a1000221e22202a'
send_packet: '100000000000002b'
send_packet: 'ffffffffffff002c'
send_packet: '387c3e7c38007c2d'
send_packet: '828282440000002e'
send_packet: 'fe0200000000be2f'
send_packet: '020000006c6c0030'
imon: error writing to file descriptor: -1


The place where it fails to write to the file descriptor changes each
run, so it definitely doesn't seem to be a particular code or anything
like that.  This also explains why I see crazy things happen to the
display.  It does write quite a bit of stuff, but not everything.

I also added a bit of code to re-try the write 3 times if it fails and
it hasn't failed 3 times in a row yet :)  But I'm not at home so I can't
tell if anything interesting is happening on the LCD.  At this point I'm
pretty convinced it's NOT an lirc problem so I'll stop spamming the list
unless I find otherwise.

Thanks for the help!
Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 18, 2009, at 1:10 PM, Jeremy Yoder wrote:

> More info today (I'm starting to strongly suspect hardware).

:(

> I added
> some print statements to the imonlcd driver and now I get:
> send_command_data: '4000000000000088'
> send_packet: '4000000000000088'
> send_command_data: '000000000000008a'
> send_packet: '000000000000008a'
> send_command_data: '080a5800ffffff03'
> send_packet: '080a5800ffffff03'
> send_command_data: '0000000000000002'
> send_packet: '0000000000000002'
> send_command_data: '0000000000000001'
> send_packet: '0000000000000001'
> send_command_data: '0000000000000010'
> send_packet: '0000000000000010'
> send_command_data: '0000000000000011'
> send_packet: '0000000000000011'
> send_command_data: '0000000000000012'
> send_packet: '0000000000000012'
> send_command_data: '0000000000000001'
> send_packet: '0000000000000001'
> send_command_data: '0000000000000010'
> send_packet: '0000000000000010'
> send_command_data: '0000000000000011'
> send_packet: '0000000000000011'
> send_command_data: '0000000000000012'
> send_packet: '0000000000000012'
> send_packet: 'ffffffffffffff20'
> send_packet: 'ffffffffff000021'
> send_packet: '00000000007c8222'
> send_packet: '82824400fe828223'
> send_packet: '827c003f22222224'
> send_packet: '1c00221e22201025'
> send_packet: '001c2222221c0026'
> send_packet: '1c22222214000027'
> send_packet: '0000000000649228'
> send_packet: '92924c001c2a2a29'
> send_packet: '2a1000221e22202a'
> send_packet: '100000000000002b'
> send_packet: 'ffffffffffff002c'
> send_packet: '387c3e7c38007c2d'
> send_packet: '828282440000002e'
> send_packet: 'fe0200000000be2f'
> send_packet: '020000006c6c0030'
> imon: error writing to file descriptor: -1

Is everything completely wedged at this point, or can you recover?

> The place where it fails to write to the file descriptor changes each
> run, so it definitely doesn't seem to be a particular code or anything
> like that.  This also explains why I see crazy things happen to the
> display.  It does write quite a bit of stuff, but not everything.

Does throttling send_packet() help any? i.e., add a bit of a udelay  
before we exit? Maybe start with a udelay(10) before it returns, try a  
few different values, etc.

> I also added a bit of code to re-try the write 3 times if it fails and
> it hasn't failed 3 times in a row yet :)  But I'm not at home so I  
> can't
> tell if anything interesting is happening on the LCD.  At this point  
> I'm
> pretty convinced it's NOT an lirc problem so I'll stop spamming the  
> list
> unless I find otherwise.

I still wouldn't completely rule out lirc_imon, but its definitely odd  
that I'm not seeing it here w/my own display in constant use.

--
Jarod Wilson
jarod@...





------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

On Fri, 18 Sep 2009 19:40:35 -0400, Jarod Wilson <jarod@...>
wrote:
> On Sep 18, 2009, at 1:10 PM, Jeremy Yoder wrote:
>
> Is everything completely wedged at this point, or can you recover?

If I run at full speed, the LCD gets pretty hosed.  I've had to unplug it
to reset/recover.

> Does throttling send_packet() help any? i.e., add a bit of a udelay  
> before we exit? Maybe start with a udelay(10) before it returns, try a  
> few different values, etc.

Yes!  I couldn't get udelay to work in the imonlcd code, so I tried
nanosleep instead.  Took a lot of playing but what seems to work with no
errors is a nanosleep delay of 2,000,000, which is a microsecond delay of
2,000 (2 hundredths of a second).  Pretty darn long if you ask me, but it
does work :)  It's cool to finally see something on my LCD...  I can go
down to 1,500,000 but then I get occasional errors.  Anything less and it
throws out errors constantly.

I'm going to run it over night with the 2,000,000 delay to make sure it
works.

> I still wouldn't completely rule out lirc_imon, but its definitely odd  
> that I'm not seeing it here w/my own display in constant use.

I have access to another identical case, so I'm going to try it out
tomorrow and see if it's just mine or if it's something with this LCD
display.

Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jeremy Yoder]

Jeremy Yoder wrote the following on 9/20/2009 3:06 AM:

> On Fri, 18 Sep 2009 19:40:35 -0400, Jarod Wilson <jarod@...>
> wrote:
>  
>> Does throttling send_packet() help any? i.e., add a bit of a udelay  
>> before we exit? Maybe start with a udelay(10) before it returns, try a  
>> few different values, etc.
>>    
>
> Yes!  I couldn't get udelay to work in the imonlcd code, so I tried
> nanosleep instead.  Took a lot of playing but what seems to work with no
> errors is a nanosleep delay of 2,000,000, which is a microsecond delay of
> 2,000 (2 hundredths of a second).  Pretty darn long if you ask me, but it
> does work :)  It's cool to finally see something on my LCD...  I can go
> down to 1,500,000 but then I get occasional errors.  Anything less and it
> throws out errors constantly.
>
> I'm going to run it over night with the 2,000,000 delay to make sure it
> works.
>  

Two days and no errors.  That definitely solved the problem.

>> I still wouldn't completely rule out lirc_imon, but its definitely odd  
>> that I'm not seeing it here w/my own display in constant use.
>>    
>
> I have access to another identical case, so I'm going to try it out
> tomorrow and see if it's just mine or if it's something with this LCD
> display.
>  

I tested the second case yesterday and it had the exact same behavior.
I put in the 2,000,000 nanosleep, everything was fine.  I tried lowering
it to 1,000,000 and it got hosed.

So, I guess this model is just slow.  I suppose I should add a throttle
parameter to imonlcd.

Jeremy

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[Jarod Wilson]

On Sep 21, 2009, at 10:14 AM, Jeremy Yoder <jyoder@...> wrote:

> Jeremy Yoder wrote the following on 9/20/2009 3:06 AM:
>> On Fri, 18 Sep 2009 19:40:35 -0400, Jarod Wilson <jarod@...>
>> wrote:
>>
>>> Does throttling send_packet() help any? i.e., add a bit of a udelay
>>> before we exit? Maybe start with a udelay(10) before it returns,  
>>> try a
>>> few different values, etc.
>>>
>>
>> Yes!  I couldn't get udelay to work in the imonlcd code, so I tried
>> nanosleep instead.  Took a lot of playing but what seems to work  
>> with no
>> errors is a nanosleep delay of 2,000,000, which is a microsecond  
>> delay of
>> 2,000 (2 hundredths of a second).  Pretty darn long if you ask me,  
>> but it
>> does work :)  It's cool to finally see something on my LCD...  I  
>> can go
>> down to 1,500,000 but then I get occasional errors.  Anything less  
>> and it
>> throws out errors constantly.
>>
>> I'm going to run it over night with the 2,000,000 delay to make  
>> sure it
>> works.
>>
>
> Two days and no errors.  That definitely solved the problem.

Good deal.

>
>>> I still wouldn't completely rule out lirc_imon, but its definitely  
>>> odd
>>> that I'm not seeing it here w/my own display in constant use.
>>>
>>
>> I have access to another identical case, so I'm going to try it out
>> tomorrow and see if it's just mine or if it's something with this LCD
>> display.
>>
>
> I tested the second case yesterday and it had the exact same behavior.
> I put in the 2,000,000 nanosleep, everything was fine.  I tried  
> lowering
> it to 1,000,000 and it got hosed.
>
> So, I guess this model is just slow.  I suppose I should add a  
> throttle
> parameter to imonlcd.

I'm not opposed to just doing it for all displays, I don't think it  
should cause any problems or any significantly noticeable behavioral  
change for "faster" devices.

--
Jarod Wilson

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

[dacorsa]

hi,
 
i have compiled lirc and lcdproc for my case silverstone lc14m, lirc works well, but on my vfd i see only 8 strange characters. This is a photo:
 

http://img205.imageshack.us/img205/861/dscn0866.jpg
 
can you help me to solve this problem?
 
thanks!

[dacorsa]

can you explain well where insert the nanosleep command?? in which file??

thanks!

[Jeremy Yoder]

For Ubuntu I "fixed" this in LCDproc.

Here's the diff:
--- lcdproc-0.5.3/server/drivers/imonlcd.c      2009-06-20
09:48:34.000000000 -0400
+++ mythbuntu/jyoder/server/drivers/imonlcd.c   2009-10-11
17:56:20.303746532 -0400
@@ -1180,10 +1180,18 @@
 send_packet(PrivateData *p)
 {
        int err;
+       struct timespec req;
+
+       req.tv_sec = 0;
+       // 1,600,000 is a little too small.  2,000,000 never fails
+       //req.tv_nsec = 2000000L;
+       req.tv_nsec = 1700000L;
+       nanosleep(&req, NULL);
+
        err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf));

        if (err <= 0)
-               printf("%s: error writing to file descriptor: %d",
"imon", err);
+               printf("%s: error writing to file descriptor: %d\n",
"imon", err);
 }

I'm hoping that Jarod comes up with a better solution eventually (he
seems pretty busy at the moment) but this does do the trick.

Jeremy


dacorsa wrote the following on 10/26/2009 4:57 PM:
> can you explain well where insert the nanosleep command?? in which file??
>
> thanks!
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[Jarod Wilson]

On Oct 27, 2009, at 2:20 PM, Jeremy Yoder wrote:

> For Ubuntu I "fixed" this in LCDproc.
>
> Here's the diff:
> --- lcdproc-0.5.3/server/drivers/imonlcd.c      2009-06-20
> 09:48:34.000000000 -0400
> +++ mythbuntu/jyoder/server/drivers/imonlcd.c   2009-10-11
> 17:56:20.303746532 -0400
> @@ -1180,10 +1180,18 @@
> send_packet(PrivateData *p)
> {
>        int err;
> +       struct timespec req;
> +
> +       req.tv_sec = 0;
> +       // 1,600,000 is a little too small.  2,000,000 never fails
> +       //req.tv_nsec = 2000000L;
> +       req.tv_nsec = 1700000L;
> +       nanosleep(&req, NULL);
> +
>        err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf));
>
>        if (err <= 0)
> -               printf("%s: error writing to file descriptor: %d",
> "imon", err);
> +               printf("%s: error writing to file descriptor: %d\n",
> "imon", err);
> }
>
> I'm hoping that Jarod comes up with a better solution eventually (he
> seems pretty busy at the moment) but this does do the trick.

Yeah, been a bit tied up... Good news is I have an iMON VFD now that  
has issues w/frequent write errors... :) Bad news is that the box is  
misbehaving slightly, at least when hooked up to the TV in the kids'  
playroom, so I need to haul it back downstairs and hook it up to a  
monitor to poke at it more... However, here's what I had in mind  
(completely untested beyond a quick compile):

diff --git a/drivers/input/lirc/lirc_imon.c b/drivers/input/lirc/
lirc_imon.c
index 6d9ff3e..70fcc3e 100644
--- a/drivers/input/lirc/lirc_imon.c
+++ b/drivers/input/lirc/lirc_imon.c
@@ -30,6 +30,7 @@
  #include <linux/usb/input.h>
  #include <linux/time.h>
  #include <linux/timer.h>
+#include <linux/delay.h>

  #include "lirc.h"
  #include "lirc_dev.h"
@@ -960,6 +961,9 @@ static ssize_t vfd_write(struct file *file, const  
char *buf,
  exit:
  mutex_unlock(&context->lock);

+ /* delay return a bit to prevent overwhelming the device */
+ mdelay(2);
+
  return (!retval) ? n_bytes : retval;
  }

@@ -1018,6 +1022,10 @@ static ssize_t lcd_write(struct file *file,  
const char *buf,
  }
  exit:
  mutex_unlock(&context->lock);
+
+ /* delay return a bit to prevent overwhelming the device */
+ mdelay(2);
+
  return (!retval) ? n_bytes : retval;
  }



--
Jarod Wilson
jarod@...


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[dacorsa]

thanks Jarod,

i have test last 2 patch, but i don't have solve my problem with lcdproc:

http://img205.imageshack.us/img205/861/dscn0866.jpg

i hope to found solution, on windows my vfd is ok.

see you soon!