From thomas.jarosch@intra2net.com Tue Jul 1 07:56:02 2008 From: thomas.jarosch@intra2net.com (Thomas Jarosch) Date: Tue Jul 1 07:56:02 2008 Subject: [Lcdproc] Noritake Itron VFD display on FT245R (ftdi) In-Reply-To: <816ec0840806290211w729f4952wbeec9bf372785961@mail.gmail.com> References: <816ec0840806200701x8540342j9051d2aeca1ed770@mail.gmail.com> <200806230948.39373.thomas.jarosch@intra2net.com> <816ec0840806290211w729f4952wbeec9bf372785961@mail.gmail.com> Message-ID: <200807010955.15860.thomas.jarosch@intra2net.com> Hello Han <-- without the s ;-), On Sunday, 29. June 2008 11:11:52 you wrote: > The problems seems to be that my VFD does not like the second nibble > during the switch from the 8bit mode to the 4bit mode after a reset. > > In the original code was the configuration implemented with the 3x times: > ftdi_HD44780_senddata (p, 0, RS_INSTR, FUNCSET | IF_4BIT ); I just checked the limited datasheet of my display module, the 4bit init mode in the hd44780-ftdi driver seems wrong to me: 8bit mode should do 3x times ftdi_HD44780_senddata (p, 0, RS_INSTR, FUNCSET | IF_8BIT ); 4bit mode should do 2x times ftdi_HD44780_senddata (p, 0, RS_INSTR, FUNCSET | IF_4BIT ); Please check with a real HD44780 datasheet, something seems wrong in 4bit mode. If you cook up a patch, the list is the right place to send it to. Cheers, Thomas From thomas.jarosch@intra2net.com Tue Jul 1 08:04:01 2008 From: thomas.jarosch@intra2net.com (Thomas Jarosch) Date: Tue Jul 1 08:04:01 2008 Subject: [Lcdproc] Noritake Itron VFD display on FT245R (ftdi) In-Reply-To: <816ec0840806290211w729f4952wbeec9bf372785961@mail.gmail.com> References: <816ec0840806200701x8540342j9051d2aeca1ed770@mail.gmail.com> <200806230948.39373.thomas.jarosch@intra2net.com> <816ec0840806290211w729f4952wbeec9bf372785961@mail.gmail.com> Message-ID: <200807011003.31786.thomas.jarosch@intra2net.com> On Sunday, 29. June 2008 11:11:52 you wrote: > By the way it could also be nice to use a FT232R instead of the > FT245R. That chip can also be put into a bitbang parallel mode, butthe > 4 cbus pins would give an option to add keys display. (I do not really > need that functionality for my project) That should already be possible as all FTDI chips share the same USB commands to enter the bitband mode, adjust the baudrate etc. Configuring the VendorID and ProductID should be enough to get going without the CBUS stuff. Thomas -- Address (better: trap) for people I really don't want to get mail from: brenda@cactusamerica.com From TELarson@west.com Tue Jul 1 12:45:02 2008 From: TELarson@west.com (Larson, Timothy E.) Date: Tue Jul 1 12:45:02 2008 Subject: [Lcdproc] solaris In-Reply-To: References: <485BF728.7010206@nurfuerspam.de> <485EAD17.1080005@nurfuerspam.de> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C8DB4E.3EF9F600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Larson, Timothy E. <> wrote: > I have fetched lcdproc from CVS on two systems and would be willing to > cron the smoketest nightly. Who needs to add my SF account to the > project so I can upload the results? Anyone? Tim -- Tim Larson AMT2 Unix Systems Administrator InterCall, a division of West Corporation Eschew obfuscation! ------=_NextPart_000_000F_01C8DB4E.3EF9F600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIhtjCCBX0w ggNloAMCAQICECemzDgLody1TCGAnUl1rQwwDQYJKoZIhvcNAQEFBQAwUTETMBEGCgmSJomT8ixk ARkWA2NvbTEaMBgGCgmSJomT8ixkARkWCndlc3R3b3JsZHMxHjAcBgNVBAMTFVdlc3RDb3Jwb3Jh dGlvblJvb3RDQTAeFw0wNTA4MTIwMDEzNTFaFw0yNTA4MTIwMDIwMzhaMFExEzARBgoJkiaJk/Is ZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgp3ZXN0d29ybGRzMR4wHAYDVQQDExVXZXN0Q29ycG9y YXRpb25Sb290Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDPHEBA8kQ57S0r6UBX goiUxXlWarmYmFyRAQ0KfqRA0pvd1qrLZdLATzqXl6PoqnOLL+Wyn4yx9pDH3mQ5NaxpLbHZCLhL cuZCJTSroyBbstHlLv33Ueu78CW6QOwSXwEYhYdFjdqd9z3u6aZ7LuPIyE8xNBJkfp91Y1KSN2Va aVP7jXXQeo2bVwBXGZFA4QoqPikADShT8sXIOmZWUXiSUvOlgrtJNhzIncVEGWv4KzKCzt69t+CE FBp34rE4hPHWTG6pdd7Be4mYLv1SiSEoIRab/7IbNL6AuAk+xLGSX/s8KepfSAQ6SsMWZCS/Qa0r sRWLN/69eIAxkdG1evis4dBZh9z6zwpe5to/kayS0qlzVh5NuS7AX8jQtmOTBghH5QAr3fjm2u5g PAHkjnVjV5zURUmx7SaTKJ5eG2rMkuDIcXDNp853ymk9DBSwEcyMZI47LfqASdWTPCS9MUDHMF7e w1yAtHq7PIHELZoOk7K4moP0DDaqqgvz8yxDEIf6MffqAdwCdTPi2gXYXPaYbBBqk6zZ2ii86EcY 0VVXHVSNkxNNh8X6igdj38h0p0H6FZvxKTl41Hl1cbY8WwrT2PVLaRjS5TvKiLZlVHfAAl0CsDIm BQHDmKZ8NpKAP3FaoDaX71zzj8RpwdHqmbgvKeJlaJPdp9wUV9BHRR7O7QIDAQABo1EwTzALBgNV HQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUs3SmQR/cwUD9O4jOi7fUEZrIj54w EAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEFBQADggIBAIEW5f7QNwAxhA4ydk3koDUmpl+3 qR4rC/xsaxCTfS33NJcBW91pvdSR56GawflP+cqL343R3i+2ILXGKpI+b/wbaK/a+aVwpz6gmFQn 2x9WBI7Su2eqBMYyYdSdBuL/7Jd2hyuUfFkGHnO0xxcMOnWBbZ/fGoZpNOUQr7ypOG3OxCCAASH8 4XvzA+Fs6WRSjKdLoCtz1W5tfhObTsWWXFzF9BPwcFr/XuPayUEzGrsWl1oSUw8gOxz4lsaErYaG raSJhmrYJrWNva0NgtLX8bJ036dSJsKDNNvZcpJ4Z5YiDZPUCihm1zLSSDOGeGDg7xF3Aj/KwEuM 8zCBOE1bKPBFawgXKVkkSrclPinDCuasuzkbbvMtxZZpXkYKfh/n0MrIKejWDexQtfrEdbsjWXys BIrMcPW2XoJJzvKu8ZBwxza8fV4z0TjXIl43zjeWF6BDXhhhmoaN3yTvxVWV+dEBza2/b5R7hcGM x1pdDuHcyyoYbwi7Ir2WxA9U5wzRLUB1/6HnpjwnUvWuNh1akRFY4H0rrr0EWSlv2mqlMe9cnTv+ CpzXi6qgfLeI8SAoHez0rlEbjiFREqzRV4Syb7UjUbv80I6ke0orC9cfU+vOSqITyGEedosBX06V whP5yOMD2zedeheYvy8rjXA04qM4mZ8WirXFUlbKvbv1dIZ3MIIGKzCCBROgAwIBAgIKLCl1sQAD AAAonDANBgkqhkiG9w0BAQUFADBpMRMwEQYKCZImiZPyLGQBGRYDY29tMRowGAYKCZImiZPyLGQB GRYKd2VzdHdvcmxkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxIDAeBgNVBAMTF1dlc3RDb3Jwb3Jh dGlvbklzc3VlQ0EyMB4XDTA4MDMwNTE2MDc0NFoXDTA5MDQyNzE2MDQ0OVowPzEbMBkGA1UEAxMS TGFyc29uLCBUaW1vdGh5IEUuMSAwHgYJKoZIhvcNAQkBFhFURUxhcnNvbkB3ZXN0LmNvbTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnri+JhTRZOBpA7Y+1C0thV/w1oi5S28d88Z0bYvR2yyN GZYr501Xzs4/CToyg/KhNoyy/99gnkVXwdcE1uzDYmRHCSDAROMWZty853W22tHORoHtDyZammLv vY8LFhqw9d6mY+XUK6JpGeOaTvyew5GY3VTe4vcHZza6EKw05jcCAwEAAaOCA4EwggN9MAsGA1Ud DwQEAwIHgDAdBgNVHQ4EFgQU6ZjOXBi5Ohn6hLDGZLmjJeo8cmAwPQYJKwYBBAGCNxUHBDAwLgYm KwYBBAGCNxUIhbCVNYTfghWC5ZUoh+yjC4TRwRcph/71PIXstHwCAWQCAQQwggFuBgNVHR8EggFl MIIBYTCCAV2gggFZoIIBVYaByGxkYXA6Ly8vQ049V2VzdENvcnBvcmF0aW9uSXNzdWVDQTIoMSks Q049b21hMTFjcGtpMDQsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2VzdHdvcmxkcyxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hjZodHRwOi8v d3d3Lndlc3QuY29tL3BraS9XZXN0Q29ycG9yYXRpb25Jc3N1ZUNBMigxKS5jcmyGUGh0dHA6Ly9v bWExMWNwa2kwNC5jb3JwLndlc3R3b3JsZHMuY29tL0NlcnRFbnJvbGwvV2VzdENvcnBvcmF0aW9u SXNzdWVDQTIoMSkuY3JsMIIBTAYIKwYBBQUHAQEEggE+MIIBOjCBuQYIKwYBBQUHMAKGgaxsZGFw Oi8vL0NOPVdlc3RDb3Jwb3JhdGlvbklzc3VlQ0EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdlc3R3b3JsZHMsREM9Y29t P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHwG CCsGAQUFBzAChnBodHRwOi8vb21hMTFjcGtpMDQuY29ycC53ZXN0d29ybGRzLmNvbS9DZXJ0RW5y b2xsL29tYTExY3BraTA0LmNvcnAud2VzdHdvcmxkcy5jb21fV2VzdENvcnBvcmF0aW9uSXNzdWVD QTIoMykuY3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH AwQwHAYDVR0RBBUwE4ERVEVMYXJzb25Ad2VzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBABxqNd9W JjT81uiGrFdVesEz3caWOBPvWj0BMQJzQdQYAun9v8jZ49QXPXAlex0ZrBwfnzvcHzNrM8gxy9ad MI88UxXkkqdIaEOrXpDRfeTfVGvBZZydk71e1OvQL2Wq6ZXKVcYtxsRImi7Wn/Vr4dICnOTrt4r0 TvR4eWmXfVknDAnCa2A6jjwiT2DD4Ldg4DeOwF6MJRukXwEMgFlL6esjZhHZsExZZi2vrhwcarsw vUNK0E2YQ57LN9MZ4/HjtZM83EDkOrr2hbtILE/CDOmCmZYqZju6dWMZZvtq+FacQ12YtJEMLNrm pEJromqnTBAPildblsCGarkI7XyRn58wggZxMIIFWaADAgECAgosKH/XAAMAACibMA0GCSqGSIb3 DQEBBQUAMGkxEzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgp3ZXN0d29ybGRz MRQwEgYKCZImiZPyLGQBGRYEY29ycDEgMB4GA1UEAxMXV2VzdENvcnBvcmF0aW9uSXNzdWVDQTIw HhcNMDgwMzA1MTYwNjI0WhcNMDkwMzA1MTYwNjI0WjA/MRswGQYDVQQDExJMYXJzb24sIFRpbW90 aHkgRS4xIDAeBgkqhkiG9w0BCQEWEVRFTGFyc29uQHdlc3QuY29tMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDr7MbsLwl0VIuaVnKwXTNYEYVWE7CeGI128toZvxpdyTtFBD9swAQfcVQrOkqj isOkmtGS81b/HbZhih8gA96jhZELYk3gfLREL7ti12Y8Stt+EeS1jkVaVbQxjq0z/h0RNGJ1se7r J3qwAGh+2pnIZHf+mj91FzE1JFVKU3TwMQIDAQABo4IDxzCCA8MwCwYDVR0PBAQDAgUgMEQGCSqG SIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggq hkiG9w0DBzAdBgNVHQ4EFgQUahJS7mmGkz5Nxvjezcybeql0lkUwPQYJKwYBBAGCNxUHBDAwLgYm KwYBBAGCNxUIhbCVNYTfghWC5ZUoh+yjC4TRwRcph6ysDoP5/yECAWQCAQcwggFuBgNVHR8EggFl MIIBYTCCAV2gggFZoIIBVYaByGxkYXA6Ly8vQ049V2VzdENvcnBvcmF0aW9uSXNzdWVDQTIoMSks Q049b21hMTFjcGtpMDQsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2VzdHdvcmxkcyxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hjZodHRwOi8v d3d3Lndlc3QuY29tL3BraS9XZXN0Q29ycG9yYXRpb25Jc3N1ZUNBMigxKS5jcmyGUGh0dHA6Ly9v bWExMWNwa2kwNC5jb3JwLndlc3R3b3JsZHMuY29tL0NlcnRFbnJvbGwvV2VzdENvcnBvcmF0aW9u SXNzdWVDQTIoMSkuY3JsMIIBTAYIKwYBBQUHAQEEggE+MIIBOjCBuQYIKwYBBQUHMAKGgaxsZGFw Oi8vL0NOPVdlc3RDb3Jwb3JhdGlvbklzc3VlQ0EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdlc3R3b3JsZHMsREM9Y29t P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHwG CCsGAQUFBzAChnBodHRwOi8vb21hMTFjcGtpMDQuY29ycC53ZXN0d29ybGRzLmNvbS9DZXJ0RW5y b2xsL29tYTExY3BraTA0LmNvcnAud2VzdHdvcmxkcy5jb21fV2VzdENvcnBvcmF0aW9uSXNzdWVD QTIoMykuY3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUH AwQwHAYDVR0RBBUwE4ERVEVMYXJzb25Ad2VzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAFB3o3bn 416wTntEc3UJB6ezoAHNyPs3JpQ6wATulH6vCCPjlBcku8XoZrjVk5mUBPGTP+OSh0vharOQbQmn BVIDB+F5NHuYjaK/x2fCr9ghzvEe4pnTmsH6bii4MQ/i8nP0ynFWb9R6mi+u+uRO8d29mvrRkFbh w1DvkcPzLs9lF+vzk24SXG4f/FX7lDnHaJSjEQL/woktgWPb0LoPSdFbq26ONEpPecKvFBVOXA7A 6VwaqmvCJmp8g9nMtPUNtj0uW77uoVsjUBt6qa1/LPMzxDLsN/dn4jGDit3PYG1fkdbqiXBd9Vvq bTLtvrc4l3SpS3S9Wzh6+CQa2ZZSzcEwggdTMIIFO6ADAgECAgphAtbtAAMAAAAmMA0GCSqGSIb3 DQEBBQUAMFQxEzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgp3ZXN0d29ybGRz MSEwHwYDVQQDExhXZXN0Q29ycG9yYXRpb25Qb2xpY3lDQTEwHhcNMDgwNjI1MTQwMjQ5WhcNMTMw NjI1MTQxMjQ5WjBpMRMwEQYKCZImiZPyLGQBGRYDY29tMRowGAYKCZImiZPyLGQBGRYKd2VzdHdv cmxkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxIDAeBgNVBAMTF1dlc3RDb3Jwb3JhdGlvbklzc3Vl Q0EyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnmadERb7eAX1a0w4pzRjBkk42lQK 4Is7Lfwd7kTmIKdseMUahfnLk6SXJiCTUNtVHp2/qnwN57KyPDnMUwroyfcwoEV0yUReN35hPHM5 +lJj70VAOO+NK/naeQU26g/18oobr+55O/UhQTU95RB/4DgMNMdURIQwjkCdtS9Hz+EPzJnDGDgW t7/6v79gS+a5FqNT/8w1OpPyV2JhDP08CIA0deCht1BeoL9DSLa+alTImEsFH34uFmGkSsb0C0rJ K9rYBGNpqlhMUUeMgmWvfU7gYypvRHrVoyzG4+ZE7pSO80Djf+of6+MHz7V1nqHeFUC3BtZHMuYg BqIAX1PvDQIDAQABo4IDEDCCAwwwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUBNi45b9akA7g wlC2wuXZamtauJkwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMBAAQwIwYJKwYBBAGCNxUC BBYEFLEamPiEsMXj55JMBvHIWgTmYppwMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1Ud IwQYMBaAFN24IxQF10dDqd4ok9WA04tXBw/PMIIBHgYDVR0fBIIBFTCCAREwggENoIIBCaCCAQWG gclsZGFwOi8vL0NOPVdlc3RDb3Jwb3JhdGlvblBvbGljeUNBMSgyKSxDTj1PTUExMUNQS0kwMixD Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Y29uZmlndXJh dGlvbixEQz13ZXN0d29ybGRzLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGN2h0dHA6Ly93d3cud2VzdC5jb20vcGtp L1dlc3RDb3Jwb3JhdGlvblBvbGljeUNBMSgyKS5jcmwwggE0BggrBgEFBQcBAQSCASYwggEiMIG6 BggrBgEFBQcwAoaBrWxkYXA6Ly8vQ049V2VzdENvcnBvcmF0aW9uUG9saWN5Q0ExLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1jb25maWd1cmF0aW9uLERD PXdlc3R3b3JsZHMsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGMGCCsGAQUFBzAChldodHRwOi8vd3d3Lndlc3QuY29tL3BraS9PTUEx MUNQS0kwMi5jb3JwLndlc3R3b3JsZHMuY29tX1dlc3RDb3Jwb3JhdGlvblBvbGljeUNBMSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADggIBAHZkXYcymPNmU8N4wGseW5qEDE98O53qhwQ0ssVbIW031mB+ ex49NNDa6I5f2jW9BlyPTnivNuCdpSEsMB4YdfNyMiwU6ltJuGAjPRY1WdNlcE0hd9yw7U3NWfBa 9myog1a+DLZaiHTpAkxyUV3MiuIFnPKjWEz2xhpGQ0AVeWMyQhmGEH3BGaW/UfcJL/BRoY8R/YxL omfE/LihrwPWXf4ZCH3WqkDAWAn0rp5BVv7jkkOnpiaDA3sy1F05cNdR5pTZ6z76VE0XiJvMVlEm oIINbDwNkh7iZYnXgyorRB7iEOLqc5/lgr96wOedBMi8Y3MBr1OYBs7qDkCO7ZWjqcWuQ6fFFePt OO+JMh2DgFrsFifZr3fkclXrvQZ62GXDlaWLF+XyFv/HVhzg3pFfp4W5QZ+W9/y8iEVtx6zuGiMc cXJxhPwb61lK6hB251p+QmQ6mneo/qUIIxQ9XJkJ46BWCCI0KJ+7s5WIZwKwjJR/o/BX3uUThxHk g/It6oU9wCA7+6Gnhvk8ZepZYfNAOsoG36PxF7OcnvkvzcKre2li0HIx5bDwSr9jfrOpN8owUy3/ bHAijMql5/ADFbseu+kgoL+aTtRzim+Ghj5COa6e5+Cz9FozGblZE3S1fB4Y7n9EjOCPprhUuYCw v9+obuokseBNFfXKWceczx/z4jLGMIIINjCCBh6gAwIBAgIKYQzovwAAAAAACjANBgkqhkiG9w0B AQUFADBRMRMwEQYKCZImiZPyLGQBGRYDY29tMRowGAYKCZImiZPyLGQBGRYKd2VzdHdvcmxkczEe MBwGA1UEAxMVV2VzdENvcnBvcmF0aW9uUm9vdENBMB4XDTA4MDYxOTE1MDAwOFoXDTE4MDYxOTE1 MTAwOFowVDETMBEGCgmSJomT8ixkARkWA2NvbTEaMBgGCgmSJomT8ixkARkWCndlc3R3b3JsZHMx ITAfBgNVBAMTGFdlc3RDb3Jwb3JhdGlvblBvbGljeUNBMTCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAJH++0luFEnU1qJLiGOZk7/eC5CX9EXEWVnurTjyU5gC3NFw4ALtIcVSrHPHfHhP gJf1Enu48EK7nJ1ijCjjmKm0InIh4f3VrMObCKhasXXWNK+kUXCdq35/aOPtrI4g0XTtnwYahwQ7 wZkbHWstQE1HtYuneUWUorzngPPLAjU2NBgQL16zN5P8ydBMbBRs2SUQbHc1hKQFr3/bhHzcjnWf wFma6ieeFcf9UWfE5buDEt2US/RBPFqCF9mRQYi/up3kRMgg0YGqAChUbpL3gSPksJuA6VYkv7z/ IFzIz41wNnEtK9AwPgkjm7Jpn71LTOpPZvy4P+Y8AaM0eu8Zy4J84EoIZ37Nk19I2kIIzkQxujj1 rZ346wpTNNe8V9UZc3xrFa1ObVSXyNa1vG7HLHvNgCLUXvnZkRN/seJQOJD4Ama/VS7oli/LK7tl o5zvPWoWNJ+I7RCJTv1XQtaRT953Zd/z9bxIaQ2IXtPILQh/VseoRUcNbIqxN5hLFwQrNi0Jiq9l 4L4nfkcaxHfdkcBaciERqkL198wL2H2mvqzgeNG2hjVgcE/0u+R1t7W7oVZzLlsBwwnw3RRQ3ZBQ H/6a5de5hSxGwXhWPZD8zVvoCbpFI7zls2GqUOVAzcL49yoQkIxCzXAL4ug/RcDDkFdqE62cfk7R NLhEpEryBx1lAgMBAAGjggMLMIIDBzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTduCMUBddH Q6neKJPVgNOLVwcPzzALBgNVHQ8EBAMCAYYwEgYJKwYBBAGCNxUBBAUCAwIAAzAjBgkrBgEEAYI3 FQIEFgQUx8024g0+Zii3xp4CnGS2QsHj8/MwEQYDVR0gBAowCDAGBgRVHSAAMBkGCSsGAQQBgjcU AgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFLN0pkEf3MFA/TuIzou31BGayI+eMIIBDwYDVR0f BIIBBjCCAQIwgf+ggfyggfmGgcNsZGFwOi8vL0NOPVdlc3RDb3Jwb3JhdGlvblJvb3RDQSxDTj1v bWExMWNwa2kwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz13ZXN0d29ybGRzLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGMWh0dHA6Ly93d3cu d2VzdC5jb20vcGtpL1dlc3RDb3Jwb3JhdGlvblJvb3RDQS5jcmwwggErBggrBgEFBQcBAQSCAR0w ggEZMIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049V2VzdENvcnBvcmF0aW9uUm9vdENBLENOPUFJ QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdlc3R3b3JsZHMsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MF0GCCsGAQUFBzAChlFodHRwOi8vd3d3Lndlc3QuY29tL3BraS9v bWExMWNwa2kwMS5jb3JwLndlc3R3b3JsZHMuY29tX1dlc3RDb3Jwb3JhdGlvblJvb3RDQS5jcnQw DQYJKoZIhvcNAQEFBQADggIBAGdOPzwVoRdDWUegSptMZTBkIZkOb+icAYDGqCy1ms4akSMyEDly NKpQXIAo8KLJrxtLrukPE2mfcjH/rjzRAzTc6UXrFSsNJjbd/Oz3iR+l0W0Z50IpjRdqpwE5wobI vT7vG3cvrelwhIPjNbNQQXU+uCV/qmzgdo8L2Q5sA2KvAxAwaJJFOXvFot+QxEq51yvc0J0AS0x6 qUeXHJYcL9zDTypm9/d/QOuR4qZfPoXdj00WHQbov9aAcIBPE7zc5JWDasqWaVm40r2XqfxcBb+w wFsmsO+kmy8ajhVzNwz2JRWwQeBZ/YDtYlscdqKWRVXVAMo1W+sxgJ1Prcfg3BaBHOnErBn3NMUa H73z06odEZcLCjjBKsz8kfamfa3nZ0peuO30qVf069FzgRMjJVU05zBe134M5c2Lq0GxKhO9jr5Q kmYKgFj01U64wtWUAsd4pXYGzCwOmLxwxwYRt0iPNBlxY+h+7dhHzQ0KuwqJPKRjOevJNkj5q0ZB lJiv1jr5DRU3FguUDdJwAZrIlhSM6kFYh8pC2rVYgYqWs3X/GRsJuE0m4DB5W63i2R7XtWOih47/ aY4Sj5nie1LAPXQdMvYSmp+6xErxFsV03B1+qpDxSPCDmD48/71ko5eRKd76KH/fjfxCpAI+Xb8U dM4l3n8k4ZVXpAT6cMoWj9QdMYIC+zCCAvcCAQEwdzBpMRMwEQYKCZImiZPyLGQBGRYDY29tMRow GAYKCZImiZPyLGQBGRYKd2VzdHdvcmxkczEUMBIGCgmSJomT8ixkARkWBGNvcnAxIDAeBgNVBAMT F1dlc3RDb3Jwb3JhdGlvbklzc3VlQ0EyAgosKXWxAAMAACicMAkGBSsOAwIaBQCgggHaMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDcwMTEyNDQwOVowIwYJKoZI hvcNAQkEMRYEFPN+hD2onWhl1elumhXd2t3zx2CiMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGGBgkrBgEEAYI3EAQxeTB3MGkxEzARBgoJkiaJk/IsZAEZ FgNjb20xGjAYBgoJkiaJk/IsZAEZFgp3ZXN0d29ybGRzMRQwEgYKCZImiZPyLGQBGRYEY29ycDEg MB4GA1UEAxMXV2VzdENvcnBvcmF0aW9uSXNzdWVDQTICCiwof9cAAwAAKJswgYgGCyqGSIb3DQEJ EAILMXmgdzBpMRMwEQYKCZImiZPyLGQBGRYDY29tMRowGAYKCZImiZPyLGQBGRYKd2VzdHdvcmxk czEUMBIGCgmSJomT8ixkARkWBGNvcnAxIDAeBgNVBAMTF1dlc3RDb3Jwb3JhdGlvbklzc3VlQ0Ey AgosKH/XAAMAACibMA0GCSqGSIb3DQEBAQUABIGABL+i2ub7o0Hm4pesppjGOu79ZvZ43pwbWfkH aerv97b4giyYpfZytVFkfzhmrI2MztVgPXniaSIWIvA0RiJ1dE+/7f7ATFnaHV1jYA/KeVMT1W8I DJ/0yRLZ7qyBaKd1QQ/Sz2GMcDM30JJ8qZO5Yty0bewcW4qZEsd7GGSJFp0AAAAAAAA= ------=_NextPart_000_000F_01C8DB4E.3EF9F600-- From e_swallie@hotmail.com Thu Jul 3 15:59:02 2008 From: e_swallie@hotmail.com (Eric Swallie) Date: Thu Jul 3 15:59:02 2008 Subject: [Lcdproc] mail address Message-ID: --_4c23e120-71a5-4dd2-b8fa-4a5931b07b01_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is my mail addrerss. if you could add em to your list so i can post _________________________________________________________________ Watch =93Cause Effect=2C=94 a show about real people making a real differen= ce. Learn more. http://im.live.com/Messenger/IM/MTV/?source=3Dtext_watchcause= --_4c23e120-71a5-4dd2-b8fa-4a5931b07b01_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is my mail addrerss. =3B if you could add em to your list so i can= post


