OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Ir Problems With 3.5.4.1
kopsis
post Aug 4 2006, 06:32 AM
Post #1





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



I'm trying to get my zkbdd IR keyboard drivers working on OZ 3.5.4.1 but I'm not having much luck with the IR port. It seems that the 2.6 kernel uses a different set of drivers for IRDA than 2.4 so I'm not entirely sure how all of the pieces fit together. For most keyboards, I need to get the port in SIR mode communicating through a tty device. So far I've tried /dev/ttyS[0-1] and /dev/ircomm[0-1] and though I can open the devices, I'm not seeing any of the IR data.

Before I go down the path of instrumenting all the drivers, I figure I should check and see if anyone has actually seen IR work on a C7xx running 3.5.4.1?
Go to the top of the page
 
+Quote Post
Hrw
post Aug 4 2006, 07:32 AM
Post #2





Group: Members
Posts: 1,376
Joined: 11-January 04
From: Poznań, Poland
Member No.: 1,413



I used irdadump (from feed) and it detect my phone and palmtops. It does not detect Ir keyboard anyway but it never did (even under 2.4)
Go to the top of the page
 
+Quote Post
kopsis
post Aug 4 2006, 08:01 AM
Post #3





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



QUOTE(Hrw @ Aug 4 2006, 10:32 AM)
I used irdadump (from feed) and it detect my phone and palmtops. It does not detect Ir keyboard anyway but it never did (even under 2.4)
*


Keyboards typically use raw SIR and don't support any of the higher level IRDA protocols so they'll never show up in an IRDA discovery.

I'll grab irdadump and see if I that works on my Z. It won't tell me much but it may help me focus my debug efforts.
Go to the top of the page
 
+Quote Post
kopsis
post Aug 4 2006, 01:38 PM
Post #4





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



Ok, I'm slowly starting to understand this problem.

In the 2.6 OZ kernel, all of the hardware specific IR port code lives in the pxaficp_ir module which hooks into the irda module to provide hardware control. So an ifconfig irda0 up makes the IRDA stack turn on and connect to the IR port. All of the OBEX stuff uses the IRDA stack so it works OK (my phone was able to see my Z and vice versa).

However, most (all?) keyboards are SIR only. They don't support any of the IRDA protocols. So zkbdd needs to connect directly to the tty device that is associated with the IR port. But IRDA owns the port so when zkbdd tries to control ttyS2, it fails. If I disconnect the IRDA stack with an ifconfig irda0 down, it powers off the IR port so now zkbdd can connect to ttyS2 just fine, but it doesn't do me any good because the port is shut off. I'm not entirely sure how to get around this yet. If anyone out there actually knows how this works, I'd love to hear from you. Note that this is on GPE. I suppose it's possible that OPIE has the solution burried in it somewhere. If anyone has gotten IRK to work with OZ 3.5.4.1 on a C7x0/C8x0, I'd love to hear from you.

Bottom line is that it doesn't look like zkbdd on 2.6 kernel devices is going to happen until I can get this sorted out.
Go to the top of the page
 
+Quote Post
lazd
post Aug 4 2006, 01:59 PM
Post #5





Group: Members
Posts: 10
Joined: 29-May 05
Member No.: 7,230



QUOTE(kopsis @ Aug 4 2006, 01:38 PM)
Ok, I'm slowly starting to understand this problem.

In the 2.6 OZ kernel, all of the hardware specific IR port code lives in the pxaficp_ir module which hooks into the irda module to provide hardware control. So an ifconfig irda0 up makes the IRDA stack turn on and connect to the IR port. All of the OBEX stuff uses the IRDA stack so it works OK (my phone was able to see my Z and vice versa).

However, most (all?) keyboards are SIR only. They don't support any of the IRDA protocols. So zkbdd needs to connect directly to the tty device that is associated with the IR port. But IRDA owns the port so when zkbdd tries to control ttyS2, it fails. If I disconnect the IRDA stack with an ifconfig irda0 down, it powers off the IR port so now zkbdd can connect to ttyS2 just fine, but it doesn't do me any good because the port is shut off. I'm not entirely sure how to get around this yet. If anyone out there actually knows how this works, I'd love to hear from you. Note that this is on GPE. I suppose it's possible that OPIE has the solution burried in it somewhere. If anyone has gotten IRK to work with OZ 3.5.4.1 on a C7x0/C8x0, I'd love to hear from you.

Bottom line is that it doesn't look like zkbdd on 2.6 kernel devices is going to happen until I can get this sorted out.
*


Dave,
zkbdd takes input perfectly on ttyS2 on my collie SL5500 under 3.5.4, meaning scancodes register on the test9600 driver. Maybe there is a conflict with the setup for your phone? Both kbdd .1 and zkbdd .2 access ttyS2 fine for me on a default install, kbdd .1 even passes input correctly to the kernel and I get the 1500T maps (which are totally off). Let me know what you think, or if I could send you any info or test anything. I think we're really close here.
-Larry
Go to the top of the page
 
+Quote Post
koen
post Aug 4 2006, 02:30 PM
Post #6





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



