From: Enrico S. <enr...@gm...> - 2003-11-06 12:37:55
|
Hi Paul, The line 259, cvs v1.7 is the place where I put if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; The question is how to implement this check using a more generic Min/Max if-clause. I am thinking about a combination with the table usb_remote_id_table. if we have the index of the current device in the struct. we could use this index as an index into a second table containing the min/max-values. If we do not have the index we may use a table containing the min/max values and as index the minor usb device id if it is stored somewhere. for most devices the pair would be min 4 / max 4 but for the device 0x0005 it would be min 4 / max 5. I will test the new version this evening. Thanks Enrico > Hi Enrico, > > Please try updating to the latest cvs again (delete your old file > first). I think I have the -EIO problem fixed. > > Also, how did you change the code to support both 4 and 5 bytes? The > only place it actually compares the bytes received is in > usb_remote_irq() with "if (urb->actual_length != ir->p->code_length/8) > return" (line 259, cvs v1.7). > > -Paul > > > On Wednesday 05 November 2003 2:44 pm, you wrote: > > Hello Paul, > > > > I am using already the current CVS version of lirc, but i changed the > > code to > support both 4 and 5 bytes in this if-clause. > > Using the modified if-clause i could use lirc - but only one time. > > > > All output is made with CONFIG_USB_DEBUG enabled. > > > > When starting irw and pressing some keys on the remote I am getting > > the > following syslog output: > > > > >>> > > > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > ... > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec > > <<< > > irw does report the correct codes. > > > > after terminating irw and starting it a second time I am getting the > > following > output: > > > > >>> > > > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > > ca0d5c64, > burb ca0d5c64 > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error > > submitting > urb > > <<< > > irw terminates without a message. > > > > starting irw a third time results in a > > > > >>> > > > > connect: Connection refused > > <<< > > and no message on syslog. > > > > after restarting the usb stack an doing the same againg with irrecord > > i am > getting the following output: > > > > >>> > > > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > ... > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > > c388ae84, > burb c388ae84 > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error > > submitting > urb > > <<< > > irrecord prints the following message: > > > > >>> > > > > irrecord: could not open /dev/lirc > > irrecord: default_init(): Input/output error > > irrecord: could not reset hardware. > > <<< > > It seems to me that irrecord opens a new lirc session after closing > > the old > one... > > > > with the original if-clause... > > > > changing bytes_in_key did not work. > > > > initializing bytes_in_key with 4 results in: > > ir->p->code_length==32 > > with 5 in: > > ir->p->code_length==40 > > in combination with urb->actual_length the result is that in the > > first case > only 4-byte codes are accepted. in the second case - > > instead of accepting only 5 byte long codes - the driver could not be > > initialised ... but this could be an other problem. > > > > I am leaving the modified if-clause but the > > "only-one-time-use"-problem is not > solved. > > I think there should be a better solution for the if-clause because > > my > modified one is very rigid. I don't know whether it is possible > > to implement the "possible counts of bits/bytes" in the > > usb_remote_id_table. > > The syslog shows the following when initialising the usb stack > > (CONFIG_USB_DEBUG enabled): > > > > >>> > > > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time > > 12:38:59 Oct > 3 2003 > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode enabled > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ > > 11 > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > > bus number > 1 > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ > > 11 > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > > bus number > 2 > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host > > Controller > Interface driver > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: usb-uhci > > Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host Controller > > Interface > driver v1.1 > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, assigned > > address > 2 > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod 0xbc7/0x5) > > is not > claimed by any active driver. > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver > > registered, at > major 61 > > Nov 5 21:16:38 amd kernel: > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC > > v0.1 > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller > > <pmi...@us...> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, frame# > > 1482 > Nov 5 21:16:38 amd kernel: lirc_dev: > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > Nov 5 21:16:38 amd insmod: Using > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o > Nov 5 21:16:38 amd insmod: > > Symbol version prefix '' > > Nov 5 21:16:38 amd insmod: Using > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o > <<< > > > > thanks a lot > > > > Enrico > > > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: > > > > > Enrico, > > > Could you please try using the latest CVS version of LIRC? The > > > check you > mentioned for urb->actual_length is not in the latest > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) if > > > the default of 4 doesn't work. > > > > > > Please send me the full debug output (load the driver w/ debug=1) > > > and > /proc/bus/usb/devices. > > > > > > Thanks, > > > -Paul > > > > > > > > > > Hello, > > > > > > > > I have an Q-Sonic Master Remote PC / TV from the german > > > > distributor Pearl > Agency. The USB Receiver gives the atached > > > > usbview output. The file /proc/bus/usb/devices is also atached. > > > > > > > > I have the problem that my some keys have 5 bytes and some 4 > > > > bytes > (urb->actual_length) in usb_remote_irq. > > > > the if clause testing these variable fails therefore. > > > > but an > > > > > > > > if ((urb->actual_length != 4) && (urb->actual_length != > > > > 5)) > return; > > > > << > > > > does also not work. this seems not the only problem. > > > > > > > > The second problem is that i have to reload the complete usb > > > > stack after > every > > > > time a program used lirc. This happens also when using irrecord. > > > > The syslog says: > > > > > > > > lirc_unregister_plugin:minor (0) device not > > > > registered!lirc_usb[2]: > didn't free resources > > > > << > > > > > > > > Thanks a lot > > > > > > > > Enrico > > > > > > -- > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > Sicherheit zu gewinnen, wird beides verlieren." > > - - Benjamin Franklin > > > > > -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
From: Enrico S. <enr...@gm...> - 2003-11-06 22:03:11
|
Hi Paul again, I am using now the current cvs version. It works as far as I do not get any error message from irw and I could start it again and again - Thanks. The contra is that lircd has about 99% cpu load... and irw does not print the codes to stdout. irrecord gives the following message: irrecord: reading in mode LIRC_MODE_LIRCCODE failed the output of strace of lircd (started with -n) when hanging in the loop gives: >>> gettimeofday({1068155794, 292700}, NULL) = 0 select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) gettimeofday({1068155794, 292794}, NULL) = 0 read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) time([1068155794]) = 1068155794 write(2, "lircd 0.6.6: ", 13) = 13 write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 <<< and the following on stdout: >>> lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed <<< Thanks Enrico Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: > Hi Paul, > > The line 259, cvs v1.7 is the place where I put > > if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; > > The question is how to implement this check using a more generic Min/Max > if-clause. > I am thinking about a combination with the table usb_remote_id_table. > if we have the index of the current device in the struct. we could use this > index as an index into a second table containing the min/max-values. > If we do not have the index we may use a table containing the min/max > values and as index the minor usb device id if it is stored somewhere. > for most devices the pair would be min 4 / max 4 but for the device 0x0005 > it would be min 4 / max 5. > > I will test the new version this evening. > > Thanks > > Enrico > > > Hi Enrico, > > > > Please try updating to the latest cvs again (delete your old file > > first). I think I have the -EIO problem fixed. > > > > Also, how did you change the code to support both 4 and 5 bytes? The > > only place it actually compares the bytes received is in > > usb_remote_irq() with "if (urb->actual_length != ir->p->code_length/8) > > return" (line 259, cvs v1.7). > > > > -Paul > > > > On Wednesday 05 November 2003 2:44 pm, you wrote: > > > Hello Paul, > > > > > > I am using already the current CVS version of lirc, but i changed the > > > code to > > > > support both 4 and 5 bytes in this if-clause. > > > > > Using the modified if-clause i could use lirc - but only one time. > > > > > > All output is made with CONFIG_USB_DEBUG enabled. > > > > > > When starting irw and pressing some keys on the remote I am getting > > > the > > > > following syslog output: > > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc > > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > > ... > > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec > > > <<< > > > irw does report the correct codes. > > > > > > after terminating irw and starting it a second time I am getting the > > > following > > > > output: > > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc > > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > > > ca0d5c64, > > > > burb ca0d5c64 > > > > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error > > > submitting > > > > urb > > > > > <<< > > > irw terminates without a message. > > > > > > starting irw a third time results in a > > > > > > > > > > > > connect: Connection refused > > > <<< > > > and no message on syslog. > > > > > > after restarting the usb stack an doing the same againg with irrecord > > > i am > > > > getting the following output: > > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc > > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > > ... > > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec > > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc > > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > > > c388ae84, > > > > burb c388ae84 > > > > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error > > > submitting > > > > urb > > > > > <<< > > > irrecord prints the following message: > > > > > > > > > > > > irrecord: could not open /dev/lirc > > > irrecord: default_init(): Input/output error > > > irrecord: could not reset hardware. > > > <<< > > > It seems to me that irrecord opens a new lirc session after closing > > > the old > > > > one... > > > > > with the original if-clause... > > > > > > changing bytes_in_key did not work. > > > > > > initializing bytes_in_key with 4 results in: > > > ir->p->code_length==32 > > > with 5 in: > > > ir->p->code_length==40 > > > in combination with urb->actual_length the result is that in the > > > first case > > > > only 4-byte codes are accepted. in the second case - > > > > > instead of accepting only 5 byte long codes - the driver could not be > > > initialised ... but this could be an other problem. > > > > > > I am leaving the modified if-clause but the > > > "only-one-time-use"-problem is not > > > > solved. > > > > > I think there should be a better solution for the if-clause because > > > my > > > > modified one is very rigid. I don't know whether it is possible > > > > > to implement the "possible counts of bits/bytes" in the > > > usb_remote_id_table. > > > The syslog shows the following when initialising the usb stack > > > (CONFIG_USB_DEBUG enabled): > > > > > > > > > > > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs > > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time > > > 12:38:59 Oct > > > > 3 2003 > > > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode enabled > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ > > > 11 > > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > > > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > > > bus number > > > > 1 > > > > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ > > > 11 > > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > > > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > > > bus number > > > > 2 > > > > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host > > > Controller > > > > Interface driver > > > > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: usb-uhci > > > Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host Controller > > > Interface > > > > driver v1.1 > > > > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, assigned > > > address > > > > 2 > > > > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod 0xbc7/0x5) > > > is not > > > > claimed by any active driver. > > > > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver > > > registered, at > > > > major 61 > > > > > Nov 5 21:16:38 amd kernel: > > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC > > > v0.1 > > > > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller > > > > > <pmi...@us...> > > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled > > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb > > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called > > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, frame# > > > 1482 > > > > Nov 5 21:16:38 amd kernel: lirc_dev: > > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: > > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > > Nov 5 21:16:38 amd insmod: Using > > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o > > > > Nov 5 21:16:38 amd insmod: > > > Symbol version prefix '' > > > Nov 5 21:16:38 amd insmod: Using > > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o > > > > <<< > > > > > thanks a lot > > > > > > Enrico > > > > > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: > > > > Enrico, > > > > Could you please try using the latest CVS version of LIRC? The > > > > check you > > > > mentioned for urb->actual_length is not in the latest > > > > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) if > > > > the default of 4 doesn't work. > > > > > > > > Please send me the full debug output (load the driver w/ debug=1) > > > > and > > > > /proc/bus/usb/devices. > > > > > > Thanks, > > > > -Paul > > > > > > > > > Hello, > > > > > > > > > > I have an Q-Sonic Master Remote PC / TV from the german > > > > > distributor Pearl > > > > Agency. The USB Receiver gives the atached > > > > > > > usbview output. The file /proc/bus/usb/devices is also atached. > > > > > > > > > > I have the problem that my some keys have 5 bytes and some 4 > > > > > bytes > > > > (urb->actual_length) in usb_remote_irq. > > > > > > > the if clause testing these variable fails therefore. > > > > > but an > > > > > > > > > > if ((urb->actual_length != 4) && (urb->actual_length != > > > > > 5)) > > > > return; > > > > > > > << > > > > > does also not work. this seems not the only problem. > > > > > > > > > > The second problem is that i have to reload the complete usb > > > > > stack after > > > > every > > > > > > > time a program used lirc. This happens also when using irrecord. > > > > > The syslog says: > > > > > > > > > > lirc_unregister_plugin:minor (0) device not > > > > > registered!lirc_usb[2]: > > > > didn't free resources > > > > > > > << > > > > > > > > > > Thanks a lot > > > > > > > > > > Enrico > > > > > > -- > > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > > Sicherheit zu gewinnen, wird beides verlieren." > > > - - Benjamin Franklin -- "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren." - - Benjamin Franklin |
From: Paul M. <pmi...@us...> - 2003-11-06 23:44:01
|
Are you mixing lirc cvs and version 0.6.6? It sure looks like it. Please uninstall version 0.6.6 before trying the cvs version. -Paul > Hi Paul again, > > I am using now the current cvs version. It works as far as I do not get > any > error message from irw and I could start it again and again - Thanks. The > contra is that lircd has about 99% cpu load... and irw does not print the > codes to stdout. irrecord gives the following message: > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed > > the output of strace of lircd (started with -n) when hanging in the loop > gives: >>>> > gettimeofday({1068155794, 292700}, NULL) = 0 > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) > gettimeofday({1068155794, 292794}, NULL) = 0 > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) > time([1068155794]) = 1068155794 > write(2, "lircd 0.6.6: ", 13) = 13 > write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 > write(2, ptrace: umoven: Input/output error > 0x40159f27, 1) = 1 > <<< > and the following on stdout: >>>> > lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed > <<< > > Thanks > > Enrico > > > Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: >> Hi Paul, >> >> The line 259, cvs v1.7 is the place where I put >> >> if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; >> >> The question is how to implement this check using a more generic Min/Max >> if-clause. >> I am thinking about a combination with the table usb_remote_id_table. >> if we have the index of the current device in the struct. we could use >> this >> index as an index into a second table containing the min/max-values. >> If we do not have the index we may use a table containing the min/max >> values and as index the minor usb device id if it is stored somewhere. >> for most devices the pair would be min 4 / max 4 but for the device >> 0x0005 >> it would be min 4 / max 5. >> >> I will test the new version this evening. >> >> Thanks >> >> Enrico >> >> > Hi Enrico, >> > >> > Please try updating to the latest cvs again (delete your old file >> > first). I think I have the -EIO problem fixed. >> > >> > Also, how did you change the code to support both 4 and 5 bytes? The >> > only place it actually compares the bytes received is in >> > usb_remote_irq() with "if (urb->actual_length != ir->p->code_length/8) >> > return" (line 259, cvs v1.7). >> > >> > -Paul >> > >> > On Wednesday 05 November 2003 2:44 pm, you wrote: >> > > Hello Paul, >> > > >> > > I am using already the current CVS version of lirc, but i changed >> the >> > > code to >> > >> > support both 4 and 5 bytes in this if-clause. >> > >> > > Using the modified if-clause i could use lirc - but only one time. >> > > >> > > All output is made with CONFIG_USB_DEBUG enabled. >> > > >> > > When starting irw and pressing some keys on the remote I am getting >> > > the >> > >> > following syslog output: >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called >> > > ... >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called >> > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec >> > > <<< >> > > irw does report the correct codes. >> > > >> > > after terminating irw and starting it a second time I am getting the >> > > following >> > >> > output: >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc >> > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb >> > > ca0d5c64, >> > >> > burb ca0d5c64 >> > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error >> > > submitting >> > >> > urb >> > >> > > <<< >> > > irw terminates without a message. >> > > >> > > starting irw a third time results in a >> > > >> > > >> > > >> > > connect: Connection refused >> > > <<< >> > > and no message on syslog. >> > > >> > > after restarting the usb stack an doing the same againg with >> irrecord >> > > i am >> > >> > getting the following output: >> > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called >> > > ... >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc >> > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb >> > > c388ae84, >> > >> > burb c388ae84 >> > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error >> > > submitting >> > >> > urb >> > >> > > <<< >> > > irrecord prints the following message: >> > > >> > > >> > > >> > > irrecord: could not open /dev/lirc >> > > irrecord: default_init(): Input/output error >> > > irrecord: could not reset hardware. >> > > <<< >> > > It seems to me that irrecord opens a new lirc session after closing >> > > the old >> > >> > one... >> > >> > > with the original if-clause... >> > > >> > > changing bytes_in_key did not work. >> > > >> > > initializing bytes_in_key with 4 results in: >> > > ir->p->code_length==32 >> > > with 5 in: >> > > ir->p->code_length==40 >> > > in combination with urb->actual_length the result is that in the >> > > first case >> > >> > only 4-byte codes are accepted. in the second case - >> > >> > > instead of accepting only 5 byte long codes - the driver could not >> be >> > > initialised ... but this could be an other problem. >> > > >> > > I am leaving the modified if-clause but the >> > > "only-one-time-use"-problem is not >> > >> > solved. >> > >> > > I think there should be a better solution for the if-clause because >> > > my >> > >> > modified one is very rigid. I don't know whether it is possible >> > >> > > to implement the "possible counts of bits/bytes" in the >> > > usb_remote_id_table. >> > > The syslog shows the following when initialising the usb stack >> > > (CONFIG_USB_DEBUG enabled): >> > > >> > > >> > > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time >> > > 12:38:59 Oct >> > >> > 3 2003 >> > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode enabled >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ >> > > 11 >> > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned >> > > bus number >> > >> > 1 >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ >> > > 11 >> > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned >> > > bus number >> > >> > 2 >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host >> > > Controller >> > >> > Interface driver >> > >> > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: usb-uhci >> > > Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host Controller >> > > Interface >> > >> > driver v1.1 >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, >> assigned >> > > address >> > >> > 2 >> > >> > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod >> 0xbc7/0x5) >> > > is not >> > >> > claimed by any active driver. >> > >> > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver >> > > registered, at >> > >> > major 61 >> > >> > > Nov 5 21:16:38 amd kernel: >> > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC >> > > v0.1 >> > >> > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller >> > >> > > <pmi...@us...> >> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled >> > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb >> > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called >> > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, frame# >> > > 1482 >> > >> > Nov 5 21:16:38 amd kernel: lirc_dev: >> > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: >> > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > > Nov 5 21:16:38 amd insmod: Using >> > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o >> > >> > Nov 5 21:16:38 amd insmod: >> > > Symbol version prefix '' >> > > Nov 5 21:16:38 amd insmod: Using >> > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o >> > >> > <<< >> > >> > > thanks a lot >> > > >> > > Enrico >> > > >> > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: >> > > > Enrico, >> > > > Could you please try using the latest CVS version of LIRC? The >> > > > check you >> > >> > mentioned for urb->actual_length is not in the latest >> > >> > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) if >> > > > the default of 4 doesn't work. >> > > > >> > > > Please send me the full debug output (load the driver w/ debug=1) >> > > > and >> > >> > /proc/bus/usb/devices. >> > >> > > > Thanks, >> > > > -Paul >> > > > >> > > > > Hello, >> > > > > >> > > > > I have an Q-Sonic Master Remote PC / TV from the german >> > > > > distributor Pearl >> > >> > Agency. The USB Receiver gives the atached >> > >> > > > > usbview output. The file /proc/bus/usb/devices is also atached. >> > > > > >> > > > > I have the problem that my some keys have 5 bytes and some 4 >> > > > > bytes >> > >> > (urb->actual_length) in usb_remote_irq. >> > >> > > > > the if clause testing these variable fails therefore. >> > > > > but an >> > > > > >> > > > > if ((urb->actual_length != 4) && (urb->actual_length != >> > > > > 5)) >> > >> > return; >> > >> > > > > << >> > > > > does also not work. this seems not the only problem. >> > > > > >> > > > > The second problem is that i have to reload the complete usb >> > > > > stack after >> > >> > every >> > >> > > > > time a program used lirc. This happens also when using irrecord. >> > > > > The syslog says: >> > > > > >> > > > > lirc_unregister_plugin:minor (0) device not >> > > > > registered!lirc_usb[2]: >> > >> > didn't free resources >> > >> > > > > << >> > > > > >> > > > > Thanks a lot >> > > > > >> > > > > Enrico >> > > >> > > -- >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um >> > > Sicherheit zu gewinnen, wird beides verlieren." >> > > - - Benjamin Franklin > > -- > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > Sicherheit zu gewinnen, wird beides verlieren." > - - Benjamin Franklin > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > |
From: Enrico S. <enr...@gm...> - 2003-11-07 20:22:22
|
Hello Paul, Yeah, I had two versions of lirc on my system, but removing all and reinstalling did nor resolve the problem :-( The output of strace again: >>> gettimeofday({1068236441, 372085}, NULL) = 0 select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) gettimeofday({1068236441, 372178}, NULL) = 0 read(7, 0xbffff4c0, 5) = -1 EINVAL (Invalid argument) time([1068236441]) = 1068236441 write(2, "lircd 0.7.0pre1: ", 17) = 17 write(5, "Nov 7 21:20:41 amd lircd 0.7.0p"..., 79) = 79 write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 <<< Thanks Enrico Am Freitag, 7. November 2003 00:43 schrieb Paul Miller: > Are you mixing lirc cvs and version 0.6.6? It sure looks like it. Please > uninstall version 0.6.6 before trying the cvs version. > > -Paul > > > Hi Paul again, > > > > I am using now the current cvs version. It works as far as I do not get > > any > > error message from irw and I could start it again and again - Thanks. The > > contra is that lircd has about 99% cpu load... and irw does not print the > > codes to stdout. irrecord gives the following message: > > > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed > > > > the output of strace of lircd (started with -n) when hanging in the loop > > gives: > > > > gettimeofday({1068155794, 292700}, NULL) = 0 > > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) > > gettimeofday({1068155794, 292794}, NULL) = 0 > > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) > > time([1068155794]) = 1068155794 > > write(2, "lircd 0.6.6: ", 13) = 13 > > write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 > > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 > > write(2, ptrace: umoven: Input/output error > > 0x40159f27, 1) = 1 > > <<< > > and the following on stdout: > > > > lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed > > <<< > > > > Thanks > > > > Enrico > > > > Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: > >> Hi Paul, > >> > >> The line 259, cvs v1.7 is the place where I put > >> > >> if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; > >> > >> The question is how to implement this check using a more generic Min/Max > >> if-clause. > >> I am thinking about a combination with the table usb_remote_id_table. > >> if we have the index of the current device in the struct. we could use > >> this > >> index as an index into a second table containing the min/max-values. > >> If we do not have the index we may use a table containing the min/max > >> values and as index the minor usb device id if it is stored somewhere. > >> for most devices the pair would be min 4 / max 4 but for the device > >> 0x0005 > >> it would be min 4 / max 5. > >> > >> I will test the new version this evening. > >> > >> Thanks > >> > >> Enrico > >> > >> > Hi Enrico, > >> > > >> > Please try updating to the latest cvs again (delete your old file > >> > first). I think I have the -EIO problem fixed. > >> > > >> > Also, how did you change the code to support both 4 and 5 bytes? The > >> > only place it actually compares the bytes received is in > >> > usb_remote_irq() with "if (urb->actual_length != ir->p->code_length/8) > >> > return" (line 259, cvs v1.7). > >> > > >> > -Paul > >> > > >> > On Wednesday 05 November 2003 2:44 pm, you wrote: > >> > > Hello Paul, > >> > > > >> > > I am using already the current CVS version of lirc, but i changed > >> > >> the > >> > >> > > code to > >> > > >> > support both 4 and 5 bytes in this if-clause. > >> > > >> > > Using the modified if-clause i could use lirc - but only one time. > >> > > > >> > > All output is made with CONFIG_USB_DEBUG enabled. > >> > > > >> > > When starting irw and pressing some keys on the remote I am getting > >> > > the > >> > > >> > following syslog output: > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > >> > > ... > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > >> > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec > >> > > <<< > >> > > irw does report the correct codes. > >> > > > >> > > after terminating irw and starting it a second time I am getting the > >> > > following > >> > > >> > output: > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > >> > > ca0d5c64, > >> > > >> > burb ca0d5c64 > >> > > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error > >> > > submitting > >> > > >> > urb > >> > > >> > > <<< > >> > > irw terminates without a message. > >> > > > >> > > starting irw a third time results in a > >> > > > >> > > > >> > > > >> > > connect: Connection refused > >> > > <<< > >> > > and no message on syslog. > >> > > > >> > > after restarting the usb stack an doing the same againg with > >> > >> irrecord > >> > >> > > i am > >> > > >> > getting the following output: > >> > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > >> > > ... > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc > >> > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, urb > >> > > c388ae84, > >> > > >> > burb c388ae84 > >> > > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error > >> > > submitting > >> > > >> > urb > >> > > >> > > <<< > >> > > irrecord prints the following message: > >> > > > >> > > > >> > > > >> > > irrecord: could not open /dev/lirc > >> > > irrecord: default_init(): Input/output error > >> > > irrecord: could not reset hardware. > >> > > <<< > >> > > It seems to me that irrecord opens a new lirc session after closing > >> > > the old > >> > > >> > one... > >> > > >> > > with the original if-clause... > >> > > > >> > > changing bytes_in_key did not work. > >> > > > >> > > initializing bytes_in_key with 4 results in: > >> > > ir->p->code_length==32 > >> > > with 5 in: > >> > > ir->p->code_length==40 > >> > > in combination with urb->actual_length the result is that in the > >> > > first case > >> > > >> > only 4-byte codes are accepted. in the second case - > >> > > >> > > instead of accepting only 5 byte long codes - the driver could not > >> > >> be > >> > >> > > initialised ... but this could be an other problem. > >> > > > >> > > I am leaving the modified if-clause but the > >> > > "only-one-time-use"-problem is not > >> > > >> > solved. > >> > > >> > > I think there should be a better solution for the if-clause because > >> > > my > >> > > >> > modified one is very rigid. I don't know whether it is possible > >> > > >> > > to implement the "possible counts of bits/bytes" in the > >> > > usb_remote_id_table. > >> > > The syslog shows the following when initialising the usb stack > >> > > (CONFIG_USB_DEBUG enabled): > >> > > > >> > > > >> > > > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time > >> > > 12:38:59 Oct > >> > > >> > 3 2003 > >> > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode enabled > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ > >> > > 11 > >> > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > >> > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > >> > > bus number > >> > > >> > 1 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ > >> > > 11 > >> > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > >> > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, assigned > >> > > bus number > >> > > >> > 2 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host > >> > > Controller > >> > > >> > Interface driver > >> > > >> > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: usb-uhci > >> > > Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host Controller > >> > > Interface > >> > > >> > driver v1.1 > >> > > >> > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, > >> > >> assigned > >> > >> > > address > >> > > >> > 2 > >> > > >> > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod > >> > >> 0xbc7/0x5) > >> > >> > > is not > >> > > >> > claimed by any active driver. > >> > > >> > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver > >> > > registered, at > >> > > >> > major 61 > >> > > >> > > Nov 5 21:16:38 amd kernel: > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC > >> > > v0.1 > >> > > >> > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller > >> > > >> > > <pmi...@us...> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled > >> > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called > >> > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, frame# > >> > > 1482 > >> > > >> > Nov 5 21:16:38 amd kernel: lirc_dev: > >> > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: > >> > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > >> > > Nov 5 21:16:38 amd insmod: Using > >> > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o > >> > > >> > Nov 5 21:16:38 amd insmod: > >> > > Symbol version prefix '' > >> > > Nov 5 21:16:38 amd insmod: Using > >> > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o > >> > > >> > <<< > >> > > >> > > thanks a lot > >> > > > >> > > Enrico > >> > > > >> > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: > >> > > > Enrico, > >> > > > Could you please try using the latest CVS version of LIRC? The > >> > > > check you > >> > > >> > mentioned for urb->actual_length is not in the latest > >> > > >> > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) if > >> > > > the default of 4 doesn't work. > >> > > > > >> > > > Please send me the full debug output (load the driver w/ debug=1) > >> > > > and > >> > > >> > /proc/bus/usb/devices. > >> > > >> > > > Thanks, > >> > > > -Paul > >> > > > > >> > > > > Hello, > >> > > > > > >> > > > > I have an Q-Sonic Master Remote PC / TV from the german > >> > > > > distributor Pearl > >> > > >> > Agency. The USB Receiver gives the atached > >> > > >> > > > > usbview output. The file /proc/bus/usb/devices is also atached. > >> > > > > > >> > > > > I have the problem that my some keys have 5 bytes and some 4 > >> > > > > bytes > >> > > >> > (urb->actual_length) in usb_remote_irq. > >> > > >> > > > > the if clause testing these variable fails therefore. > >> > > > > but an > >> > > > > > >> > > > > if ((urb->actual_length != 4) && (urb->actual_length != > >> > > > > 5)) > >> > > >> > return; > >> > > >> > > > > << > >> > > > > does also not work. this seems not the only problem. > >> > > > > > >> > > > > The second problem is that i have to reload the complete usb > >> > > > > stack after > >> > > >> > every > >> > > >> > > > > time a program used lirc. This happens also when using irrecord. > >> > > > > The syslog says: > >> > > > > > >> > > > > lirc_unregister_plugin:minor (0) device not > >> > > > > registered!lirc_usb[2]: > >> > > >> > didn't free resources > >> > > >> > > > > << > >> > > > > > >> > > > > Thanks a lot > >> > > > > > >> > > > > Enrico > >> > > > >> > > -- > >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > >> > > Sicherheit zu gewinnen, wird beides verlieren." > >> > > - - Benjamin Franklin > > > > -- > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > Sicherheit zu gewinnen, wird beides verlieren." > > - - Benjamin Franklin > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ -- "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren." - - Benjamin Franklin |
From: Enrico S. <enr...@gm...> - 2003-11-08 07:41:15
|
Hello Paul, with the latest cvs the message output changed a bit... <<< Nov 8 08:16:47 amd kernel: lirc_atiusb[2]: set use inc Nov 8 08:16:47 amd kernel: lirc_atiusb[2]: data received (length 1) Nov 8 08:17:03 amd kernel: lirc_atiusb[2]: data received (length 4) Nov 8 08:17:03 amd last message repeated 3 times Nov 8 08:17:21 amd kernel: lirc_atiusb[2]: data received (length 5) Nov 8 08:17:36 amd last message repeated 5 times Nov 8 08:17:40 amd kernel: lirc_atiusb[2]: set use dec >>> I don't know where the length 1 came from but it appears when starting irw the first time. length 4 and 5 are my key presses on the remote. lircd does not hang anymore - instead it does nothing else than waiting... here comes the strace <<< select(8, [4 6 7], NULL, NULL, NULL) >>> irw does nothing too :-( Regards Enrico Am Freitag, 7. November 2003 21:22 schrieb Enrico Schnepel: > Hello Paul, > > Yeah, I had two versions of lirc on my system, but removing all and > reinstalling did nor resolve the problem :-( > The output of strace again: > > gettimeofday({1068236441, 372085}, NULL) = 0 > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) > gettimeofday({1068236441, 372178}, NULL) = 0 > read(7, 0xbffff4c0, 5) = -1 EINVAL (Invalid argument) > time([1068236441]) = 1068236441 > write(2, "lircd 0.7.0pre1: ", 17) = 17 > write(5, "Nov 7 21:20:41 amd lircd 0.7.0p"..., 79) = 79 > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 > write(2, ptrace: umoven: Input/output error > 0x40159f27, 1) = 1 > <<< > > Thanks Enrico > > Am Freitag, 7. November 2003 00:43 schrieb Paul Miller: > > Are you mixing lirc cvs and version 0.6.6? It sure looks like it. > > Please uninstall version 0.6.6 before trying the cvs version. > > > > -Paul > > > > > Hi Paul again, > > > > > > I am using now the current cvs version. It works as far as I do not get > > > any > > > error message from irw and I could start it again and again - Thanks. > > > The contra is that lircd has about 99% cpu load... and irw does not > > > print the codes to stdout. irrecord gives the following message: > > > > > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed > > > > > > the output of strace of lircd (started with -n) when hanging in the > > > loop gives: > > > > > > gettimeofday({1068155794, 292700}, NULL) = 0 > > > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) > > > gettimeofday({1068155794, 292794}, NULL) = 0 > > > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) > > > time([1068155794]) = 1068155794 > > > write(2, "lircd 0.6.6: ", 13) = 13 > > > write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 > > > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 > > > write(2, ptrace: umoven: Input/output error > > > 0x40159f27, 1) = 1 > > > <<< > > > and the following on stdout: > > > > > > lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed > > > <<< > > > > > > Thanks > > > > > > Enrico > > > > > > Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: > > >> Hi Paul, > > >> > > >> The line 259, cvs v1.7 is the place where I put > > >> > > >> if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; > > >> > > >> The question is how to implement this check using a more generic > > >> Min/Max if-clause. > > >> I am thinking about a combination with the table usb_remote_id_table. > > >> if we have the index of the current device in the struct. we could use > > >> this > > >> index as an index into a second table containing the min/max-values. > > >> If we do not have the index we may use a table containing the min/max > > >> values and as index the minor usb device id if it is stored somewhere. > > >> for most devices the pair would be min 4 / max 4 but for the device > > >> 0x0005 > > >> it would be min 4 / max 5. > > >> > > >> I will test the new version this evening. > > >> > > >> Thanks > > >> > > >> Enrico > > >> > > >> > Hi Enrico, > > >> > > > >> > Please try updating to the latest cvs again (delete your old file > > >> > first). I think I have the -EIO problem fixed. > > >> > > > >> > Also, how did you change the code to support both 4 and 5 bytes? > > >> > The only place it actually compares the bytes received is in > > >> > usb_remote_irq() with "if (urb->actual_length != > > >> > ir->p->code_length/8) return" (line 259, cvs v1.7). > > >> > > > >> > -Paul > > >> > > > >> > On Wednesday 05 November 2003 2:44 pm, you wrote: > > >> > > Hello Paul, > > >> > > > > >> > > I am using already the current CVS version of lirc, but i changed > > >> > > >> the > > >> > > >> > > code to > > >> > > > >> > support both 4 and 5 bytes in this if-clause. > > >> > > > >> > > Using the modified if-clause i could use lirc - but only one time. > > >> > > > > >> > > All output is made with CONFIG_USB_DEBUG enabled. > > >> > > > > >> > > When starting irw and pressing some keys on the remote I am > > >> > > getting the > > >> > > > >> > following syslog output: > > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc > > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > >> > > ... > > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > >> > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec > > >> > > <<< > > >> > > irw does report the correct codes. > > >> > > > > >> > > after terminating irw and starting it a second time I am getting > > >> > > the following > > >> > > > >> > output: > > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc > > >> > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, > > >> > > urb ca0d5c64, > > >> > > > >> > burb ca0d5c64 > > >> > > > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 error > > >> > > submitting > > >> > > > >> > urb > > >> > > > >> > > <<< > > >> > > irw terminates without a message. > > >> > > > > >> > > starting irw a third time results in a > > >> > > > > >> > > > > >> > > > > >> > > connect: Connection refused > > >> > > <<< > > >> > > and no message on syslog. > > >> > > > > >> > > after restarting the usb stack an doing the same againg with > > >> > > >> irrecord > > >> > > >> > > i am > > >> > > > >> > getting the following output: > > >> > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc > > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called > > >> > > ... > > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called > > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec > > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc > > >> > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags 0, > > >> > > urb c388ae84, > > >> > > > >> > burb c388ae84 > > >> > > > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 error > > >> > > submitting > > >> > > > >> > urb > > >> > > > >> > > <<< > > >> > > irrecord prints the following message: > > >> > > > > >> > > > > >> > > > > >> > > irrecord: could not open /dev/lirc > > >> > > irrecord: default_init(): Input/output error > > >> > > irrecord: could not reset hardware. > > >> > > <<< > > >> > > It seems to me that irrecord opens a new lirc session after > > >> > > closing the old > > >> > > > >> > one... > > >> > > > >> > > with the original if-clause... > > >> > > > > >> > > changing bytes_in_key did not work. > > >> > > > > >> > > initializing bytes_in_key with 4 results in: > > >> > > ir->p->code_length==32 > > >> > > with 5 in: > > >> > > ir->p->code_length==40 > > >> > > in combination with urb->actual_length the result is that in the > > >> > > first case > > >> > > > >> > only 4-byte codes are accepted. in the second case - > > >> > > > >> > > instead of accepting only 5 byte long codes - the driver could not > > >> > > >> be > > >> > > >> > > initialised ... but this could be an other problem. > > >> > > > > >> > > I am leaving the modified if-clause but the > > >> > > "only-one-time-use"-problem is not > > >> > > > >> > solved. > > >> > > > >> > > I think there should be a better solution for the if-clause > > >> > > because my > > >> > > > >> > modified one is very rigid. I don't know whether it is possible > > >> > > > >> > > to implement the "possible counts of bits/bytes" in the > > >> > > usb_remote_id_table. > > >> > > The syslog shows the following when initialising the usb stack > > >> > > (CONFIG_USB_DEBUG enabled): > > >> > > > > >> > > > > >> > > > > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver usbdevfs > > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time > > >> > > 12:38:59 Oct > > >> > > > >> > 3 2003 > > >> > > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode > > >> > > enabled Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O > > >> > > 0xd800, IRQ 11 > > >> > > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > >> > > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, > > >> > > assigned bus number > > >> > > > >> > 1 > > >> > > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, > > >> > > IRQ 11 > > >> > > > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports > > >> > > > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, > > >> > > assigned bus number > > >> > > > >> > 2 > > >> > > > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found > > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected > > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal Host > > >> > > Controller > > >> > > > >> > Interface driver > > >> > > > >> > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: > > >> > > usb-uhci Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host > > >> > > Controller Interface > > >> > > > >> > driver v1.1 > > >> > > > >> > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, > > >> > > >> assigned > > >> > > >> > > address > > >> > > > >> > 2 > > >> > > > >> > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod > > >> > > >> 0xbc7/0x5) > > >> > > >> > > is not > > >> > > > >> > claimed by any active driver. > > >> > > > >> > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver > > >> > > registered, at > > >> > > > >> > major 61 > > >> > > > >> > > Nov 5 21:16:38 amd kernel: > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for LIRC > > >> > > v0.1 > > >> > > > >> > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller > > >> > > > >> > > <pmi...@us...> > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled > > >> > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver lirc_usb > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called > > >> > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, > > >> > > frame# 1482 > > >> > > > >> > Nov 5 21:16:38 amd kernel: lirc_dev: > > >> > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: > > >> > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on usb1:2.0 > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called > > >> > > Nov 5 21:16:38 amd insmod: Using > > >> > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o > > >> > > > >> > Nov 5 21:16:38 amd insmod: > > >> > > Symbol version prefix '' > > >> > > Nov 5 21:16:38 amd insmod: Using > > >> > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o > > >> > > > >> > <<< > > >> > > > >> > > thanks a lot > > >> > > > > >> > > Enrico > > >> > > > > >> > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: > > >> > > > Enrico, > > >> > > > Could you please try using the latest CVS version of LIRC? The > > >> > > > check you > > >> > > > >> > mentioned for urb->actual_length is not in the latest > > >> > > > >> > > > cvs version. Also try changing "bytes_in_key" to 5 (line 323) > > >> > > > if the default of 4 doesn't work. > > >> > > > > > >> > > > Please send me the full debug output (load the driver w/ > > >> > > > debug=1) and > > >> > > > >> > /proc/bus/usb/devices. > > >> > > > >> > > > Thanks, > > >> > > > -Paul > > >> > > > > > >> > > > > Hello, > > >> > > > > > > >> > > > > I have an Q-Sonic Master Remote PC / TV from the german > > >> > > > > distributor Pearl > > >> > > > >> > Agency. The USB Receiver gives the atached > > >> > > > >> > > > > usbview output. The file /proc/bus/usb/devices is also > > >> > > > > atached. > > >> > > > > > > >> > > > > I have the problem that my some keys have 5 bytes and some 4 > > >> > > > > bytes > > >> > > > >> > (urb->actual_length) in usb_remote_irq. > > >> > > > >> > > > > the if clause testing these variable fails therefore. > > >> > > > > but an > > >> > > > > > > >> > > > > if ((urb->actual_length != 4) && (urb->actual_length > > >> > > > > != 5)) > > >> > > > >> > return; > > >> > > > >> > > > > << > > >> > > > > does also not work. this seems not the only problem. > > >> > > > > > > >> > > > > The second problem is that i have to reload the complete usb > > >> > > > > stack after > > >> > > > >> > every > > >> > > > >> > > > > time a program used lirc. This happens also when using > > >> > > > > irrecord. The syslog says: > > >> > > > > > > >> > > > > lirc_unregister_plugin:minor (0) device not > > >> > > > > registered!lirc_usb[2]: > > >> > > > >> > didn't free resources > > >> > > > >> > > > > << > > >> > > > > > > >> > > > > Thanks a lot > > >> > > > > > > >> > > > > Enrico > > >> > > > > >> > > -- > > >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > >> > > Sicherheit zu gewinnen, wird beides verlieren." > > >> > > - - Benjamin Franklin > > > > > > -- > > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > > > Sicherheit zu gewinnen, wird beides verlieren." > > > - - Benjamin Franklin > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: SF.net Giveback Program. > > > Does SourceForge.net help you be more productive? Does it > > > help you create better code? SHARE THE LOVE, and help us help > > > YOU! Click Here: http://sourceforge.net/donate/ > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ -- "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren." - - Benjamin Franklin |
From: Paul M. <pmi...@us...> - 2003-11-08 20:47:08
|
Enrico, So what buttons emit a data length of 5? All of them or just a couple? Do they also emit a 4 byte code? The cvs version still only accepts 4 byte codes. The 1 byte code is known to occur, but is ignored. Try irrecord -d /dev/lirc/0 /tmp/lircd.conf and see if you can generate a configuration file. lircd communicates with the hardware (or networked lircd). irw communicates with lircd and won't do anything unless you have created a lirc keymap (~/.lircrc). Xine generates a nice example with xine --keymap lirc... -Paul > Hello Paul, > > with the latest cvs the message output changed a bit... > <<< > Nov 8 08:16:47 amd kernel: lirc_atiusb[2]: set use inc > Nov 8 08:16:47 amd kernel: lirc_atiusb[2]: data received (length 1) > Nov 8 08:17:03 amd kernel: lirc_atiusb[2]: data received (length 4) > Nov 8 08:17:03 amd last message repeated 3 times > Nov 8 08:17:21 amd kernel: lirc_atiusb[2]: data received (length 5) > Nov 8 08:17:36 amd last message repeated 5 times > Nov 8 08:17:40 amd kernel: lirc_atiusb[2]: set use dec >>>> > I don't know where the length 1 came from but it appears when starting irw > the > first time. length 4 and 5 are my key presses on the remote. > > lircd does not hang anymore - instead it does nothing else than waiting... > here comes the strace > <<< > select(8, [4 6 7], NULL, NULL, NULL) >>>> > > irw does nothing too :-( > > Regards > > Enrico > > Am Freitag, 7. November 2003 21:22 schrieb Enrico Schnepel: >> Hello Paul, >> >> Yeah, I had two versions of lirc on my system, but removing all and >> reinstalling did nor resolve the problem :-( >> The output of strace again: >> >> gettimeofday({1068236441, 372085}, NULL) = 0 >> select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) >> gettimeofday({1068236441, 372178}, NULL) = 0 >> read(7, 0xbffff4c0, 5) = -1 EINVAL (Invalid argument) >> time([1068236441]) = 1068236441 >> write(2, "lircd 0.7.0pre1: ", 17) = 17 >> write(5, "Nov 7 21:20:41 amd lircd 0.7.0p"..., 79) = 79 >> write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 >> write(2, ptrace: umoven: Input/output error >> 0x40159f27, 1) = 1 >> <<< >> >> Thanks Enrico >> >> Am Freitag, 7. November 2003 00:43 schrieb Paul Miller: >> > Are you mixing lirc cvs and version 0.6.6? It sure looks like it. >> > Please uninstall version 0.6.6 before trying the cvs version. >> > >> > -Paul >> > >> > > Hi Paul again, >> > > >> > > I am using now the current cvs version. It works as far as I do not >> get >> > > any >> > > error message from irw and I could start it again and again - >> Thanks. >> > > The contra is that lircd has about 99% cpu load... and irw does not >> > > print the codes to stdout. irrecord gives the following message: >> > > >> > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed >> > > >> > > the output of strace of lircd (started with -n) when hanging in the >> > > loop gives: >> > > >> > > gettimeofday({1068155794, 292700}, NULL) = 0 >> > > select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) >> > > gettimeofday({1068155794, 292794}, NULL) = 0 >> > > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid >> argument) >> > > time([1068155794]) = 1068155794 >> > > write(2, "lircd 0.6.6: ", 13) = 13 >> > > write(5, "Nov 6 22:56:34 amd lircd 0.6.6:"..., 75) = 75 >> > > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 >> > > write(2, ptrace: umoven: Input/output error >> > > 0x40159f27, 1) = 1 >> > > <<< >> > > and the following on stdout: >> > > >> > > lircd 0.6.6: reading in mode LIRC_MODE_LIRCCODE failed >> > > <<< >> > > >> > > Thanks >> > > >> > > Enrico >> > > >> > > Am Donnerstag, 6. November 2003 13:37 schrieb Enrico Schnepel: >> > >> Hi Paul, >> > >> >> > >> The line 259, cvs v1.7 is the place where I put >> > >> >> > >> if ((urb->actual_length != 4) && (urb->actual_length != 5)) return; >> > >> >> > >> The question is how to implement this check using a more generic >> > >> Min/Max if-clause. >> > >> I am thinking about a combination with the table >> usb_remote_id_table. >> > >> if we have the index of the current device in the struct. we could >> use >> > >> this >> > >> index as an index into a second table containing the >> min/max-values. >> > >> If we do not have the index we may use a table containing the >> min/max >> > >> values and as index the minor usb device id if it is stored >> somewhere. >> > >> for most devices the pair would be min 4 / max 4 but for the device >> > >> 0x0005 >> > >> it would be min 4 / max 5. >> > >> >> > >> I will test the new version this evening. >> > >> >> > >> Thanks >> > >> >> > >> Enrico >> > >> >> > >> > Hi Enrico, >> > >> > >> > >> > Please try updating to the latest cvs again (delete your old file >> > >> > first). I think I have the -EIO problem fixed. >> > >> > >> > >> > Also, how did you change the code to support both 4 and 5 bytes? >> > >> > The only place it actually compares the bytes received is in >> > >> > usb_remote_irq() with "if (urb->actual_length != >> > >> > ir->p->code_length/8) return" (line 259, cvs v1.7). >> > >> > >> > >> > -Paul >> > >> > >> > >> > On Wednesday 05 November 2003 2:44 pm, you wrote: >> > >> > > Hello Paul, >> > >> > > >> > >> > > I am using already the current CVS version of lirc, but i >> changed >> > >> >> > >> the >> > >> >> > >> > > code to >> > >> > >> > >> > support both 4 and 5 bytes in this if-clause. >> > >> > >> > >> > > Using the modified if-clause i could use lirc - but only one >> time. >> > >> > > >> > >> > > All output is made with CONFIG_USB_DEBUG enabled. >> > >> > > >> > >> > > When starting irw and pressing some keys on the remote I am >> > >> > > getting the >> > >> > >> > >> > following syslog output: >> > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: set use inc >> > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called >> > >> > > ... >> > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called >> > >> > > Nov 5 20:51:05 amd kernel: lirc_usb[2]: set use dec >> > >> > > <<< >> > >> > > irw does report the correct codes. >> > >> > > >> > >> > > after terminating irw and starting it a second time I am >> getting >> > >> > > the following >> > >> > >> > >> > output: >> > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: set use inc >> > >> > > Nov 5 20:51:19 amd kernel: usb-uhci.c: ENXIO 44408280, flags >> 0, >> > >> > > urb ca0d5c64, >> > >> > >> > >> > burb ca0d5c64 >> > >> > >> > >> > > Nov 5 20:51:19 amd kernel: lirc_usb[2]: open result = -E10 >> error >> > >> > > submitting >> > >> > >> > >> > urb >> > >> > >> > >> > > <<< >> > >> > > irw terminates without a message. >> > >> > > >> > >> > > starting irw a third time results in a >> > >> > > >> > >> > > >> > >> > > >> > >> > > connect: Connection refused >> > >> > > <<< >> > >> > > and no message on syslog. >> > >> > > >> > >> > > after restarting the usb stack an doing the same againg with >> > >> >> > >> irrecord >> > >> >> > >> > > i am >> > >> > >> > >> > getting the following output: >> > >> > > Nov 5 20:56:45 amd kernel: lirc_usb[2]: set use inc >> > >> > > Nov 5 20:50:27 amd kernel: lirc_usb[2]: usb irq called >> > >> > > ... >> > >> > > Nov 5 20:50:51 amd kernel: lirc_usb[2]: usb irq called >> > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use dec >> > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: set use inc >> > >> > > Nov 5 20:57:15 amd kernel: usb-uhci.c: ENXIO 44408280, flags >> 0, >> > >> > > urb c388ae84, >> > >> > >> > >> > burb c388ae84 >> > >> > >> > >> > > Nov 5 20:57:15 amd kernel: lirc_usb[2]: open result = -E10 >> error >> > >> > > submitting >> > >> > >> > >> > urb >> > >> > >> > >> > > <<< >> > >> > > irrecord prints the following message: >> > >> > > >> > >> > > >> > >> > > >> > >> > > irrecord: could not open /dev/lirc >> > >> > > irrecord: default_init(): Input/output error >> > >> > > irrecord: could not reset hardware. >> > >> > > <<< >> > >> > > It seems to me that irrecord opens a new lirc session after >> > >> > > closing the old >> > >> > >> > >> > one... >> > >> > >> > >> > > with the original if-clause... >> > >> > > >> > >> > > changing bytes_in_key did not work. >> > >> > > >> > >> > > initializing bytes_in_key with 4 results in: >> > >> > > ir->p->code_length==32 >> > >> > > with 5 in: >> > >> > > ir->p->code_length==40 >> > >> > > in combination with urb->actual_length the result is that in >> the >> > >> > > first case >> > >> > >> > >> > only 4-byte codes are accepted. in the second case - >> > >> > >> > >> > > instead of accepting only 5 byte long codes - the driver could >> not >> > >> >> > >> be >> > >> >> > >> > > initialised ... but this could be an other problem. >> > >> > > >> > >> > > I am leaving the modified if-clause but the >> > >> > > "only-one-time-use"-problem is not >> > >> > >> > >> > solved. >> > >> > >> > >> > > I think there should be a better solution for the if-clause >> > >> > > because my >> > >> > >> > >> > modified one is very rigid. I don't know whether it is possible >> > >> > >> > >> > > to implement the "possible counts of bits/bytes" in the >> > >> > > usb_remote_id_table. >> > >> > > The syslog shows the following when initialising the usb stack >> > >> > > (CONFIG_USB_DEBUG enabled): >> > >> > > >> > >> > > >> > >> > > >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver >> usbdevfs >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: registered new driver hub >> > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: $Revision: 1.275 $ time >> > >> > > 12:38:59 Oct >> > >> > >> > >> > 3 2003 >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: High bandwidth mode >> > >> > > enabled Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O >> > >> > > 0xd800, IRQ 11 >> > >> > >> > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, >> > >> > > assigned bus number >> > >> > >> > >> > 1 >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected >> > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: USB UHCI at I/O 0xdc00, >> > >> > > IRQ 11 >> > >> > >> > >> > Nov 5 21:16:28 amd kernel: usb-uhci.c: Detected 2 ports >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: usb.c: new USB bus registered, >> > >> > > assigned bus number >> > >> > >> > >> > 2 >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: USB hub found >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: 2 ports detected >> > >> > > Nov 5 21:16:28 amd kernel: usb-uhci.c: v1.275:USB Universal >> Host >> > >> > > Controller >> > >> > >> > >> > Interface driver >> > >> > >> > >> > > Nov 5 21:16:28 amd /etc/hotplug/usb.rc[10185]: loaded HCD: >> > >> > > usb-uhci Nov 5 21:16:28 amd kernel: uhci.c: USB Universal Host >> > >> > > Controller Interface >> > >> > >> > >> > driver v1.1 >> > >> > >> > >> > > Nov 5 21:16:28 amd kernel: hub.c: new USB device 00:07.2-2, >> > >> >> > >> assigned >> > >> >> > >> > > address >> > >> > >> > >> > 2 >> > >> > >> > >> > > Nov 5 21:16:29 amd kernel: usb.c: USB device 2 (vend/prod >> > >> >> > >> 0xbc7/0x5) >> > >> >> > >> > > is not >> > >> > >> > >> > claimed by any active driver. >> > >> > >> > >> > > Nov 5 21:16:38 amd kernel: lirc_dev: IR Remote Control driver >> > >> > > registered, at >> > >> > >> > >> > major 61 >> > >> > >> > >> > > Nov 5 21:16:38 amd kernel: >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: USB remote driver for >> LIRC >> > >> > > v0.1 >> > >> > >> > >> > Nov 5 21:16:38 amd kernel: lirc_usb: Paul Miller >> > >> > >> > >> > > <pmi...@us...> >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: debug mode enabled >> > >> > > Nov 5 21:16:38 amd kernel: usb.c: registered new driver >> lirc_usb >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb: usb probe called >> > >> > > Nov 5 21:16:38 amd kernel: usb-uhci.c: interrupt, status 3, >> > >> > > frame# 1482 >> > >> > >> > >> > Nov 5 21:16:38 amd kernel: lirc_dev: >> > >> > > lirc_register_plugin:sample_rate: 0 Nov 5 21:16:38 amd kernel: >> > >> > > lirc_usb[2]: X10 Wireless Technology Inc USB Receiver on >> usb1:2.0 >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: maxp = 5, buf_len = 8 >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8004) >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: send called (0x8007) >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > >> > > Nov 5 21:16:38 amd kernel: lirc_usb[2]: usb out called >> > >> > > Nov 5 21:16:38 amd insmod: Using >> > >> > > /lib/modules/2.4.20-4GB/misc/lirc_dev.o >> > >> > >> > >> > Nov 5 21:16:38 amd insmod: >> > >> > > Symbol version prefix '' >> > >> > > Nov 5 21:16:38 amd insmod: Using >> > >> > > /lib/modules/2.4.20-4GB/misc/lirc_atiusb.o >> > >> > >> > >> > <<< >> > >> > >> > >> > > thanks a lot >> > >> > > >> > >> > > Enrico >> > >> > > >> > >> > > Am Dienstag, 4. November 2003 15:37 schrieb Paul Miller: >> > >> > > > Enrico, >> > >> > > > Could you please try using the latest CVS version of LIRC? >> The >> > >> > > > check you >> > >> > >> > >> > mentioned for urb->actual_length is not in the latest >> > >> > >> > >> > > > cvs version. Also try changing "bytes_in_key" to 5 (line >> 323) >> > >> > > > if the default of 4 doesn't work. >> > >> > > > >> > >> > > > Please send me the full debug output (load the driver w/ >> > >> > > > debug=1) and >> > >> > >> > >> > /proc/bus/usb/devices. >> > >> > >> > >> > > > Thanks, >> > >> > > > -Paul >> > >> > > > >> > >> > > > > Hello, >> > >> > > > > >> > >> > > > > I have an Q-Sonic Master Remote PC / TV from the german >> > >> > > > > distributor Pearl >> > >> > >> > >> > Agency. The USB Receiver gives the atached >> > >> > >> > >> > > > > usbview output. The file /proc/bus/usb/devices is also >> > >> > > > > atached. >> > >> > > > > >> > >> > > > > I have the problem that my some keys have 5 bytes and some >> 4 >> > >> > > > > bytes >> > >> > >> > >> > (urb->actual_length) in usb_remote_irq. >> > >> > >> > >> > > > > the if clause testing these variable fails therefore. >> > >> > > > > but an >> > >> > > > > >> > >> > > > > if ((urb->actual_length != 4) && >> (urb->actual_length >> > >> > > > > != 5)) >> > >> > >> > >> > return; >> > >> > >> > >> > > > > << >> > >> > > > > does also not work. this seems not the only problem. >> > >> > > > > >> > >> > > > > The second problem is that i have to reload the complete >> usb >> > >> > > > > stack after >> > >> > >> > >> > every >> > >> > >> > >> > > > > time a program used lirc. This happens also when using >> > >> > > > > irrecord. The syslog says: >> > >> > > > > >> > >> > > > > lirc_unregister_plugin:minor (0) device not >> > >> > > > > registered!lirc_usb[2]: >> > >> > >> > >> > didn't free resources >> > >> > >> > >> > > > > << >> > >> > > > > >> > >> > > > > Thanks a lot >> > >> > > > > >> > >> > > > > Enrico >> > >> > > >> > >> > > -- >> > >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um >> > >> > > Sicherheit zu gewinnen, wird beides verlieren." >> > >> > > - - Benjamin Franklin >> > > >> > > -- >> > > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um >> > > Sicherheit zu gewinnen, wird beides verlieren." >> > > - - Benjamin Franklin >> > > >> > > >> > > ------------------------------------------------------- >> > > This SF.net email is sponsored by: SF.net Giveback Program. >> > > Does SourceForge.net help you be more productive? Does it >> > > help you create better code? SHARE THE LOVE, and help us help >> > > YOU! Click Here: http://sourceforge.net/donate/ >> > >> > ------------------------------------------------------- >> > This SF.net email is sponsored by: SF.net Giveback Program. >> > Does SourceForge.net help you be more productive? Does it >> > help you create better code? SHARE THE LOVE, and help us help >> > YOU! Click Here: http://sourceforge.net/donate/ > > -- > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > Sicherheit zu gewinnen, wird beides verlieren." > - - Benjamin Franklin > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > |
From: <col...@hi...> - 2003-11-10 13:06:57
|
Hi! Enrico Schnepel "enr...@gm..." wrote: [...] > I am using now the current cvs version. It works as far as I do not get any > error message from irw and I could start it again and again - Thanks. The > contra is that lircd has about 99% cpu load... and irw does not print the > codes to stdout. irrecord gives the following message: > > irrecord: reading in mode LIRC_MODE_LIRCCODE failed [...] > read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) The driver says that it will provide 5 bytes, but it configures the buffer to only hold 4 bytes. Some general remarks on lirc buffers: lircd expects the buffer size to be constant. If you receive both 4 and 5 bytes from the hardware, you will have to deliver 5 bytes to userspace. Most of the time the best approach is to find out what the remote control really sends. Most receivers will not provide the raw code that the remote control sends. Translating the received code to the original remote control code will help here. These codes have constand length if they use the same protocol. Some remote controls use different protocols for different buttons, but this is rare. Christoph |
From: Enrico S. <enr...@gm...> - 2003-11-10 22:03:28
|
Hello Christoph, The the 5-byte-codes trancated to 4-byte codes are mostly unique (there are 3 codes which are also in 5 bytes non-unique). Using only 4 bytes should be ok for this remote in PC mode. But in this case the actual_length should always be truncated to 4. What do you mean with: > Most of the time the best approach is to find out what the remote > control really sends. Most receivers will not provide the raw code that > the remote control sends. Translating the received code to the original > remote control code will help here. These codes have constand length if > they use the same protocol. Some remote controls use different protocols > for different buttons, but this is rare. The remote transmites the codes not via IR but uses an antenna. I think the recieved codes are those which the remote sends. My Remote has two functions. One is to control the mouse with 11 keys which send 4-byte codes. Second, the about 30 other keys, which emits 5 bytes, have normal TV or REC remote control functions. It might be possible that these two groups have different protocols. How could I find out? Some Examples: 4-Byte-Codes: 00000000142570e0 00 PC_MOVE_W qsonicmr6in1pc 00000000142671e0 00 PC_MOVE_E qsonicmr6in1pc 00000000142772e0 00 PC_MOVE_N qsonicmr6in1pc 00000000142873e0 00 PC_MOVE_S qsonicmr6in1pc 00000000142974e0 00 PC_MOVE_NW qsonicmr6in1pc 00000000142a75e0 00 PC_MOVE_NE qsonicmr6in1pc 00000000142b76e0 00 PC_MOVE_SE qsonicmr6in1pc 00000000142c77e0 00 PC_MOVE_SW qsonicmr6in1pc 00000000142d78e0 00 PC_CLICK_LEFT qsonicmr6in1pc 0000000014307be0 00 PC_CLICK_HAND qsonicmr6in1pc 0000000014317ce0 00 PC_CLICK_RIGTH qsonicmr6in1pc _____________X__ For this Remote Bits 9-13 seems to be relevant for 4-byte keys (These are all 4-byte keys) 5-Byte-Codes: 20ee11827d 20ee11d52a 20ee1152ad 20ee11c936 20ee11b04f Every Code starts with 20EE11 so this could be truncated. In combination with 4-Byte codes the lowest 16 Bytes are relevant. The problem is that I could speak only for my remote in Combination with my reciever but the driver supports some more... See also Message thread with Paul Miller. Thanks Enrico |
From: Paul M. <pmi...@us...> - 2003-11-11 03:32:59
|
Enrico, Christoph, Alright, the driver should now handles 4 and 5 byte codes correctly (cvs=20 revision 1.10). All users will need to update their configuration file=20 such that the codes are 5 bytes long. =2DPaul On Monday 10 November 2003 4:00 pm, Enrico Schnepel wrote: > Hello Christoph, >=20 > The the 5-byte-codes trancated to 4-byte codes are mostly unique > (there are 3 =0D codes which are also in 5 bytes non-unique). Using > only 4 bytes should be ok for this remote in PC mode. But in this > case the actual_length should always be truncated to 4. >=20 > What do you mean with: >=20 > > > Most of the time the best approach is to find out what the remote > > control really sends. Most receivers will not provide the raw code > > that=0D the remote control sends. Translating the received code to > > the original remote control code will help here. These codes have > > constand length if they use the same protocol. Some remote controls > > use different protocols for different buttons, but this is rare. > >=20 > The remote transmites the codes not via IR but uses an antenna. I > think the =0D recieved codes are those which the remote sends. > My Remote has two functions. One is to control the mouse with 11 keys > which =0D send 4-byte codes. Second, the about 30 other keys, which > emits 5 bytes, have normal TV or REC remote control functions. It > might be possible that these two groups have different protocols. How > could I find out? >=20 > Some Examples: > 4-Byte-Codes: > 00000000142570e0 00 PC_MOVE_W qsonicmr6in1pc > 00000000142671e0 00 PC_MOVE_E qsonicmr6in1pc > 00000000142772e0 00 PC_MOVE_N qsonicmr6in1pc > 00000000142873e0 00 PC_MOVE_S qsonicmr6in1pc > 00000000142974e0 00 PC_MOVE_NW qsonicmr6in1pc > 00000000142a75e0 00 PC_MOVE_NE qsonicmr6in1pc > 00000000142b76e0 00 PC_MOVE_SE qsonicmr6in1pc > 00000000142c77e0 00 PC_MOVE_SW qsonicmr6in1pc > 00000000142d78e0 00 PC_CLICK_LEFT qsonicmr6in1pc > 0000000014307be0 00 PC_CLICK_HAND qsonicmr6in1pc > 0000000014317ce0 00 PC_CLICK_RIGTH qsonicmr6in1pc > _____________X__ > For this Remote Bits 9-13 seems to be relevant for 4-byte keys (These > are all =0D 4-byte keys) >=20 > 5-Byte-Codes: > 20ee11827d > 20ee11d52a > 20ee1152ad > 20ee11c936 > 20ee11b04f > Every Code starts with 20EE11 so this could be truncated. >=20 > In combination with 4-Byte codes the lowest 16 Bytes are relevant. >=20 > The problem is that I could speak only for my remote in Combination > with my =0D reciever but the driver supports some more... >=20 > See also Message thread with Paul Miller. >=20 > Thanks >=20 > Enrico >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ |
From: Enrico S. <enr...@gm...> - 2003-11-11 20:30:09
|
Hi Paul, When pressing a key (4- or 5-byte) on the remote and irw is running - lircd seems to be in an endless loop and strace produces the following looping output: >>> read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) time([1068581743]) = 1068581743 write(2, "lircd 0.7.0pre1: ", 17) = 17 write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 79) = 79 write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 gettimeofday({1068581743, 537511}, NULL) = 0 select(8, [4 6 7], NULL, NULL, NULL) = 1 (in [7]) gettimeofday({1068581743, 537628}, NULL) = 0 <<< When terminating irw the following happens: >>> read(7, 0xbffff4d0, 5) = -1 EINVAL (Invalid argument) time([1068581743]) = 1068581743 write(2, "lircd 0.7.0pre1: ", 17) = 17 write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 79) = 79 write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) = 41 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 gettimeofday({1068581743, 537860}, NULL) = 0 select(8, [4 6 7], NULL, NULL, NULL) = 2 (in [6 7]) gettimeofday({1068581743, 547006}, NULL) = 0 select(7, [6], NULL, NULL, {0, 0}) = 1 (in [6], left {0, 0}) read(6, "", 256) = 0 shutdown(6, 2 /* send and receive */) = 0 close(6) = 0 time([1068581743]) = 1068581743 write(2, "lircd 0.7.0pre1: ", 17) = 17 write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 52) = 52 write(2, "removed client", 14) = 14 write(2, ptrace: umoven: Input/output error 0x40159f27, 1) = 1 close(7) = 0 gettimeofday({1068581743, 548042}, NULL) = 0 select(5, [4], NULL, NULL, NULL <<< if lirc recieves the key wile irw is not listening nothing happens except that a message is printed to syslog. This case seems to be correctly handled. irrecord does have the same problem. I think lircd and irrecord should handle this error better and preventing the endless loop. Thanks Enrico Am Dienstag, 11. November 2003 04:32 schrieb Paul Miller: > Enrico, Christoph, > > Alright, the driver should now handles 4 and 5 byte codes correctly (cvs > revision 1.10). All users will need to update their configuration file > such that the codes are 5 bytes long. > > -Paul > > On Monday 10 November 2003 4:00 pm, Enrico Schnepel wrote: > > Hello Christoph, > > > > The the 5-byte-codes trancated to 4-byte codes are mostly unique > > (there are 3 codes which are also in 5 bytes non-unique). Using > > only 4 bytes should be ok for this remote in PC mode. But in this > > case the actual_length should always be truncated to 4. > > > > What do you mean with: > > > Most of the time the best approach is to find out what the remote > > > control really sends. Most receivers will not provide the raw code > > > that the remote control sends. Translating the received code to > > > the original remote control code will help here. These codes have > > > constand length if they use the same protocol. Some remote controls > > > use different protocols for different buttons, but this is rare. > > > > The remote transmites the codes not via IR but uses an antenna. I > > think the recieved codes are those which the remote sends. > > My Remote has two functions. One is to control the mouse with 11 keys > > which send 4-byte codes. Second, the about 30 other keys, which > > emits 5 bytes, have normal TV or REC remote control functions. It > > might be possible that these two groups have different protocols. How > > could I find out? > > > > Some Examples: > > 4-Byte-Codes: > > 00000000142570e0 00 PC_MOVE_W qsonicmr6in1pc > > 00000000142671e0 00 PC_MOVE_E qsonicmr6in1pc > > 00000000142772e0 00 PC_MOVE_N qsonicmr6in1pc > > 00000000142873e0 00 PC_MOVE_S qsonicmr6in1pc > > 00000000142974e0 00 PC_MOVE_NW qsonicmr6in1pc > > 00000000142a75e0 00 PC_MOVE_NE qsonicmr6in1pc > > 00000000142b76e0 00 PC_MOVE_SE qsonicmr6in1pc > > 00000000142c77e0 00 PC_MOVE_SW qsonicmr6in1pc > > 00000000142d78e0 00 PC_CLICK_LEFT qsonicmr6in1pc > > 0000000014307be0 00 PC_CLICK_HAND qsonicmr6in1pc > > 0000000014317ce0 00 PC_CLICK_RIGTH qsonicmr6in1pc > > _____________X__ > > For this Remote Bits 9-13 seems to be relevant for 4-byte keys (These > > are all 4-byte keys) > > > > 5-Byte-Codes: > > 20ee11827d > > 20ee11d52a > > 20ee1152ad > > 20ee11c936 > > 20ee11b04f > > Every Code starts with 20EE11 so this could be truncated. > > > > In combination with 4-Byte codes the lowest 16 Bytes are relevant. > > > > The problem is that I could speak only for my remote in Combination > > with my reciever but the driver supports some more... > > > > See also Message thread with Paul Miller. > > > > Thanks > > > > Enrico > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: ApacheCon 2003, > > 16-19 November in Las Vegas. Learn firsthand the latest > > developments in Apache, PHP, Perl, XML, Java, MySQL, > > WebDAV, and more! http://www.apachecon.com/ > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ -- "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um Sicherheit zu gewinnen, wird beides verlieren." - - Benjamin Franklin |
From: Paul M. <pmi...@us...> - 2003-11-11 23:55:03
|
Enrico, I could not verify this problem. Please delete your source file and run=20 cvs update again. Also make sure your using the same version of gcc=20 that you used to compile your kernel... You'll also need to rerun irrecord to generate a new config file. =2DPaul On Tuesday 11 November 2003 2:29 pm, Enrico Schnepel wrote: > Hi Paul, >=20 > When pressing a key (4- or 5-byte) on the remote and irw is running - > lircd =0D seems to be in an endless loop and strace produces the > following looping output: > > >>> > > read(7, 0xbffff4d0, 5) =3D -1 EINVAL (Invalid > argument)=0D time([1068581743]) =3D 1068581743 > write(2, "lircd 0.7.0pre1: ", 17) =3D 17 > write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 79) =3D 79 > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) =3D 41 > write(2, ptrace: umoven: Input/output error > 0x40159f27, 1) =3D 1 > gettimeofday({1068581743, 537511}, NULL) =3D 0 > select(8, [4 6 7], NULL, NULL, NULL) =3D 1 (in [7]) > gettimeofday({1068581743, 537628}, NULL) =3D 0 > <<< > When terminating irw the following happens: > > >>> > > read(7, 0xbffff4d0, 5) =3D -1 EINVAL (Invalid > argument)=0D time([1068581743]) =3D 1068581743 > write(2, "lircd 0.7.0pre1: ", 17) =3D 17 > write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 79) =3D 79 > write(2, "reading in mode LIRC_MODE_LIRCCO"..., 41) =3D 41 > write(2, ptrace: umoven: Input/output error > 0x40159f27, 1) =3D 1 > gettimeofday({1068581743, 537860}, NULL) =3D 0 > select(8, [4 6 7], NULL, NULL, NULL) =3D 2 (in [6 7]) > gettimeofday({1068581743, 547006}, NULL) =3D 0 > select(7, [6], NULL, NULL, {0, 0}) =3D 1 (in [6], left {0, 0}) > read(6, "", 256) =3D 0 > shutdown(6, 2 /* send and receive */) =3D 0 > close(6) =3D 0 > time([1068581743]) =3D 1068581743 > write(2, "lircd 0.7.0pre1: ", 17) =3D 17 > write(5, "Nov 11 21:15:43 amd lircd 0.7.0p"..., 52) =3D 52 > write(2, "removed client", 14) =3D 14 > write(2, ptrace: umoven: Input/output error > 0x40159f27, 1) =3D 1 > close(7) =3D 0 > gettimeofday({1068581743, 548042}, NULL) =3D 0 > select(5, [4], NULL, NULL, NULL > <<< >=20 > if lirc recieves the key wile irw is not listening nothing happens > except that =0D a message is printed to syslog. This case seems to be > correctly handled.=20 > irrecord does have the same problem. >=20 > I think lircd and irrecord should handle this error better and > preventing the =0D endless loop. >=20 > Thanks >=20 > Enrico >=20 > Am Dienstag, 11. November 2003 04:32 schrieb Paul Miller: > > > Enrico, Christoph, > > > > Alright, the driver should now handles 4 and 5 byte codes correctly > > (cvs=0D revision 1.10). All users will need to update their > > configuration file such that the codes are 5 bytes long. > > > > -Paul > > > > On Monday 10 November 2003 4:00 pm, Enrico Schnepel wrote: > > > > > Hello Christoph, > > > > > > The the 5-byte-codes trancated to 4-byte codes are mostly unique > > > (there are 3 codes which are also in 5 bytes non-unique). Using > > > only 4 bytes should be ok for this remote in PC mode. But in > > > this=0D case the actual_length should always be truncated to 4.=20 > > > What do you mean with: > > > > > > > Most of the time the best approach is to find out what the > > > > remote=0D control really sends. Most receivers will not provide > > > > the raw code that the remote control sends. Translating the > > > > received code to the original remote control code will help > > > > here. These codes have constand length if they use the same > > > > protocol. Some remote controls use different protocols for > > > > different buttons, but this is rare. > > > > > > > > > The remote transmites the codes not via IR but uses an antenna. > > > I=0D think the recieved codes are those which the remote sends. My > > > Remote has two functions. One is to control the mouse with 11 > > > keys which send 4-byte codes. Second, the about 30 other keys, > > > which emits 5 bytes, have normal TV or REC remote control > > > functions. It might be possible that these two groups have > > > different protocols. How could I find out? > > > > > > Some Examples: > > > 4-Byte-Codes: > > > 00000000142570e0 00 PC_MOVE_W qsonicmr6in1pc > > > 00000000142671e0 00 PC_MOVE_E qsonicmr6in1pc > > > 00000000142772e0 00 PC_MOVE_N qsonicmr6in1pc > > > 00000000142873e0 00 PC_MOVE_S qsonicmr6in1pc > > > 00000000142974e0 00 PC_MOVE_NW qsonicmr6in1pc > > > 00000000142a75e0 00 PC_MOVE_NE qsonicmr6in1pc > > > 00000000142b76e0 00 PC_MOVE_SE qsonicmr6in1pc > > > 00000000142c77e0 00 PC_MOVE_SW qsonicmr6in1pc > > > 00000000142d78e0 00 PC_CLICK_LEFT qsonicmr6in1pc > > > 0000000014307be0 00 PC_CLICK_HAND qsonicmr6in1pc > > > 0000000014317ce0 00 PC_CLICK_RIGTH qsonicmr6in1pc > > > _____________X__ > > > For this Remote Bits 9-13 seems to be relevant for 4-byte keys > > > (These=0D are all 4-byte keys) > > > > > > 5-Byte-Codes: > > > 20ee11827d > > > 20ee11d52a > > > 20ee1152ad > > > 20ee11c936 > > > 20ee11b04f > > > Every Code starts with 20EE11 so this could be truncated. > > > > > > In combination with 4-Byte codes the lowest 16 Bytes are > > > relevant.=0D=20 > > > The problem is that I could speak only for my remote in > > > Combination=0D with my reciever but the driver supports some > > > more... > > > > > > See also Message thread with Paul Miller. > > > > > > Thanks > > > > > > Enrico > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: ApacheCon 2003, > > > 16-19 November in Las Vegas. Learn firsthand the latest > > > developments in Apache, PHP, Perl, XML, Java, MySQL, > > > WebDAV, and more! http://www.apachecon.com/ > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: ApacheCon 2003, > > 16-19 November in Las Vegas. Learn firsthand the latest > > developments in Apache, PHP, Perl, XML, Java, MySQL, > > WebDAV, and more! http://www.apachecon.com/ > >=20 > --=20 > "Der Mensch, der bereit ist, seine Freiheit aufzugeben, um > Sicherheit zu gewinnen, wird beides verlieren." > - - Benjamin Franklin >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ |
From: Enrico S. <enr...@gm...> - 2003-11-10 22:03:14
Attachments:
lircd.conf
|
Hello Paul, Yaeh it does work now!!! You will find attached the generated lircd.conf (With 4-Byte Codes) The gap depends on the button with 4-bytes-keys it is about 150000 and with 5-byte-key about 220000. is it important? in the non-PC-Modes the cond send depends on the learned code. I have found 3 keys where each of them does have the same code as 3 other keys. even in 5-byte mode... See also message in reply to Christoph Bartelmus. Thanks a lot. Enrico Am Sonntag, 9. November 2003 18:06 schrieb Paul Miller: > Alright, 5 byte codes should be "allowed." The bytes_in_key parameter > is still set to 4, so please test that all your keys emit different > codes (and work). > > When you run irrecord, you must have the lirc_dev and lirc_atiusb > modules loaded. lircd should not be running. If you're using DEVFS, > then /dev/lirc/0 or /dev/lirc should be created automatically. If not, > you'll need to create the device yourself (see LIRC documentation). > > -Paul > > On Sunday 09 November 2003 4:25 am, you wrote: > > Hello Paul, > > > > The remote which is described in German including a picture under > > http://www.pearl.de/product.jsp?pdid=PE4444&catid=5005&rate=5 > > has some mouse movement keys. These and the corresponding mouse > > buttons have 4-byte codes (7 codes). The rest which are more than > > 30 keys have 5-byte codes. What do you mean with "Do they also emit a > > 4 byte code?" ? What I have seen, is that the first code of a 5-byte > > key press is send 2 times. the following codes while holding the key > > are send only one time. 4-byte (mouse) codes do not behave so. > > > > irrecord -d /dev/lirc/0 /tmp/lircd.conf > > results with closed lircd in > > > > > > > > /usr/local/bin/irrecord: could not get file information for f > > /usr/local/bin/irrecord: default_init(): No such file or directory > > /usr/local/bin/irrecord: could not init hardware (lircd running ? --> > > close it, check permissions) > > <<< > > > > /dev/lirc/ is an empty dirrectory. > > > > irrecord /tmp/lircd.conf > > results in > > > > > > > > ... > > Hold down an arbitrary button. > > /usr/local/bin/irrecord: gap not found, can't continue > > <<< > > > > Regards > > > > Enrico > > > > Am Samstag, 8. November 2003 21:47 schrieb Paul Miller: > > > Enrico, > > > > > > So what buttons emit a data length of 5? All of them or just a > > > couple? Do they also emit a 4 byte code? The cvs version still > > > only accepts 4 byte codes. The 1 byte code is known to occur, but > > > is ignored. > > > Try > > > irrecord -d /dev/lirc/0 /tmp/lircd.conf > > > > > > and see if you can generate a configuration file. > > > > > > lircd communicates with the hardware (or networked lircd). > > > irw communicates with lircd and won't do anything unless you have > > > created a lirc keymap (~/.lircrc). Xine generates a nice example > > > with xine --keymap lirc... > > > > > > -Paul |
From: Paul M. <pmi...@us...> - 2003-11-11 03:35:30
|
Cool. I'm not totally sure what the gap length is, but I'd choose the=20 lower number. I don't think it is important for a RF or USB remote. =2DPaul On Monday 10 November 2003 4:01 pm, Enrico Schnepel wrote: > Hello Paul, >=20 > Yaeh it does work now!!! > You will find attached the generated lircd.conf (With 4-Byte Codes) > The gap depends on the button with 4-bytes-keys it is about 150000 > and with =0D 5-byte-key about 220000. is it important? in the > non-PC-Modes the cond send depends on the learned code. I have found > 3 keys where each of them does have the same code as 3 other keys. > even in 5-byte mode... >=20 > See also message in reply to Christoph Bartelmus. >=20 > Thanks a lot. >=20 > Enrico >=20 > Am Sonntag, 9. November 2003 18:06 schrieb Paul Miller: > > > Alright, 5 byte codes should be "allowed." The bytes_in_key > > parameter=0D is still set to 4, so please test that all your keys > > emit different codes (and work). > > > > When you run irrecord, you must have the lirc_dev and lirc_atiusb > > modules loaded. lircd should not be running. If you're using > > DEVFS,=0D then /dev/lirc/0 or /dev/lirc should be created > > automatically. If not, you'll need to create the device yourself > > (see LIRC documentation).=20 > > -Paul > > > > On Sunday 09 November 2003 4:25 am, you wrote: > > > > > Hello Paul, > > > > > > The remote which is described in German including a picture > > > under > > > http://www.pearl.de/product.jsp?pdid=3DPE4444&catid=3D5005&rate=3D5 h= as > > > some mouse movement keys. These and the corresponding mouse > > > buttons have 4-byte codes (7 codes). The rest which are more > > > than 30 keys have 5-byte codes. What do you mean with "Do they > > > also emit a 4 byte code?" ? What I have seen, is that the first > > > code of a 5-byte key press is send 2 times. the following codes > > > while holding the key are send only one time. 4-byte (mouse) > > > codes do not behave so.=20 > > > irrecord -d /dev/lirc/0 /tmp/lircd.conf > > > results with closed lircd in > > > > > > > > > > > > /usr/local/bin/irrecord: could not get file information for f > > > /usr/local/bin/irrecord: default_init(): No such file or > > > directory=0D /usr/local/bin/irrecord: could not init hardware > > > (lircd running ? --> close it, check permissions) > > > <<< > > > > > > /dev/lirc/ is an empty dirrectory. > > > > > > irrecord /tmp/lircd.conf > > > results in > > > > > > > > > > > > ... > > > Hold down an arbitrary button. > > > /usr/local/bin/irrecord: gap not found, can't continue > > > <<< > > > > > > Regards > > > > > > Enrico > > > > > > Am Samstag, 8. November 2003 21:47 schrieb Paul Miller: > > > > > > > Enrico, > > > > > > > > So what buttons emit a data length of 5? All of them or just > > > > a=0D couple? Do they also emit a 4 byte code? The cvs version > > > > still only accepts 4 byte codes. The 1 byte code is known to > > > > occur, but is ignored. > > > > Try > > > > irrecord -d /dev/lirc/0 /tmp/lircd.conf > > > > > > > > and see if you can generate a configuration file. > > > > > > > > lircd communicates with the hardware (or networked lircd). > > > > irw communicates with lircd and won't do anything unless you > > > > have=0D created a lirc keymap (~/.lircrc). Xine generates a nice > > > > example with xine --keymap lirc... > > > > > > > > -Paul |
From: <col...@hi...> - 2003-11-12 12:46:59
|
Hi! Paul Miller "pmi...@us..." wrote: > Cool. I'm not totally sure what the gap length is, but I'd choose the > lower number. No, the config file should be seperated in two parts, each part having it's according gap value. Christoph |