Hi Dean,

thanks for your new patch. I'll test it today.
I've fixed the umlauts rudimentarily - they are now being displayed correctly but with a leading space:
"äöüß" becomes " ä ö ü ß".
I took them from the "mediaportal-code" and was surprised that ä, ü and ö were displayed upside down and with a leading space (the comments at the mediaportal forum implicated that the umlauts worked correctly?!?). So I had to "redesign" them - but could not get rid of the space which seems to prevent the vdr-lcdproc-plugin to recognize the umlauts and just inserts a space instead of the umlaut (or even space+umlaut).
I fully understand why you do not want to struggle with the charsets as I can hardly cope with them too ;-)
btw. I use ISO-8859-15 encoding.

The corresponding lines for the font are:
{ 'ö', { 0x0, 0x1C, 0xA2, 0x22, 0xA2, 0x1C } },
{ 'ä', { 0x0, 0x04, 0xAA, 0x2A, 0xAA, 0x1E } },
{ 'ü', { 0x0, 0x3C, 0x82, 0x02, 0x84, 0x3E } },
{ 'ß', { 0x0, 0x7E, 0x80, 0xA8, 0xA8, 0x50 } },

Could you please insert them into your next upcoming patch (there surely may be one ;-)) if I/we got rid of the spaces?.

As for the bars: Thanks for caring about it! If I understood the lcdproc-API correctly (I digged into it for a bit some months ago) there should be no problem with using the built-in bars.

However, my knowledge seems to be outdated/incorrect since I do not get the lcd's backlight turned on and off as stated in the "mediaportal-code" (and mentioned in ralphy's API):
// shut down the display
SendData(0x5000000000000008);

I tried it with a lcdproc-API-compliant (uncommenting it in the .h as well):
MODULE_EXPORT void imonlcd_backlight(Driver *drvthis, int on)
{
PrivateData *p = drvthis->private_data;

if ( on )
send_data((uint64_t)0x5000000000000040, p->imon_fd);
else
send_data((uint64_t)0x5000000000000008, p->imon_fd);
}

I was not successul with that quick shot when calling it e.g. after the init of the display.

OK, so much for now ...

Best regards!
Chriss

Test of patch lcdproc-0.5.2-imonlcd-0.2.patch work greet. The display is correct.
Now i test with vdr-lcdproc.

Regards.

Just a remarque. Syntax in not "./configure --with-drivers=imonlcd" but "./configure --enable-drivers=imonlcd"

regards

The test with vdr-lcdproc plugin work greet.
Many thanks
A+

Christian: Thanks for those. I actually "borrowed" my font characters from the media portal code in the first place as well and noticed they were upside down. They call a method "BitReverse" before sending the characters to the display, which reverses the bits. But I did that as a pre-process step so I don't have to do it with my characters (no point doing something every time when you can do it once, right?) I'm not sure why they did it like that...

As for the spaces, you have to make sure that the encoding you used when compiling is exactly the same as the encoding that LCDd is using at runtime. My guess is that some places might be using ISO-8859-15 while others are using UTF-8. I'll see what I can do for you in the next update, though :-)

sosi: Sorry, that'll teach me for typing it out from memory :-) I'll fix it up.

Great to see that you guys have been able to leverage off my original work and cybrmage's extensions.

It's funny now that you mention the BitReverse helper - you're absolutely right - why do this every time as you say! After finding a font file, it was the expedient way for the non programmer in me to get the fonts displayed. I ought get a copy of the 'reversed' font map from you and change the C# driver.

Thanks a lot for your hard work, ralphy! I certainly appreciate it :-)

With the font file, I just took yours, converted the C# into C, and then wrote a little program which reversed all the bits in the bytes and re-wrote the contents out as a C structure definition, which I just copy'n'pasted back into my original source file :-) you're more than welcome to download my code, of course :-)

