All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.