On Sun, 2008-11-09 at 20:57 +0100, Niels de Vos wrote:
> 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
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
>> > > tr
On Sat, 2008-11-08 at 18:02 -0500, Chris Frey wrote:
> Hi Rick,
>
> Your latest CVS compiles against 2.6.26.5.
>
> I noticed you fixed a couple of errors in my previous patches. Thanks.
>
>
> > We can't return ENODEV if the socket is 0 in desktop_open. In the case
> > of a non-blocking open th
Hi Rick,
Your latest CVS compiles against 2.6.26.5.
I noticed you fixed a couple of errors in my previous patches. Thanks.
> We can't return ENODEV if the socket is 0 in desktop_open. In the case
> of a non-blocking open the socket will not yet have been set, but
> the open must succeed. This
On Sat, Nov 8, 2008 at 5:59 PM, Rick Scott <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-11-08 at 17:20 -0500, Martin Owens wrote:
>> 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
On Sat, 2008-11-08 at 17:20 -0500, Martin Owens wrote:
> 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 mainlin
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
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
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 sou
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
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
On Sat, 2008-11-08 at 01:24 -0500, Chris Frey wrote:
> 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?
Is software ever really finished :) How so?
>
> It also looks like the interface, f
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 rea
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
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.
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/ker
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, s
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 late
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
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
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
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 cc44215eaaa5e4032946b962353526ae
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
--
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
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, al
> 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 kno
On Thu, 2008-10-16 at 21:46 -0400, Chris Frey wrote:
> On Wed, Oct 08, 2008 at 06:32:42AM -0400, Rick Scott wrote:
> > 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
On Wed, Oct 08, 2008 at 06:32:42AM -0400, Rick Scott wrote:
> 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 wo
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 fiel
On Wed, Oct 08, 2008 at 01:59:55PM -0400, Martin Owens wrote:
> What I feel is that instead of me running barry discover the information
> could be made available via a serial node. although if Chris would
> include my fdi/hal stuff in the distrobution I'd at least get feedback
> about it.
I didn'
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 R
>
> - 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
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.
> 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. Th
On Wed, Oct 8, 2008 at 11:59 AM, Martin Owens <[EMAIL PROTECTED]> wrote:
>> >>
>> >> 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 t
> >>
> >> 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.
>
> Is it important tha
On Wed, Oct 8, 2008 at 11:13 AM, Martin Owens <[EMAIL PROTECTED]> wrote:
> 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
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 wr
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 de
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 min
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
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 ident
> > 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
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
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, bbm
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 ol
46 matches
Mail list logo