Watch =93Cause Effect=2C=94 a show about real peop= le making a real difference. Learn more. = --_4c23e120-71a5-4dd2-b8fa-4a5931b07b01_-- From e_swallie@hotmail.com Thu Jul 3 16:16:02 2008 From: e_swallie@hotmail.com (Eric) Date: Thu Jul 3 16:16:02 2008 Subject: [Lcdproc] picolcd Message-ID: i am trying to get lcdproc to work on a mini-box m200 lcd case. this uses the picolcd. my problem is i do not know anything aout linux in general, and certainly nothing about compiling and installing drivers. the box is running ubuntu 8.04 (hardy) can anybody help me get this working? Eric From a.errington@lancaster.ac.uk Fri Jul 4 00:02:01 2008 From: a.errington@lancaster.ac.uk (Andrew Errington) Date: Fri Jul 4 00:02:01 2008 Subject: [Lcdproc] picolcd In-Reply-To: References: Message-ID: <36472.211.8.77.2.1215129653.squirrel@webmail02.lancs.ac.uk> On Fri, July 4, 2008 01:10, Eric wrote: > i am trying to get lcdproc to work on a mini-box m200 lcd case. this > uses the picolcd. my problem is i do not know anything aout linux in > general, and certainly nothing about compiling and installing drivers. > > the box is running ubuntu 8.04 (hardy) can anybody help me get this > working? Hello, Firstly, Google is your friend. I see that the picoLCD is a USB HID module. It has an LCD, an IR receiver, and a keypad interface. Googling for "lcdproc m200" gives me this (amongst others): http://www.mini-itx.com/store/?c=37 and about half-way down the page is some documentation regarding Linux, including a mention of lcdproc. This might be enough to get you started. If you want to download and compile the drivers you can read about how to do it here: http://lcdproc.sourceforge.net/docs/stable-0-5-x-user.html#installation but you might not have to, as this note explains: "Note If you have installed the Debian package with apt-get (or another Debian package management tool), you can skip this this chapter." Basically, this means you should be able to use Synaptic in Ubuntu, or apt-get from the command line to get and install the package "lcdproc". However, it is possible that the support for the m200 is too new, and is not yet present in the pre-packaged version, so you may have to compile the latest version from CVS anyway. After installing the package (by whatever means) you will need to configure the software. This is explained in chapter 4: http://lcdproc.sourceforge.net/docs/stable-0-5-x-user.html#configuration Congratulations on choosing Linux. Many people complain that "Linux is hard", but if you weren't familiar with Windows then Windows would be hard too. I am sure you will be able to get lcdproc going with the m200, especially with some helpful and supportive advice. In summary: * The easiest way to get software for Linux is via the package manager (Synaptic or apt-get) * The packaged version of lcdproc might not be new enough to support the m200 * If this is the case, download the source from CVS and follow the instructions for compilation, installation and configuration If you have specific problems with any of these stages, please ask again! Best wishes, Andrew PS List admin, why is reply-to set to originator and not the list? From e_swallie@hotmail.com Fri Jul 4 07:36:01 2008 From: e_swallie@hotmail.com (Eric) Date: Fri Jul 4 07:36:01 2008 Subject: [Lcdproc] Re: picolcd References: <36472.211.8.77.2.1215129653.squirrel@webmail02.lancs.ac.uk> Message-ID: i have read many posts like the ones you mention and i have read other posts on this site as well. however i have tried to do what they tell me, and i can't get it working. i do not know eneugh about linux to know if i have installed all the bits correctly, and i do not know if i have even compiled the items correctly in the first place. when i say i know nothing about linux, i am not exagerating. this is my first attemp at using linux, and so far i have had no luck getting any of the things i have tried to work. basically i need somone who has done this before, or somone who is willing to try to lead me step by step through the process and see what is going on. From nombrandue@tsukinokage.net Mon Jul 7 23:34:01 2008 From: nombrandue@tsukinokage.net (Seann Clark) Date: Mon Jul 7 23:34:01 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 Message-ID: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C8E05F.DAF51970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, This is my first post to the list, but I am having a little problem with my (new) LCDproc install base. Here is the stat info: LCD: Matrix Orbital GLK19264-7T-1U Serial Graphical LCD O/S: Fedora 9 x86_64 Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core I just downloaded and configured a test of the software on this system to test the LCD out and after getting the configs file correctly set up for the system I get an error as follows: Could not open driver module server/drivers/glk.so: server/drivers/glk.so: undefined symbol: lib_adv_bignum Driver [glk] binding failed Could not load driver glk There is no output driver Critical error while initializing, abort. Config file (cut for the sake of Sanity): ## Server section with all kinds of settings for the LCDd server ## [server] Driver=glk # Tells the driver to bind to the given interface Bind=127.0.0.1 # Listen on this specified port; defaults to 13666. Port=13666 # Sets the reporting level; defaults to 2 (warnings and errors only). ReportLevel=2 # Should we report to syslog instead of stderr ? Default: no ReportToSyslog=yes # Sets the default time in seconds to displays a screen. WaitTime=30 # User to run as. LCDd will drop its root priviledges, # if any, and run as this user instead. User=nobody ServerScreen=no Foreground=no DriverPath=/usr/local/lib/lcdproc/ ToggleRotateKey=Enter PrevScreenKey=Left NextScreenKey=Right ScrollUpKey=Up ScrollDownKey=Down ScrollDownKey=Down [Input] FreePauseKey=yes FreeBackKey=yes FreeForwardKey=yes FreeMainMenuKey=yes [menu] MenuKey=Escape EnterKey=Enter UpKey=Up DownKey=Down LeftKey=Left RightKey=Right ## Matrix Orbital GLK driver ## [glk] # select the serial device to use [default: /dev/lcd] Device=/dev/ttyS0 # set the initial contrast value [default: 560; legal: 0 - 1000] Contrast=560 # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] Speed=19200 Regards and thanks in advance, Seann ------=_NextPart_000_0042_01C8E05F.DAF51970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

         =    This is my first post to the list, but I am having a little problem with my (new) LCDproc install base. Here is the = stat info:

