You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(6) |
Feb
(2) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(9) |
Oct
(2) |
Nov
(3) |
Dec
|
2002 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
(1) |
May
(12) |
Jun
(3) |
Jul
(7) |
Aug
(10) |
Sep
(5) |
Oct
(6) |
Nov
(2) |
Dec
|
2003 |
Jan
(3) |
Feb
(11) |
Mar
(9) |
Apr
(6) |
May
(2) |
Jun
(1) |
Jul
(2) |
Aug
(36) |
Sep
(19) |
Oct
(54) |
Nov
(14) |
Dec
(23) |
2004 |
Jan
(30) |
Feb
(49) |
Mar
(35) |
Apr
(9) |
May
(18) |
Jun
(3) |
Jul
(8) |
Aug
(1) |
Sep
(15) |
Oct
(6) |
Nov
(5) |
Dec
(21) |
2005 |
Jan
(32) |
Feb
(14) |
Mar
(2) |
Apr
(13) |
May
(7) |
Jun
(31) |
Jul
(14) |
Aug
(27) |
Sep
(9) |
Oct
(19) |
Nov
(9) |
Dec
(13) |
2006 |
Jan
(35) |
Feb
(8) |
Mar
(27) |
Apr
(16) |
May
(4) |
Jun
(5) |
Jul
(20) |
Aug
(53) |
Sep
(58) |
Oct
(19) |
Nov
(21) |
Dec
(11) |
2007 |
Jan
(42) |
Feb
(20) |
Mar
(5) |
Apr
(14) |
May
(18) |
Jun
(11) |
Jul
(22) |
Aug
(17) |
Sep
(2) |
Oct
(8) |
Nov
|
Dec
(2) |
2008 |
Jan
(25) |
Feb
(1) |
Mar
(4) |
Apr
(5) |
May
(5) |
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
2009 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
(7) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2010 |
Jan
(17) |
Feb
(2) |
Mar
(2) |
Apr
(6) |
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(5) |
Jun
|
Jul
(11) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(5) |
Dec
(18) |
2012 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(2) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(2) |
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(4) |
Mar
|
Apr
(12) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael R. <re...@eu...> - 2004-05-22 04:35:14
|
Hi Juergen, sorry for the delay, I've been too busy with my real-life job... >> Celerons do not have a TSC? >> What linux kernel are you using? Could you check the "flags" line from >> /proc/cpuinfo ? >> > Kernelversion is 2.4.18 on Redhat 8 Fine. > /proc/cpuinfo > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca > cmov pat pse36 mmx fxsr Here we are: TSC is supported. I think the lack of TSC support on your setup comes from the fact that the asm/msr.h file is missing. >> It's not /dev/ppdev, but /dev/parport/0 (devfs) or /dev/parport0, >> major 99, kernel module ppdev.o > > modprobe: Can't locate module ppdev.o try 'modprobe ppdev' (not 'modprobe ppdev.o') You tried to run lcd4linux on another machine. Did you succeed? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Michael R. <re...@eu...> - 2004-05-22 04:26:33
|
Hi there, GL4Chris Hale wrote: [something] and later we wrote: > Cheers, > Matt Oh, now what's your name? > I am using a 16x4 line POWERTIP TECHNOLOGY PC1604LRSA display (HD44780 Compatable). > > I have set the config as 16x4. > > The first two lines display no problems, however the 2nd two line have an indent > of 4 characters. Does anybody know how to fix this. This is a known bug and has already been fixed (16x4 displays use a slightly different layout, which lead exactly to the 4 char indent. Which version of lcd4linux are you using? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Michael R. <re...@eu...> - 2004-05-20 08:40:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jean-Michel, | I'd like to get the PowerTip Display model PC1602Q see | (http://www.powertipusa.com/lcdc.htm) running under suSE linux. | | Do you think it's a supported display by LCD4Linux? I don't know. Maybe anyone on the list knows? Teh "data sheet" is quite short, and it does not say which LCD controller is used. From the signal names, I think it's a HD44780. If it's HD44780-compatible, it can be used with lcd4linux. Try to find some better description or a data sheet or something... bye, Michael - -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFArG76iebFT98TulARAgZFAJ9UVyxI/JTJbZziD8n3JHO99EBbZwCeOMTN n6+2GjPoMAS3ZZpBXE7v9kY= =rd1C -----END PGP SIGNATURE----- |
From: Michael R. <re...@eu...> - 2004-05-20 07:51:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert, Hi List, | I have a question, maybe sugestion... | is posible to display Time and Date with lcd4linux? | Now i use exec "date", but maybe it's posible to add this | to the source of lcd4linux... and take this informations | from /proc/driver/rtc ? I just added plugin_time to the CVS. At the moment it adds two functions to the evaluator: time(): returns the number of secons since the epoc. strftime(format, time): returns a string try strftime('%a, %d %b %Y %H:%M:%S %Z', time()) bye, Michael - -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFArGNtiebFT98TulARAmNKAJ9WFp9u45gFlXkHvZ6Kp8bQgleJTwCdFozY HBGtxQ9QM9vxNsuU9+yIdXY= =FkR1 -----END PGP SIGNATURE----- |
From: Michael R. <re...@eu...> - 2004-05-15 03:59:17
|
Hi Lars, > I want to know, how it works with virtual rows. First, you should ask such questions on the mailing list (lcd...@li...) > I want to Use an 44780 Display with 4X20 Characters and > display more than 4 rows. > > How do I implantate the code? > > It won't work with my version (0.9.9) You should upgrade to the latest stable release 0.9.11 Virtual rows require that you specify the number of rows with the 'rows' keyword. Further, you have to specify the 'scroll' and 'turn' values. See the documentation on the lcd4linux homepage. If it still doesn't work for you, just post your config file here, and the output of 'lcd4linux -Fvv', then we will be able to help you. bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: <AB...@pa...> - 2004-05-12 20:55:15
|
ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender =3D lcd...@li... Recipient(s) =3D Uwe Bloch Subject =3D you are a bad writer Scanning Time =3D 05/12/2004 22:53:28 Engine/Pattern =3D 7.000-1004/889 Action on message: The attachment talk.zip contained WORM_NETSKY.C virus. ScanMail has = taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Virus\talk40a28ec811aa.zip_. Warning to sender. ScanMail has detected a virus in an email you sent. Diese E-Mail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in = this e-mail is strictly forbidden. |
From: <An...@t-...> - 2004-05-07 21:15:22
|
Hello List. I try to compile the lcd4linux driver from cvs to get it working with my display from www.kernelconcepts.de (a small 20x4). I read in the List that the different RAM setup of the HD 66712 is testlike implemented. I would like to test it, but my compile-run fails with "No rule to make target "plugin_isdn.c". I would like to disable this plugin, but dunno how. Did i miss something? Any Idea? Regards, Andreas |
From: GL4Chris H. <tox...@ho...> - 2004-04-20 14:56:44
|
<html><div style='background-color:'><DIV class=RTE></DIV> <DIV>Hi</DIV> <DIV> </DIV> <DIV>I am using a 16x4 line POWERTIP TECHNOLOGY PC1604LRSA display (HD44780 Compatable).</DIV> <DIV> </DIV> <DIV>I have set the config as 16x4.</DIV> <DIV> </DIV> <DIV>The first two lines display no problems, however the 2nd two line have an indent of 4 characters. Does anybody know how to fix this.</DIV> <DIV> </DIV> <DIV>Cheers</DIV> <DIV> </DIV> <DIV>Matt</DIV></div><br clear=all><hr>Have more fun with your phone - download ringtones, logos, screensavers, games & more. <a href="http://g.msn.com/8HMAENUK/2746??PS=">Click here to begin!</a> </html> |
From: Michael R. <re...@eu...> - 2004-04-09 15:21:43
|
Hi there, The LCD4Linux Website just joined the protest against Software Patents! bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: juergen <ju...@wi...> - 2004-04-08 12:45:38
|
Hi Michael, > > Celerons do not have a TSC? > What linux kernel are you using? Could you check the "flags" line from > /proc/cpuinfo ? > Kernelversion is 2.4.18 on Redhat 8 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping : 5 cpu MHz : 467.740 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 925.52 > It's not /dev/ppdev, but /dev/parport/0 (devfs) or /dev/parport0, > major 99, kernel module ppdev.o modprobe: Can't locate module ppdev.o >> The wiring is from LCDproc and i edit the LCD4linux.conf. The Display >> runns with lcdproc too, but with much more CPU-Load an time to >> display somethimg.... > > So lcdproc has the same problem than lcd4linux? No, no. LCDproc need's only up to 4% >>> Here we are: This means that the "busy check" does not work for you. >>> The T6963 requires this busy checking, which means it has to read >>> values back from the parallel port. The message "hang in status.." >>> is emitted when the busy-check does not success after a certain >>> amount of time >>> >> I think 150ns for Statuscheck. That's the Problem? > > No, not the 150 ns, but statuscheck does never return, or the status > can not be read correctly. > > Can you test lcd4linux on this machine? I Think the last Mail did not reach the right Adress.... :-) > > Did you? > Yes, i did! But its the same Problem! But only up to 25% CPUload...... I don't know what i will do next with this Problem. Since last Weekend i try to make an own Program to check the Problem. But this was not a good Idee.... The only IDE i can use on my faster Maschine is Borlands C++BuilderX. For this i must deinstall Redhat 9 (many Problems with C++BuilderX and Kdevelop 3..) and install SuSE 9.0..... It's a long way to go..... 6 Days work for a C/C++ IDE without problems! Uff! Greetings Jürgen |
From: Michael R. <re...@eu...> - 2004-04-08 11:37:33
|
Hi nicolas, nicolas bussieres schrieb: > hi im trying to intergrate lcd4linux for LRP to show wireless data on LCD , but on the latest release i get this response > > WARNING: unknown token <%w> in <WIFI link %wl> > WARNING: unknown token <%w> in <WIFI signal %ws> > WARNING: unknown token <%w> in <WIFI noise %wn> I can tell you nothing about this client, as I don't have wifi here. Xavier? -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Michael R. <re...@eu...> - 2004-04-08 11:26:45
|
Hi Xavier, > Barry : In fact, the mysql plugin is work in progress and Michael didn't > modify the configuration stuff to make it work, so if you have the mysql > headers installed it will fail. Just do as Alex says for the moment I'm still looking for someone with deep autoconf knowledge :-) > Yes. I think I've been a little too verbose with this plugin, don't care > about these warnings. > The claim is that by now all 'plugins' and drivers are hard linked into > the lcd4linux executable, but there's no configure switch to choose > which ones to compile. > In the future (after 0.10.0), we'll try to make plugins dynamicaly > loaded, and configure switches to select plugins just as it's possible > for drivers, but wait a little. > > Michael : Maybe you should think about this configure switch for 0.10.0 > ? I'll try to do it myself if I can. No, I've a better idea:just move this initialisatin stuff into the data-fetch function, and execute it on the first call only. This way the plugin_init() function does nothing but register the plugin. Same goes for all other plugins! (Nico? are you listening?) bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Michael R. <re...@eu...> - 2004-04-08 11:19:19
|
Hi Juergen, >>> udelay.c: using gettimeofday() delay loop >> not that good. But you are using an old processor without TSC... >> > Intel Celeron, 467MHz Celerons do not have a TSC? What linux kernel are you using? Could you check the "flags" line from /proc/cpuinfo ? > It's a long way..... I don't know what's wrong with /dev/ppdev! It's not /dev/ppdev, but /dev/parport/0 (devfs) or /dev/parport0, major 99, kernel module ppdev.o > The wiring is from LCDproc and i edit the LCD4linux.conf. The Display > runns with lcdproc too, but with much more CPU-Load an time to display > somethimg.... So lcdproc has the same problem than lcd4linux? >> Here we are: This means that the "busy check" does not work for you. >> The T6963 requires this busy checking, which means it has to read >> values back from the parallel port. The message "hang in status.." is >> emitted when the busy-check does not success after a certain amount of >> time >> > I think 150ns for Statuscheck. That's the Problem? No, not the 150 ns, but statuscheck does never return, or the status can not be read correctly. >> Can you test lcd4linux on this machine? Did you? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Michael R. <re...@eu...> - 2004-04-08 07:02:26
|
Hi there, first, sorry for my absence in the last weeks. I've been too busy with my real-world job, and finally was bitten by a virus (not a computer virus, but a biological one), and have been ill this whole week (in fact, I should be in my bed now ;-) But I want to let you know that I will give a talk about LCD4Linux on Saturday, May 08 2004, on the Grazer LinuxTage. (http://www.linuxtage.at) Details about the talk can be found at http://www.linuxtage.at/?id=39 bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Barry G. <mai...@pe...> - 2004-04-05 01:03:04
|
Hi, in 0.98, I had to add a 5.0second sleep to the CrystalFontz.c driver. Otherwise the display never initializes correctly. In the current CVS version, I've had to do it again. Line 675: // Fixme: why such a large delay? usleep(350*1000); sleep(5); // needed for 634 V2.0 Now it is working. The scrolling speed is too fast though (for the first line- OS/kernel info); it flickers too much to read. Also, the Curses & PNG displays are missing from the sample config file. BTW, does anyone have a sample config for showing 3 nics, or 3 nics + total? Thanks, Barry Gould |
From: Xavier V. <xav...@fr...> - 2004-04-04 11:03:06
|
Hello Alex and Barry ! Barry : In fact, the mysql plugin is work in progress and Michael didn't modify the configuration stuff to make it work, so if you have the mysql headers installed it will fail. Just do as Alex says for the moment Alex : > I never needed those sensors, so i never compiled it in the kernel. So i > get messages like: > [i2c_sensors] Impossible to open /sys/bus/i2c/devices/! Is /sys mounted? > [i2c_sensors] Impossible to open /proc/sys/dev/sensors/! Is i2c_proc > loaded ? > [i2c_sensors] No i2c sensors found via the i2c interface ! > [i2c_sensors] Try to specify the path to the sensors ! Yes. I think I've been a little too verbose with this plugin, don't care about these warnings. The claim is that by now all 'plugins' and drivers are hard linked into the lcd4linux executable, but there's no configure switch to choose which ones to compile. In the future (after 0.10.0), we'll try to make plugins dynamicaly loaded, and configure switches to select plugins just as it's possible for drivers, but wait a little. Michael : Maybe you should think about this configure switch for 0.10.0 ? I'll try to do it myself if I can. Bye ! ---- Xavier Vello <xav...@fr...> |
From: juergen <ju...@wi...> - 2004-03-31 19:07:49
|
Hi Michael, Michael Reinelt schrieb: > Hi Juergen, > > sorry for the delay, I've been on a business journey... > no, problem. :-) > >> udelay.c: using gettimeofday() delay loop > > not that good. But you are using an old processor without TSC... > Intel Celeron, 467MHz >> drv_generic_parport.c: using raw port 0x378 > > Again, try to switch to ppdev (but this has nothing to do with your > problem) It's a long way..... I don't know what's wrong with /dev/ppdev! > >> T6963: wiring: [DISPLAY:CE]<==>[PARPORT:AUTOFD] >> T6963: wiring: [DISPLAY:CD]<==>[PARPORT:INIT] >> T6963: wiring: [DISPLAY:RD]<==>[PARPORT:SELECT] >> T6963: wiring: [DISPLAY:WR]<==>[PARPORT:STROBE] > > Is this ok? Please triple-check your wiring, 98% of all error reports > I get come from wrong wirings... > The wiring is from LCDproc and i edit the LCD4linux.conf. The Display runns with lcdproc too, but with much more CPU-Load an time to display somethimg.... >> drv_T6963.c: hang in status1 >> drv_T6963.c: hang in status2 >> drv_T6963.c: bug occured at byte 0 of 320 > > Here we are: This means that the "busy check" does not work for you. > The T6963 requires this busy checking, which means it has to read > values back from the parallel port. The message "hang in status.." is > emitted when the busy-check does not success after a certain amount of > time > I think 150ns for Statuscheck. That's the Problem? > Can you test lcd4linux on this machine? > "I check this! On my Athlon 1800+ / Epoxboard is no Problem, but with Windows an LCDHype. The Parallel port on this Board provide 5V." On this maschine runs lcdproc without any Problems (but on both maschines its only 40x12 possible!) With LCDhype working all "pixel". But not with Linuxproggys.. At the moment i can't test the Display with lcd4linux on the faster maschine. The "old" maschine is in the moment really busy with compilling arts, QT and Kdevelop..... The Parport on the maschine where the Display works, provide 5V too. I will test the Display on the faster maschine at the weekend. bye Jürgen |
From: Michael R. <re...@eu...> - 2004-03-31 15:04:33
|
Hi Juergen, sorry for the delay, I've been on a business journey... >> Could you try running lcd4linux with debug enabled (lcd4linux -Fvv) >> and check for some strange errors? >> > Yes i do. See at the end of the Mail. > Version 0.10.0 starting Fine. This is the CVS version > lcd4linux.c: initializing driver T6963 Ok > T6963: using model 'generic' Ok > udelay.c: using gettimeofday() delay loop not that good. But you are using an old processor without TSC... > drv_generic_parport.c: using raw port 0x378 Again, try to switch to ppdev (but this has nothing to do with your problem) > T6963: wiring: [DISPLAY:CE]<==>[PARPORT:AUTOFD] > T6963: wiring: [DISPLAY:CD]<==>[PARPORT:INIT] > T6963: wiring: [DISPLAY:RD]<==>[PARPORT:SELECT] > T6963: wiring: [DISPLAY:WR]<==>[PARPORT:STROBE] Is this ok? Please triple-check your wiring, 98% of all error reports I get come from wrong wirings... > drv_T6963.c: hang in status1 > drv_T6963.c: hang in status2 > drv_T6963.c: bug occured at byte 0 of 320 Here we are: This means that the "busy check" does not work for you. The T6963 requires this busy checking, which means it has to read values back from the parallel port. The message "hang in status.." is emitted when the busy-check does not success after a certain amount of time >> Another point may be that the T6963 is very sensitive to signal >> levels. It uses TTL levels (0V/5V), where many newer parallel ports >> provide 3.3V only. I built a special circuits with two additional IC's >> for this... > > I check this! On my Athlon 1800+ / Epoxboard is no Problem, but with > Windows an LCDHype. The Parallel port on this Board provide 5V. Can you test lcd4linux on this machine? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: juergen <ju...@wi...> - 2004-03-26 11:07:08
|
Sorry, i've forgotten something.... Version 0.10.0 starting plugin_cfg.c: Variable minute = '60000' (60000.000000) plugin_cfg.c: Variable tack = '100' (100.000000) plugin_cfg.c: Variable tick = '500' (500.000000) lcd4linux.c: initializing driver T6963 T6963: using model 'generic' udelay.c: using gettimeofday() delay loop drv_generic_parport.c: using raw port 0x378 T6963: wiring: [DISPLAY:CE]<==>[PARPORT:AUTOFD] T6963: wiring: [DISPLAY:CD]<==>[PARPORT:INIT] T6963: wiring: [DISPLAY:RD]<==>[PARPORT:SELECT] T6963: wiring: [DISPLAY:WR]<==>[PARPORT:STROBE] drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 ...... *snip* drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 320 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 320 drv_T6963.c: hang in status2 ...... *snip* drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 319 of 320 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 2560 drv_T6963.c: hang in status2 ...... *snip* drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2559 of 2560 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 320 drv_T6963.c: hang in status2 ...... *snip* drv_T6963.c: bug occured at byte 319 of 320 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 2560 drv_T6963.c: hang in status2 ...... *snip* drv_T6963.c: bug occured at byte 2559 of 2560 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 initializing layout 'L24x8' lcd4linux.c: starting main loop drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 3 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 4 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 7 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 8 of 10, addr=0 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 3 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 4 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 8 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 9 of 10, addr=40 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 4 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 7 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 8 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 9 of 10, addr=80 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 3 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 7 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 8 of 10, addr=120 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 4 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 7 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 8 of 9, addr=160 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 1 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 2 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 3 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 4 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 7 of 9, addr=200 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 10, addr=240 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 5 of 10, addr=240 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 6 of 10, addr=240 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=10 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=50 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=90 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=130 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=170 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=210 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=250 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 ...... *snip* drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 2, addr=55 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 2, addr=95 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 2, addr=135 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in status2 drv_T6963.c: bug occured at byte 0 of 1, addr=15 drv_T6963.c: hang in status2 drv_T6963.c: hang in status1 drv_T6963.c: hang in status1 drv_T6963.c: hang in >>>Break with CNTRL + C Segmentation fault |
From: juergen <ju...@wi...> - 2004-03-26 10:56:35
|
Hi Michael, Michael Reinelt wrote: > Hi Juergen, > >> i have some problems with the 0.9.11 Version. >> Display Hitachi LMG7420 240x128pixel T6963 Chip. >> Redhat 8 on a 466Celeron Maschine with 256MB Ram >> lcd4linux.conf: >> >> Display TLC1091 >> Port 0x378 (/dev/ppdev does not work :-( ) > > It should be /dev/parport0 (old /dev structure) or /dev/parport/0 (devfs) > No device! > >> Compilling is ok. But when I start lcd4linux the proggy needs up to >> 1min to Display something! >> My CPU Usage is over 50% for lcd4linux!!!! >> The last 4 columns are only mismatch... :-( > > > Hmmm... my T6963 works fine, without noticeable CPU load (but I've > much faster machines than you). > > Could you try running lcd4linux with debug enabled (lcd4linux -Fvv) > and check for some strange errors? > Yes i do. See at the end of the Mail. > Maybe you want to try the CVS version (but be warned that it is very > different from 0.9, take a look at lcd4linux.conf.sample) > Now, i try the CVS version since Yesterday. It's exact the same Problem. > Another point may be that the T6963 is very sensitive to signal > levels. It uses TTL levels (0V/5V), where many newer parallel ports > provide 3.3V only. I built a special circuits with two additional IC's > for this... I check this! On my Athlon 1800+ / Epoxboard is no Problem, but with Windows an LCDHype. The Parallel port on this Board provide 5V. > > bye, Michael > Bye, Juergen |
From: Michael R. <re...@eu...> - 2004-03-26 06:58:04
|
Hi Juergen, > i have some problems with the 0.9.11 Version. > Display Hitachi LMG7420 240x128pixel T6963 Chip. > Redhat 8 on a 466Celeron Maschine with 256MB Ram > lcd4linux.conf: > > Display TLC1091 > Port 0x378 (/dev/ppdev does not work :-( ) It should be /dev/parport0 (old /dev structure) or /dev/parport/0 (devfs) > Compilling is ok. But when I start lcd4linux the proggy needs up to 1min > to Display something! > My CPU Usage is over 50% for lcd4linux!!!! > The last 4 columns are only mismatch... :-( Hmmm... my T6963 works fine, without noticeable CPU load (but I've much faster machines than you). Could you try running lcd4linux with debug enabled (lcd4linux -Fvv) and check for some strange errors? Maybe you want to try the CVS version (but be warned that it is very different from 0.9, take a look at lcd4linux.conf.sample) Another point may be that the T6963 is very sensitive to signal levels. It uses TTL levels (0V/5V), where many newer parallel ports provide 3.3V only. I built a special circuits with two additional IC's for this... bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Juergen W. <ju...@wi...> - 2004-03-24 11:32:06
|
Hello, i have some problems with the 0.9.11 Version. Display Hitachi LMG7420 240x128pixel T6963 Chip. Redhat 8 on a 466Celeron Maschine with 256MB Ram lcd4linux.conf: Display TLC1091 Port 0x378 (/dev/ppdev does not work :-( ) Size 40x16 Wire.CE AUTOFD Wire.CD INIT Wire.RD SELECT Wire.WR STROBE Reset on Ground Compilling is ok. But when I start lcd4linux the proggy needs up to 1min to Display something! My CPU Usage is over 50% for lcd4linux!!!! The last 4 columns are only mismatch... :-( When i run LCDproc the CPU Usage is only up to 4%! But the last 4 columns the same mismatch. First I think the Display is not ok. But when i connect the Display to a Windows Maschine and run Lcdhype the complette Display work!!! What's wrong? Greetings Juergen |
From: Michael R. <re...@eu...> - 2004-03-17 06:26:21
|
Hi Stolz, > Is the scroll feature ported to the CVS version? > If afirmative, how can I use it? No, it isn't. The concept is fundamental different: The NextGeneration uses two framebuffers (one for the layout, one for the display) which can be of different size. To scroll either horizontal or vertical, you just have to change the offset. But bthis is not implemented at the moment. Xavier, can you add this to our Todo-List? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
From: Stolz <st...@ya...> - 2004-03-16 16:32:53
|
Hi. Is the scroll feature ported to the CVS version? If afirmative, how can I use it? Thanks. Bye. |
From: Michael R. <re...@eu...> - 2004-03-14 12:55:35
|
Hi Marco, > It works with LCDHYPE on Windows ! > And it works fine ! Fine. But I'm afraid this will be not of much help for Benjamin. If it works with windows, this means that neither the display nor the parallel port have a problem, and that there is a working wiring scheme. But this is valid for _your_ computer, _your_ wiring, and _your_ display. Benjamin may have another display, another PC and another wiring. Benjamin, do you have a possibility to try LCDHYPE? (whatever this is...) bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |