linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: linux-hotplug@vger.kernel.org
Subject: Re: wireless keyboard interaction
Date: Sat, 06 Jan 2007 16:02:14 +0000	[thread overview]
Message-ID: <20070106160214.GA32053@suse.cz> (raw)
In-Reply-To: <27d8a6b3aa6e28a87f0a.20070105190625.whnafynlgba@www.dslextreme.com>

On Sat, Jan 06, 2007 at 07:34:14AM -0800, juanslayton@dslextreme.com wrote:

> Good morning and thanks for your interest.
> 
> So far as I know, all the boards I have used are 27 MHz.  That would be
> Logitech, Mozart, and, I think, Interlink.  I certainly have considered
> radio interference.  But with that, I would expect some scrambling of the
> keycodes, and I haven't observed that; the key I press seems always to be
> the key that is printed, even when I get multiple bursts.  I've tried a
> number of things and I'm going from memory here, but as I recall, the
> evdev value for those bursts was '2' (the normal value for autorepeat) and
> I was able to suppress them by writing the application to reject an event
> with value 2.  However, this still left the opposite interference, in
> which keypress on one board inhibits a read on another.  It's not obvious
> to me how signal interference would have either of these effects, or for
> that matter how there could be signal interference at all, given that usb
> devices are not peer to peer and should not be transmitting until they are
> interrogated by a USB 'host' routine.  (I'm likely using the wrong term
> here, but I think you will understand what I mean.)

It's not USB that goes over the wireless link. (*) It's a custom, much
simpler protocol, where the keyboard initates the transaction on a
keypress. This is also needed because USB doesn't like transmission
errors.

This means that two keyboards will be attempting to transmit when keys
on them are depressed at the same time, resulting in interference,
failed receives and retransmits until the situation resolves. Since the
keyboards will not be implementing random backoff like ethernet does,
this can take a while.

If a key release transmit is delayed because of this, the input core
will see a long keypress, and will generate software autorepeat (value 2
events) at a default rate of 30 per second.

So, it's really most likely interference.

(*) It would not be practical to try to push a 1.5 Mbit/sec
(bidirectional!) link over a 27 MHz radio channel. WUSB (wireless USB)
uses UWB (ultrawideband) to work.

-- 
Vojtech Pavlik
Director SuSE Labs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2007-01-06 16:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-06  3:06 wireless keyboard interaction juanslayton
2007-01-06  9:05 ` Maciej Grela
2007-01-06 15:34 ` juanslayton
2007-01-06 16:02 ` Vojtech Pavlik [this message]
2007-01-06 18:55 ` juanslayton

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=20070106160214.GA32053@suse.cz \
    --to=vojtech@suse.cz \
    --cc=linux-hotplug@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).