Re: Questions about the USB HID device drivers
On 2/18/19 3:37 PM, Ian Lepore wrote: Not to userland applications so much as to sysadmin-controlled configuration which is applied from userland during system startup and when new devices are attached. See the manpage for devfs.conf. Which does make sense on servers & network infrastructure. However, I'm wondering if there's a better way to do this for systems that aren't expected to have a sysadmin -basic desktop systems. From the kernel side, some subsystems do create a hierarchy (or at least a subdir for a set of related devices), and others don't. There is no system-wide policy about it either way. I have to admit that I'm surprised that there's no system-wide policy for this. -- Regards, Apollo D. Sharpe, Sr. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Questions about the USB HID device drivers
On 2/18/19 3:18 PM, Warner Losh wrote: Yes and no. If the unique prefix has / in it, devfs puts it in a subdir. If I'm reading the code right, the unique prefix is basically driver_t::name. Is that correct? If so, I haven't seen a device name (in the entire tree) that has "/" in it's device name. Maybe I'm missing something here. Way back in the days of yore, it was 100% userland to create the hierarchy. You did your mknod and that was that. We had big tables of major numbers that mapped device names to the kernel. There were problems with this: not the least was that major numbers were a limited resource and soon ran out. Now, devfs manages everything. You can get it to create many different hierarchies. see devfs(8) for details. I can imagine how much of a pain that was. Though, it looks as though not too many people bother changing beyond the default devfs.rules and devfs.conf files -they also seem to be a pain to deal with. It's a reasonable solution for servers, however it would be much more valuable on desktops to have /dev/input/* for various input devices. I guess I'm going to have to figure out how to make devices publish themselves in /dev based on their primary function. Thank you, and everyone else, for taking the time to explain the setup to me. -- Regards, Apollo D. Sharpe, Sr. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 235625] Repeated excessive logging about unsuccessful port reset during device enumeration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235625 --- Comment #8 from Max --- Also there is the following event seen a few seconds later for the port in the snippet: >>>Feb 18 16:16:44 kernel: uhub_explore: Overcurrent on port 3. >>>Feb 18 16:16:44 kernel: uhub_reattach_port: reattaching port 3 Thanks, Max -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Questions about the USB HID device drivers
On Mon, 2019-02-18 at 15:03 -0600, Apollo D. Sharpe, Sr. via freebsd- usb wrote: > On 2/18/19 3:26 AM, Hans Petter Selasky wrote: > > Each devicename has a uniq prefix followed by a uniq unit number. > > So, we just end up dumping ALL device nodes in /dev... > > > > Character device nodes are automatically created. However it is > > possible for user-space applications to create symbolic links > > afterwards in /dev . > > ...and leave it to user-space to create the hierarchy within /dev? > Is > there a technical reason that kernel drivers don't automatically > subscribe to a hierarchy, or is this just historic inertia? It seems > funny to me that such decisions are left to user-space applications. > > Not to userland applications so much as to sysadmin-controlled configuration which is applied from userland during system startup and when new devices are attached. See the manpage for devfs.conf. >From the kernel side, some subsystems do create a hierarchy (or at least a subdir for a set of related devices), and others don't. There is no system-wide policy about it either way. -- Ian ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 235625] Repeated excessive logging about unsuccessful port reset during device enumeration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235625
--- Comment #7 from Max ---
Hello
Here is captured syslog snippet with the message. It appears after
uhub_read_port_status call.
The below conditional expects either right-most bit to be set for port_change
or unset for port_status.
As per log snippet wPortStatus = 0x07fb and wPortChange = 0x00fb which seem to
satisfy the condition for the error message...`
>>>if ((sc->sc_st.port_change & UPS_C_CONNECT_STATUS) ||
>>>(!(sc->sc_st.port_status & UPS_CURRENT_CONNECT_STATUS)))
>>> {
>>>Feb 18 16:17:48 kernel: uhub_reattach_port: Port 3 is in Host Mode
>>>Feb 18 16:17:49 kernel: usb_needs_explore:
>>>Feb 18 16:17:49 kernel: uhub_read_port_status: port 3, wPortStatus=0x07fb,
>>>wPortChange=0x00fb, err=USB_ERR_NORMAL_COMPLETION
>>>Feb 18 16:17:49 kernel: uhub_reattach_port: giving up port reset - device
>>>vanished
>>>Feb 18 16:17:49 kernel: uhub_suspend_resume_port: port 3
>>>Feb 18 16:17:49 kernel: uhub_read_port_status: port 3, wPortStatus=0x07fb,
>>>wPortChange=0x00fb, err=USB_ERR_NORMAL_COMPLETION
>>>Feb 18 16:17:49 kernel: uhub_suspend_resume_port: suspended=0
Please let me know if more information is needed
Thanks,
Max
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Questions about the USB HID device drivers
On Mon, Feb 18, 2019 at 2:04 PM Apollo D. Sharpe, Sr. via freebsd-usb < freebsd-usb@freebsd.org> wrote: > On 2/18/19 3:26 AM, Hans Petter Selasky wrote: > > Each devicename has a uniq prefix followed by a uniq unit number. > > So, we just end up dumping ALL device nodes in /dev... > Yes and no. If the unique prefix has / in it, devfs puts it in a subdir. > > Character device nodes are automatically created. However it is > > possible for user-space applications to create symbolic links > > afterwards in /dev . > > ...and leave it to user-space to create the hierarchy within /dev? Is > there a technical reason that kernel drivers don't automatically > subscribe to a hierarchy, or is this just historic inertia? It seems > funny to me that such decisions are left to user-space applications. > Way back in the days of yore, it was 100% userland to create the hierarchy. You did your mknod and that was that. We had big tables of major numbers that mapped device names to the kernel. There were problems with this: not the least was that major numbers were a limited resource and soon ran out. Now, devfs manages everything. You can get it to create many different hierarchies. see devfs(8) for details. Warner ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Questions about the USB HID device drivers
On 2/18/19 3:26 AM, Hans Petter Selasky wrote: Each devicename has a uniq prefix followed by a uniq unit number. So, we just end up dumping ALL device nodes in /dev... Character device nodes are automatically created. However it is possible for user-space applications to create symbolic links afterwards in /dev . ...and leave it to user-space to create the hierarchy within /dev? Is there a technical reason that kernel drivers don't automatically subscribe to a hierarchy, or is this just historic inertia? It seems funny to me that such decisions are left to user-space applications. -- Regards, Apollo D. Sharpe, Sr. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 91546] [umodem] [patch] Nokia 6630 mobile phone does not work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=91546 Oleksandr Tymoshenko changed: What|Removed |Added CC||go...@freebsd.org Status|Open|Closed Resolution|--- |Overcome By Events --- Comment #14 from Oleksandr Tymoshenko --- Closing as OBE since nobody picked patches for commit and target devices has become obsolete since then. Feel free to reopen if patches still relevant and should be committed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 118141] [ucom] usb serial and nokia phones ucomreadcb ucomreadcb: IOERROR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=118141 Oleksandr Tymoshenko changed: What|Removed |Added Resolution|--- |Overcome By Events CC||go...@freebsd.org Status|Open|Closed --- Comment #3 from Oleksandr Tymoshenko --- Closing as OBE since nobody picked it up to work on and target device has become obsolete since then. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 119653] [cam] [patch] iriver s7 player sync cache error patch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=119653 Oleksandr Tymoshenko changed: What|Removed |Added Resolution|--- |Overcome By Events CC||go...@freebsd.org Status|Open|Closed --- Comment #3 from Oleksandr Tymoshenko --- Closing as OBE since nobody picked it up to work on and target device has become obsolete since then. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 118140] [ucom] [patch] quick hack for ucom to get it behave with Nokia phones
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=118140 Oleksandr Tymoshenko changed: What|Removed |Added Resolution|--- |Overcome By Events CC||go...@freebsd.org Status|Open|Closed --- Comment #3 from Oleksandr Tymoshenko --- Closing as OBE since nobody picked it up to work on and target devices has become obsolete since then. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
[Bug 96224] [usb] [msdosfs] mount_msdosfs cause page fault in syncer process
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=96224 Andriy Gapon changed: What|Removed |Added Resolution|--- |Overcome By Events Status|Open|Closed --- Comment #2 from Andriy Gapon --- 13 years without any activity, closing... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Questions about the USB HID device drivers
On 2/17/19 11:00 PM, Apollo D. Sharpe, Sr. wrote: On 2/15/19 7:46 AM, Hans Petter Selasky wrote: On 2/15/19 2:22 PM, A. D. Sharpe wrote: On 2/15/2019 3:30 AM, Hans Petter Selasky wrote: Did you have a look at the code? sys/dev/usb/input/ums.c and sys/dev/usb/input/ukbd.c I think I have a decent understanding of USB devices under FreeBSD. However, two things are tripping me up: a) the fact that the ums & ukbd drivers don't have "make_dev()" calls in them; and b) I can't seem to find an overall keyboard system or overall mouse system. Events are delivered from the USB INTERRUPT endpoint's completion handler to various places. At the moment events can end up via EVDEV or simply sysmouse or the regular keyboard API depending on the system configuration. At the moment, only for EVDEVS's /dev/input/, there is a per-device character device handle, I think. I think I've gotten a pretty good understanding of what's going on now, based on the answers that I've gotten from the developers part of the FreeBSD forums(*). The USB keyboard and mouse paths seems to go like this: ums->usb_hid->/dev/ums0->sysmouse ukbd->usb_hid->/dev/ukbd0->kbdmux If this is correct, then the majority of my inquiry has been satisfied. My next questions are more centered around /dev as it relates to device drivers in general: Hi, 1. Is there a published standard of how device drivers should publish themselves in /dev? From what I can tell, they seem to be thrown into /dev without any sort of hierarchy to organize the nodes into what type of device they represent. Each devicename has a uniq prefix followed by a uniq unit number. 2. Does usb_hid automatically dump device nodes into /dev, or is there a way for hid drivers to specify specifically where their nodes should be publish -such as: /dev/input/somehiddevice0 ? Character device nodes are automatically created. However it is possible for user-space applications to create symbolic links afterwards in /dev . (*) https://forums.freebsd.org/threads/questions-about-the-usb-hid-device-drivers.69604/ --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
