Ir Problems With 3.5.4.1

[kopsis]

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?

[Hrw]

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)

[kopsis]

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)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137452\"][{POST_SNAPBACK}][/a][/div]

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.

[kopsis]

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.

[lazd]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137471\"][{POST_SNAPBACK}][/a][/div]

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

[koen]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137471\"][{POST_SNAPBACK}][/a][/div]

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
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137474\"][{POST_SNAPBACK}][/a][/div]

your collie is running 2.4, not 2.6

[lazd]

that would explain the difference, but it sounds like this will work for collie owners sooon.

[kopsis]

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.

[anunakin]

I have found a minor change on pxaficp_ir.c in kernel 2.6.18

Code: [Select]

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
 #include
 #include
 #include
Maybe it solve this issue?  

[kopsis]

I have found a minor change on pxaficp_ir.c in kernel 2.6.18
[div align=\"right\"][a href=\"index.php?act=findpost&pid=143947\"][{POST_SNAPBACK}][/a][/div]

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.

[koen]

I have found a minor change on pxaficp_ir.c in kernel 2.6.18
[div align=\"right\"][a href=\"index.php?act=findpost&pid=143947\"][{POST_SNAPBACK}][/a][/div]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144003\"][{POST_SNAPBACK}][/a][/div]

Filed a bug about it?

[KerwoodDerby]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137471\"][{POST_SNAPBACK}][/a][/div]

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

[kopsis]

Filed a bug about it?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144019\"][{POST_SNAPBACK}][/a][/div]

No, I haven't.

When I tried, my first problem was that the only choices for "product" were:

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

[koen]

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.

[kopsis]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144082\"][{POST_SNAPBACK}][/a][/div]

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.