Thanks Dean!
I already suspected these utf-8 problems, but you pointed out the exact solution. When putting some umlauts into the goodbye message of LCDd my editor (vim) used utf-8, although everything in my terminal-profile is set to ISO-8859-15. After your hint I used another editor (joe) and "bingo", the spaces are gone.
Now I "only" have to find out, why vdr (and/or the vdr-lcdproc-plugin) sends the "wrong" umlauts, although vdr itself detects utf-encoding locale settings at runtime and exits if found.
And I'm glad (or better said relieved) to see some comments in your code which indicate that even you have some problems with the display I could not explain during my tests yesterday (i.e. setting the contrast sometimes is impossible).

Chriss

Got it!
In the vdr-lcdproc-plugin there are translation/mapping tables for the charsets of different displays. For my former display I had to use set 1 and for the Soundgraph-LCD I have to use 0 (= no mapping).
As often: Once you figured something out years ago you get stuck at the same problem years after.

Greets!
Chriss

Heh, yeah, I've put in "TODO" comments in all the places I've still got work to do (there's quite a lot :p).

Glad to see you got your charset problems sorted!

Hello Dean,

to shorten the todo-list a bit I implemented the vbars, see http://lcr.vdr-developer.org/downloads/imonlcd.c-ver2.diff
for the changes.

Best regards
Chriss

Thanks, that looks great! I'll be sure to incorporate it!

Hello again ;-)

As I'm in a hurry for leaving now I just drop this bit of information that I "found out" a moment ago and thinking about it, it seems logical:
Characters were upside down, some hints in Ralphy's API about msb at the end and so on.
You have to send the bytes in reversed order - as in the quickshot:
unsigned char backlightOn[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50 }; // turn on the display
unsigned char backlightOff[] = { 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50 }; // turn off the backlight

write(fd, backlightOn, 8);
// write(fd, backlightOff, 8);

I must admit that I did not digged into the media-portal-code too deep for the reversal of bytes and/or commands but now I think I ought to ;-).

If you already figured that out yourself, please ignore this posting.
OK, I have to go - bye!
Chriss

Hi,

Thanks for this patch.

I have an error when a start LCDd. It tell me that the size is invalid but i made the ajustemtn in LCDd.conf

Server running in foreground
Listening for queries on 127.0.0.1:13666
imonlcd: using Device /dev/lcd0
imonlcd: allocating 0 bytes for framebuffer.
Driver [imonlcd] has invalid display size
Key "Escape" is now reserved in exclusive mode by client [-1]
Key "Enter" is now reserved in shared mode by client [-1]
Key "Up" is now reserved in shared mode by client [-1]
Key "Down" is now reserved in shared mode by client [-1]
screenlist_switch: switched to screen [_server_screen]
Floating point exception

Any suggestions?
Thanks Bob

Cool, this works great on my system. One problem though. I have the hauppage 150 with the IR blaster and remote, and when I configure lirc to load both lirc_pvr150 and lirc_imon, the LCD works, but my remote no longer works. Can anyone point me in the right direction to fix this so I can use both at the same time?

Bob: what's the relevent section of your LCDd.conf file? It should look something like:

[imonlcd]
Size=16x2
Device=/dev/lcd0

Bob:
About the Floating point exception -- I had the same problem, and commenting out the Size=16x2 line in the LCDd.conf file prevented the problem.

Hi again,

I don't know want i made but it's working pretty well now. I'm very happy to see my Silverstone GD01-MX working like it should.

Thanks a lot for this great solution
Bob

Glad to see you got it working, Bob :-)

Hi Dean,

thanks to your great work (and of course Ralphy's and cybrmage's) I extended the driver, so that I'm pretty satisfied with it in conjuction with the vdr-lcdproc-plugin (also heavily patched now).
I hope that I saved you from some tedious work and that the code might be incorporated with few (if any) changes.
The patch ought to get applied just as in your instructions.
Please let me know, whether the changes are according to your plans as I may try to implement the imonlcd_icon() method if you have not already done this.
The patch can be found at: http://lcr.vdr-developer.org/downloads/lcdproc-0.5.2-imonlcd-ver3.diff

Best regards,
Chriss

Hi.

I have Antec Fusion Black. I downloaded lirc from cvs and lcdproc 0.5.2 and I applied your patches without any problems.