LCD:

Matrix Orbital GLK19264-7T-1U Serial Graphical = LCD

O/S: Fedora 9 x86_64

Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad = core

 

I just downloaded and configured a test of the = software on this system to test the LCD out and after getting the configs file = correctly set up for the system I get an error as follows:

 

Could not open driver module server/drivers/glk.so: server/drivers/glk.so: undefined symbol: = lib_adv_bignum

Driver [glk] binding failed

Could not load driver glk

There is no output driver

Critical error while initializing, = abort.

 

 

 

Config file (cut for the sake of = Sanity):

 

## Server section with all kinds of settings for the = LCDd server ##

[server]

Driver=3Dglk

# Tells the driver to bind to the given = interface

Bind=3D127.0.0.1

# Listen on this specified port; defaults to = 13666.

Port=3D13666

# Sets the reporting level; defaults to 2 (warnings = and errors only).

ReportLevel=3D2

# Should we report to syslog instead of stderr ? = Default: no

ReportToSyslog=3Dyes

# Sets the default time in seconds to displays a = screen.

WaitTime=3D30

# User to run as.  LCDd will drop its root = priviledges,

# if any, and run as this user = instead.

User=3Dnobody

ServerScreen=3Dno

Foreground=3Dno

DriverPath=3D/usr/local/lib/lcdproc/

=

ToggleRotateKey=3DEnter

PrevScreenKey=3DLeft

NextScreenKey=3DRight

ScrollUpKey=3DUp

ScrollDownKey=3DDown

ScrollDownKey=3DDown

 [Input]

FreePauseKey=3Dyes

FreeBackKey=3Dyes

FreeForwardKey=3Dyes

FreeMainMenuKey=3Dyes

 [menu]

MenuKey=3DEscape

EnterKey=3DEnter

UpKey=3DUp

DownKey=3DDown

LeftKey=3DLeft

RightKey=3DRight

## Matrix Orbital GLK driver ##

[glk]

# select the serial device to use [default: = /dev/lcd]

Device=3D/dev/ttyS0

# set the initial contrast value [default: 560; = legal: 0 - 1000]

Contrast=3D560

# set the serial port speed [default: 19200; legal: = 9600, 19200, 38400]

Speed=3D19200

 

 

Regards and thanks in advance,

Seann

 