QUOTE(lazd @ Aug 4 2006, 09:59 PM)
QUOTE(kopsis @ Aug 4 2006, 01:38 PM)
Ok, I'm slowly starting to understand this problem.

In the 2.6 OZ kernel, all of the hardware specific IR port code lives in the pxaficp_ir module which hooks into the irda module to provide hardware control. So an ifconfig irda0 up makes the IRDA stack turn on and connect to the IR port. All of the OBEX stuff uses the IRDA stack so it works OK (my phone was able to see my Z and vice versa).

However, most (all?) keyboards are SIR only. They don't support any of the IRDA protocols. So zkbdd needs to connect directly to the tty device that is associated with the IR port. But IRDA owns the port so when zkbdd tries to control ttyS2, it fails. If I disconnect the IRDA stack with an ifconfig irda0 down, it powers off the IR port so now zkbdd can connect to ttyS2 just fine, but it doesn't do me any good because the port is shut off. I'm not entirely sure how to get around this yet. If anyone out there actually knows how this works, I'd love to hear from you. Note that this is on GPE. I suppose it's possible that OPIE has the solution burried in it somewhere. If anyone has gotten IRK to work with OZ 3.5.4.1 on a C7x0/C8x0, I'd love to hear from you.

Bottom line is that it doesn't look like zkbdd on 2.6 kernel devices is going to happen until I can get this sorted out.
*


Dave,
zkbdd takes input perfectly on ttyS2 on my collie SL5500 under 3.5.4, meaning scancodes register on the test9600 driver. Maybe there is a conflict with the setup for your phone? Both kbdd .1 and zkbdd .2 access ttyS2 fine for me on a default install, kbdd .1 even passes input correctly to the kernel and I get the 1500T maps (which are totally off). Let me know what you think, or if I could send you any info or test anything. I think we're really close here.
-Larry
*



your collie is running 2.4, not 2.6
Go to the top of the page
 
+Quote Post
lazd
post Aug 4 2006, 05:06 PM
Post #7





Group: Members
Posts: 10
Joined: 29-May 05
Member No.: 7,230



that would explain the difference, but it sounds like this will work for collie owners sooon.
Go to the top of the page
 
+Quote Post
kopsis
post Aug 4 2006, 06:24 PM
Post #8





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



Yeah, my IR problems are specific to the 2.6 kernel. Unfortunately that's preventing me from testing the userspace portions of the new version of zkbdd which (once debugged) may work fine with the 2.4 OZ kernel. Perhaps I'll dig out my old 5500 this weekend and flash OZ onto it so I have a 2.4 machine to test on.

In the mean time I'm digging through the 2.6/2.4 kernel code. IR keyboard support is a deal breaker for me (much more important than IRDA) so I'm determined to get this working on clamshells. I now think I know exactly what's wrong and I'm working on ideas to fix it. Stay tuned.
Go to the top of the page
 
+Quote Post
anunakin
post Oct 13 2006, 12:26 PM
Post #9





Group: Members
Posts: 340
Joined: 22-August 04
From: Belem, Brasil
Member No.: 4,358



I have found a minor change on pxaficp_ir.c in kernel 2.6.18
CODE
diff -ruN /usr/src/linux-2.6.16/drivers/net/irda/pxaficp_ir.c /usr/src/linux-2.6.18/drivers/net/irda/pxaficp_ir.c
--- /usr/src/linux-2.6.16/drivers/net/irda/pxaficp_ir.c 2006-03-20 02:53:29.000000000 -0300
+++ /usr/src/linux-2.6.18/drivers/net/irda/pxaficp_ir.c 2006-09-20 00:42:06.000000000 -0300
@@ -12,7 +12,6 @@
 * Infra-red driver (SIR/FIR) for the PXA2xx embedded microprocessor
 *
 */
-#include <linux/config.h>
#include <linux/module.h>
#include <linux/types.h>
#include <linux/init.h>


Maybe it solve this issue? ph34r.gif
Go to the top of the page
 
+Quote Post
kopsis
post Oct 14 2006, 06:41 PM
Post #10





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



QUOTE(anunakin @ Oct 13 2006, 03:26 PM)
I have found a minor change on pxaficp_ir.c in kernel 2.6.18
*


Nope. Problem is that pxaficp_ir is used only for the IRDA protocol. Yes, some devices can do TTY over IRDA (ircomm) but most keyboards are not among them.

Keyboards need IR support in the PXA serial port driver. Sharp had kludged a bunch of extra IR handling code into the 2.4 kernel serial port driver, but none of it is present in the 2.6 kernel serial driver. Someone with a lot of time on their hands is going to have to either figure out Sharp's (actually Lineo's) spaghetti code and port it to the 2.6 serial driver or they'll have to design in IR support from scratch. I have the knowledge but I expect to be working 60 hour weeks through Feb so not much time for volunteer kernel hacking. I'm actually looking to drop back to a 2.4 kernel based ROM so I can get my keyboard back.
Go to the top of the page
 
