Re: usb2 moused issue

On Mon, Feb 16, 2009 at 10:30 AM, Hans Petter Selasky
<hselasky_at_freebsd.org> wrote:
> On Monday 16 February 2009, Giorgos Keramidas wrote:
>> On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky
> <hselasky_at_freebsd.org> wrote:
>> > On Monday 16 February 2009, Giorgos Keramidas wrote:
>> >> I just rebuild my kernel after flipping the switch to usb2 in my kernel
>> >> config file:
>> >>
>> >>
>> >>   [ dmesg output with hw.usb2.ums.debug=1 ]
>> >>   Feb 16 16:19:00 kobe kernel: ugen4.2: <Microsoft> at usbus4
>> >>   Feb 16 16:19:00 kobe kernel: ums0: <Microsoft Wireless Optical Mouse
>> >> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16
>> >> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16
>> >> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000
>> >
>> > If you "cat /dev/ums0" while having the debugging on, do you see
>> > anything?
>>
>> Hmm, there's a dmesg line saying that:
>>
>>   Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16
>>
>> but there is no ums0 symlink in /dev:
>>
>>   # ls -ld ums*
>>   ls: ums*: No such file or directory
>>   #
>
> Hi,
>
> The device is invisible. You should be able to cat it, if it's not already
> opened.

yeah, i've been bitten by the same "invisible device node" problem
while converting ubtbcmfw(4) to usb2.  for example,

Feb 16 10:35:19 yak kernel: ugen0.2: <Broadcom> at usbus0
Feb 16 10:35:19 yak kernel: ubtbcmfw0: <Broadcom BCM2033 Bluetooth USB
dongle, class 224/1, rev 1.01/0.a0, addr 2> on usbus0
Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0 -> usb0.2.0.16
Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.1 -> usb0.2.0.16
Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.2 -> usb0.2.0.16

and

> pwd
/dev

> ls -la usb0.2.*
ls: No match.
> ls -la usb0.2.0.16
crwxrwxrwx  1 root  operator    0,  68 Feb  5 10:19 usb0.2.0.16

> ls -la ubtbcmfw*
ls: No match.
> ls -la ubtbcmfw0
crwxrwxrwx  1 root  operator    0,  68 Feb  5 10:19 ubtbcmfw0

> ls -la ubtbcmfw0.*
ls: No match.

> ls -la ubtbcmfw0.1
crwxrwxrwx  1 root  operator    0,  68 Feb  5 10:19 ubtbcmfw0.1
> ls -la ubtbcmfw0.2
crwxrwxrwx  1 root  operator    0,  68 Feb  5 10:19 ubtbcmfw0.2

 i suspect it probably has something to do with the way devfs cloning
works (for example, i think, somewhat similar problem exists with
/dev/tap, /dev/tun device nodes). of course, if one does not know
that, the first reaction would be - wtf? where is my device nodes?! :)

i wonder if there is any way to "fix" it...

thanks,
max