------=_NextPart_000_0042_01C8E05F.DAF51970-- From herdler@gmx.de Tue Jul 8 00:09:02 2008 From: herdler@gmx.de (Stefan Herdler) Date: Tue Jul 8 00:09:02 2008 Subject: [Lcdproc] SerialVFD support for BA63/BA66 VFD Message-ID: <4872AFDD.2080400@gmx.de> This is a multi-part message in MIME format. --------------080208040508050604080102 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, attached patch enables the serialVFD-driver to drive the BA63 and BA66 POS-displays made by Siemens / Wincor Nixdorf too. Note: This displays have no brightness-control and user-characters. The hardware doesn't support that. have fun Stefan --------------080208040508050604080102 Content-Type: text/x-diff; name="ba6_3_doc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ba6_3_doc.diff" diff -r -u -p ./lcdproc/docs/lcdproc-user/drivers/serialVFD.docbook ./lcdproc_ba6x/docs/lcdproc-user/drivers/serialVFD.docbook --- ./lcdproc/docs/lcdproc-user/drivers/serialVFD.docbook 2008-05-02 17:48:18.000000000 +0200 +++ ./lcdproc_ba6x/docs/lcdproc-user/drivers/serialVFD.docbook 2008-06-15 23:48:26.000000000 +0200 @@ -64,7 +64,7 @@ Feedback is welcome. KD Rev 2.1 AT90S.... microcontroller Ok - Ok + - Yes 1, 0 @@ -166,6 +166,16 @@ Feedback is welcome. 5 + + Siemens/Wincor Nixdorf BA63/66 + ? + Ok + - + Yes + 8 + Display needs different connection, see below! + no Custom-Characters, no brightness-control + @@ -319,6 +329,19 @@ Pin 19 ------ RxD ]]> + +Siemens/Wincor Nixdorf BA63/66: +This display doesn't need the inverter! +It must be connected directly with the serial port. + +Check the serial port setup of the display, it has to be "9600 8N1". In most cases JP3 needs to be modified (closed) by the user! + + + +More detailed information can be found in the users manual of +the display. + @@ -530,6 +553,10 @@ Number of Custom-Characters [default: Di 7 Samsung 20S207DA? + + 8 + Siemens/Wincor Nixdorf BA63/66 + diff -r -u -p ./lcdproc/LCDd.conf ./lcdproc_ba6x/LCDd.conf --- ./lcdproc/LCDd.conf 2008-05-09 11:28:18.000000000 +0200 +++ ./lcdproc_ba6x/LCDd.conf 2008-06-16 01:19:34.000000000 +0200 @@ -867,6 +867,7 @@ Speed=9600 # 5 IEE S03601-96-080 (*) # 6 Futaba NA202SD08FA (allmost IEE compatible) # 7 Samsung 20S207DA4 and 20S207DA6 +# 8 Nixdorf BA6x / VT100 # (* most should work, not testet yet.) Type=0 diff -r -u -p ./lcdproc/server/drivers/serialVFD.c ./lcdproc_ba6x/server/drivers/serialVFD.c --- ./lcdproc/server/drivers/serialVFD.c 2008-05-02 17:48:18.000000000 +0200 +++ ./lcdproc_ba6x/server/drivers/serialVFD.c 2008-06-04 21:28:19.000000000 +0200 @@ -91,6 +91,7 @@ get_info Implemented. #define init_cmds 7 //commands needed to initialize the display. #define set_user_char 8 //set user character. #define hor_tab 9 //moves cursor 1 chr right +#define next_line 10 //moves cursor to the first character of the next line (= LF + CR) #define LPTPORT 0x378 /* Vars for the server core */ @@ -103,6 +104,7 @@ MODULE_EXPORT char *symbol_prefix = "ser static void serialVFD_init_vbar (Driver *drvthis); static void serialVFD_init_hbar (Driver *drvthis); static void serialVFD_put_char (Driver *drvthis, int n); +static void serialVFD_hw_write (Driver *drvthis, int i); // Opens com port and sets baud correctly... // @@ -129,6 +131,7 @@ serialVFD_init (Driver *drvthis) p->refresh_timer = 480; p->hw_brightness = 0; p->para_wait = DEFAULT_PARA_WAIT; + p->hw_cmd[next_line][0] = 0; debug(RPT_INFO, "%s(%p)", __FUNCTION__, drvthis); @@ -403,7 +406,7 @@ serialVFD_set_char (Driver *drvthis, int static void serialVFD_put_char (Driver *drvthis, int n) -{ // put char in display +{ // put userchar in display PrivateData *p = drvthis->private_data; Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[set_user_char][1],\ @@ -413,7 +416,6 @@ serialVFD_put_char (Driver *drvthis, int } - ///////////////////////////////////////////////////////////// // Blasts a single frame onscreen, to the lcd... // @@ -438,7 +440,7 @@ serialVFD_flush (Driver *drvthis) } if (p->refresh_timer > 500) { // Do a full refresh every 500 refreshs. - // With this it is possible to switch display on and off while lcdproc is running + // With this it is possible to switch the display on and off while LCDd is running Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[init_cmds][1],p->hw_cmd[init_cmds][0]); Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[p->hw_brightness][1],\ @@ -453,73 +455,107 @@ serialVFD_flush (Driver *drvthis) p->refresh_timer++; - if (p->display_type != 1) { //not KD Rev 2.1 + if (p->display_type == 1) { // KD Rev 2.1 only + if (custom_char_changed[p->last_custom]) + p->last_custom = -10; + } + else { // other Displays for (i = 0; i < p->customchars; i++) // set customcharacters if (custom_char_changed[i]) serialVFD_put_char(drvthis, i); - } + } - if (custom_char_changed[p->last_custom]) - p->last_custom = -10; - if (p->hw_cmd[mv_cursor][0] == 0) { // Workaround for Displays that doesn't support mv_cursor command - Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[pos1_cursor][1], p->hw_cmd[pos1_cursor][0]); - last_chr = -1; - } - - for (i = 0; i < (p->height * p->width); i++) { - - /* Backing-store implementation. If it's already - * on the screen, don't put it there again - */ - - if ((p->framebuf[i] != p->backingstore[i]) || - ((p->framebuf[i] <= 30) && (custom_char_changed[(int)p->framebuf[i]] != 0))) { - if (last_chr < i-1) { // if not last char written cursor has to be moved. - if (((p->hw_cmd[hor_tab][0] * (i-1-last_chr)) > (p->hw_cmd[mv_cursor][0]+1)) && (p->hw_cmd[mv_cursor][0] != 0)) { - Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[mv_cursor][1], - p->hw_cmd[mv_cursor][0]); - Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *) &i, 1); -//report(RPT_WARNING, "%s: move %d", drvthis->name, i); - } - else { - for (j = last_chr; j < (i-1); j++) - Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[hor_tab][1], p->hw_cmd[hor_tab][0]); -//report(RPT_WARNING, "%s: TAB %d", drvthis->name, j-last_chr); - } - } - - if (p->framebuf[i] <= 30) { // custom character - if (p->display_type == 1) { // KD Rev 2.1 only - if (p->last_custom != p->framebuf[i]) { - // substitute and select character to overwrite (237) - Port_Function[p->use_parallel].write_fkt(drvthis, "\x1A\xDB", 2); - // overwrite selected character - Port_Function[p->use_parallel].write_fkt(drvthis, &p->custom_char[(int)p->framebuf[i]][0], 7); + if (p->hw_cmd[next_line][0] == 0) { // normal mode Display + if (p->hw_cmd[mv_cursor][0] == 0) { // Workaround for Displays that doesn't support mv_cursor command + Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[pos1_cursor][1], p->hw_cmd[pos1_cursor][0]); + last_chr = -1; + } + + for (i = 0; i < (p->height * p->width); i++) { + + /* Backing-store implementation. If it's already + * on the screen, don't put it there again + */ + + if ((p->framebuf[i] != p->backingstore[i]) || (p->hw_cmd[hor_tab][0] == 0) || + ((p->framebuf[i] <= 30) && (custom_char_changed[(int)p->framebuf[i]] != 0))) { + if (last_chr < i-1) { // if not last char written cursor has to be moved. + if (((p->hw_cmd[hor_tab][0] * (i-1-last_chr)) > (p->hw_cmd[mv_cursor][0]+1)) && (p->hw_cmd[mv_cursor][0] != 0)) { + Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[mv_cursor][1], + p->hw_cmd[mv_cursor][0]); + Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *) &i, 1); + //report(RPT_WARNING, "%s: move %d", drvthis->name, i); + } + else { + for (j = last_chr; j < (i-1); j++) + Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[hor_tab][1], p->hw_cmd[hor_tab][0]); + //report(RPT_WARNING, "%s: TAB %d", drvthis->name, j-last_chr); } - Port_Function[p->use_parallel].write_fkt(drvthis, "\xDB", 1); // write character - p->last_custom = p->framebuf[i]; - } - else { // all other displays - Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *) &p->usr_chr_mapping[(int)p->framebuf[i]], 1); } + serialVFD_hw_write(drvthis, i); + last_chr = i; } - else if ((p->framebuf[i] == 127) || ((p->framebuf[i] > 127) && (p->ISO_8859_1 != 0))) { // ISO_8859_1 translation for 129 ... 255 - Port_Function[p->use_parallel].write_fkt(drvthis, &p->charmap[p->framebuf[i] - 127], 1); + } + } + + else { // line mode Display (partitially borrowed from serialPOS.c) + for (j = 0; j < p->height; j++) { + // set pointers to start of the line in frame buffer & backing store + unsigned char *sp = p->framebuf + (j * p->width); + unsigned char *sq = p->backingstore + (j * p->width); + if (j == 0) { + Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[pos1_cursor][1], p->hw_cmd[pos1_cursor][0]); } else { - Port_Function[p->use_parallel].write_fkt(drvthis, &p->framebuf[i], 1); + Port_Function[p->use_parallel].write_fkt(drvthis, &p->hw_cmd[next_line][1], p->hw_cmd[next_line][0]); } - - last_chr = i; + // skip over identical lines + if ( memcmp(sp, sq, p->width) == 0) { + /* The lines are the same. */ + continue; + } + for (i = 0; i < p->width; i++) { + serialVFD_hw_write(drvthis, (i + (j * p->width))); + } + last_chr = 10; } } if (last_chr >= 0) { // update backingstore if something changed memcpy(p->backingstore, p->framebuf, p->height * p->width); -//report(RPT_WARNING, "%s: memcpy", drvthis->name); + //report(RPT_WARNING, "%s: memcpy", drvthis->name); } + +} + +static void +serialVFD_hw_write (Driver *drvthis, int i) +{ // finally write character/usercharacter on the display + PrivateData *p = drvthis->private_data; + + if (p->framebuf[i] <= 30) { // custom character + if (p->display_type == 1) { // KD Rev 2.1 only + if (p->last_custom != p->framebuf[i]) { + // substitute and select character to overwrite (237) + Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *)"\x1A\xDB", 2); + // overwrite selected character + Port_Function[p->use_parallel].write_fkt(drvthis, &p->custom_char[(int)p->framebuf[i]][0], 7); + } + Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *)"\xDB", 1); // write character + p->last_custom = p->framebuf[i]; + } + else { // all other displays + Port_Function[p->use_parallel].write_fkt(drvthis, (unsigned char *) &p->usr_chr_mapping[(int)p->framebuf[i]], 1); + } + } + else if ((p->framebuf[i] == 127) || ((p->framebuf[i] > 127) && (p->ISO_8859_1 != 0))) { // ISO_8859_1 translation for 129 ... 255 + Port_Function[p->use_parallel].write_fkt(drvthis, &p->charmap[p->framebuf[i] - 127], 1); + } + else { + Port_Function[p->use_parallel].write_fkt(drvthis, &p->framebuf[i], 1); + } } diff -r -u -p ./lcdproc/server/drivers/serialVFD_displays.c ./lcdproc_ba6x/server/drivers/serialVFD_displays.c --- ./lcdproc/server/drivers/serialVFD_displays.c 2008-05-02 17:48:18.000000000 +0200 +++ ./lcdproc_ba6x/server/drivers/serialVFD_displays.c 2008-06-05 00:03:15.000000000 +0200 @@ -40,7 +40,7 @@ void serialVFD_load_IEE_95B (Driver *drv void serialVFD_load_IEE_96 (Driver *drvthis); void serialVFD_load_Futaba_NA202SD08FA(Driver *drvthis); void serialVFD_load_Samsung (Driver *drvthis); - +void serialVFD_load_Nixdorf_BA6x (Driver *drvthis); int serialVFD_load_display_data(Driver *drvthis) { @@ -70,6 +70,9 @@ int serialVFD_load_display_data(Driver * case 7: serialVFD_load_Samsung(drvthis); break; + case 8: + serialVFD_load_Nixdorf_BA6x(drvthis); + break; default: return -1; break; @@ -95,17 +98,22 @@ serialVFD_load_NEC_FIPC (Driver *drvthis // hw_cmd[Command][data] = {{commandlength , command 1}, // ..... // {commandlength , command N}} - const char hw_cmd[10][4] = {{1 ,0x04}, // dark + const char hw_cmd[11][4] = {{1 ,0x04}, // dark {1 ,0x03}, {1 ,0x02}, {1 ,0x01}, // bright - {1 ,0x0D}, // pos1 + {1 ,0x0D}, // pos1 + // pos1 command is only used (and needed), when mv_cursor command is not supported {1 ,0x1B}, // move cursor (set to 0 if not supported) {1 ,0x0C}, // reset {2 ,0x14, 0x11}, // init {1 ,0x1A}, // set user char - {1 ,0x09}}; // tab - for (tmp = 0; tmp < 10; tmp++) + {1 ,0x09}, // tab + {0 }}; // next_line (only used in line mode) + // Line mode will be used if Next_line command is set!!! + // Do not set if the display supports normal mode (most displays should do this). + + for (tmp = 0; tmp < 11; tmp++) for (w = 0; w < 4; w++) p->hw_cmd[tmp][w] = hw_cmd[tmp][w]; @@ -154,6 +162,15 @@ serialVFD_load_NEC_FIPC (Driver *drvthis {0xAF,0,0,0,0,0, 0x5F, 0xE0, 0xE1, 0xE2, 0xE3, 0xE4, 0, 0x5F, 0xE1, 0xE3, 0xE4}; for (tmp = 0; tmp < 31; tmp++) p->usr_chr_mapping[tmp] = usr_chr_mapping[tmp]; + + // The following is only needet to set if the display needs a different setting + // for loading the usercharacters. + // Example: The character loaded to 0x00 will be shown at 0xFD. + // usr_chr_load_mapping[0] or usr_chr_load_mapping[1] has to be != 0 + //const unsigned int usr_chr_load_mapping[31]= + //{ 0x02, 0x01, 0x00}; + //for (tmp = 0; tmp < 31; tmp++) + // p->usr_chr_load_mapping[tmp] = usr_chr_load_mapping[tmp]; } @@ -697,3 +714,76 @@ serialVFD_load_Samsung (Driver *drvthis) for (tmp = 0; tmp < 31; tmp++) p->usr_chr_mapping[tmp] = usr_chr_mapping[tmp]; } + +void +serialVFD_load_Nixdorf_BA6x (Driver *drvthis) +{ // Nixdorf BA63 & BA66 + PrivateData *p = (PrivateData*) drvthis->private_data; + int tmp, w; + + //if (p->customchars == -83) // display doesn't support custom characters + p->customchars = 0; // number of custom characters the display provides + p->vbar_cc_offset = 5; // character offset of the bars + p->hbar_cc_offset = 12; // character offset of the bars + p->predefined_hbar = 1; // the display has predefined hbar-characters + p->predefined_vbar = 1; // the display has predefined vbar-characters + + // hardwarespecific commands: + // hw_cmd[Command][data] = {{commandlength , command 1}, + // ..... + // {commandlength , command N}} + const char hw_cmd[11][10] = {{0 }, // dark + {0 }, + {0 }, + {0 }, // bright + {6 ,0x1B, 0x5B, '1', 0x3B, '1', 0x48}, // pos1 + // pos1 command is only used (and needed), when mv_cursor command is not supported + {0 }, // move cursor + {4 ,0x1B, 0x5B, 0x32, 0x4A}, // reset + {3 ,0x1B, 0x52, 0x00}, // init + {0 }, // set user char + {0 }, // tab + {2 ,0x0D, 0x0A} // next_line + // Next_line command is only used in line mode. + // Line mode will be used if Next_line command is set!!! + // Set to "0" if display supports normal_mode! + }; + for (tmp = 0; tmp < 11; tmp++) + for (w = 0; w < 10; w++) + p->hw_cmd[tmp][w] = hw_cmd[tmp][w]; + + // Translates ISO 8859-1 to display charset. + const unsigned char charmap[] = { + 0xDB, // the "filled-block"-character usually 127 + /* #128 = 0x80 */ + 128, 129, 130, 131, 132, 133, 134, 135, + 136, 137, 138, 139, 140, 141, 142, 143, + 144, 145, 146, 147, 148, 149, 150, 151, + 152, 153, 154, 155, 156, 157, 158, 159, + /* #160 = 0xA0 */ + 160, 0xAD, 0x9B, 0x9C, 0xC8, 0x9D, 0x7C, 0xC0, + '"', '?', 0xA6, 0xAE, 0xAA, '-', '?', '?', + 0xEF, 0xCA, 0xC6, 0xC7, 0x27, 0xB8, '?', '.', + ',', '?', 0xA7, 0xAF, 0xAC, 0xAB, '?', 0xA8, + /* #192 = 0xC0 */ + 0xD0, 'A', 0xD5, 'A', 0x8E, 0x8F, 0x92, 0x80, + 0xD1, 0x90, 0xD6, 0xD3, 'I', 'I', 0xD7, 0xD4, + 'D', 0xA5, 'O', 'O', 0xD8, 'O', 0x99, 'x', + '0', 0xD2, 'U', 0xD9, 0x9A, 'Y', 'p', 0xB1, + /* #224 = 0xE0 */ + 0x85, 0xA0, 0x83, 'a', 0x84, 0x86, 0x91, 0x87, + 0x8A, 0x82, 0x88, 0x89, 0x8D, 0xA1, 0x8C, 0x8B, + 'o', 0xA4, 0x95, 0xA9, 0x93, 'o', 0x94, '/', + '0', 0x97, 0xA3, 0x96, 0x81, 'y', 'p', 0x89 }; + for (tmp = 0; tmp < 129; tmp++) + p->charmap[tmp] = charmap[tmp]; + + + // Where to place the usercharacters (0..30) in the asciicode. + // Also used to map standardcharacters in the usercharacterspace(0..30) + // (useful for displays with less then 30 usercharacters and predefined bars) + const unsigned int usr_chr_mapping[31]= + {0,0,0,0,0,0, ' ', ' ', 0xDC, 0xDC, 0xDC, 0xDB, 0, ' ', 0xDD, 0xDD, 0xDB}; + for (tmp = 0; tmp < 31; tmp++) + p->usr_chr_mapping[tmp] = usr_chr_mapping[tmp]; +} diff -r -u -p ./lcdproc/server/drivers/serialVFD.h ./lcdproc_ba6x/server/drivers/serialVFD.h --- ./lcdproc/server/drivers/serialVFD.h 2008-05-02 17:48:18.000000000 +0200 +++ ./lcdproc_ba6x/server/drivers/serialVFD.h 2008-06-04 18:48:59.000000000 +0200 @@ -100,7 +100,7 @@ typedef struct driver_private_data { int last_custom; // last custom character written unsigned char custom_char[31][7]; // stored custom characters unsigned char custom_char_store[31][7]; // custom characters backingstore - unsigned char hw_cmd[10][4]; // hardwarespecific commands + unsigned char hw_cmd[11][10]; // hardwarespecific commands int usr_chr_dot_assignment[57]; // how to setup usercharacters unsigned int usr_chr_mapping[31];// where to place the usercharacters (0..30) in the asciicode unsigned int usr_chr_load_mapping[31];// needed for displays with different read and write mapping diff -r -u -p ./lcdproc/server/drivers/serialVFD_io.c ./lcdproc_ba6x/server/drivers/serialVFD_io.c --- ./lcdproc/server/drivers/serialVFD_io.c 2008-05-02 17:48:18.000000000 +0200 +++ ./lcdproc_ba6x/server/drivers/serialVFD_io.c 2008-06-04 19:59:30.000000000 +0200 @@ -44,6 +44,9 @@ void serialVFD_write_serial (Driver *drvthis, unsigned char *dat, size_t length) { + if (length <= 0) + return; + PrivateData *p = drvthis->private_data; write(p->fd,dat,length); } @@ -51,6 +54,9 @@ serialVFD_write_serial (Driver *drvthis, void serialVFD_write_parallel (Driver *drvthis, unsigned char *dat, size_t length) { + if (length <= 0) + return; + #ifdef HAVE_PCSTYLE_LPT_CONTROL PrivateData *p = drvthis->private_data; int i_para, j_para; --------------080208040508050604080102-- From rmolenkamp@matrixorbital.ca Tue Jul 8 00:39:02 2008 From: rmolenkamp@matrixorbital.ca (Ray Molenkamp) Date: Tue Jul 8 00:39:02 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 In-Reply-To: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> References: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> Message-ID: <4872B71F.6080205@matrixorbital.ca> There seems to be a line missing from server/drivers/Makefile.am if you add the following line to it glk_LDADD = libLCD.a libbignum.a and rerun the autogen.sh script you should be all good. --Ray tSeann Clark wrote: > > All, > > > > This is my first post to the list, but I am having a > little problem with my (new) LCDproc install base. Here is the stat info: > > LCD: > > Matrix Orbital GLK19264-7T-1U Serial Graphical LCD > > O/S: Fedora 9 x86_64 > > Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core > > > > I just downloaded and configured a test of the software on this system > to test the LCD out and after getting the configs file correctly set > up for the system I get an error as follows: > > > > Could not open driver module server/drivers/glk.so: > server/drivers/glk.so: undefined symbol: lib_adv_bignum > > Driver [glk] binding failed > > Could not load driver glk > > There is no output driver > > Critical error while initializing, abort. > > > > > > > > Config file (cut for the sake of Sanity): > > > > ## Server section with all kinds of settings for the LCDd server ## > > [server] > > Driver=glk > > # Tells the driver to bind to the given interface > > Bind=127.0.0.1 > > # Listen on this specified port; defaults to 13666. > > Port=13666 > > # Sets the reporting level; defaults to 2 (warnings and errors only). > > ReportLevel=2 > > # Should we report to syslog instead of stderr ? Default: no > > ReportToSyslog=yes > > # Sets the default time in seconds to displays a screen. > > WaitTime=30 > > # User to run as. LCDd will drop its root priviledges, > > # if any, and run as this user instead. > > User=nobody > > ServerScreen=no > > Foreground=no > > DriverPath=/usr/local/lib/lcdproc/ > > ToggleRotateKey=Enter > > PrevScreenKey=Left > > NextScreenKey=Right > > ScrollUpKey=Up > > ScrollDownKey=Down > > ScrollDownKey=Down > > [Input] > > FreePauseKey=yes > > FreeBackKey=yes > > FreeForwardKey=yes > > FreeMainMenuKey=yes > > [menu] > > MenuKey=Escape > > EnterKey=Enter > > UpKey=Up > > DownKey=Down > > LeftKey=Left > > RightKey=Right > > ## Matrix Orbital GLK driver ## > > [glk] > > # select the serial device to use [default: /dev/lcd] > > Device=/dev/ttyS0 > > # set the initial contrast value [default: 560; legal: 0 - 1000] > > Contrast=560 > > # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] > > Speed=19200 > > > > > > Regards and thanks in advance, > > Seann > > > From nombrandue@tsukinokage.net Tue Jul 8 01:22:01 2008 From: nombrandue@tsukinokage.net (Seann Clark) Date: Tue Jul 8 01:22:01 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 In-Reply-To: <4872B71F.6080205@matrixorbital.ca> References: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> <4872B71F.6080205@matrixorbital.ca> Message-ID: Ray, I just spent about 45 minutes fighting with this for that rather easy looking change. No matter what I do, from a complete removal of the software, deleted the src directory, unpacked the downloaded source again, made the changes, recompiled, reinstalled, and got this in the syslog: Jul 7 19:54:50 haruhi-new LCDd: Could not open driver module /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined symbol: lib_adv_bignum Jul 7 19:54:50 haruhi-new LCDd: Driver [glk] binding failed Jul 7 19:54:50 haruhi-new LCDd: Could not load driver glk Jul 7 19:54:50 haruhi-new LCDd: There is no output driver Jul 7 19:54:50 haruhi-new LCDd: Critical error while initializing, abort. Jul 7 19:56:45 haruhi-new LCDd: Could not open driver module /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined symbol: lib_adv_bignum Jul 7 19:56:45 haruhi-new LCDd: Driver [glk] binding failed Jul 7 19:56:45 haruhi-new LCDd: Could not load driver glk Jul 7 19:56:45 haruhi-new LCDd: There is no output driver Jul 7 19:56:45 haruhi-new LCDd: Critical error while initializing, abort. Sadly enough, as a lark it looks like the Fedora 9 x86_64 package has the same issue (Prob the SAME exact problem) -----Original Message----- From: lcdproc-admin@lists.omnipotent.net [mailto:lcdproc-admin@lists.omnipotent.net] On Behalf Of Ray Molenkamp Sent: Monday, July 07, 2008 7:39 PM To: Seann Clark Cc: lcdproc@lists.omnipotent.net Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 There seems to be a line missing from server/drivers/Makefile.am if you add the following line to it glk_LDADD = libLCD.a libbignum.a and rerun the autogen.sh script you should be all good. --Ray tSeann Clark wrote: > > All, > > > > This is my first post to the list, but I am having a > little problem with my (new) LCDproc install base. Here is the stat info: > > LCD: > > Matrix Orbital GLK19264-7T-1U Serial Graphical LCD > > O/S: Fedora 9 x86_64 > > Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core > > > > I just downloaded and configured a test of the software on this system > to test the LCD out and after getting the configs file correctly set > up for the system I get an error as follows: > > > > Could not open driver module server/drivers/glk.so: > server/drivers/glk.so: undefined symbol: lib_adv_bignum > > Driver [glk] binding failed > > Could not load driver glk > > There is no output driver > > Critical error while initializing, abort. > > > > > > > > Config file (cut for the sake of Sanity): > > > > ## Server section with all kinds of settings for the LCDd server ## > > [server] > > Driver=glk > > # Tells the driver to bind to the given interface > > Bind=127.0.0.1 > > # Listen on this specified port; defaults to 13666. > > Port=13666 > > # Sets the reporting level; defaults to 2 (warnings and errors only). > > ReportLevel=2 > > # Should we report to syslog instead of stderr ? Default: no > > ReportToSyslog=yes > > # Sets the default time in seconds to displays a screen. > > WaitTime=30 > > # User to run as. LCDd will drop its root priviledges, > > # if any, and run as this user instead. > > User=nobody > > ServerScreen=no > > Foreground=no > > DriverPath=/usr/local/lib/lcdproc/ > > ToggleRotateKey=Enter > > PrevScreenKey=Left > > NextScreenKey=Right > > ScrollUpKey=Up > > ScrollDownKey=Down > > ScrollDownKey=Down > > [Input] > > FreePauseKey=yes > > FreeBackKey=yes > > FreeForwardKey=yes > > FreeMainMenuKey=yes > > [menu] > > MenuKey=Escape > > EnterKey=Enter > > UpKey=Up > > DownKey=Down > > LeftKey=Left > > RightKey=Right > > ## Matrix Orbital GLK driver ## > > [glk] > > # select the serial device to use [default: /dev/lcd] > > Device=/dev/ttyS0 > > # set the initial contrast value [default: 560; legal: 0 - 1000] > > Contrast=560 > > # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] > > Speed=19200 > > > > > > Regards and thanks in advance, > > Seann > > > _______________________________________________ LCDproc mailing list LCDproc@lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc From rmolenkamp@matrixorbital.ca Tue Jul 8 01:38:01 2008 From: rmolenkamp@matrixorbital.ca (Ray Molenkamp) Date: Tue Jul 8 01:38:01 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 In-Reply-To: References: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> <4872B71F.6080205@matrixorbital.ca> Message-ID: <4872C4E4.2020902@matrixorbital.ca> Humzz I tested with a recent copy from cvs. I can recommend a cvs snapshot over the latest official release. See the sourceforge page on instructions how to fetch a copy from cvs. 1) edited the server/drivers/Makefile.am Pay attention though cause things are kinda case sensitive. If in doubt copy the MtxOrb_LDADD line and replace MtxOrb with glk. 2) ran auogen.sh 3) ran ./configure --enable-drivers=glk 4) ran make clean 5) ran make After that went into the server folder and ran LCDd from there with pretty much the default LCDd.conf. I'm at home right now so didn't have any GLK to test with so tried fooling into opening /dev/null but the driver was definitely unhappy about that but at least it loaded. I'll verify that it actually works when I get into the office tomorrow morning but about 98% sure it works fine. --Ray Seann Clark wrote: > Ray, > > I just spent about 45 minutes fighting with this for that rather > easy looking change. No matter what I do, from a complete removal of the > software, deleted the src directory, unpacked the downloaded source again, > made the changes, recompiled, reinstalled, and got this in the syslog: > > Jul 7 19:54:50 haruhi-new LCDd: Could not open driver module > /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined > symbol: lib_adv_bignum > Jul 7 19:54:50 haruhi-new LCDd: Driver [glk] binding failed > Jul 7 19:54:50 haruhi-new LCDd: Could not load driver glk > Jul 7 19:54:50 haruhi-new LCDd: There is no output driver > Jul 7 19:54:50 haruhi-new LCDd: Critical error while initializing, abort. > Jul 7 19:56:45 haruhi-new LCDd: Could not open driver module > /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined > symbol: lib_adv_bignum > Jul 7 19:56:45 haruhi-new LCDd: Driver [glk] binding failed > Jul 7 19:56:45 haruhi-new LCDd: Could not load driver glk > Jul 7 19:56:45 haruhi-new LCDd: There is no output driver > Jul 7 19:56:45 haruhi-new LCDd: Critical error while initializing, abort. > > > Sadly enough, as a lark it looks like the Fedora 9 x86_64 package has the > same issue (Prob the SAME exact problem) > > -----Original Message----- > From: lcdproc-admin@lists.omnipotent.net > [mailto:lcdproc-admin@lists.omnipotent.net] On Behalf Of Ray Molenkamp > Sent: Monday, July 07, 2008 7:39 PM > To: Seann Clark > Cc: lcdproc@lists.omnipotent.net > Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 > > There seems to be a line missing from server/drivers/Makefile.am > if you add the following line to it > > glk_LDADD = libLCD.a libbignum.a > > and rerun the autogen.sh script you should be all good. > > --Ray > > tSeann Clark wrote: > >> All, >> >> >> >> This is my first post to the list, but I am having a >> little problem with my (new) LCDproc install base. Here is the stat info: >> >> LCD: >> >> Matrix Orbital GLK19264-7T-1U Serial Graphical LCD >> >> O/S: Fedora 9 x86_64 >> >> Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core >> >> >> >> I just downloaded and configured a test of the software on this system >> to test the LCD out and after getting the configs file correctly set >> up for the system I get an error as follows: >> >> >> >> Could not open driver module server/drivers/glk.so: >> server/drivers/glk.so: undefined symbol: lib_adv_bignum >> >> Driver [glk] binding failed >> >> Could not load driver glk >> >> There is no output driver >> >> Critical error while initializing, abort. >> >> >> >> >> >> >> >> Config file (cut for the sake of Sanity): >> >> >> >> ## Server section with all kinds of settings for the LCDd server ## >> >> [server] >> >> Driver=glk >> >> # Tells the driver to bind to the given interface >> >> Bind=127.0.0.1 >> >> # Listen on this specified port; defaults to 13666. >> >> Port=13666 >> >> # Sets the reporting level; defaults to 2 (warnings and errors only). >> >> ReportLevel=2 >> >> # Should we report to syslog instead of stderr ? Default: no >> >> ReportToSyslog=yes >> >> # Sets the default time in seconds to displays a screen. >> >> WaitTime=30 >> >> # User to run as. LCDd will drop its root priviledges, >> >> # if any, and run as this user instead. >> >> User=nobody >> >> ServerScreen=no >> >> Foreground=no >> >> DriverPath=/usr/local/lib/lcdproc/ >> >> ToggleRotateKey=Enter >> >> PrevScreenKey=Left >> >> NextScreenKey=Right >> >> ScrollUpKey=Up >> >> ScrollDownKey=Down >> >> ScrollDownKey=Down >> >> [Input] >> >> FreePauseKey=yes >> >> FreeBackKey=yes >> >> FreeForwardKey=yes >> >> FreeMainMenuKey=yes >> >> [menu] >> >> MenuKey=Escape >> >> EnterKey=Enter >> >> UpKey=Up >> >> DownKey=Down >> >> LeftKey=Left >> >> RightKey=Right >> >> ## Matrix Orbital GLK driver ## >> >> [glk] >> >> # select the serial device to use [default: /dev/lcd] >> >> Device=/dev/ttyS0 >> >> # set the initial contrast value [default: 560; legal: 0 - 1000] >> >> Contrast=560 >> >> # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] >> >> Speed=19200 >> >> >> >> >> >> Regards and thanks in advance, >> >> Seann >> >> >> >> > _______________________________________________ > LCDproc mailing list > LCDproc@lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From nombrandue@tsukinokage.net Tue Jul 8 02:03:02 2008 From: nombrandue@tsukinokage.net (Seann Clark) Date: Tue Jul 8 02:03:02 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 In-Reply-To: <4872C4E4.2020902@matrixorbital.ca> References: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> <4872B71F.6080205@matrixorbital.ca> <4872C4E4.2020902@matrixorbital.ca> Message-ID: Ok, so I found the autogen.sh and was able to get farther with this. Now I get this error in Syslog: Jul 7 20:57:20 haruhi-new LCDd: glk: unrecognized module type: 0x2A Jul 7 20:57:20 haruhi-new LCDd: Driver [glk] init failed, return code < 0 Jul 7 20:57:20 haruhi-new LCDd: Could not load driver glk Jul 7 20:57:20 haruhi-new LCDd: There is no output driver Jul 7 20:57:20 haruhi-new LCDd: Critical error while initializing, abort. It is different so that is good, I just have no clue what that hex points to. I was careful and made sure that the MtxOrb_LDADD was identical to the glk_LDADD so I think I am a bit farther with this. Any suggestions on this? I will look on my side to my limited knowledge of the stuff in the code. Regards, Seann -----Original Message----- From: Ray Molenkamp [mailto:rmolenkamp@matrixorbital.ca] Sent: Monday, July 07, 2008 8:38 PM To: Seann Clark Cc: lcdproc@lists.omnipotent.net Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 Humzz I tested with a recent copy from cvs. I can recommend a cvs snapshot over the latest official release. See the sourceforge page on instructions how to fetch a copy from cvs. 1) edited the server/drivers/Makefile.am Pay attention though cause things are kinda case sensitive. If in doubt copy the MtxOrb_LDADD line and replace MtxOrb with glk. 2) ran auogen.sh 3) ran ./configure --enable-drivers=glk 4) ran make clean 5) ran make After that went into the server folder and ran LCDd from there with pretty much the default LCDd.conf. I'm at home right now so didn't have any GLK to test with so tried fooling into opening /dev/null but the driver was definitely unhappy about that but at least it loaded. I'll verify that it actually works when I get into the office tomorrow morning but about 98% sure it works fine. --Ray Seann Clark wrote: > Ray, > > I just spent about 45 minutes fighting with this for that rather > easy looking change. No matter what I do, from a complete removal of the > software, deleted the src directory, unpacked the downloaded source again, > made the changes, recompiled, reinstalled, and got this in the syslog: > > Jul 7 19:54:50 haruhi-new LCDd: Could not open driver module > /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined > symbol: lib_adv_bignum > Jul 7 19:54:50 haruhi-new LCDd: Driver [glk] binding failed > Jul 7 19:54:50 haruhi-new LCDd: Could not load driver glk > Jul 7 19:54:50 haruhi-new LCDd: There is no output driver > Jul 7 19:54:50 haruhi-new LCDd: Critical error while initializing, abort. > Jul 7 19:56:45 haruhi-new LCDd: Could not open driver module > /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined > symbol: lib_adv_bignum > Jul 7 19:56:45 haruhi-new LCDd: Driver [glk] binding failed > Jul 7 19:56:45 haruhi-new LCDd: Could not load driver glk > Jul 7 19:56:45 haruhi-new LCDd: There is no output driver > Jul 7 19:56:45 haruhi-new LCDd: Critical error while initializing, abort. > > > Sadly enough, as a lark it looks like the Fedora 9 x86_64 package has the > same issue (Prob the SAME exact problem) > > -----Original Message----- > From: lcdproc-admin@lists.omnipotent.net > [mailto:lcdproc-admin@lists.omnipotent.net] On Behalf Of Ray Molenkamp > Sent: Monday, July 07, 2008 7:39 PM > To: Seann Clark > Cc: lcdproc@lists.omnipotent.net > Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 > > There seems to be a line missing from server/drivers/Makefile.am > if you add the following line to it > > glk_LDADD = libLCD.a libbignum.a > > and rerun the autogen.sh script you should be all good. > > --Ray > > tSeann Clark wrote: > >> All, >> >> >> >> This is my first post to the list, but I am having a >> little problem with my (new) LCDproc install base. Here is the stat info: >> >> LCD: >> >> Matrix Orbital GLK19264-7T-1U Serial Graphical LCD >> >> O/S: Fedora 9 x86_64 >> >> Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core >> >> >> >> I just downloaded and configured a test of the software on this system >> to test the LCD out and after getting the configs file correctly set >> up for the system I get an error as follows: >> >> >> >> Could not open driver module server/drivers/glk.so: >> server/drivers/glk.so: undefined symbol: lib_adv_bignum >> >> Driver [glk] binding failed >> >> Could not load driver glk >> >> There is no output driver >> >> Critical error while initializing, abort. >> >> >> >> >> >> >> >> Config file (cut for the sake of Sanity): >> >> >> >> ## Server section with all kinds of settings for the LCDd server ## >> >> [server] >> >> Driver=glk >> >> # Tells the driver to bind to the given interface >> >> Bind=127.0.0.1 >> >> # Listen on this specified port; defaults to 13666. >> >> Port=13666 >> >> # Sets the reporting level; defaults to 2 (warnings and errors only). >> >> ReportLevel=2 >> >> # Should we report to syslog instead of stderr ? Default: no >> >> ReportToSyslog=yes >> >> # Sets the default time in seconds to displays a screen. >> >> WaitTime=30 >> >> # User to run as. LCDd will drop its root priviledges, >> >> # if any, and run as this user instead. >> >> User=nobody >> >> ServerScreen=no >> >> Foreground=no >> >> DriverPath=/usr/local/lib/lcdproc/ >> >> ToggleRotateKey=Enter >> >> PrevScreenKey=Left >> >> NextScreenKey=Right >> >> ScrollUpKey=Up >> >> ScrollDownKey=Down >> >> ScrollDownKey=Down >> >> [Input] >> >> FreePauseKey=yes >> >> FreeBackKey=yes >> >> FreeForwardKey=yes >> >> FreeMainMenuKey=yes >> >> [menu] >> >> MenuKey=Escape >> >> EnterKey=Enter >> >> UpKey=Up >> >> DownKey=Down >> >> LeftKey=Left >> >> RightKey=Right >> >> ## Matrix Orbital GLK driver ## >> >> [glk] >> >> # select the serial device to use [default: /dev/lcd] >> >> Device=/dev/ttyS0 >> >> # set the initial contrast value [default: 560; legal: 0 - 1000] >> >> Contrast=560 >> >> # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] >> >> Speed=19200 >> >> >> >> >> >> Regards and thanks in advance, >> >> Seann >> >> >> >> > _______________________________________________ > LCDproc mailing list > LCDproc@lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From rmolenkamp@matrixorbital.ca Tue Jul 8 02:09:01 2008 From: rmolenkamp@matrixorbital.ca (Ray Molenkamp) Date: Tue Jul 8 02:09:01 2008 Subject: [Lcdproc] Matrix Orbital on Linux x86_64 In-Reply-To: References: <64D1B69D81484FD5BFC4B674ECCF348A@MARIKO> <4872B71F.6080205@matrixorbital.ca> <4872C4E4.2020902@matrixorbital.ca> Message-ID: <4872CC1D.8010503@matrixorbital.ca> Well the good news the driver is up and running and actually talking to your display. It asked its module type so it knows what size the display is. Since the driver hasn't been touched in years it doens't know about your GLK19264 yet. Shouldn't be too hard to fix , open up glk.c in the drivers folder and add some code to the big switch that lives there. case 0x2a : p->model = "GLK19264"; p->width = 32; p->height = 8; break; recompile and give it another try :) --Ray Seann Clark wrote: > Ok, so I found the autogen.sh and was able to get farther with this. Now I > get this error in Syslog: > > Jul 7 20:57:20 haruhi-new LCDd: glk: unrecognized module type: 0x2A > Jul 7 20:57:20 haruhi-new LCDd: Driver [glk] init failed, return code < 0 > Jul 7 20:57:20 haruhi-new LCDd: Could not load driver glk > Jul 7 20:57:20 haruhi-new LCDd: There is no output driver > Jul 7 20:57:20 haruhi-new LCDd: Critical error while initializing, abort. > > > It is different so that is good, I just have no clue what that hex points > to. I was careful and made sure that the MtxOrb_LDADD was identical to the > glk_LDADD so I think I am a bit farther with this. > > Any suggestions on this? I will look on my side to my limited knowledge of > the stuff in the code. > > Regards, > Seann > > -----Original Message----- > From: Ray Molenkamp [mailto:rmolenkamp@matrixorbital.ca] > Sent: Monday, July 07, 2008 8:38 PM > To: Seann Clark > Cc: lcdproc@lists.omnipotent.net > Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 > > Humzz I tested with a recent copy from cvs. I can > recommend a cvs snapshot over the latest official > release. See the sourceforge page on instructions > how to fetch a copy from cvs. > > 1) edited the server/drivers/Makefile.am > Pay attention though cause things are kinda case > sensitive. If in doubt copy the MtxOrb_LDADD > line and replace MtxOrb with glk. > > 2) ran auogen.sh > > 3) ran ./configure --enable-drivers=glk > > 4) ran make clean > > 5) ran make > > After that went into the server folder and ran LCDd from there > with pretty much the default LCDd.conf. I'm at home right now > so didn't have any GLK to test with so tried fooling into opening > /dev/null but the driver was definitely unhappy about that but > at least it loaded. > > I'll verify that it actually works when I get into the office tomorrow > morning but about 98% sure it works fine. > > --Ray > > Seann Clark wrote: > >> Ray, >> >> I just spent about 45 minutes fighting with this for that rather >> easy looking change. No matter what I do, from a complete removal of the >> software, deleted the src directory, unpacked the downloaded source again, >> made the changes, recompiled, reinstalled, and got this in the syslog: >> >> Jul 7 19:54:50 haruhi-new LCDd: Could not open driver module >> /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined >> symbol: lib_adv_bignum >> Jul 7 19:54:50 haruhi-new LCDd: Driver [glk] binding failed >> Jul 7 19:54:50 haruhi-new LCDd: Could not load driver glk >> Jul 7 19:54:50 haruhi-new LCDd: There is no output driver >> Jul 7 19:54:50 haruhi-new LCDd: Critical error while initializing, abort. >> Jul 7 19:56:45 haruhi-new LCDd: Could not open driver module >> /usr/local/lib/lcdproc/glk.so: /usr/local/lib/lcdproc/glk.so: undefined >> symbol: lib_adv_bignum >> Jul 7 19:56:45 haruhi-new LCDd: Driver [glk] binding failed >> Jul 7 19:56:45 haruhi-new LCDd: Could not load driver glk >> Jul 7 19:56:45 haruhi-new LCDd: There is no output driver >> Jul 7 19:56:45 haruhi-new LCDd: Critical error while initializing, abort. >> >> >> Sadly enough, as a lark it looks like the Fedora 9 x86_64 package has the >> same issue (Prob the SAME exact problem) >> >> -----Original Message----- >> From: lcdproc-admin@lists.omnipotent.net >> [mailto:lcdproc-admin@lists.omnipotent.net] On Behalf Of Ray Molenkamp >> Sent: Monday, July 07, 2008 7:39 PM >> To: Seann Clark >> Cc: lcdproc@lists.omnipotent.net >> Subject: Re: [Lcdproc] Matrix Orbital on Linux x86_64 >> >> There seems to be a line missing from server/drivers/Makefile.am >> if you add the following line to it >> >> glk_LDADD = libLCD.a libbignum.a >> >> and rerun the autogen.sh script you should be all good. >> >> --Ray >> >> tSeann Clark wrote: >> >> >>> All, >>> >>> >>> >>> This is my first post to the list, but I am having a >>> little problem with my (new) LCDproc install base. Here is the stat info: >>> >>> LCD: >>> >>> Matrix Orbital GLK19264-7T-1U Serial Graphical LCD >>> >>> O/S: Fedora 9 x86_64 >>> >>> Hardware: Asus DSBF 4Gigs RAM Dual Xeon Quad core >>> >>> >>> >>> I just downloaded and configured a test of the software on this system >>> to test the LCD out and after getting the configs file correctly set >>> up for the system I get an error as follows: >>> >>> >>> >>> Could not open driver module server/drivers/glk.so: >>> server/drivers/glk.so: undefined symbol: lib_adv_bignum >>> >>> Driver [glk] binding failed >>> >>> Could not load driver glk >>> >>> There is no output driver >>> >>> Critical error while initializing, abort. >>> >>> >>> >>> >>> >>> >>> >>> Config file (cut for the sake of Sanity): >>> >>> >>> >>> ## Server section with all kinds of settings for the LCDd server ## >>> >>> [server] >>> >>> Driver=glk >>> >>> # Tells the driver to bind to the given interface >>> >>> Bind=127.0.0.1 >>> >>> # Listen on this specified port; defaults to 13666. >>> >>> Port=13666 >>> >>> # Sets the reporting level; defaults to 2 (warnings and errors only). >>> >>> ReportLevel=2 >>> >>> # Should we report to syslog instead of stderr ? Default: no >>> >>> ReportToSyslog=yes >>> >>> # Sets the default time in seconds to displays a screen. >>> >>> WaitTime=30 >>> >>> # User to run as. LCDd will drop its root priviledges, >>> >>> # if any, and run as this user instead. >>> >>> User=nobody >>> >>> ServerScreen=no >>> >>> Foreground=no >>> >>> DriverPath=/usr/local/lib/lcdproc/ >>> >>> ToggleRotateKey=Enter >>> >>> PrevScreenKey=Left >>> >>> NextScreenKey=Right >>> >>> ScrollUpKey=Up >>> >>> ScrollDownKey=Down >>> >>> ScrollDownKey=Down >>> >>> [Input] >>> >>> FreePauseKey=yes >>> >>> FreeBackKey=yes >>> >>> FreeForwardKey=yes >>> >>> FreeMainMenuKey=yes >>> >>> [menu] >>> >>> MenuKey=Escape >>> >>> EnterKey=Enter >>> >>> UpKey=Up >>> >>> DownKey=Down >>> >>> LeftKey=Left >>> >>> RightKey=Right >>> >>> ## Matrix Orbital GLK driver ## >>> >>> [glk] >>> >>> # select the serial device to use [default: /dev/lcd] >>> >>> Device=/dev/ttyS0 >>> >>> # set the initial contrast value [default: 560; legal: 0 - 1000] >>> >>> Contrast=560 >>> >>> # set the serial port speed [default: 19200; legal: 9600, 19200, 38400] >>> >>> Speed=19200 >>> >>> >>> >>> >>> >>> Regards and thanks in advance, >>> >>> Seann >>> >>> >>> >>> >>> >> _______________________________________________ >> LCDproc mailing list >> LCDproc@lists.omnipotent.net >> http://lists.omnipotent.net/mailman/listinfo/lcdproc >> >> From chr.fr@gmx.net Mon Jul 21 20:47:01 2008 From: chr.fr@gmx.net (Christoph Fritsche) Date: Mon Jul 21 20:47:01 2008 Subject: [Lcdproc] IOWarrior24 broken size on 16x4 display Message-ID: <4884F59F.8070405@gmx.net> Hi list, I got lcdproc 0.5.2 up and running on debian etch. I guess, from reading through the web archives, that the majority uses a 20x4 display in combination with the IOWarrior driver. Unfortunately I got an 16x4 HD44780 compatible one and it causes some trouble to lcdproc or the IOWarrior driver. The first and second row is displayed correctly. The third and fourth row is messed up with 4 leading spaces or junk. It looks like the internal buffer allocates 20 chars and overrides the next lines. So lcdproc continues printout on fifth char on row 3 and 4. When changing the display size to 32x2 everything works fine. The first row extends to the third and the second joins with the fourth. Does anybody have a similar setup or even a fix to get those 16x4 displays working? I looked through the code but couldn't find the right place where things went wrong. Could someone point out where to look at? Thanks in advance Christoph From chr.fr@gmx.net Wed Jul 23 00:16:02 2008 From: chr.fr@gmx.net (Christoph Fritsche) Date: Wed Jul 23 00:16:02 2008 Subject: [Lcdproc] IOWarrior24 broken size on 16x4 display In-Reply-To: <4884F59F.8070405@gmx.net> References: <4884F59F.8070405@gmx.net> Message-ID: <488677F3.4000506@gmx.net> Hi list, I tracked the problem down. There is a hard coded offset in IOWarrior.c in iowlcd_set_pos() Here is a patch to get 16x4 displays working: --- IOWarrior.c.org 2008-07-23 01:48:43.000000000 +0200 +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200 @@ -163,7 +163,7 @@ static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y) { - const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 }; + const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 }; unsigned char addr = lineOff[y] + x; return iowlcd_set_ddram_addr(udh, addr); } Due a lack of understanding what those addresses really mean, especially for other models than mine, I can not provide a general fix. This is left to the more skilled programmers out there. Works for me^(tm) on lcdproc0.5.2 IOWarrior24 HD44780 compatible 16x4 display Thanks for your attention. Christoph From erik@frenchguys.com Fri Jul 25 02:39:01 2008 From: erik@frenchguys.com (Erik Dasque) Date: Fri Jul 25 02:39:01 2008 Subject: [Lcdproc] LCDproc on DIY USB (serial) LCD on Mac OS X (10.5.4) Message-ID: Hi all, I just started looking at LCDproc and I have a million questions, hopefully you guys will be able to help answer some of them. Without anything connected just yet, I got LCDd running on Mac OS X with ncurses. I have built the nightly tarball on my system (removing the reference to kvm.h) and I can launch LCDd. I can also launch LCDproc which connects to LCDd and displays the different screens well. Now to the hardware. I am using a Sparkfun Breakout Board for FT232RL USB to Serial (http://www.sparkfun.com/commerce/product_info.php?products_id=718 ) and a Sparkfun Serial Enabled 16x2 LCD - ( http://www.sparkfun.com/commerce/product_info.php?products_id=813 ). I can give you a bit more information on the setup if you need any, it's pretty much $40 worth of hardware. I am able to establish a serial communication with the device and the characters I type (as well as control sequences) do appear on the LCD using: screen /dev/tty.usbserial-A8003TFi 9600 The LCD uses a HD44780 controller coupled with a "SerLCD backpack.. [which]... takes care of all the HD44780 commands allowing seamless integration with any micro that can communicate at 9600bps TTL serial". It obeys the HD44780 commands (clear, move cursor, scroll, ...). So I chose the HD44780 driver and it seemed that the closest connection type is picanlcd. This is what I get, I think it's pretty close about as you see there is quite a bit of garbage. with PicanLCD: http://youtube.com/watch?v=tjFTjKKs0mM With lcdserializer, we're getting closer I think, as you can see the boot and shut down messages display correctly. At this point, I wonder if it's just the default message that doesn't play well in 16x2 or maybe some weird characters are not interpreted correctly (the hearts ?). I am not very familiar with the clients yet so I don't know what to try out that would be simpler. Unless there is a unit testing type client that attempts more and more complex operations. With lcdserializer: http://youtube.com/watch?v=9G6O0pO0wt4 I also tried pertelian which gives me the same result as lcdserializer (hearts, some scrolling on top but erratic, nothing much changing at the bottom). Same thing with vdr-lcd and los-panel. I think I am very close, I hope I documented it enough to get some help. Any suggestion ? Thanks in advance, Erik ---------------------------------------------------------------------------------- P.S. here are my HD44780 parameters: ## Hitachi HD44780 driver ## [hd44780] ConnectionType=lcdserializer #ConnectionType=picanlcd #ConnectionType=pertelian Port=0x378 Device=/dev/tty.usbserial-A8003TFi Speed=9600 Keypad=no Contrast=0 Backlight=no OutputPort=no Size=16x2 #ExtendedMode=yes # Character map to to map ISO-8859-1 to the LCD's character set # [default: hd44780_default; legal: hd44780_default, ea_ks0073, sed1278f_0b ] Charmap=hd44780_default # If your display is slow and cannot keep up with the flow of data from # LCDd, garbage can appear on the LCDd. Set this delay factor to 2 or 4 # to increase the delays. Default: 1. #DelayMult=2 # Some displays (e.g. vdr-wakeup) need a message from the driver to that it # is still alive. When set to a value bigger then null the character in the # upper left corner is updated every seconds. Default: 0. #KeepAliveDisplay=0 # If you experience occasional garbage on your display you can use this # option as workaround. If set to a value bigger than null it forces a # full screen refresh seconds. Default: 0. #RefreshDisplay=5 # You can reduce the inserted delays by setting this to false. # On fast PCs it is possible your LCD does not respond correctly. # Default: true. DelayBus=true # If you have a keypad you can assign keystrings to the keys. # See documentation for used terms and how to wire it. # For example to give directly connected key 4 the string "Enter", use: # KeyDirect_4=Enter # For matrix keys use the X and Y coordinates of the key: # KeyMatrix_1_3=Enter KeyMatrix_4_1=Enter KeyMatrix_4_2=Up KeyMatrix_4_3=Down KeyMatrix_4_4=Escape From peter@adpm.de Sun Jul 27 20:31:01 2008 From: peter@adpm.de (Peter Marschall) Date: Sun Jul 27 20:31:01 2008 Subject: [Lcdproc] IOWarrior24 broken size on 16x4 display In-Reply-To: <488677F3.4000506@gmx.net> References: <4884F59F.8070405@gmx.net> <488677F3.4000506@gmx.net> Message-ID: <200807272229.59224.peter@adpm.de> Hi Christoph, On Wednesday, 23. July 2008, Christoph Fritsche wrote: > I tracked the problem down. There is a hard coded offset in IOWarrior.c > in iowlcd_set_pos() > > Here is a patch to get 16x4 displays working: > --- IOWarrior.c.org 2008-07-23 01:48:43.000000000 +0200 > +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200 > @@ -163,7 +163,7 @@ > > static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y) > { > - const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 }; > + const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 }; > unsigned char addr = lineOff[y] + x; > return iowlcd_set_ddram_addr(udh, addr); > } > > Due a lack of understanding what those addresses really mean, especially > for other models than mine, I can not provide a general fix. This is > left to the more skilled programmers out there. > > Works for me^(tm) on > lcdproc0.5.2 > IOWarrior24 > HD44780 compatible 16x4 display Thanks for the report. I am trying to find a solution that works with 20 character displays (the previous one) and 16 character display (with your patch). Ideas are welcome ;-) Regards Peter -- Peter Marschall peter@adpm.de From mattia.jona@gmail.com Sun Jul 27 21:41:02 2008 From: mattia.jona@gmail.com (Mattia Jona-Lasinio) Date: Sun Jul 27 21:41:02 2008 Subject: [Lcdproc] IOWarrior24 broken size on 16x4 display In-Reply-To: <200807272229.59224.peter@adpm.de> References: <4884F59F.8070405@gmx.net> <488677F3.4000506@gmx.net> <200807272229.59224.peter@adpm.de> Message-ID: <7af880ab0807271440u36bd8416r252d6c758d3a2a5b@mail.gmail.com> ------=_Part_10489_2064013.1217194842005 Content-Type: multipart/alternative; boundary="----=_Part_10490_10684671.1217194842005" ------=_Part_10490_10684671.1217194842005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Peter and Christoph, I have a possible solution to suggest. It is clear that ddram addresses cannot be hardcoded anymore. I suggest the following patch, to be applied against the current CVS version. Bye, Mattia On Sun, Jul 27, 2008 at 10:29 PM, Peter Marschall wrote: > Hi Christoph, > > On Wednesday, 23. July 2008, Christoph Fritsche wrote: > > I tracked the problem down. There is a hard coded offset in IOWarrior.c > > in iowlcd_set_pos() > > > > Here is a patch to get 16x4 displays working: > > --- IOWarrior.c.org 2008-07-23 01:48:43.000000000 +0200 > > +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200 > > @@ -163,7 +163,7 @@ > > > > static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y) > > { > > - const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 }; > > + const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 }; > > unsigned char addr = lineOff[y] + x; > > return iowlcd_set_ddram_addr(udh, addr); > > } > > > > Due a lack of understanding what those addresses really mean, especially > > for other models than mine, I can not provide a general fix. This is > > left to the more skilled programmers out there. > > > > Works for me^(tm) on > > lcdproc0.5.2 > > IOWarrior24 > > HD44780 compatible 16x4 display > > Thanks for the report. > > I am trying to find a solution that works with 20 character displays (the > previous one) and 16 character display (with your patch). > > Ideas are welcome ;-) > > Regards > Peter > > > > -- > Peter Marschall > peter@adpm.de > _______________________________________________ > LCDproc mailing list > LCDproc@lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > ------=_Part_10490_10684671.1217194842005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi Peter and Christoph,
I have a possible solution to suggest.
It is clear that ddram addresses cannot be hardcoded anymore.
I suggest the following patch, to be applied against the current CVS version.

Bye,

Mattia


On Sun, Jul 27, 2008 at 10:29 PM, Peter Marschall <peter@adpm.de> wrote:
Hi Christoph,

On Wednesday, 23. July 2008, Christoph Fritsche wrote:
> I tracked the problem down. There is a hard coded offset in IOWarrior.c
> in iowlcd_set_pos()
>
> Here is a patch to get 16x4 displays working:
> --- IOWarrior.c.org     2008-07-23 01:48:43.000000000 +0200
> +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200
> @@ -163,7 +163,7 @@
>
>  static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y)
>  {
> -  const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 };
> +  const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 };
>    unsigned char addr = lineOff[y] + x;
>    return iowlcd_set_ddram_addr(udh, addr);
>  }
>
> Due a lack of understanding what those addresses really mean, especially
> for other models than mine, I can not provide a general fix. This is
> left to the more skilled programmers out there.
>
> Works for me^(tm) on
> lcdproc0.5.2
> IOWarrior24
> HD44780 compatible 16x4 display

