public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Re: [PATCH] - for BT HID fixes + beginning of ctrl handling
Date: Mon, 06 Dec 2004 07:49:05 +0100	[thread overview]
Message-ID: <1102315745.8510.64.camel@pegasus> (raw)
In-Reply-To: <1102315086.6245.1.camel@localhost>

Hi Matthew,

> > 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.

maybe we have to move the hidp_schedule() call around. Don't duplicate
code even if 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.

The debug code is for the development stage. After the merge back we
remove it and leave only a minimal amount of debug code in there. That
is also the reason why no config option for it exists even if the define
looks like one.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

      reply	other threads:[~2004-12-06  6:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-01 19:49 [PATCH] - for BT HID fixes + beginning of ctrl handling Matthew Grant
2004-12-01 20:33 ` [Bluez-devel] " Marcel Holtmann
     [not found]   ` <1101982200.6274.24.camel@localhost>
     [not found]     ` <1101987344.15615.109.camel@pegasus>
2004-12-06  6:38       ` Matthew Grant
2004-12-06  6:49         ` Marcel Holtmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1102315745.8510.64.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox