[Bluez-devel] Re: [PATCH] - for BT HID fixes + beginning of ctrl handling

[Matthew Grant <grantma@anathoth.gen.nz>]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

Hi Marcel,

Busy weekend.  Remotely upgrading a Debian box, and upgrading its
hardware, having to take it one step at a time. I have started editing
the code to put in the style changes you recommended. Should be able to
get something to you tomorrow.

On Thu, 2004-12-02 at 12:35 +0100, Marcel Holtmann wrote:
> Hi Matthew,
> 
> as a side note: Finally decide if you are going to discuss this in
> private with me or on the mailing list. Don't switch back and forth.
> 

Probably bets to discuss this matter on bluez-devel.

> > At times the hidp_send_message gets called from within the context of
> > the running kernel thread when responding to received messages with
> > error handshakes, and you want to keep processing if possible until the
> > original hidp_schedule() after the transmission of messages.  The aim is
> > to keep the execution flow as you planned it originally.
> > 
> > Do you think a separate function is needed, without the schedule call at
> > the end?
> 
> Actually a schedule should not harm in any way. If you think we really
> need it then I would prefer the same as a looked() versus __unlocked()
> functions.

Like you I want to keep things simple here, but I want to also avoid the
effects of giving up the processor to readily.  Also I want to avoid the
complications of more locks.  The reply messages are being sent inside
the global? Bluetooth HID lock.  We have to be careful about the context
that this is all happening within.  If you are that concerned about the
third function schedule parameter, I will create 2 separate control
message sending functions as they are only 3-4 lines long.

> > Thinking about how best to look after all the code and patching.
> > Putting all the BT code into a version control system here is looking to
> > be quite sensible to make the patching easier to handle.  If we were not
> > patching core.c for the report mode support, this would be a lot easier
> > and cleaner.
> 
> I don't see any need for it at the moment. Once we get your HIDP core
> stuff ready, I will try to merge it back mainline as soon as possible.
> Every change after that should be minimal.
> 

This first patch is only phase 1 in a 3 stage process.  Next 2 steps
will be just as big and invasive.  After this probably half of the BT
HID may be changed around quite significantly.  Please accept Debug code
code changes I make, as I need these to get debug code to compile for my
own use.  The version control system is so that I can more easily keep
track of what I am doing.

As I write this, I am making changes you suggested to my code so that we
can get it merged.  I still have a lot of this work on the machine in
Bangladesh to deal with for the next couple of nights till I can put it
on hold for a week or two before their final upgrade from woody to
sarge.

Best Regards,

Matthew Grant

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]