Thanks for the report.

I am trying to find a solution that works with 20 character displays (the
previous one) and 16 character display (with your patch).

Ideas are welcome ;-)

Regards
Peter



--
Peter Marschall
peter@adpm.de
_______________________________________________
LCDproc mailing list
LCDproc@lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc

------=_Part_10490_10684671.1217194842005-- ------=_Part_10489_2064013.1217194842005 Content-Type: application/octet-stream; name=IOWarrior.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_fj66apdm0 Content-Disposition: attachment; filename=IOWarrior.diff LS0tIElPV2Fycmlvci5jCTIwMDctMTItMDIgMTg6MjQ6NDUuMDAwMDAwMDAwICswMTAwCisrKyBJ T1dhcnJpb3JfMS5jCTIwMDgtMDctMjcgMjM6MzY6MzAuMDAwMDAwMDAwICswMjAwCkBAIC0xNjEs MTggKzE2MSwxNyBAQAogICByZXR1cm4gbGVuOwogfQogCi1zdGF0aWMgaW50IGlvd2xjZF9zZXRf cG9zKHVzYl9kZXZfaGFuZGxlICp1ZGgsIGludCBzaXplLCBpbnQgeCwgaW50IHkpCitzdGF0aWMg aW50IGlvd2xjZF9zZXRfcG9zKFByaXZhdGVEYXRhICpwLCBpbnQgc2l6ZSwgaW50IHgsIGludCB5 KQogewotICBjb25zdCB1bnNpZ25lZCBjaGFyIGxpbmVPZmZbNF0gPSB7IDB4MDAsIDB4NDAsIDB4 MTQsIDB4NTQgfTsKLSAgdW5zaWduZWQgY2hhciBhZGRyID0gbGluZU9mZlt5XSArIHg7Ci0gIHJl dHVybiBpb3dsY2Rfc2V0X2RkcmFtX2FkZHIodWRoLCBzaXplLCBhZGRyKTsKKyAgdW5zaWduZWQg Y2hhciBhZGRyID0gKCh5JTIpKjB4NDApICsgKCh5ID49IDIpKnAtPndpZHRoKSArIHg7CisgIHJl dHVybiBpb3dsY2Rfc2V0X2RkcmFtX2FkZHIocC0+dWRoLCBzaXplLCBhZGRyKTsKIH0KIAotc3Rh dGljIGludCBpb3dsY2Rfc2V0X3RleHQodXNiX2Rldl9oYW5kbGUgKnVkaCwgaW50IHNpemUsIGlu dCB4LCBpbnQgeSwgaW50IGxlbiwgdW5zaWduZWQgY2hhciAqZGF0YSkKK3N0YXRpYyBpbnQgaW93 bGNkX3NldF90ZXh0KFByaXZhdGVEYXRhICpwLCBpbnQgc2l6ZSwgaW50IHgsIGludCB5LCBpbnQg bGVuLCB1bnNpZ25lZCBjaGFyICpkYXRhKQogewotICBpZiAoaW93bGNkX3NldF9wb3ModWRoLCBz aXplLCB4LCB5KSA9PSBJT1dfRVJST1IpCisgIGlmIChpb3dsY2Rfc2V0X3BvcyhwLCBzaXplLCB4 LCB5KSA9PSBJT1dfRVJST1IpCiAgICAgcmV0dXJuIElPV19FUlJPUjsKLSAgcmV0dXJuIGlvd2xj ZF93cml0ZV9kYXRhKHVkaCwgc2l6ZSwgbGVuLCBkYXRhKTsKKyAgcmV0dXJuIGlvd2xjZF93cml0 ZV9kYXRhKHAtPnVkaCwgc2l6ZSwgbGVuLCBkYXRhKTsKIH0KIAogc3RhdGljIGludCBpb3dsY2Rf bG9hZF9jaGFycyh1c2JfZGV2X2hhbmRsZSAqdWRoLCBpbnQgc2l6ZSwgaW50IG9mZnNldCwgaW50 IG51bSwgdW5zaWduZWQgY2hhciAqYml0cykKQEAgLTU0Myw3ICs1NDIsNyBAQAogICAgICAgICAg IGJ1ZmZlcltjb3VudF0gPSBIRDQ0NzgwX2NoYXJtYXBbKHVuc2lnbmVkIGNoYXIpIHAtPmZyYW1l YnVmW29mZnNldCtjb3VudF1dOwogICAgICAgICAgIHAtPmJhY2tpbmdzdG9yZVtvZmZzZXQrY291 bnRdID0gcC0+ZnJhbWVidWZbb2Zmc2V0K2NvdW50XTsKICAgICAgICAgfQotICAgICAgICBpb3ds Y2Rfc2V0X3RleHQocC0+dWRoLCBJT1dMQ0RfU0laRSwgMCwgeSwgY291bnQsIGJ1ZmZlcik7Cisg ICAgICAgIGlvd2xjZF9zZXRfdGV4dChwLCBJT1dMQ0RfU0laRSwgMCwgeSwgY291bnQsIGJ1ZmZl cik7CiAgICAgICAgIGRlYnVnKFJQVF9ERUJVRywgIiVzOiBmbHVzaGVkICVkIGNoYXJzIGF0ICgl ZCwlZCkiLAogCQkJZHJ2dGhpcy0+bmFtZSwgY291bnQsIDAsIHkpOwogCkBAIC01NTgsNyArNTU3 LDcgQEAKIC8vCQkgICAgYnVmZmVyW2ldID0gSEQ0NDc4MF9jaGFybWFwWyh1bnNpZ25lZCBjaGFy KSBwLT5mcmFtZWJ1ZltvZmZzZXQreCtpXV07CiAvLwkJICAgIHAtPmJhY2tpbmdzdG9yZVtvZmZz ZXQreCtpXSA9IHAtPmZyYW1lYnVmW29mZnNldCt4K2ldOwogLy8JCX0KLS8vCQlpb3dsY2Rfc2V0 X3RleHQocC0+dWRoLCBJT1dMQ0RfU0laRSwgeCwgeSwgY291bnQsIGJ1ZmZlcik7CisvLwkJaW93 bGNkX3NldF90ZXh0KHAsIElPV0xDRF9TSVpFLCB4LCB5LCBjb3VudCwgYnVmZmVyKTsKIC8vCQlk ZWJ1ZyhSUFRfREVCVUcsICIlczogZmx1c2hlZCAlZCBjaGFycyBhdCAoJWQsJWQpIiwKIC8vCQkJ ZHJ2dGhpcy0+bmFtZSwgY291bnQsIHgsIHkpOwogCkBAIC03OTcsNyArNzk2LDcgQEAKIHsKIFBy aXZhdGVEYXRhICpwID0gZHJ2dGhpcy0+cHJpdmF0ZV9kYXRhOwogCi0gIGlvd2xjZF9zZXRfcG9z KHAtPnVkaCwgSU9XTENEX1NJWkUsIHgsIHkpOworICBpb3dsY2Rfc2V0X3BvcyhwLCBJT1dMQ0Rf U0laRSwgeCwgeSk7CiAKICAgc3dpdGNoIChzdGF0ZSkgewogICAgIGNhc2UgQ1VSU09SX09GRjoK ------=_Part_10489_2064013.1217194842005-- From mattia.jona@gmail.com Sun Jul 27 21:53:02 2008 From: mattia.jona@gmail.com (Mattia Jona-Lasinio) Date: Sun Jul 27 21:53:02 2008 Subject: [Lcdproc] IOWarrior24 broken size on 16x4 display In-Reply-To: <7af880ab0807271440u36bd8416r252d6c758d3a2a5b@mail.gmail.com> References: <4884F59F.8070405@gmx.net> <488677F3.4000506@gmx.net> <200807272229.59224.peter@adpm.de> <7af880ab0807271440u36bd8416r252d6c758d3a2a5b@mail.gmail.com> Message-ID: <7af880ab0807271452p1bfbb78esf1953e2783a8f13a@mail.gmail.com> ------=_Part_10592_13379382.1217195540028 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Uhmmm, for some strange reason the patch is not recognised as a plain text file. I'll try with this: --------------- start of patch ------------------- --- IOWarrior.c 2007-12-02 18:24:45.000000000 +0100 +++ IOWarrior.c 2008-07-27 23:36:30.000000000 +0200 @@ -161,18 +161,17 @@ return len; } -static int iowlcd_set_pos(usb_dev_handle *udh, int size, int x, int y) +static int iowlcd_set_pos(PrivateData *p, int size, int x, int y) { - const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 }; - unsigned char addr = lineOff[y] + x; - return iowlcd_set_ddram_addr(udh, size, addr); + unsigned char addr = ((y%2)*0x40) + ((y >= 2)*p->width) + x; + return iowlcd_set_ddram_addr(p->udh, size, addr); } -static int iowlcd_set_text(usb_dev_handle *udh, int size, int x, int y, int len, unsigned char *data) +static int iowlcd_set_text(PrivateData *p, int size, int x, int y, int len, unsigned char *data) { - if (iowlcd_set_pos(udh, size, x, y) == IOW_ERROR) + if (iowlcd_set_pos(p, size, x, y) == IOW_ERROR) return IOW_ERROR; - return iowlcd_write_data(udh, size, len, data); + return iowlcd_write_data(p->udh, size, len, data); } static int iowlcd_load_chars(usb_dev_handle *udh, int size, int offset, int num, unsigned char *bits) @@ -543,7 +542,7 @@ buffer[count] = HD44780_charmap[(unsigned char) p->framebuf[offset+count]]; p->backingstore[offset+count] = p->framebuf[offset+count]; } - iowlcd_set_text(p->udh, IOWLCD_SIZE, 0, y, count, buffer); + iowlcd_set_text(p, IOWLCD_SIZE, 0, y, count, buffer); debug(RPT_DEBUG, "%s: flushed %d chars at (%d,%d)", drvthis->name, count, 0, y); @@ -558,7 +557,7 @@ // buffer[i] = HD44780_charmap[(unsigned char) p->framebuf[offset+x+i]]; // p->backingstore[offset+x+i] = p->framebuf[offset+x+i]; // } -// iowlcd_set_text(p->udh, IOWLCD_SIZE, x, y, count, buffer); +// iowlcd_set_text(p, IOWLCD_SIZE, x, y, count, buffer); // debug(RPT_DEBUG, "%s: flushed %d chars at (%d,%d)", // drvthis->name, count, x, y); @@ -797,7 +796,7 @@ { PrivateData *p = drvthis->private_data; - iowlcd_set_pos(p->udh, IOWLCD_SIZE, x, y); + iowlcd_set_pos(p, IOWLCD_SIZE, x, y); switch (state) { case CURSOR_OFF: ----------- end of patch ----------- On Sun, Jul 27, 2008 at 11:40 PM, Mattia Jona-Lasinio wrote: > > Hi Peter and Christoph, > I have a possible solution to suggest. > It is clear that ddram addresses cannot be hardcoded anymore. > I suggest the following patch, to be applied against the current CVS > version. > > Bye, > > Mattia > > > > On Sun, Jul 27, 2008 at 10:29 PM, Peter Marschall wrote: > >> Hi Christoph, >> >> On Wednesday, 23. July 2008, Christoph Fritsche wrote: >> > I tracked the problem down. There is a hard coded offset in IOWarrior.c >> > in iowlcd_set_pos() >> > >> > Here is a patch to get 16x4 displays working: >> > --- IOWarrior.c.org 2008-07-23 01:48:43.000000000 +0200 >> > +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200 >> > @@ -163,7 +163,7 @@ >> > >> > static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y) >> > { >> > - const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 }; >> > + const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 }; >> > unsigned char addr = lineOff[y] + x; >> > return iowlcd_set_ddram_addr(udh, addr); >> > } >> > >> > Due a lack of understanding what those addresses really mean, especially >> > for other models than mine, I can not provide a general fix. This is >> > left to the more skilled programmers out there. >> > >> > Works for me^(tm) on >> > lcdproc0.5.2 >> > IOWarrior24 >> > HD44780 compatible 16x4 display >> >> Thanks for the report. >> >> I am trying to find a solution that works with 20 character displays (the >> previous one) and 16 character display (with your patch). >> >> Ideas are welcome ;-) >> >> Regards >> Peter >> >> >> >> -- >> Peter Marschall >> peter@adpm.de >> _______________________________________________ >> LCDproc mailing list >> LCDproc@lists.omnipotent.net >> http://lists.omnipotent.net/mailman/listinfo/lcdproc >> > > ------=_Part_10592_13379382.1217195540028 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Uhmmm, for some strange reason the patch is not recognised as a plain text file.
I'll try with this:



