Dear Marcel,
I have reworked the patches as you have requested. They are attached to
this message.
This is the BT HID message parsing framework that I wrote, based on the
Bluetooth HID specs. The kernel versions the patches are against are
mentioned in their names. The one against 2.6.10-rc3-bk6 is the one for
the standard BT HID code in the stock kernel, then other contains fixes
for report mode processing where the BT device is stuck in Boot mode due
to being first of all configured by the computer BIOS.
The devices I tested this with are Apple BT keyboard, and Logitech Mx900
mouse. the changes are all conservative, and should work with all
devices.
I have left the debug work I did as is in the patches as I need it to
debug the work I am doing. It fixes various compile problems with the
debug code, as well as adding output of data that I found useful in
diagnosing my keyboard problems. I am planning to continue my work on
the BT HID as I am able, and hope to do phase 2 (SET_ and GET_) HID
state machines over the Christmas holidays. The Debug stuff has to stay
there. Basically if you want me to significant work in the BT HID area,
I need a free hand to do things. I already have to spend quite a bit of
time making a patch for the standard kernel, as well as against the
2.6.x-mhx patches which I do my development against. We need to discuss
how we are going to work this so that it does not take too much of your
time.
I am hoping to get a Web site up shortly with these patches and further
work, as well as a version control system for a BT HID project!
Best Regards,
Matthew Grant
Hi Marcel,
Thank you for this message. It is good to know all the reasons, and
have an explanation for what is going on. Having the full picture like
this averts a lot of the frustration and makes it all understandable.
I do not have much time to respond fully now, but I will tomorrow.
It all looks really good on my first read.
Best Regards,
Matthew Grant
Have a good weekend!
On Thu, 2004-12-16 at 11:01 +0100, Marcel Holtmann wrote:
> Hi Matthew,
>
> > > I only looked at the -rc3-bk6 patch, because as I said, this is what we
> > > gonna do first. I don't wanna see any debug specific changes in there. I
> > > will remove them anyway and this takes me only longer to merge this
> > > patch into my tree.
> >
> > You have to appreciate this given that I will bw writing 500-1000 lines
> > more of code for net/bluetooth/hidp/core.c (maybe a seperate file) for
> > the control channel state machine:
>
> no need for an extra file. 500-1000 lines are not a lot of code.
>
> > o Your debug code in the hidp directory DOES NOT COMPILE!!!
> > I need working debug for the amount of work I am doing. Please read
> > my patch and fix it!
>
> If my debug code doesn't compile then this is a bug. Why didn't you send
> in a patch for this? Such a fix could already be merged mainline.
>
> > o The code I am writing needs debug code so I can write it and get it
> > working.
>
> Fine with me, but before you submit it for inclusion remove this debug
> code.
>
> > o Extra debug code is needed in other places in the hidp directory to
> > support any general user debugging of the control channel state machine
> > code.
>
> As I said before, I will only allow simple debug code in the Bluetooth
> code that is off by default. I don't think that you can convince to add
> deeper levels of debugging in the code. No extra debug code will make it
> easy to merge your code back mainline. Otherwise we will be stuck here
> and I have to remove everything by myself.
>
> > > The rest of this patch looks fine and there is only
> > > one coding style issues that I might not mentioned last time. In a
> > > "switch" construct we normally add an empty line between "break" and the
> > > next "case".
> > >
> > > And another thing. What is the difference between ...ctrl_message()
> > > and ...ctrl_byte()? We don't need that. If data is NULL then both is the
> > > same.
> >
> > ...ctrl_message() is needed latter in the state machine work as some
> > control messages will be over 1 byte in size. It will be used in phase
> > 2.
>
> You don't get my point. You need only one of these functions to do the
> job. What you did is code duplication:
>
> #define ...ctrl_byte() ...ctrl_message(a, b, NULL, 0)
>
> > You may also notice the 2 separate functions for queueing the sending of
> > control bytes (..ctrl_byte() and ...ctrl_reply()), one from within the
> > hidp_session() kernel process, and one for use from the ioctl(s). Here
> > is my reasoning for it. I take it that you do not want to put extra
> > schedule() calls in the middle of the hidp_session() while loop, between
> > the processing of individual received control packets, before even
> > processing the interrupt (high priority, basically incoming HID events)
> > and the transmission queue. Even if this inserted schedule() call is
> > conditional, 2 extra context switches for the hidp_session() thread get
> > introduced before received keystrokes/HID events are processed, and the
> > transmit queue gets looked at. The BT HID spec says that the interrupt
> > channel should be processed at higher priority (and even before?) the
> > control channel. Both ..ctrl_byte() and ...ctrl_reply() are needed
> > according to this.
>
> I haven't said anything about these two. I will look at it when I
> applied the patch to me tree and started testing.
>
> > Now about us working together, from your replies and comments about my
> > patches it has been obvious to me that you have not had much time to
> > look them over and think about things. You comments on coding style are
> > appreciated, and I myself don't like being sloppy, and I know that the
> > netfilter people are way too sloppy for my own liking to. But you are
> > holding on too tightly to the control of the BT HID code. I need the
> > flexibility and autonomy of being the delegated lead developer there so
> > that my development can be speed along.
>
> The coding style is important, because it makes it a lot easier to merge
> your changes back mainline. I simply won't spent any time fixing coding
> style mistakes of other people.
>
> And actually I looked in detail at your patches, but as I said only the
> patch against the -rc3-bk6. We do this step by step and this is the one
> that comes first. I will merge it back mainline after I tested it with
> my devices. However this will be after 2.6.10 is out.
>
> There is no tight control on the BT HID code, but every patch goes
> through my hands. I acknowlege it or reject it with a reason and an
> advice on how to fix it. The BT HID is a little bit special, because we
> don't have the generic HID parser at the moment. I am working on a final
> Bitkeeper tree for mainline inclusion. This must be done this way,
> because we must keep the revision history. If this is done and 2.6.10 is
> finally out everything will be very easy.
>
> > Could you please freeze the BT HID code in the kernel for 3 months
> > (apart from brown-paper bag stuff), and let me subsume the HID report
> > code in your mh* patches, and strip the net/bluetooth/hidp code from
> > your patches, and use my stuff instead so that I can efficiently get the
> > work done on improving it rapidly. If changes are needed to the in
> > kernel stuff, please feed them my way and I will integrate them as
> > quickly as I can. This should not be too hard, as it looks like there
> > has not been much activity in the BT HID area in the last few months
> > apart from my work.
>
> The generic HID parser is the way to go.
>
> > I really want to work together with you on this, as cooperation will get
> > far more done in the bluetooth area of the kernel given the small user
> > base. If the above arrangement is not suitable to you, please come up
> > with one that we do not have major code clashes when merging each others
> > code.
>
> Since you don't use Bitkeeper, there can't be any easy working together
> until I got the generic HID parser in the right shape. I am not willing
> to loose the revision history of the current USB HID code. It documents
> many reasons why decissions are made and why it is done this way. It is
> way too important.
>
> > If you have doubts as to my ability, I am a professional router
> > programmer who got fired because I insisted on making my work bug-free,
> > robust, and high quality, with experience in OSPF, router device
> > driveers and IPX code. My early CV reads like that of Alan Cox, and I
> > have been using Linux since 1993, with a bit work accepted into the
> > 2.2.x kernel for ethernet bridging, 2.2.x security patches, and
> > 2.2.x/2.4.x Sangoma driver fixes. I will send you my resume if you want
> > to look it over (it is a little out of date).
>
> I have absolutly no doubts on your ability and actually I never read any
> CVs, because I judge on the code people write.
>
> > My patience on this is starting to wear out. If we can't work something
> > out soon, I am going to go ahead anyhow, and the merits of the work by
> > itself will warrant its inclusion in a few months time.
>
> I am sorry for that and I really appreciate your help. At the moment we
> are in the final phase of 2.6.10 and so hoping that we get any stuff
> into it is ridiculous (besides fixing my debug code bug maybe). So what
> we can do is to get your patch against -rc3-bk6 ready for inclusion and
> I will merge it mainline as soon as 2.6.10 is out.
>
> I can start with the merge tree of the generic HID parser tomorrow, but
> actually there is one patch from the input subsystem tree that hasn't
> been merged back mainline so far. It changes a lot of things and I
> haven't looked at it in detail at the moment.
>
> If these two things happened I will remove my current report mode
> support from the -mh patch and we will have a common base. Then you can
> send in changes for the HID parser and/or for the HIDP code.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
Hi Matthew,
> > I only looked at the -rc3-bk6 patch, because as I said, this is what we
> > gonna do first. I don't wanna see any debug specific changes in there. I
> > will remove them anyway and this takes me only longer to merge this
> > patch into my tree.
>
> You have to appreciate this given that I will bw writing 500-1000 lines
> more of code for net/bluetooth/hidp/core.c (maybe a seperate file) for
> the control channel state machine:
no need for an extra file. 500-1000 lines are not a lot of code.
> o Your debug code in the hidp directory DOES NOT COMPILE!!!
> I need working debug for the amount of work I am doing. Please read
> my patch and fix it!
If my debug code doesn't compile then this is a bug. Why didn't you send
in a patch for this? Such a fix could already be merged mainline.
> o The code I am writing needs debug code so I can write it and get it
> working.
Fine with me, but before you submit it for inclusion remove this debug
code.
> o Extra debug code is needed in other places in the hidp directory to
> support any general user debugging of the control channel state machine
> code.
As I said before, I will only allow simple debug code in the Bluetooth
code that is off by default. I don't think that you can convince to add
deeper levels of debugging in the code. No extra debug code will make it
easy to merge your code back mainline. Otherwise we will be stuck here
and I have to remove everything by myself.
> > The rest of this patch looks fine and there is only
> > one coding style issues that I might not mentioned last time. In a
> > "switch" construct we normally add an empty line between "break" and the
> > next "case".
> >
> > And another thing. What is the difference between ...ctrl_message()
> > and ...ctrl_byte()? We don't need that. If data is NULL then both is the
> > same.
>
> ...ctrl_message() is needed latter in the state machine work as some
> control messages will be over 1 byte in size. It will be used in phase
> 2.
You don't get my point. You need only one of these functions to do the
job. What you did is code duplication:
#define ...ctrl_byte() ...ctrl_message(a, b, NULL, 0)
> You may also notice the 2 separate functions for queueing the sending of
> control bytes (..ctrl_byte() and ...ctrl_reply()), one from within the
> hidp_session() kernel process, and one for use from the ioctl(s). Here
> is my reasoning for it. I take it that you do not want to put extra
> schedule() calls in the middle of the hidp_session() while loop, between
> the processing of individual received control packets, before even
> processing the interrupt (high priority, basically incoming HID events)
> and the transmission queue. Even if this inserted schedule() call is
> conditional, 2 extra context switches for the hidp_session() thread get
> introduced before received keystrokes/HID events are processed, and the
> transmit queue gets looked at. The BT HID spec says that the interrupt
> channel should be processed at higher priority (and even before?) the
> control channel. Both ..ctrl_byte() and ...ctrl_reply() are needed
> according to this.
I haven't said anything about these two. I will look at it when I
applied the patch to me tree and started testing.
> Now about us working together, from your replies and comments about my
> patches it has been obvious to me that you have not had much time to
> look them over and think about things. You comments on coding style are
> appreciated, and I myself don't like being sloppy, and I know that the
> netfilter people are way too sloppy for my own liking to. But you are
> holding on too tightly to the control of the BT HID code. I need the
> flexibility and autonomy of being the delegated lead developer there so
> that my development can be speed along.
The coding style is important, because it makes it a lot easier to merge
your changes back mainline. I simply won't spent any time fixing coding
style mistakes of other people.
And actually I looked in detail at your patches, but as I said only the
patch against the -rc3-bk6. We do this step by step and this is the one
that comes first. I will merge it back mainline after I tested it with
my devices. However this will be after 2.6.10 is out.
There is no tight control on the BT HID code, but every patch goes
through my hands. I acknowlege it or reject it with a reason and an
advice on how to fix it. The BT HID is a little bit special, because we
don't have the generic HID parser at the moment. I am working on a final
Bitkeeper tree for mainline inclusion. This must be done this way,
because we must keep the revision history. If this is done and 2.6.10 is
finally out everything will be very easy.
> Could you please freeze the BT HID code in the kernel for 3 months
> (apart from brown-paper bag stuff), and let me subsume the HID report
> code in your mh* patches, and strip the net/bluetooth/hidp code from
> your patches, and use my stuff instead so that I can efficiently get the
> work done on improving it rapidly. If changes are needed to the in
> kernel stuff, please feed them my way and I will integrate them as
> quickly as I can. This should not be too hard, as it looks like there
> has not been much activity in the BT HID area in the last few months
> apart from my work.
The generic HID parser is the way to go.
> I really want to work together with you on this, as cooperation will get
> far more done in the bluetooth area of the kernel given the small user
> base. If the above arrangement is not suitable to you, please come up
> with one that we do not have major code clashes when merging each others
> code.
Since you don't use Bitkeeper, there can't be any easy working together
until I got the generic HID parser in the right shape. I am not willing
to loose the revision history of the current USB HID code. It documents
many reasons why decissions are made and why it is done this way. It is
way too important.
> If you have doubts as to my ability, I am a professional router
> programmer who got fired because I insisted on making my work bug-free,
> robust, and high quality, with experience in OSPF, router device
> driveers and IPX code. My early CV reads like that of Alan Cox, and I
> have been using Linux since 1993, with a bit work accepted into the
> 2.2.x kernel for ethernet bridging, 2.2.x security patches, and
> 2.2.x/2.4.x Sangoma driver fixes. I will send you my resume if you want
> to look it over (it is a little out of date).
I have absolutly no doubts on your ability and actually I never read any
CVs, because I judge on the code people write.
> My patience on this is starting to wear out. If we can't work something
> out soon, I am going to go ahead anyhow, and the merits of the work by
> itself will warrant its inclusion in a few months time.
I am sorry for that and I really appreciate your help. At the moment we
are in the final phase of 2.6.10 and so hoping that we get any stuff
into it is ridiculous (besides fixing my debug code bug maybe). So what
we can do is to get your patch against -rc3-bk6 ready for inclusion and
I will merge it mainline as soon as 2.6.10 is out.
I can start with the merge tree of the generic HID parser tomorrow, but
actually there is one patch from the input subsystem tree that hasn't
been merged back mainline so far. It changes a lot of things and I
haven't looked at it in detail at the moment.
If these two things happened I will remove my current report mode
support from the -mh patch and we will have a common base. Then you can
send in changes for the HID parser and/or for the HIDP code.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
How are you? I hope that you are coping with the upcoming Silly season
(Christmas, high pressure commercialism etc). I am getting sick of the
same TV ads repeated every 10 minutes if not hourly... (I am a
person :-) ).
Please read, there is a lot in hear that you should look at and think
carefully about.
On Wed, 2004-12-15 at 13:05 +0100, Marcel Holtmann wrote:
> I only looked at the -rc3-bk6 patch, because as I said, this is what we
> gonna do first. I don't wanna see any debug specific changes in there. I
> will remove them anyway and this takes me only longer to merge this
> patch into my tree.
You have to appreciate this given that I will bw writing 500-1000 lines
more of code for net/bluetooth/hidp/core.c (maybe a seperate file) for
the control channel state machine:
o Your debug code in the hidp directory DOES NOT COMPILE!!!
I need working debug for the amount of work I am doing. Please read
my patch and fix it!
o The code I am writing needs debug code so I can write it and get it
working.
o Extra debug code is needed in other places in the hidp directory to
support any general user debugging of the control channel state machine
code.
> The rest of this patch looks fine and there is only
> one coding style issues that I might not mentioned last time. In a
> "switch" construct we normally add an empty line between "break" and the
> next "case".
>
> And another thing. What is the difference between ...ctrl_message()
> and ...ctrl_byte()? We don't need that. If data is NULL then both is the
> same.
...ctrl_message() is needed latter in the state machine work as some
control messages will be over 1 byte in size. It will be used in phase
2.
You may also notice the 2 separate functions for queueing the sending of
control bytes (..ctrl_byte() and ...ctrl_reply()), one from within the
hidp_session() kernel process, and one for use from the ioctl(s). Here
is my reasoning for it. I take it that you do not want to put extra
schedule() calls in the middle of the hidp_session() while loop, between
the processing of individual received control packets, before even
processing the interrupt (high priority, basically incoming HID events)
and the transmission queue. Even if this inserted schedule() call is
conditional, 2 extra context switches for the hidp_session() thread get
introduced before received keystrokes/HID events are processed, and the
transmit queue gets looked at. The BT HID spec says that the interrupt
channel should be processed at higher priority (and even before?) the
control channel. Both ..ctrl_byte() and ...ctrl_reply() are needed
according to this.
Now about us working together, from your replies and comments about my
patches it has been obvious to me that you have not had much time to
look them over and think about things. You comments on coding style are
appreciated, and I myself don't like being sloppy, and I know that the
netfilter people are way too sloppy for my own liking to. But you are
holding on too tightly to the control of the BT HID code. I need the
flexibility and autonomy of being the delegated lead developer there so
that my development can be speed along.
Could you please freeze the BT HID code in the kernel for 3 months
(apart from brown-paper bag stuff), and let me subsume the HID report
code in your mh* patches, and strip the net/bluetooth/hidp code from
your patches, and use my stuff instead so that I can efficiently get the
work done on improving it rapidly. If changes are needed to the in
kernel stuff, please feed them my way and I will integrate them as
quickly as I can. This should not be too hard, as it looks like there
has not been much activity in the BT HID area in the last few months
apart from my work.
I really want to work together with you on this, as cooperation will get
far more done in the bluetooth area of the kernel given the small user
base. If the above arrangement is not suitable to you, please come up
with one that we do not have major code clashes when merging each others
code.
If you have doubts as to my ability, I am a professional router
programmer who got fired because I insisted on making my work bug-free,
robust, and high quality, with experience in OSPF, router device
driveers and IPX code. My early CV reads like that of Alan Cox, and I
have been using Linux since 1993, with a bit work accepted into the
2.2.x kernel for ethernet bridging, 2.2.x security patches, and
2.2.x/2.4.x Sangoma driver fixes. I will send you my resume if you want
to look it over (it is a little out of date).
My patience on this is starting to wear out. If we can't work something
out soon, I am going to go ahead anyhow, and the merits of the work by
itself will warrant its inclusion in a few months time.
Looking forward to hearing back from you soon,
Best Regards,
Matthew Grant
Hi Matthew,
> I have reworked the patches as you have requested. They are attached to
> this message.
>
> This is the BT HID message parsing framework that I wrote, based on the
> Bluetooth HID specs. The kernel versions the patches are against are
> mentioned in their names. The one against 2.6.10-rc3-bk6 is the one for
> the standard BT HID code in the stock kernel, then other contains fixes
> for report mode processing where the BT device is stuck in Boot mode due
> to being first of all configured by the computer BIOS.
>
> The devices I tested this with are Apple BT keyboard, and Logitech Mx900
> mouse. the changes are all conservative, and should work with all
> devices.
>
> I have left the debug work I did as is in the patches as I need it to
> debug the work I am doing. It fixes various compile problems with the
> debug code, as well as adding output of data that I found useful in
> diagnosing my keyboard problems. I am planning to continue my work on
> the BT HID as I am able, and hope to do phase 2 (SET_ and GET_) HID
> state machines over the Christmas holidays. The Debug stuff has to stay
> there. Basically if you want me to significant work in the BT HID area,
> I need a free hand to do things. I already have to spend quite a bit of
> time making a patch for the standard kernel, as well as against the
> 2.6.x-mhx patches which I do my development against. We need to discuss
> how we are going to work this so that it does not take too much of your
> time.
I only looked at the -rc3-bk6 patch, because as I said, this is what we
gonna do first. I don't wanna see any debug specific changes in there. I
will remove them anyway and this takes me only longer to merge this
patch into my tree. The rest of this patch looks fine and there is only
one coding style issues that I might not mentioned last time. In a
"switch" construct we normally add an empty line between "break" and the
next "case".
And another thing. What is the difference between ...ctrl_message()
and ...ctrl_byte()? We don't need that. If data is NULL then both is the
same.
> I am hoping to get a Web site up shortly with these patches and further
> work, as well as a version control system for a BT HID project!
I don't see any advantage of it, but if it helps you, do it. I only
accept plain patches with a description like you sent.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel