Re: CVS commit: src/distrib/utils/sysinst

2012-01-11 Thread Joerg Sonnenberger
On Sun, Oct 30, 2011 at 12:30:57AM +, Jonathan A. Kollasch wrote:
 Log Message:
 As both of the ns-wide.wide.ad.jp and light.imasy.or.jp IPv6 resolvers
 now refuse my queries, replace them with google-public-dns-a.google.com
 and google-public-dns-b.google.com.

(a) Why offer two options for the same company? Can we make the
selection of DNS provider just Google with the two addresses in the
backend?

(b) What about offering OpenDNS as alternative?

Joerg


Re: CVS commit: src/sys/dev/bluetooth

2012-01-11 Thread Radoslaw Kujawa
Hi Iain.

On 7 sty 2012, at 09:42, Iain Hibbert wrote:
 I don't have a USB keyboard, but pressing the caps lock on my laptop or
 Bluetooth keyboard does always toggle both LEDs.

Even after applying your patch it doesn't work this way for me, so probably the 
problem with this is somewhere else.

 it really should disassociate from the context, maybe doing
 the call from a callout or separate task instead.
 
 Wouldn't that again lead to the situation where mtx_owner assertion will
 fail? If we call mutex_exit() from other thread than the one which
 acquired the lock, it will certainly fail. I understand that callout or
 separate task will be executed in another thread.
 
 Should not, I have reworked it to offset the processing of reports to a
 thread (patch attached) which does not trigger any mutex failures with
 LOCKDEBUG. I'm still testing but I think its correct.. any comments?

It works for me. Looks good even with LOCKDEBUG, but I am not a locking expert 
;). Since it works, should I commit it, or do you prefer doing it yourself?

 No, that's the FN key.
 
 Ok thats separate issue, does the output of 'btdevctl -a keyboard -d
 device -s hid' show anything for ID 17?  Unfortunately, there is no way
 to handle things like that in a generic way from within the current HID
 framework if the device does not report its capabilities in the descriptor
 (Apple devices at least seem to be prone to this) so we need a special
 driver (eg btmagic which handles several such reports) - Linux has a
 concept where a driver can attach and register for other reports that
 might be sent, but I'm not sure I liked their method, surely something
 better can be designed..

I've attached the output of btdevctl. 
local bdaddr: 00:18:5d:01:17:ad
remote bdaddr: 00:1f:5b:fc:ac:86
link mode: encrypt
vendor id: 0x05ac
product id: 0x022d
device type: bthidev
control psm: 0x0011
interrupt psm: 0x0013
Collection page=Generic_Desktop usage=Keyboard
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftControl Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftShift Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftAlt Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_Left_GUI Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightControl Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightShift Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightAlt Variable, 
logical range 0..1
  Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_Right_GUI Variable, 
logical range 0..1
  Input id=1 size=8 count=1 page=0x usage=0x Const, logical range 0..1
 Output id=1 size=1 count=1 page=LEDs usage=Num_Lock Variable, logical range 
0..1
 Output id=1 size=1 count=1 page=LEDs usage=Caps_Lock Variable, logical range 
0..1
 Output id=1 size=1 count=1 page=LEDs usage=Scroll_Lock Variable, logical range 
0..1
 Output id=1 size=1 count=1 page=LEDs usage=Compose Variable, logical range 0..1
 Output id=1 size=1 count=1 page=LEDs usage=Kana Variable, logical range 0..1
 Output id=1 size=3 count=1 page=0x usage=0x Const, logical range 0..1
  Input id=1 size=8 count=6 page=Keyboard usage=No_Event, logical range 0..255
End collection
Collection page=Consumer usage=Consumer_Control
Collection page=Generic_Desktop usage=Keyboard
  Input id=71 size=8 count=1 page=Device_Controls usage=Battery_Strength 
Variable, logical range 0..255
End collection
End collection
  Input id=17 size=1 count=3 page=0x usage=0x Const, logical range 0..1
Collection page=Consumer usage=Consumer_Control
  Input id=17 size=1 count=1 page=Consumer usage=Eject Variable, logical range 
0..1
  Input id=17 size=1 count=1 page=0x00ff usage=0x0003 Variable, logical range 
0..1
  Input id=17 size=1 count=3 page=0x usage=0x Const, logical range 0..1
  Input id=18 size=1 count=1 page=Consumer usage=Pause/Play Variable, logical 
range 0..1
  Input id=18 size=1 count=1 page=Consumer usage=Fast_Forward Variable, logical 
range 0..1
  Input id=18 size=1 count=1 page=Consumer usage=Rewind Variable, logical range 
0..1
  Input id=18 size=1 count=1 page=Consumer usage=Scan_Next_Track Variable, 
logical range 0..1
  Input id=18 size=1 count=1 page=Consumer usage=Scan_Previous_Track Variable, 
logical range 0..1
  Input id=18 size=1 count=1 page=0x usage=0x Const, logical range 0..1
  Input id=18 size=1 count=1 page=0x usage=0x Const, logical range 0..1
  Input id=18 size=1 count=1 page=0x usage=0x Const, logical range 0..1
  Input id=19 size=1 count=1 page=0xff01 usage=0x000a Variable, logical range 
0..1
  Input id=19 size=1 count=7 page=0x usage=0x Const, logical range 0..1
Feature id=9 size=8 count=1 page=0xff01 usage=0x000b Variable, logical range 
0..1
Feature id=9 size=8 count=2 page=0x 

Re: CVS commit: src/sys/dev/bluetooth

2012-01-11 Thread David Laight
On Wed, Jan 11, 2012 at 05:27:45PM +, Iain Hibbert wrote:
 Module Name:  src
 Committed By: plunky
 Date: Wed Jan 11 17:27:45 UTC 2012
 
 Modified Files:
   src/sys/dev/bluetooth: bthidev.c btkbd.c
 
 Log Message:
 offset processing of input reports to a kernel thread, to avoid
 locking issues when a child device needs to call back into the
 Bluetooth stack (eg when caps-lock is pressed, and wskbd wants
 to change a LED)

Actually, I suspect it would be better to make X (etc) always use
a separate context when reflecting indications back to the driver.

As has been pointed out changing the LED for caps-lock (and other
locks) is pressed should change the LEDs on all keyboards, and
the inter-device cross call could also cause problems.

David

-- 
David Laight: da...@l8s.co.uk