--------------- start of patch -------------------

--- IOWarrior.c    2007-12-02 18:24:45.000000000 +0100
+++ IOWarrior.c    2008-07-27 23:36:30.000000000 +0200
@@ -161,18 +161,17 @@
   return len;
 }
 
-static int iowlcd_set_pos(usb_dev_handle *udh, int size, int x, int y)
+static int iowlcd_set_pos(PrivateData *p, int size, int x, int y)
 {
-  const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 };
-  unsigned char addr = lineOff[y] + x;
-  return iowlcd_set_ddram_addr(udh, size, addr);
+  unsigned char addr = ((y%2)*0x40) + ((y >= 2)*p->width) + x;
+  return iowlcd_set_ddram_addr(p->udh, size, addr);
 }
 
-static int iowlcd_set_text(usb_dev_handle *udh, int size, int x, int y, int len, unsigned char *data)
+static int iowlcd_set_text(PrivateData *p, int size, int x, int y, int len, unsigned char *data)
 {
-  if (iowlcd_set_pos(udh, size, x, y) == IOW_ERROR)
+  if (iowlcd_set_pos(p, size, x, y) == IOW_ERROR)
     return IOW_ERROR;
-  return iowlcd_write_data(udh, size, len, data);
+  return iowlcd_write_data(p->udh, size, len, data);
 }
 
 static int iowlcd_load_chars(usb_dev_handle *udh, int size, int offset, int num, unsigned char *bits)
