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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
- 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',
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
23 matches
Mail list logo
