On Wed, Aug 23, 2017 at 11:41:27AM -0700, Roderick Colenbrander wrote: . > > + <event name="usb_id"> > > + <description summary="device USB vendor/product id"> > > + This event is sent in the initial burst of events before the > > + wp_inputfd_device_evdev.done event. > > + > > + This event is optional, if the required information is not available > > + for this device the event is omitted. > > + </description> > > + <arg name="vid" type="uint" summary="USB vendor id"/> > > + <arg name="pid" type="uint" summary="USB product id"/> > > + </event> > > Minor, but should this be named usb id? There are other various > wireless busses as well.
good point. This is modelled after the evdev input_id struct, so I guess adding a bustype to it and just naming it "id" would be good enough for the majority of use-cases. > > + <event name="focus_in"> > > + <description summary="input fd device focus in event"> > > + Notification that this client now has the focus and/or access to > > + this device. How focus is set is left to the > > + compositor. For example, a compositor may tie joystick focus to the > > + wl_pointer focus of this seat. The protocol does not guarantee that > > + any specific client ever receives the focus for a device. > > + > > + The client is passed a file descriptor with access to this > > + device. This file descriptor is valid until a subsequent > > + wp_inputfd_device_evdev.focus_out event. Upon > > + wp_inputfd_device_evdev.focus_out, the compositor may revoke the fd > > + and further operations will fail. > > + > > + However, due to potential race conditions a client must be able to > > + handle errors as if it opened the fd itself. No guarantee is given > > + that the wp_inputfd_device_evdev.focus_out event or > > + wp_inputfd_device_evdev.removed event are sent before the client > > + encounters an error on the file descriptor. > > + > > + A compositor guarantees the file descriptor for a > > + wp_inputfd_device_evdev refers to the same kernel device after each > > + focus_in event. In other words, any constant information about the > > + device obtained through the fd (e.g. the EVIOCGPROP ioctl) is > > + the same after each focus in event. Thus, a client needs to do so > > + only once at the first focus_in. This guarantee does not extend to > > + information that the kernel may change at runtime (e.g. the > > + EVIOCGABS ioctl). > > + > > + If applicable, this event contains the surface that has the focus. > > + In some cases, the focus may not be tied to a specific client > > surface > > + but is given to the client independent of any surface. In that case, > > + the surface is null. > > + > > + The protocol guarantees that focus_in and focus_out always come in > > + pairs. If the client currently has the focus and the device is > > + removed, a focus_out event is sent to the client before the > > + wp_inputfd_device_evdev.removed event. > > + </description> > > + <arg name="serial" type="uint"/> > > + <arg name="fd" type="fd" summary="file descriptor to the device"/> > > The only concern I have is whether the fd is enough to know everything > about a device e.g. be able to locate sysfs entries just from the fd. > Since I wasn't sure I did some digging. My first attempt was to use > EVIOCGPHYS, which for many HID devices seems to return hardware bus > information, which with some parsing could be mapped to a sysfs path. > However many older devices don't put reliable data in here, so this is > unreliable. > > My next step was to see if instead of constructing a hardware bus path > to a sysfs device, we could maybe use /sys/dev/char/<major>:<minor>. > It looks like we could the major and minor number from fstat on the > fd, so it seems possible to get to sysfs just from the fd without any > other information. fwiw, this is what we use in libinput to get the udev device. run fstat() on the fd, pass the st.st_rdev into udev_device_new_from_devnum() and you're good, at least unless you're running in flatpak or some other environment where udev/sysfs isn't available. Obviously the manual syspath like you said above will work too. biggest problem is the race condition that happens when a device is removed and re-added between fstat and the udev init call. I don't have a good solution for that (beyond comparing usb ids) and have failed to come up with one so far. Cheers, Peter _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