@@ -543,7 +542,7 @@
           buffer[count] = HD44780_charmap[(unsigned char) p->framebuf[offset+count]];
           p->backingstore[offset+count] = p->framebuf[offset+count];
         }
-        iowlcd_set_text(p->udh, IOWLCD_SIZE, 0, y, count, buffer);
+        iowlcd_set_text(p, IOWLCD_SIZE, 0, y, count, buffer);
         debug(RPT_DEBUG, "%s: flushed %d chars at (%d,%d)",
             drvthis->name, count, 0, y);
 
@@ -558,7 +557,7 @@
 //            buffer[i] = HD44780_charmap[(unsigned char) p->framebuf[offset+x+i]];
 //            p->backingstore[offset+x+i] = p->framebuf[offset+x+i];
 //        }
-//        iowlcd_set_text(p->udh, IOWLCD_SIZE, x, y, count, buffer);
+//        iowlcd_set_text(p, IOWLCD_SIZE, x, y, count, buffer);
 //        debug(RPT_DEBUG, "%s: flushed %d chars at (%d,%d)",
 //            drvthis->name, count, x, y);
 
@@ -797,7 +796,7 @@
 {
 PrivateData *p = drvthis->private_data;
 
-  iowlcd_set_pos(p->udh, IOWLCD_SIZE, x, y);
+  iowlcd_set_pos(p, IOWLCD_SIZE, x, y);
 
   switch (state) {
     case CURSOR_OFF:



----------- end of patch -----------


On Sun, Jul 27, 2008 at 11:40 PM, Mattia Jona-Lasinio <mattia.jona@gmail.com> wrote:

Hi Peter and Christoph,
I have a possible solution to suggest.
It is clear that ddram addresses cannot be hardcoded anymore.
I suggest the following patch, to be applied against the current CVS version.

Bye,

Mattia



On Sun, Jul 27, 2008 at 10:29 PM, Peter Marschall <peter@adpm.de> wrote:
Hi Christoph,

On Wednesday, 23. July 2008, Christoph Fritsche wrote:
> I tracked the problem down. There is a hard coded offset in IOWarrior.c
> in iowlcd_set_pos()
>
> Here is a patch to get 16x4 displays working:
> --- IOWarrior.c.org     2008-07-23 01:48:43.000000000 +0200
> +++ IOWarrior.c 2008-07-23 01:41:33.000000000 +0200
> @@ -163,7 +163,7 @@
>
>  static int iowlcd_set_pos(usb_dev_handle *udh,int x,int y)
>  {
> -  const unsigned char lineOff[4] = { 0x00, 0x40, 0x14, 0x54 };
> +  const unsigned char lineOff[4] = { 0x00, 0x40, 0x10, 0x50 };
>    unsigned char addr = lineOff[y] + x;
>    return iowlcd_set_ddram_addr(udh, addr);
>  }
>
> Due a lack of understanding what those addresses really mean, especially
> for other models than mine, I can not provide a general fix. This is
> left to the more skilled programmers out there.
>
> Works for me^(tm) on
> lcdproc0.5.2
> IOWarrior24
> HD44780 compatible 16x4 display

Thanks for the report.

I am trying to find a solution that works with 20 character displays (the
previous one) and 16 character display (with your patch).

Ideas are welcome ;-)

Regards
Peter



--
Peter Marschall
peter@adpm.de
_______________________________________________
LCDproc mailing list
LCDproc@lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc


------=_Part_10592_13379382.1217195540028-- From bsdfan@nurfuerspam.de Tue Jul 29 01:10:02 2008 From: bsdfan@nurfuerspam.de (Markus Dolze) Date: Tue Jul 29 01:10:02 2008 Subject: [Lcdproc] FreeBSD 4.x and 5.x support ceased Message-ID: <488E1B6B.4070706@nurfuerspam.de> Dear users of LCDproc on FreeBSD, as the FreeBSD project has declared * FreeBSD 4.x and * FreeBSD 5.x 'end of life' (EOL), I will stop testing (smoketests) and maintaining LCDproc for these platforms. The last known working LCDproc release on these platforms is 0.5.2. Currently supported are * FreeBSD 6.3 and * FreeBSD 7.0. Regards, Markus Dolze From tfangio@fractech.net Wed Jul 30 03:04:01 2008 From: tfangio@fractech.net (Topher Fangio) Date: Wed Jul 30 03:04:01 2008 Subject: [Lcdproc] LCDProc on OS X 10.5 Message-ID: <42B18A8261FAE0428A17F9A6A539339E0DEB336218@EXCHCLST01.FRACTECH.LOCAL> Hello all, I am currently working on an open source API written in Ruby that communica= tes with LCDProc. Actually, it's already mostly written and I just need to do some testing an= d add a bit more documentation and examples. My problem is that I cannot seem to compile LCDProc 0.5.2 on OS X 10.5. (ED= IT: I got it working, see EDIT below) I have done the following: ./configure --enable-drivers=3Dcurses make It dies on make with the following error: then mv -f ".deps/eyebox.Tpo" ".deps/eyebox.Po"; else rm -f ".deps/= eyebox.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -DSYSCONFDIR=3D\"/usr/local= /etc\" -Wall -O3 -Wno-unused-function -MT machine_Darwin.o -MD -MP -MF "= .deps/machine_Darwin.Tpo" -c -o machine_Darwin.o machine_Darwin.c; \ then mv -f ".deps/machine_Darwin.Tpo" ".deps/machine_Darwin.Po"; el= se rm -f ".deps/machine_Darwin.Tpo"; exit 1; fi machine_Darwin.c:48:17: error: kvm.h: No such file or directory make[3]: *** [machine_Darwin.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 >From what I have read, 10.5 completely removes kvm.h and so I was wondering= if there was any particular reason that it was still in LCDProc and if it was needed (accord= ing to this link http://home.sandiego.edu/~epooch/cgi-bin/blosxom.cgi/tech/leds/GrowLCDproc1= _3_5.writeback it is not). EDIT: I commented out the include statement (#include ) inside machi= ne_Darwin.c and everything compiled just fine. Any reason this cannot be fully removed from= LCDProc? At the very least, how would I go about adding a note about this to the documentation? Thanks! Topher Fangio CONFIDENTIALITY NOTICE: This email message and any attachments hereto are = intended only for use by the addressee(s) named herein and may contain info= rmation which is legally privileged, confidential and/or exempt from disclo= sure under applicable law. If you are not the intended recipient, or an au= thorized representative of the intended recipient, of this email message, y= ou are hereby notified that any review, dissemination, distribution, copyin= g, or use (including any reliance thereon) of this email message, and/or an= y attachment hereto, is strictly prohibited. Although this transmission and any attachments are believed to be free of a= ny virus or other defect that might affect any computer system into which i= t is received and opened, it is the responsibility of the recipient to ensu= re that it is free from virus or other defect and no responsibility is acce= pted by the sending company, its subsidiaries and affiliates, as applicable= , for any loss or damage arising in any way from its use. If you have received this email message in error, please immediately notify= the sender by return email and permanently delete from your system, the or= iginal and any copies of this email and any attachments hereto and any prin= tout hereof. Unauthorized interception of this email is a violation of fed= eral criminal law. From erik@frenchguys.com Wed Jul 30 03:20:02 2008 From: erik@frenchguys.com (Erik Dasque) Date: Wed Jul 30 03:20:02 2008 Subject: [Lcdproc] LCDproc on DIY USB (serial) LCD on Mac OS X (10.5.4) In-Reply-To: References: Message-ID: <0906B3DD-31EA-4725-9365-590F82047473@frenchguys.com> /bump. Any ideas, anyone ? Erik On Jul 24, 2008, at 10:38 PM, Erik Dasque wrote: > Hi all, > > I just started looking at LCDproc and I have a million questions, > hopefully you guys will be able to help answer some of them. > > Without anything connected just yet, I got LCDd running on Mac OS X > with ncurses. I have built the nightly tarball on my system > (removing the reference to kvm.h) and I can launch LCDd. I can also > launch LCDproc which connects to LCDd and displays the different > screens well. > > Now to the hardware. > > I am using a Sparkfun Breakout Board for FT232RL USB to Serial (http://www.sparkfun.com/commerce/product_info.php?products_id=718 > ) and a Sparkfun Serial Enabled 16x2 LCD - ( http://www.sparkfun.com/commerce/product_info.php?products_id=813 > ). I can give you a bit more information on the setup if you need > any, it's pretty much $40 worth of hardware. > > I am able to establish a serial communication with the device and > the characters I type (as well as control sequences) do appear on > the LCD using: > screen /dev/tty.usbserial-A8003TFi 9600 > > The LCD uses a HD44780 controller coupled with a "SerLCD backpack.. > [which]... takes care of all the HD44780 commands allowing seamless > integration with any micro that can communicate at 9600bps TTL > serial". It obeys the HD44780 commands (clear, move cursor, > scroll, ...). > > So I chose the HD44780 driver and it seemed that the closest > connection type is picanlcd. This is what I get, I think it's pretty > close about as you see there is quite a bit of garbage. > > with PicanLCD: http://youtube.com/watch?v=tjFTjKKs0mM > > With lcdserializer, we're getting closer I think, as you can see the > boot and shut down messages display correctly. At this point, I > wonder if it's just the default message that doesn't play well in > 16x2 or maybe some weird characters are not interpreted correctly > (the hearts ?). I am not very familiar with the clients yet so I > don't know what to try out that would be simpler. Unless there is a > unit testing type client that attempts more and more complex > operations. > > With lcdserializer: http://youtube.com/watch?v=9G6O0pO0wt4 > > I also tried pertelian which gives me the same result as > lcdserializer (hearts, some scrolling on top but erratic, nothing > much changing at the bottom). Same thing with vdr-lcd and los-panel. > > I think I am very close, I hope I documented it enough to get some > help. Any suggestion ? > > Thanks in advance, > > Erik > > ---------------------------------------------------------------------------------- > P.S. here are my HD44780 parameters: > > ## Hitachi HD44780 driver ## > [hd44780] > > ConnectionType=lcdserializer > #ConnectionType=picanlcd > #ConnectionType=pertelian > > Port=0x378 > Device=/dev/tty.usbserial-A8003TFi > Speed=9600 > > Keypad=no > Contrast=0 > Backlight=no > OutputPort=no > > Size=16x2 > > #ExtendedMode=yes > > # Character map to to map ISO-8859-1 to the LCD's character set > # [default: hd44780_default; legal: hd44780_default, ea_ks0073, > sed1278f_0b ] > Charmap=hd44780_default > > # If your display is slow and cannot keep up with the flow of data > from > # LCDd, garbage can appear on the LCDd. Set this delay factor to 2 > or 4 > # to increase the delays. Default: 1. > #DelayMult=2 > > # Some displays (e.g. vdr-wakeup) need a message from the driver to > that it > # is still alive. When set to a value bigger then null the character > in the > # upper left corner is updated every seconds. > Default: 0. > #KeepAliveDisplay=0 > > # If you experience occasional garbage on your display you can use > this > # option as workaround. If set to a value bigger than null it forces a > # full screen refresh seconds. Default: 0. > #RefreshDisplay=5 > > # You can reduce the inserted delays by setting this to false. > # On fast PCs it is possible your LCD does not respond correctly. > # Default: true. > DelayBus=true > > # If you have a keypad you can assign keystrings to the keys. > # See documentation for used terms and how to wire it. > # For example to give directly connected key 4 the string "Enter", > use: > # KeyDirect_4=Enter > # For matrix keys use the X and Y coordinates of the key: > # KeyMatrix_1_3=Enter > KeyMatrix_4_1=Enter > KeyMatrix_4_2=Up > KeyMatrix_4_3=Down > KeyMatrix_4_4=Escape > > _______________________________________________ > LCDproc mailing list > LCDproc@lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From bsdfan@nurfuerspam.de Wed Jul 30 05:21:01 2008 From: bsdfan@nurfuerspam.de (Markus Dolze) Date: Wed Jul 30 05:21:01 2008 Subject: [Lcdproc] LCDProc on OS X 10.5 In-Reply-To: <42B18A8261FAE0428A17F9A6A539339E0DEB336218@EXCHCLST01.FRACTECH.LOCAL> References: <42B18A8261FAE0428A17F9A6A539339E0DEB336218@EXCHCLST01.FRACTECH.LOCAL> Message-ID: <488FFA38.8020003@nurfuerspam.de> Topher Fangio wrote: > Hello all, > > >From what I have read, 10.5 completely removes kvm.h and so I was wondering if there was any > particular reason that it was still in LCDProc and if it was needed (according to this link > http://home.sandiego.edu/~epooch/cgi-bin/blosxom.cgi/tech/leds/GrowLCDproc1_3_5.writeback > it is not). > > EDIT: I commented out the include statement (#include ) inside machine_Darwin.c and > everything compiled just fine. Any reason this cannot be fully removed from LCDProc? At the very > least, how would I go about adding a note about this to the documentation? > > Thanks! > > Topher Fangio > > It really seems that is not used within machine_Darwin.c. The Darwin code orginates from the *BSD code where kvm calls are used, but these are not used on Darwin. Does the client (lcdproc) works correctly (especially the 'Memory' and 'ProcSize' screens)? Regards Markus