Re: Questions about the USB HID device drivers

2019-02-18 Thread Apollo D. Sharpe, Sr. via freebsd-usb

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

2019-02-18 Thread Apollo D. Sharpe, Sr. via freebsd-usb

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"


Re: Questions about the USB HID device drivers

2019-02-18 Thread Ian Lepore
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"


Re: Questions about the USB HID device drivers

2019-02-18 Thread Warner Losh
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

2019-02-18 Thread Apollo D. Sharpe, Sr. via freebsd-usb

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"


Re: Questions about the USB HID device drivers

2019-02-18 Thread Hans Petter Selasky

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"


Re: Questions about the USB HID device drivers

2019-02-17 Thread Apollo D. Sharpe, Sr. via freebsd-usb

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:


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.


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 ?



(*) 
https://forums.freebsd.org/threads/questions-about-the-usb-hid-device-drivers.69604/



--
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

2019-02-15 Thread Hans Petter Selasky

On 2/15/19 1:44 AM, Apollo D. Sharpe, Sr. via freebsd-usb wrote:

Hello,

Specifically, I'm interested in how the USB keyboard & mouse drivers 
publish their nodes. I've been combing through the sources of both 
drivers in an attempt to understand a) how they make available the data 
from their devices, b) how they publish their device nodes, and c) where 
all of the code that implements both sets of sequences is stored at in 
the source tree. I currently see the ukb & ums driver sources. Beyond 
that, I'm not sure where to look in order to follow the path between 
those drivers & /dev. Can anyone help me understand this?




Hi,

Did you have a look at the code?

sys/dev/usb/input/ums.c and sys/dev/usb/input/ukbd.c

--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"