I saw that Driver was already entered as "Driver=imonlcd" and [imonlcd] block was also already available in /etc/LCDd.conf. I just added the correct size: 16x2. But I get this error when I run "LCDd -f -r 4":
-------------------------------------
Server running in foreground
Listening for queries on 127.0.0.1:13666
imonlcd: using Device /dev/lcd0
imonlcd: allocating 0 bytes for framebuffer.
Driver [imonlcd] has invalid display size
Key "Escape" is now reserved in exclusive mode by client [-1]
Key "Enter" is now reserved in shared mode by client [-1]
Key "Up" is now reserved in shared mode by client [-1]
Key "Down" is now reserved in shared mode by client [-1]
screenlist_switch: switched to screen [_server_screen]
Floating point exception
root@mythbox:~/packages#
-------------------------------------

this is from LCDd.conf and it looks OK as I can see:
--------------------------------
## Soundgraph iMON LCD driver ##
[imonlcd]

# select the device to use
Device=/dev/lcd0

# display dimensions (generally, don't need to touch)
#Size=96x16
Size=16x2

# what to do when the server stops. 0=show exit message, 1=show clock (default)
# and 2=blank LCD screen
#OnExit=2
------------------------------


If I remove the line with Size=16x2, the lights on display start rotating more or less. That means that most but not all of the lights getting turned off and on pretty fast and it looks like lights in the display would rotate.

Any ideas? Can I debug this somehow?

Thanks a lot for your work.

X.

One more thing. I tried this (from mythtv wiki) but I also got error:
> modprobe lirc_imon
> echo "Hello MythTV and good morning" > /dev/lcd0
> -bash: echo: write error: Invalid argument

dmesg:
/root/packages/lirc/drivers/lirc_imon/lirc_imon.c: lcd_write: invalid payload size: 9 (expecting 8)
/root/packages/lirc/drivers/lirc_imon/lirc_imon.c: VFD port closed


So I shortened text to 8 characters and I still got error. The error was gone after I cut it to 7 characters:
> echo HelloMy > /dev/lcd0

dmesg:
/root/packages/lirc/drivers/lirc_imon/lirc_imon.c: lcd_write: invalid payload size: 9 (expecting 8)
/root/packages/lirc/drivers/lirc_imon/lirc_imon.c: VFD port closed


LCDd was off course not running during this. I tried it while LCDd was running just to be sure, but /dev/lcd0 was busy.

Xe Yieang: The protocol of the iMON LCD is binary, which means echo'ing characters to it won't work (this is different to the VFD, which was text-based -- this is because the LCD is capabable of displaying more than just ASCII text).

Some people have mentioned that removing the "Size=16x2" line altogether will help with that "Floating point exception" error. I guess I have to check the code there!

I'm not sure what you mean by "the lights on display start rotating more or less" you mean the text-part of the screen? I have not built my code against the cvs version of LIRC, only the currently-released version (0.8.2) but I don't think that there should be a problem with the CVS version. Could you describe what you're seeing in a bit more details perhaps? A photo would be even better (if you go to the forums, http://codeka.com/forums/ you are able to upload attachments with your posts, so you can upload a photo there).

Christian: That looks great!! I can't wait to get home now and give it a go :-)

Quote:
"I'm not sure what you mean by "the lights on display start rotating more or less" you mean the text-part of the screen?"

Well ... making picture would not use, I should make a movie to show you that effect :). But I will try to describe it.

I wanted to say that the central part of lcd does not change, but all the "icons" like music, movie, photo, mpg, divx, xvid etc... are blinking as soon as I start LCDd. even the big CD icon in the left upper corner is partly blinking (not all the slices of the CD, but a few of them).

It looks funny, but only for a few seconds :).


I am using lirc from cvs because I need it for my hauppauge remote. You patches applied without problems, and that probably means that there were no significant changes.

I tried Christian's patch, but LCDd does not start at all with it.

