LCDproc development and user support list

Text archives Help


[Lcdproc] Older vfd lockups


Chronological Thread 
  • From: jarod at wilsonet.com (Jarod Wilson)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Wed, 20 Jan 2010 16:40:23 -0500

On Wed, Jan 20, 2010 at 4:28 PM, jk <fblack947 at yahoo.com> wrote:
>> From: Jarod Wilson <jarod at wilsonet.com>
>> ...
>> Outside of the ffdc devices, you shouldn't have to touch a damned
>> thing, auto-detection of display type and auto-config of stuff should
>> Just Work.
>
> Agreed, but is this a function of Ubuntu packaging, or should lcdproc be
> figuring things out?
> A philosophical question to be sure, but my approach was to let the
> end-user (or the ubuntu packager) adjust the configuration file are
> required.

I think lcdproc still needs some manual config to tell it exactly what
device type it is you want it to talk to, otherwise, (I assume) it
would have to load up *all* drivers and try them out, and/or have its
own internal device ID to driver mapping table or other similar
insanity. It *would* be nice, however, if the imonlcd driver could
figure out from usb device ID whether it needed to use Protocol=0 or
1, and eliminate the user having to figure that out/remember to put it
into their config. Not a big deal though, only has to be done once, so
I haven't bothered to look into it myself...

>> Would be much easier to debug these problems if I actually had an imon
>> device that exhibited them, both my (newer than ffdc) VFD and LCD work
>> flawlessly though. :\
>
> Yeah, that's a tough one - too many friggin different devices and
> protocols. ? Coupled with a complete lack of linux support from
> SoundGraph. ?Sigh.

Yeah, SoundGraph was completely and totally unresponsive when I tried
pinging them for *any* sort of information, even with the "hey, I'm
trying to make your device fully supported under linux, and you guys
don't have to do an ounce of development work, just please help me out
with a bit of data" caveat added...

>> > ...I think there also was (still is?) a parameter setting to limit the
>> > frequency of
>>> the screen refresh, which might still be there, and might help.
>>
>> Is this in the lcdproc driver? Nobody ever got back to me with any
>> useful feedback on whether adding a delay in the kernel driver helped
>> with this issue...
>
> Actually, it might be a driver-specific thing. ?Some drivers have this
> function, others don't (see DELAYMULT parameter in hd44780-low.h and
> hd44780.c).

Ah, hm. So maybe we need it added to the imon{,lcd} drivers?

> I don't remember the discussion about delays in the kernel driver. ?Might
> have been before I was involved.

It was over on the lirc list, if I'm thinking clearly.


--
Jarod Wilson
jarod at wilsonet.com




Archive powered by MHonArc 2.6.18.

Top of page