+Quote Post
koen
post Oct 15 2006, 12:22 AM
Post #11





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



QUOTE(kopsis @ Oct 15 2006, 02:41 AM)
QUOTE(anunakin @ Oct 13 2006, 03:26 PM)
I have found a minor change on pxaficp_ir.c in kernel 2.6.18
*


Nope. Problem is that pxaficp_ir is used only for the IRDA protocol. Yes, some devices can do TTY over IRDA (ircomm) but most keyboards are not among them.

Keyboards need IR support in the PXA serial port driver. Sharp had kludged a bunch of extra IR handling code into the 2.4 kernel serial port driver, but none of it is present in the 2.6 kernel serial driver. Someone with a lot of time on their hands is going to have to either figure out Sharp's (actually Lineo's) spaghetti code and port it to the 2.6 serial driver or they'll have to design in IR support from scratch. I have the knowledge but I expect to be working 60 hour weeks through Feb so not much time for volunteer kernel hacking. I'm actually looking to drop back to a 2.4 kernel based ROM so I can get my keyboard back.
*



Filed a bug about it?
Go to the top of the page
 
+Quote Post
KerwoodDerby
post Oct 15 2006, 03:03 AM
Post #12





Group: Members
Posts: 7
Joined: 15-June 06
Member No.: 10,174



QUOTE(kopsis @ Aug 4 2006, 05:38 PM)
Ok, I'm slowly starting to understand this problem.

In the 2.6 OZ kernel, all of the hardware specific IR port code lives in the pxaficp_ir module which hooks into the irda module to provide hardware control. So an ifconfig irda0 up makes the IRDA stack turn on and connect to the IR port. All of the OBEX stuff uses the IRDA stack so it works OK (my phone was able to see my Z and vice versa).

However, most (all?) keyboards are SIR only. They don't support any of the IRDA protocols.
*

For the sake of completeness, the latest Pocketop keyboard (CT4700) really does emit complete IRDA packets, which I was able to observe using irdadump. (However, the keyboard also has a serious design defect: relatively high idle current and no way to switch it off, running the battery down in a few days.)

Marshall
Go to the top of the page
 
+Quote Post
kopsis
post Oct 15 2006, 07:16 PM
Post #13





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



QUOTE(koen @ Oct 15 2006, 03:22 AM)
Filed a bug about it?
*


No, I haven't.

When I tried, my first problem was that the only choices for "product" were:
QUOTE
BitBake:    Bug reports for the BitBake build tool
Openembedded:  Queue for tracking tickets against the OE metadata repository and OE based distributions.

Neither of which seemed entirely appropriate. The OE Bugzilla DB has a "Zaurus Kernel" product which does seem like the correct place, but the submit page doesn't give me that option. I was a little worried that submitting incorrectly would get me labeled a "whiny Zaurus user" for whom the OE folks clearly have a serious dislike (and then what would my chances be of my bug ever being fixed).

But, not being one to give up easily, I decided to take a chance and pick Openembedded. Now I'm faced with a Bugzilla login screen. I need to register for an account and provide an email address. It has to be a working address because I can't log in until a password gets mailed to me. And then that address is going to get slapped onto my bug report with no obfuscation whatever making it a prime target for spammers. No thanks.

If you are serious about wanting end users to submit bug reports, then you need to make it easier and you need to provide at least a little protection for the submitter's personal information. And if you're really serious about it, then you need to hide that Bugzilla abomination on a developer's only site and give end users a nice simple "Submit a bug" form that doesn't require registration and doesn't have more than about 4 fields and a "submit" button. I should probably submit a bug report for that ... ERROR: RECURSIVE POST DETECTED smile.gif
Go to the top of the page
 
+Quote Post
koen
post Oct 15 2006, 11:12 PM
Post #14





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



let me tell the gnome, gentoo and kde folk that bugzilla doesn't work for users, so they can install something different, since you speak for *each and every* user.
Go to the top of the page
 
+Quote Post
kopsis
post Oct 16 2006, 08:38 AM
Post #15





Group: Members
Posts: 329
Joined: 1-July 04
Member No.: 3,880



QUOTE(koen @ Oct 16 2006, 02:12 AM)
let me tell the gnome, gentoo and kde folk that bugzilla doesn't work for users, so they can install something different, since you speak for *each and every* user.
*

I didn't say don't use bugzilla, I said hide it behind a friendly interface.

Have you actually looked at KDE's bugzilla interface? They did exactly what I suggested and hid bugzilla's horrible bug entry form behind a nice user friendly wizard that presents only a couple fields at a time and actually explains what to do with them. Yeah, I still have to register an account, but since they don't plaster my registered email address all over the displayed bug reports, it's a minor inconvenience.

And no, I don't speak for all users. But I do have extensive experience providing support to paying customers. Since you're always pissed off about users not entering OE bug reports, I thought you might appreciate some suggestions that could help address that problem. I forgot that the only "acceptable" explanations are those that put the blame on the users.

OpenZaurus has such great potential, it's a shame it's shrouded in such an impenetrable cloud of arrogance.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 09:09 AM