/var/log/syslog gives me this:
Sep 24 21:03:29 mythbox LCDd: Critical error while initializing, abort.
Sep 24 21:03:34 mythbox LCDd: Could not open driver module /usr/lib/lcdproc/imonlcd.so: /usr/lib/lcdproc/imonlcd.so: undefined symbol: lround
Sep 24 21:03:34 mythbox LCDd: Driver [imonlcd] binding failed
Sep 24 21:03:34 mythbox LCDd: Could not load driver imonlcd
Sep 24 21:03:34 mythbox LCDd: There is no output driver
Sep 24 21:03:34 mythbox LCDd: Critical error while initializing, abort.

Am I maybe missing something.

M.

Nevermind.. I did some research and found that I have the VFD and not the LCD. I'd really prefer the LCD version so now I suppose I need to figure out how I can replace it.

- Mark.

Xe: Yeah, I think the problem is the use of the "round" function in Christian's patch. I had to replace "round" with my own function because it wouldn't even compile on my compiler (without specifying it to run in C99-mode on the command-line -- something I would not be comfortable doing given that the rest of LCDd compiles without it :)

So I'm thinking of releasing a newer version of the patch with Christian's code incorporated, as well as some of the things I've been working on as well.

Great work, by the way, Christian. You got the clock working when you exit LCDd which was something I was trying to do as well :-)

Mark: Glad you figured it out :-)

Hi Guys,


How to control brightness and contrast for this thing ?

Thanks!

Dev Null: If you're using the latest version of patches (0.3) then there's a "Contrast" setting in the configuration file. Possible values range from 0 (lowest) to 1000 (highest). It actually corresponds more to "bightness" than "contrast" but there you go :-)

It also depends on your specific device, but on some models you can actually turn off the backlight (set "Backlight" to 0) which might help if you have a high contrast value. On mine, though, turning the backlight off actually turns the whole device off so I can't do that.

Thanks for reply,

Sorry I didn't put device name in my first post. It's Antec Fusion Black LCD. When I set "Backlight" to 0 it turns off. Now trying to play with Contrast.

Thanks again, you did a great job !

Yeah, I've got the Antec Fusion Black and it's one of the ones that turn the device off completely when the backlight goes off. I've found that a Contrast of "200" or so looks OK on mine.

There is an imon page on the mythTV wiki dedicated to imon and lcdproc.
http://www.mythtv.org/wiki/index.php/Imon

When using mythTV - please put your info on the wiki.

Thanks,

Moosy

Thanks for these. You've done a great job!


Just a little problem with imonlcd
If I use "Size=16x2" parameter I got only few sequences on the screen.

It says:
imonlcd: allocating 0 bytes for framebuffer.
Driver [imonlcd] has invalid display size
Key "Escape" is now reserved in exclusive mode by client [-1]
Key "Enter" is now reserved in shared mode by client [-1]
Key "Up" is now reserved in shared mode by client [-1]
Key "Down" is now reserved in shared mode by client [-1]
screenlist_switch: switched to screen [_server_screen]
Floating point exception

It doesn't allocate framebuffer? I've tried with different sizes but it is always the same. If I take size out, it doesn't hang but the screen just keep running with some odd characters.

Case is Antec Fusion V2.

I just got a Moneual MonCaso 832 case a couple of days ago. I followed your instructions, but I'm having some problems. I've tried using both imonlcd and imon drivers. For imonlcd, I had to comment out the size line, whereas imon ran without modification. In either case, nothing is displayed on the screen.

This may help weed out the floating point exception bug: When I set the size to 2x16 instead of 16x2, it doesn't raise a floating point exception, allocates a 4-byte buffer, and still complains about an incorrect size. A 96x16 size allocates a 192-byte buffer, and no complaints.

Like Sean (Mon 17-Sep-2007 04:23) I am having difficulty with these patches and having the ir receiver work.
The LCD usually seems to work fine, but with lircd running in conjunction with lcdproc, pressing keys on the IR remote eventually kills the LCD rotating message.
And syslog suddenly is flooded with:

lirc_imon.c: lcd_write: no iMON device present

System is x86_64.

Any tips or news that this is being fixed?

Hi guys, I've updated the post with a pointer to the forums. That's where most of the discussion is happening now. I'm going to close comments on these posts, because all new discussion should be happening on the forums, where there are plenty more people willing to help you out. Thanks for the support!