Re: [Barry-devel] kernel driver notes
Hi Rick, On Sat, Nov 8, 2008 at 10:14 AM, Rick Scott [EMAIL PROTECTED] wrote: On Fri, 2008-11-07 at 21:59 -0500, Chris Frey wrote: On Fri, Nov 07, 2008 at 08:04:54PM -0500, Rick Scott wrote: I grabbed your latest CVS and noticed you added ifdefs. I was still having trouble compiling against 2.6.26.5, so I'm moving the crypto stuff into its own API... I think we only need sha1 right? That's all I know about, so far :) Me too. :-) In going through the module, and working on getting it to compile, I was wondering what your plans are for it. Are you planning to eventually include it in the main kernel? If so, perhaps it is not worth it to work so hard to support all possible kernels, and focus should be on supporting the latest kernel, and using the kernel coding style guidelines. - Chris Plans? I plan on using it, and learning a little more about the kernel. I don't want to rule out the possibility of it being in the main kernel. If it does get to the main kernel, someone else would probably take care of little changes, like the URB callback stuff. That would be nice :) With all of the #ifdef's creeping in, I'm thinking of doing some autoconf macros to spot the differences and using #ifdef HAVE_xxx instead of having to figure out the correct kernel version for these things. Should be able to get the info from the headers I started out trying automake, but it was insisting on things that didn't work with a kernel Makefile :( It should be doable with autoconf though. Inclusion in main-line should be the target imho. I would also be able to do some reviewing if you like. I'm not that senior in the linux-kernel, but I'm working with usb-drivers too. Instead of working with #ifdef in the main sources for version checking, I would recommend a compatibility header. Only use the new/current kernel funtions, backport/fake them in a header which can be included on the command-line. Same trick does madwifi with compat..h (http://madwifi-project.org/browser/madwifi/trunk/include/compat.h) and 'gcc -include header ...'. In the short term, it _has_ to work with my Fedora Core [34] and CentOS 5.2 boxes, along with my 8800. I have a 6200, 7100, 8700, and 8800 that I test with. Oh, and a 6710 which is not relevant for the module but is my gold standard for the serial protocol, along with the rfcomm bluetooth of the newer devices. Using the same distros here, but I also have the current git-tree of the kernel for compiling against. Please let me know if I can be of any help. (Where are the sources exactly?) Cheers, Niels - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver questions
On Sat, 2008-11-08 at 05:37 -0500, Chris Frey wrote: On Sat, Nov 08, 2008 at 05:11:23AM -0500, Rick Scott wrote: In reading through the code, it appears that the desktop support is not finished yet. Is this correct? Is software ever really finished :) How so? :-) I saw a desktop_write() but I didn't see a desktop_read(), so I assumed that meant it was not quite functional. That one had me going for a while also :) Read is handled by the tty layer, all we need to do is stuff the flip_buffer. I've been using it for my daily syncs for a couple weeks now. Most of the problems I was having were with the device resetting when using pppd, but that seems solid now also. Only one program would have desktop0 open. That's not really accurate ... Only one program would be reading/writing desktop at a time, other programs/threads may have it open to monitor the modem lines. Hmmm... I was hoping for sharing of the socket. I suppose if one program is in the middle of a full database download, the socket would need to be busy. Still, I was hoping that it would be possible to do a sync at the same time as having a FUSE filesystem loaded, since normally there's lots of idle time between USB commands. Interesting idea. Sort of makes me think of fsck'ing a disk while it is mounted though With the right FUSE layout the sync could be done with it, think opensync's file sync. That way we wouldn't have to deal with an opensync plugin for the rim. Dealing with opensync is not a great deal of fun, as I'm sure you are aware Is there any way of telling which file descriptor is talking to the tty, in the kernel module? I'd like to know that it is theoretically possible, even if it isn't yet implemented. I'm new to the kernel also :) I think the file descriptor would probably be the same, but you could burrow down to find the pid of the process, somehow. fd, pid would probably be a unique indicator. Your patches break my build :( Not terribly bad though. Moving in the right direction :) Thanks, - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver questions
On Sat, Nov 08, 2008 at 05:11:23AM -0500, Rick Scott wrote: In reading through the code, it appears that the desktop support is not finished yet. Is this correct? Is software ever really finished :) How so? :-) I saw a desktop_write() but I didn't see a desktop_read(), so I assumed that meant it was not quite functional. Only one program would have desktop0 open. That's not really accurate ... Only one program would be reading/writing desktop at a time, other programs/threads may have it open to monitor the modem lines. Hmmm... I was hoping for sharing of the socket. I suppose if one program is in the middle of a full database download, the socket would need to be busy. Still, I was hoping that it would be possible to do a sync at the same time as having a FUSE filesystem loaded, since normally there's lots of idle time between USB commands. Is there any way of telling which file descriptor is talking to the tty, in the kernel module? I'd like to know that it is theoretically possible, even if it isn't yet implemented. Thanks, - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver license details
On Sat, 2008-11-08 at 04:18 -0500, Rick Scott wrote: On Sat, 2008-11-08 at 01:06 -0500, Chris Frey wrote: Hi Rick, I notice that your license text for your kernel module indicates GPL v2 only while the code indicates GPL v2 or later. That seemed to be what the kernel sources I looked at had, so I wanted to go with that. It might not be a good idea to limit the kernel further like this. It's going to be a job enough contacting all the authors of existing GPLv2 only code without having even more code that'll need licensing later on. Regards, Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver license details
Just as a point here, and only because I know far too much about OSS licensing and have worked closely with the Linux Foundation. If you intend to follow kernel mainline as decided by Linus, he has already stated that ALL mainline code should be GPLv2 only. So I would strongly suggest that you have GPL v2 (leave out the 'or later', that's enough). Chris (aka Chris Maresca - Founding Partner - www.olliancegroup.com) Rick Scott wrote: On Sat, 2008-11-08 at 01:06 -0500, Chris Frey wrote: Hi Rick, I notice that your license text for your kernel module indicates GPL v2 only while the code indicates GPL v2 or later. That seemed to be what the kernel sources I looked at had, so I wanted to go with that. If you really do mean GPL v2 only, you may wish to apply the following patch. This is based on the comments in include/linux/module.h. Good point, done... - Chris diff --git a/kernel/init.c b/kernel/init.c index 4e33e3a..2b068e8 100644 --- a/kernel/init.c +++ b/kernel/init.c @@ -44,7 +44,7 @@ #define SUCCESS (0) #endif -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); MODULE_AUTHOR(PACKAGE_BUGREPORT); MODULE_DESCRIPTION(Device driver for the RIM Blackberry); MODULE_VERSION(PACKAGE_VERSION); - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver license details
On Sat, 2008-11-08 at 11:56 -0800, Chris Maresca wrote: Just as a point here, and only because I know far too much about OSS licensing and have worked closely with the Linux Foundation. If you intend to follow kernel mainline as decided by Linus, he has already stated that ALL mainline code should be GPLv2 only. So I would strongly suggest that you have GPL v2 (leave out the 'or later', that's enough). It's usually not like Linus to limit his future options like that. Are you sure? can you cite? If it's true, then it would be a damning irrational act, since it's going to be a bastard to move the kernel to GPLv4 in 80 years. And starting a new kernel project, well... Regards, Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] kernel driver notes
On Thu, 2008-11-06 at 20:41 -0500, Chris Frey wrote: Hi Rick, Starting a new thread for commentary on the kernel, and various questions and notes. In November 2006, the crypto_digest* family of functions was removed from the kernel: commit cc44215eaaa5e4032946b962353526ae6c370c0e Author: Adrian Bunk [EMAIL PROTECTED] Date: Wed Nov 22 17:55:00 2006 +1100 [CRYPTO] api: Remove unused functions This patch removes the following no longer used functions: - api.c: crypto_alg_available() - digest.c: crypto_digest_init() - digest.c: crypto_digest_update() - digest.c: crypto_digest_final() - digest.c: crypto_digest_digest() Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Herbert Xu [EMAIL PROTECTED] It seems that the crypto algorithms are now split out into *_alg structs, with function pointers as 'member functions' of the various sets of crypto APIs. That kinda sounds like the way it is ... This change makes it fail to compile on a recent kernel like 2.6.26.5. Guess I'm going to have to find a newer kernel. Most of the crypto stuff was done with 2.6.18. I only have access to Fedora Core [34] and CentOS 5.2 at the moment. The digest_alg API (not sure if that's the one you want to use) seems to have stabilized at the 2.6.17 kernel release. I'm not positive it's the one I want either, but it gives me good hash (so to speak :). And I've been using 2.6.18 ... I'll have to have a look - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] kernel driver notes
On Fri, 2008-11-07 at 02:14 -0500, Chris Frey wrote: On Thu, Nov 06, 2008 at 08:41:25PM -0500, Chris Frey wrote: The digest_alg API (not sure if that's the one you want to use) seems to have stabilized at the 2.6.17 kernel release. Are you in patch-accepting mode if I happen to cook one up for the 2.6.26 kernel? Most definitely!! If you become too annoying I'll make you commit them yourself :) - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] kernel driver notes
On Fri, 2008-11-07 at 18:47 -0500, Chris Frey wrote: On Fri, Nov 07, 2008 at 07:03:42AM -0500, Rick Scott wrote: I just pulled back 2.6.27. I think I see the differences, more reading :( Would it help in the short term if I just #ifdef out the password stuff?? I grabbed your latest CVS and noticed you added ifdefs. I was still having trouble compiling against 2.6.26.5, so I'm moving the crypto stuff into its own API... I think we only need sha1 right? That's all I know about, so far :) It should be easier to deal with multiple kernels in one module. - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
[Barry-devel] Kernel driver license details
Hi Rick, I notice that your license text for your kernel module indicates GPL v2 only while the code indicates GPL v2 or later. If you really do mean GPL v2 only, you may wish to apply the following patch. This is based on the comments in include/linux/module.h. - Chris diff --git a/kernel/init.c b/kernel/init.c index 4e33e3a..2b068e8 100644 --- a/kernel/init.c +++ b/kernel/init.c @@ -44,7 +44,7 @@ #define SUCCESS (0) #endif -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); MODULE_AUTHOR(PACKAGE_BUGREPORT); MODULE_DESCRIPTION(Device driver for the RIM Blackberry); MODULE_VERSION(PACKAGE_VERSION); - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
[Barry-devel] Kernel driver questions
Hi Rick, Got some questions for you: :-) In reading through the code, it appears that the desktop support is not finished yet. Is this correct? It also looks like the interface, from a userspace perspective, is reading and writing to the desktop0 tty, and using the Blackberry serial protocol. Is this correct? How much different is that, once the size and socket are stripped off a USB packet? Also, how do you plan on multiplexing multiple programs that have the same desktop0 tty open, and are using the same desktop socket? I don't see how to tell which file descriptor is currently reading or writing to the tty. tty_struct-index appears to be for something else. And finally, do you want me to cc the xmblackberry list for the patches I send? Thanks! - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] kernel driver notes
On Thu, Nov 06, 2008 at 08:41:25PM -0500, Chris Frey wrote: The digest_alg API (not sure if that's the one you want to use) seems to have stabilized at the 2.6.17 kernel release. Are you in patch-accepting mode if I happen to cook one up for the 2.6.26 kernel? - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
I didn't realize you wanted it included. The research packet I received in December 2007 had a note reminding me that it contained private data from people's phones. I generally don't apply patches unless people ask publically, or they grant permission publically. Please let me know what is safe to apply, ideally in 'diff -ruN' format, or even just a tarball, and I'll gladly drop it into the contrib/ directory. If you have granted this permission, and I dropped it on the floor, my apologies. Just keep bugging me. :-) It's done as a part of the usb mass storage specification. Much like the usb audio specification which allows all usb audio devices (the ones that use the standard) to work without specific drivers. What happens is that the system sees the mass storage device end points in the usb schema and adds the capability to the hal nodes. which then promptly enable any auto mounting or configuration such as custom icon searching ect. PhoneIntergration.tar.gz Description: GNU Zip compressed data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
2008/10/16 Chris Frey [EMAIL PROTECTED]: On Wed, Oct 08, 2008 at 04:45:10PM -0400, Martin Owens wrote: Capability 'tethering' links into the network manager and uses a general schema for phone tethering. Capability 'databases' provides ways to access multiple device databases, although nothing specific about what tables or fields, that would be handled by the app (such as an open-sync plugin) Capability 'mass-storage-device' already works, check it out as an example of how this kind of thing can be done. Hi Martin, Was the 'mass-storage-device' capability done specifically for the Blackberry? Or is it just part of the normal USB Mass Storage class support? Ah I see, Well it's really just two files (see attached), the first is an fdi file that should be added to /usr/share/hal/fdi/information/10freedesktop/ and the second is a script which should go in the bin directory. See attached. If you install them right you should see extra data in your hal information when you use the hal list script or the hardware information gui. Best Regards, Martin Owens P.S. Emails have been garbled by gmail-SMTP failures and I think I've sent the wrong responses to the wrong emails. sorry. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
On Mon, Oct 06, 2008 at 08:06:04PM -0400, Rick Scott wrote: I just noticed mention of a kernel driver in your TODO file. It just happens that I'm looking at that now. My thought is to create a device file for each function. So for the first blackberry plugged in, you'd get bbdesktop0, bbmodem0, bbjavaloader0, and so on. The serial protocol, used in the older devices and bluetooth, is basically the same as what is sent over the RIM Desktop socket with a different header. So if the RIM Desktop packets are converted to the serial format and presented on bbdesktop0, anything to do with database access is the same on /dev/ttyS0, /dev/ttyUSB0, /dev/rfcomm0, /dev/bbdesktop0. The modem from /dev/rfcomm1, /dev/bbmodem1, and so on. This would give consistent access to all of the functions, whatever the means of connection. Hi Rick, It's a useful feature to have the ability to share a Blackberry USB connection across multiple programs and multiple purposes. I think it is best to start at the lowest level we can, and we may run into some roadblocks along the way. Especially the probe messages that are not well understood yet. I think a kernel level interface that handles sockets and the opening and closing of modes, is best. I'm quite against the idea of putting record parsing in the kernel... I don't want to have to recompile my kernel to get at a new Contact field, nor do I want to swim the depths of the the kernel development process for something that is more quickly updated in userspace. But it *would* be very useful to do something like this: start a backup start a tethered modem connection end backup start a javaloader transfer start a restore end restore do a full sync of contacts and calendar end javaloader end modem There are some gotcha's in that list, I think. :-) Should be doable in theory though. Thoughts? - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
On Wed, 2008-10-08 at 04:16 -0400, Chris Frey wrote: On Mon, Oct 06, 2008 at 08:06:04PM -0400, Rick Scott wrote: I just noticed mention of a kernel driver in your TODO file. It just happens that I'm looking at that now. My thought is to create a device file for each function. So for the first blackberry plugged in, you'd get bbdesktop0, bbmodem0, bbjavaloader0, and so on. The serial protocol, used in the older devices and bluetooth, is basically the same as what is sent over the RIM Desktop socket with a different header. So if the RIM Desktop packets are converted to the serial format and presented on bbdesktop0, anything to do with database access is the same on /dev/ttyS0, /dev/ttyUSB0, /dev/rfcomm0, /dev/bbdesktop0. The modem from /dev/rfcomm1, /dev/bbmodem1, and so on. This would give consistent access to all of the functions, whatever the means of connection. Hi Rick, It's a useful feature to have the ability to share a Blackberry USB connection across multiple programs and multiple purposes. I think it is best to start at the lowest level we can, and we may run into some roadblocks along the way. Especially the probe messages that are not well understood yet. I think a kernel level interface that handles sockets and the opening and closing of modes, is best. I'm quite against the idea of putting record parsing in the kernel... I don't want to have to recompile my kernel to get at a new Contact field, nor do I want to swim the depths of the the kernel development process for something that is more quickly updated in userspace. I think we are on the same page here. My thought is to handle the socket 0 stuff in the module and have a device file created for all the other sockets that get opened. So far, RIM Desktop and Usb_SerData. The desktop socket would peal off the usb type header, socket and length, and replace it with the serial header, 3 constant bytes and a checksum. That would give a consistent interface to the device on usb, bluetooth, and serial. Record parsing and a database file system would be better left to a fuse implementation, I think. It would be cool though, just cat a vCard into a file :) I've got a loadable module building outside of the kernel tree, so control would still be outside of the kernel process. Gotta run to pay the bills, more later But it *would* be very useful to do something like this: start a backup start a tethered modem connection end backup start a javaloader transfer start a restore end restore do a full sync of contacts and calendar end javaloader end modem There are some gotcha's in that list, I think. :-) Should be doable in theory though. Take out the javaloader part and it's doable now. Thoughts? - Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
On Wed, Oct 8, 2008 at 7:03 AM, Martin Owens [EMAIL PROTECTED] wrote: I think it is best to start at the lowest level we can, and we may run into some roadblocks along the way. Especially the probe messages that are not well understood yet. Did you ever work out how to identify a given BlackBerry device? having good identification for devices is key if you want to move functionality up into userspace. If you can create a black berry information dobry that's used by dbi and/or hal to populate stuff ready for userland. _that_ would be useful. So long as hardware identification, power management (you know) and low level interfaces are kernel bound. The user space can excel then at cooking up some cool stuff. Since 2.6 linux has started to rely heavily on hal and a quick glance at it on an F8 (2.6.21) box shows that hal notices a blackberry as both a storage device and a usb device. And once hal has noticed a device it's very easy to get whatever information there is out. I haven't been paying a lot of attention to what information barry wants, but I'll go back and look so we can verify that hal sees what we want it to see. -edge - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
I agree with edge. I don't see much point in a kernel driver as it's USB device and it's already recognized by the HAL. Perhaps a better USB HAL driver, but a kernel driver seems like overkill and dangerous. Chris. Brian Edginton wrote: On Wed, Oct 8, 2008 at 7:03 AM, Martin Owens [EMAIL PROTECTED] wrote: I think it is best to start at the lowest level we can, and we may run into some roadblocks along the way. Especially the probe messages that are not well understood yet. Did you ever work out how to identify a given BlackBerry device? having good identification for devices is key if you want to move functionality up into userspace. If you can create a black berry information dobry that's used by dbi and/or hal to populate stuff ready for userland. _that_ would be useful. So long as hardware identification, power management (you know) and low level interfaces are kernel bound. The user space can excel then at cooking up some cool stuff. Since 2.6 linux has started to rely heavily on hal and a quick glance at it on an F8 (2.6.21) box shows that hal notices a blackberry as both a storage device and a usb device. And once hal has noticed a device it's very easy to get whatever information there is out. I haven't been paying a lot of attention to what information barry wants, but I'll go back and look so we can verify that hal sees what we want it to see. -edge - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
The problem, is that it's not recognised in HAL. Most BlackBerries are recognised as generic 0001/0004 or 0006 modes via usb_id. What you'd need to do is write a HAL driver that can give something of a meaning to the device other than the generic information available at the moment. I wouldn't mind if you wrote a udev script. On Wed, 2008-10-08 at 08:10 -0700, Chris Maresca wrote: I agree with edge. I don't see much point in a kernel driver as it's USB device and it's already recognized by the HAL. Perhaps a better USB HAL driver, but a kernel driver seems like overkill and dangerous. Chris. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
On Wed, 2008-10-08 at 10:02 -0600, Brian Edginton wrote: On Wed, Oct 8, 2008 at 9:51 AM, Martin Owens [EMAIL PROTECTED] wrote: The problem, is that it's not recognised in HAL. Most BlackBerries are recognised as generic 0001/0004 or 0006 modes via usb_id. What you'd need to do is write a HAL driver that can give something of a meaning to the device other than the generic information available at the moment. I'm not certain what you mean here, could you elaborate? Here is what I see with just a cursory glance at hal: (again, this is an 8830 on F8) udi = '/org/freedesktop/Hal/devices/usb_device_fca_4_155FF3210780674CC49459D03AE08189ACFE3799_if1_scsi_host_scsi_device_lun0' snip usb.version_bcd = 272 (0x110) (int) Which part of that said it was an 8830? All I saw was generic devices. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
Ah, now I think I understand better what you are thinking. You are detecting the BB properties from user space and stuffing the info back into the os (via hal) and using, or proposing to use, that info from other apps. Am I close? Indeed, Usability by applications is what I'm thinking. There is (as an example) an application called gtkpod which manages ipods. It uses hal via dbus to detect when an ipod is plugged in, yet because of the lack of information available in hal it has to ask the user what kind of ipod was just plugged in. (for compatibility I guess) At the moment we don't even have blackberry or syncing programs that are stable yet. But when we do, I don't want them doing the same thing. If we extend this path, then I guess the most obvious way to access the 'data' is via a file system layer that may look like /dev/bb/pim/various_databases If you do offer this kind of thing, then put it in /sys instead of /dev, no point cluttering up the place. Then again, avoid the whole thing and keep it in user space, put add them as capabilities into hal. Capability 'tethering' links into the network manager and uses a general schema for phone tethering. Capability 'databases' provides ways to access multiple device databases, although nothing specific about what tables or fields, that would be handled by the app (such as an open-sync plugin) Capability 'mass-storage-device' already works, check it out as an example of how this kind of thing can be done. Regards, Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
- usb.serial - usb.vendor_id - usb.product_id So it might be easier to do than it seems. Then again, I don't really know all that much about USB HAL, so perhaps these are just bogus settings. Those fields are gathered from the usb data, so usb.vendor == 'Research in Motion' or 'RIM', usb.vendor_id == 0xfca, usb.product == '', usb.product_id == 0x004 or 0x001 or 0x006 Same problem. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] Kernel driver
All excellent points however We don't have an application that will talk to a blackberry! We have an application that will talk to a blackberry on the usb, we have one that will talk to one on bluetooth and serial but, we don't have one that will talk to a blackberry. This would be simple if RIM didn't cram a whole bunch of functions into a single usb interface. They did it right when they made storage a separate interface. They did it right when they made DUN and Desktop separate bluetooth services (okay, they messed up the ppp protocol, but they got close). They screwed the pooch when they multiplexed a bunch of services into a single usb interface. Even worse, is that these multiple services are on the same 2 endpoints. They simplified things somewhat by moving the modem access to its own set of endpoints. What I'm proposing is a thin module to simply de-multiplex the mess into separate devices. That way a single application can talk to the blackberry desktop by pointing it at the correct device file. The application will not have to know what type of interface the blackberry is attached to. It will also provide simultaneous access to the desktop, modem, and storage. All of this wonderful DBUS and HAL stuff will be simpler once the mess of multiple independent services in a single interface is fixed up. On Wed, 2008-10-08 at 14:59 -0700, Chris Maresca wrote: Could you not have a userspace application interrogate the BB when plugged in? After all, you do know it's a Blackberry (or at least a RIM device) from the HAL logs sent by Edge. There are also a bunch of identifiers that might identify the specific device: - usb.serial - usb.vendor_id - usb.product_id So it might be easier to do than it seems. Then again, I don't really know all that much about USB HAL, so perhaps these are just bogus settings. Chris. Martin Owens wrote: Ah, now I think I understand better what you are thinking. You are detecting the BB properties from user space and stuffing the info back into the os (via hal) and using, or proposing to use, that info from other apps. Am I close? Indeed, Usability by applications is what I'm thinking. There is (as an example) an application called gtkpod which manages ipods. It uses hal via dbus to detect when an ipod is plugged in, yet because of the lack of information available in hal it has to ask the user what kind of ipod was just plugged in. (for compatibility I guess) At the moment we don't even have blackberry or syncing programs that are stable yet. But when we do, I don't want them doing the same thing. If we extend this path, then I guess the most obvious way to access the 'data' is via a file system layer that may look like /dev/bb/pim/various_databases If you do offer this kind of thing, then put it in /sys instead of /dev, no point cluttering up the place. Then again, avoid the whole thing and keep it in user space, put add them as capabilities into hal. Capability 'tethering' links into the network manager and uses a general schema for phone tethering. Capability 'databases' provides ways to access multiple device databases, although nothing specific about what tables or fields, that would be handled by the app (such as an open-sync plugin) Capability 'mass-storage-device' already works, check it out as an example of how this kind of thing can be done. Regards, Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Barry-devel
