Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Fri, May 24, 2013 at 05:07:14PM +0200, David Herrmann wrote: [...] This library is intended to solve the classification/detection problem. While the kernel evdev-interface provides us a bunch of information for each device, it doesn't provide any classification of the device (mostly because it would be unreliable). So libinputmapper as I see it is supposed to replace the heuristics that we currently have (KEY_A-KEY_Z = keyboard, REL_X/Y = mouse, ...) with a more user-controlled interface. So a *compositor* defines the type of devices, that it wants to support. As an example, it needs mouse+touchpad devices as mouse-input, keyboards as keyboard input. It then listens for all input hotplug events via udev, calls libinputmapper to provide tags for the devices and then checks, whether it's one of the devices that it wants. Client-side support is not involved, yet. ok, that makes sense to me and is a good idea. it's a combined version of (formerly) udev's input_id tool and the Match* system that X has, in the form of a library with simple adjustment based on textfiles. good. and sorry, I did somewhat tie all this in with the client side as well, which is where the confusion came from. I think the tagging library will be quite private to the compositor implementation (even if that means all compositors). in the X case, we have evdev and the wacom driver for tablet devices since they're different enough to basic tablets. I suspect something like that may be required for wayland sooner or later. input_id+Match* seems to be a good description. That's what I had in mind. But I don't see a reason to keep it private to the compositor. The compositor is the #1 user of the library, but whatever API is used to forward events to a client, we shouldn't hide this source. We can save all other kinds of useful information in these files. A client could retrieve device-geometry information or other static data. I designed the configuration to allow a global database with local additions. So a compositor can have a different configuration than a client. But both have the same global base/fallback configuration. ok. the reason I assumed private is because you need to decide where the level of abstraction sits and I think we don't think of it the same way there. you can tag a device as tablet, but that doesn't tell you which driver to use in the compositor to parse the data (see wacom example). so now the compositor has another lookup table so it knows which module to load for this device. this lookup table can either be duplicated across compositors, or be moved into a library. and now you have your libinputmodulemapper on top (well, on the side) of libinputmapper. likewise, as in another part of this thread: the compositor may not care about the distinction between joystick/gamepad but the client may. so again we have two different use-cases and mapping requirements here. so the tagging library would have to tag a device not just as graphics tablet but more as input module selection library. which again, means it's a library version of input_id and Match*, etc. what you will also need then is for drivers to provide hooks to notify what they can deal with. i.e. libtouchpadcommon needs to install data files for libinputmapper to notify that it's now taking over touchpads. I wanted to keep this private to the compositor. So the compositor has a list of drivers and a libinputmapper context. It then retrieves the tags for a device and assigns the device depending on the tags to the right driver. So libinputmapper always returns the same information. It's up to the compositor to use this according to it's capabilities. Or what would be the benefit of telling libinputmapper which drivers are available? I also don't understand what you mean by install data files. What data-files would libtouchpadcommon install? once you have input modules that are externalised (which they should be to allow for re-use across compositors) you'll have to deal with the issue of _which_ modules are actually installed. so you run into the same situation as we do with X input modules: evdev handles anything, but synaptics will install a MatchIsTouchpad snippet to take over all touchpads. on top of that you have per-device quirks. the X wacom driver knows it can handle some n-trig and waltop devices, but it can't handle all tablets. so it installs MatchProduct snippets for those devices. you could handle all that in the compositor, but it can get complex once you look at more than 3+ modules and several compositors that would duplicate this. My idea was to keep config-files generic. One file with match-rules and a bunch of device-rules files. The match-rules would be used by libinputmapper to find the device-rule (if any) files that should be applied to the device. The device-rules contain different sections. libinputmapper only parses one section
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Mon, May 27, 2013 at 12:35 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, May 24, 2013 at 05:07:14PM +0200, David Herrmann wrote: [...] This library is intended to solve the classification/detection problem. While the kernel evdev-interface provides us a bunch of information for each device, it doesn't provide any classification of the device (mostly because it would be unreliable). So libinputmapper as I see it is supposed to replace the heuristics that we currently have (KEY_A-KEY_Z = keyboard, REL_X/Y = mouse, ...) with a more user-controlled interface. So a *compositor* defines the type of devices, that it wants to support. As an example, it needs mouse+touchpad devices as mouse-input, keyboards as keyboard input. It then listens for all input hotplug events via udev, calls libinputmapper to provide tags for the devices and then checks, whether it's one of the devices that it wants. Client-side support is not involved, yet. ok, that makes sense to me and is a good idea. it's a combined version of (formerly) udev's input_id tool and the Match* system that X has, in the form of a library with simple adjustment based on textfiles. good. and sorry, I did somewhat tie all this in with the client side as well, which is where the confusion came from. I think the tagging library will be quite private to the compositor implementation (even if that means all compositors). in the X case, we have evdev and the wacom driver for tablet devices since they're different enough to basic tablets. I suspect something like that may be required for wayland sooner or later. input_id+Match* seems to be a good description. That's what I had in mind. But I don't see a reason to keep it private to the compositor. The compositor is the #1 user of the library, but whatever API is used to forward events to a client, we shouldn't hide this source. We can save all other kinds of useful information in these files. A client could retrieve device-geometry information or other static data. I designed the configuration to allow a global database with local additions. So a compositor can have a different configuration than a client. But both have the same global base/fallback configuration. ok. the reason I assumed private is because you need to decide where the level of abstraction sits and I think we don't think of it the same way there. you can tag a device as tablet, but that doesn't tell you which driver to use in the compositor to parse the data (see wacom example). so now the compositor has another lookup table so it knows which module to load for this device. this lookup table can either be duplicated across compositors, or be moved into a library. and now you have your libinputmodulemapper on top (well, on the side) of libinputmapper. I don't understand. What's wrong with linking device-TAGs to drivers in the compositor? So the compositor loads all drivers dynamically and each driver specifies which tags it supports. A new device is then assigned to the driver that currently is associated with the tag. If you want to overwrite that, add a [driver] section to the device-config/rule and use bind = some-driver-name. The compositor then needs to support the [driver] section and can see whether it should force-bind another driver than the default. Or even better, if you have multiple tags for tablets, like TAG_TABLET and TAG_WACOM_TABLET, you can define both on wacom tablets but only TAG_TABLET on other random tablets. Then bind the normal tablet/mouse/whatever driver to TAG_TABLET and your wacom driver to TAG_WACOM_TABLET. Of course, TAG_WACOM_TABLET then needs a higher priority than TAG_TABLET. This will work whether the wacom-driver is loaded or not. likewise, as in another part of this thread: the compositor may not care about the distinction between joystick/gamepad but the client may. so again we have two different use-cases and mapping requirements here. Then the compositor just binds it's gaming-device-driver to (TAG_JOYSTICK | TAG_GAMEPAD). A client may use TAG_JOYSTICK or TAG_GAMEPAD separately. I don't see the problem here? so the tagging library would have to tag a device not just as graphics tablet but more as input module selection library. which again, means it's a library version of input_id and Match*, etc. what you will also need then is for drivers to provide hooks to notify what they can deal with. i.e. libtouchpadcommon needs to install data files for libinputmapper to notify that it's now taking over touchpads. I wanted to keep this private to the compositor. So the compositor has a list of drivers and a libinputmapper context. It then retrieves the tags for a device and assigns the device depending on the tags to the right driver. So libinputmapper always returns the same information. It's up to the compositor to use this according to it's capabilities. Or what would be the
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi On Thu, May 23, 2013 at 7:32 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, May 21, 2013 at 04:30:03PM +0200, David Herrmann wrote: Hi Peter On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: Hi Peter On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [..] So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it doesn't work. if you want a mapping table, you need a per-client table because sooner or later you have a client that needs BTN_FOO when the kernel gives you BTN_BAR and you can't change the client to fix it. i.e. the same issue evdev has now, having a global remapping table just moves the problem down by 2 years. a mapping table is good, but you probably want two stages of mapping: one that's used in the compositor for truly broken devices that for some reason can't be fixed in the kernel, and one that's used on a per-client basis. and you'll likely want to be able to overide the client-specific from outside the client too. IMHO, the problem with evdev is, that it doesn't provide device classes. The only class we have is this is an input device. All other event-flags can be combined in whatever way we want. So like 10 years ago when the first gamepad driver was introduced, we added some mapping that was unique to this device (the device was probably unique, too). Some time later, we added some other gamepad-like driver with a different mapping (as it was probably a very different device-type, back then, and we didn't see it coming that this will become a wide-spread device-type). However, today we notice that a GamePad is an established type of device (like a touchpad), but we have tons of different mappings in the kernel for backwards-compatibility reasons. I can see that this kind of development can happen again (and very likely it _will_ happen again) and it will happen for all kinds of devices. But that's why I designed the proposal from a compositor's view instead of from a kernel's view. A touchpad driver of the compositor needs to know exactly what kind of events it gets from the kernel. If it gets wrong events, it will misbehave. As we cannot guarantee that all kernel drivers behave the same way, the compositor's touchpad driver needs to work around all these little details on a per-device basis. To avoid this, I tried to abstract the touchpad-protocol and moved per-device handling into a separate library. It detects all devices that can serve as a touchpad and fixes trivial (1-to-1 mapping) incompatibilities. This removes all per-device handling from the touchpad driver and it can expect all input it gets to be conform with a touchpad protocol. And in fact, it removes this from all the compositor's input drivers. So I think of it more like a lib-detect-and-make-compat. All devices that do not fall into one of the categories (I called it capability), will be handled as custom devices. So if we want an input driver for a new fancy device, then we need a custom driver, anyway (or adjust a generic driver to handle both). If at some point it turns out, that this kind of device becomes more established, we can add a new capability for it. Or we try extending an existing capability in a backwards-compatible way. We can then remove the custom-device handling from
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Wed, May 22, 2013 at 12:25:19AM -0400, Rick Yorgason wrote: On 2013-05-20 23:56, Peter Hutterer wrote: what I am wondering is whether that difference matters to the outside observer (i.e. the compositor). a gamepad and a joystick are both gaming devices and with the exception of the odd need to control the pointer it doesn't matter much which type they are. as for a game that would access the device - does it matter if the device is labelled gamepad or joystick? if it's a gaming device you have to look at the pysical properties anyway and decide which you use in what matter. That would seem to unnecessarily complicate things. Let's say you want to do something simple, like display a list of the devices plugged into the computer, with a graphic showing the device type. If you don't have separate gamepad and joystick types, you would need to use some heuristic to decide whether to show the gamepad or joystick graphic. Really, the device driver should be able to tell us what kind of device it considers itself. you don't need to differ between gamepad and joystick for that. to take the wacom example (again), we want those devices to show themselves with the right graphics for the tablet series* - they're still all tablets as far as compositors and clients are concerned. so the driver that handles the device can provide the graphics. you could subgroup categories, or have a tag hierarchy to categorise appropriately. in any case,this is conflating the concept of a library to map drivers to devices with a library to tag devices in a client-visible way. Cheers, Peter * the OS X driver does that, and libwacom + latest GNOME too Granted, we can't do that right now, because the kernel doesn't expose device types, which is something that should probably be resolved regardless of what happens with libinputmapper. In the meantime, we can put the heuristic in libinputmapper, and if the kernel ever grows the ability to expose device types, we can remove the heuristic all together (or maybe demote it to a backup strategy). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Tue, May 21, 2013 at 04:30:03PM +0200, David Herrmann wrote: Hi Peter On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: Hi Peter On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [..] So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it doesn't work. if you want a mapping table, you need a per-client table because sooner or later you have a client that needs BTN_FOO when the kernel gives you BTN_BAR and you can't change the client to fix it. i.e. the same issue evdev has now, having a global remapping table just moves the problem down by 2 years. a mapping table is good, but you probably want two stages of mapping: one that's used in the compositor for truly broken devices that for some reason can't be fixed in the kernel, and one that's used on a per-client basis. and you'll likely want to be able to overide the client-specific from outside the client too. IMHO, the problem with evdev is, that it doesn't provide device classes. The only class we have is this is an input device. All other event-flags can be combined in whatever way we want. So like 10 years ago when the first gamepad driver was introduced, we added some mapping that was unique to this device (the device was probably unique, too). Some time later, we added some other gamepad-like driver with a different mapping (as it was probably a very different device-type, back then, and we didn't see it coming that this will become a wide-spread device-type). However, today we notice that a GamePad is an established type of device (like a touchpad), but we have tons of different mappings in the kernel for backwards-compatibility reasons. I can see that this kind of development can happen again (and very likely it _will_ happen again) and it will happen for all kinds of devices. But that's why I designed the proposal from a compositor's view instead of from a kernel's view. A touchpad driver of the compositor needs to know exactly what kind of events it gets from the kernel. If it gets wrong events, it will misbehave. As we cannot guarantee that all kernel drivers behave the same way, the compositor's touchpad driver needs to work around all these little details on a per-device basis. To avoid this, I tried to abstract the touchpad-protocol and moved per-device handling into a separate library. It detects all devices that can serve as a touchpad and fixes trivial (1-to-1 mapping) incompatibilities. This removes all per-device handling from the touchpad driver and it can expect all input it gets to be conform with a touchpad protocol. And in fact, it removes this from all the compositor's input drivers. So I think of it more like a lib-detect-and-make-compat. All devices that do not fall into one of the categories (I called it capability), will be handled as custom devices. So if we want an input driver for a new fancy device, then we need a custom driver, anyway (or adjust a generic driver to handle both). If at some point it turns out, that this kind of device becomes more established, we can add a new capability for it. Or we try extending an existing capability in a backwards-compatible way. We can then remove the custom-device handling from the input-driver and instead extend/write a generic driver for the new capability.
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: Hi Peter On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [..] So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it doesn't work. if you want a mapping table, you need a per-client table because sooner or later you have a client that needs BTN_FOO when the kernel gives you BTN_BAR and you can't change the client to fix it. i.e. the same issue evdev has now, having a global remapping table just moves the problem down by 2 years. a mapping table is good, but you probably want two stages of mapping: one that's used in the compositor for truly broken devices that for some reason can't be fixed in the kernel, and one that's used on a per-client basis. and you'll likely want to be able to overide the client-specific from outside the client too. IMHO, the problem with evdev is, that it doesn't provide device classes. The only class we have is this is an input device. All other event-flags can be combined in whatever way we want. So like 10 years ago when the first gamepad driver was introduced, we added some mapping that was unique to this device (the device was probably unique, too). Some time later, we added some other gamepad-like driver with a different mapping (as it was probably a very different device-type, back then, and we didn't see it coming that this will become a wide-spread device-type). However, today we notice that a GamePad is an established type of device (like a touchpad), but we have tons of different mappings in the kernel for backwards-compatibility reasons. I can see that this kind of development can happen again (and very likely it _will_ happen again) and it will happen for all kinds of devices. But that's why I designed the proposal from a compositor's view instead of from a kernel's view. A touchpad driver of the compositor needs to know exactly what kind of events it gets from the kernel. If it gets wrong events, it will misbehave. As we cannot guarantee that all kernel drivers behave the same way, the compositor's touchpad driver needs to work around all these little details on a per-device basis. To avoid this, I tried to abstract the touchpad-protocol and moved per-device handling into a separate library. It detects all devices that can serve as a touchpad and fixes trivial (1-to-1 mapping) incompatibilities. This removes all per-device handling from the touchpad driver and it can expect all input it gets to be conform with a touchpad protocol. And in fact, it removes this from all the compositor's input drivers. So I think of it more like a lib-detect-and-make-compat. All devices that do not fall into one of the categories (I called it capability), will be handled as custom devices. So if we want an input driver for a new fancy device, then we need a custom driver, anyway (or adjust a generic driver to handle both). If at some point it turns out, that this kind of device becomes more established, we can add a new capability for it. Or we try extending an existing capability in a backwards-compatible way. We can then remove the custom-device handling from the input-driver and instead extend/write a generic driver for the new capability. So I cannot follow how you think this will have the same problems as evdev? Or, let's ask the inverse question: How does this differ from the X11 model where we move
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On 2013-05-20 23:56, Peter Hutterer wrote: what I am wondering is whether that difference matters to the outside observer (i.e. the compositor). a gamepad and a joystick are both gaming devices and with the exception of the odd need to control the pointer it doesn't matter much which type they are. as for a game that would access the device - does it matter if the device is labelled gamepad or joystick? if it's a gaming device you have to look at the pysical properties anyway and decide which you use in what matter. That would seem to unnecessarily complicate things. Let's say you want to do something simple, like display a list of the devices plugged into the computer, with a graphic showing the device type. If you don't have separate gamepad and joystick types, you would need to use some heuristic to decide whether to show the gamepad or joystick graphic. Really, the device driver should be able to tell us what kind of device it considers itself. Granted, we can't do that right now, because the kernel doesn't expose device types, which is something that should probably be resolved regardless of what happens with libinputmapper. In the meantime, we can put the heuristic in libinputmapper, and if the kernel ever grows the ability to expose device types, we can remove the heuristic all together (or maybe demote it to a backup strategy). -Rick- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Thu, May 16, 2013 at 08:38:44AM -0400, Todd Showalter wrote: On Thu, May 16, 2013 at 1:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: why are gamepads and joysticks different? buttons, a few axes that may or may not map to x/y and the rest is device-specific. this may be in the thread, but I still haven't gone through all msgs here. Joysticks are designed for a different purpose (flight sims), and so have a different set of controls. For example, on a lot of joysticks there is a throttle, which is a constrained axis you can set to any position and it will stay there until you move it again. Button placement on joysticks tends to be more arbitrary as well. In terms of raw functionality they're similar, but the differences are large enough (especially in the way they're used) that they are better treated separately. what I am wondering is whether that difference matters to the outside observer (i.e. the compositor). a gamepad and a joystick are both gaming devices and with the exception of the odd need to control the pointer it doesn't matter much which type they are. as for a game that would access the device - does it matter if the device is labelled gamepad or joystick? if it's a gaming device you have to look at the pysical properties anyway and decide which you use in what matter. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: Hi Peter On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [..] So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it doesn't work. if you want a mapping table, you need a per-client table because sooner or later you have a client that needs BTN_FOO when the kernel gives you BTN_BAR and you can't change the client to fix it. i.e. the same issue evdev has now, having a global remapping table just moves the problem down by 2 years. a mapping table is good, but you probably want two stages of mapping: one that's used in the compositor for truly broken devices that for some reason can't be fixed in the kernel, and one that's used on a per-client basis. and you'll likely want to be able to overide the client-specific from outside the client too. IMHO, the problem with evdev is, that it doesn't provide device classes. The only class we have is this is an input device. All other event-flags can be combined in whatever way we want. So like 10 years ago when the first gamepad driver was introduced, we added some mapping that was unique to this device (the device was probably unique, too). Some time later, we added some other gamepad-like driver with a different mapping (as it was probably a very different device-type, back then, and we didn't see it coming that this will become a wide-spread device-type). However, today we notice that a GamePad is an established type of device (like a touchpad), but we have tons of different mappings in the kernel for backwards-compatibility reasons. I can see that this kind of development can happen again (and very likely it _will_ happen again) and it will happen for all kinds of devices. But that's why I designed the proposal from a compositor's view instead of from a kernel's view. A touchpad driver of the compositor needs to know exactly what kind of events it gets from the kernel. If it gets wrong events, it will misbehave. As we cannot guarantee that all kernel drivers behave the same way, the compositor's touchpad driver needs to work around all these little details on a per-device basis. To avoid this, I tried to abstract the touchpad-protocol and moved per-device handling into a separate library. It detects all devices that can serve as a touchpad and fixes trivial (1-to-1 mapping) incompatibilities. This removes all per-device handling from the touchpad driver and it can expect all input it gets to be conform with a touchpad protocol. And in fact, it removes this from all the compositor's input drivers. So I think of it more like a lib-detect-and-make-compat. All devices that do not fall into one of the categories (I called it capability), will be handled as custom devices. So if we want an input driver for a new fancy device, then we need a custom driver, anyway (or adjust a generic driver to handle both). If at some point it turns out, that this kind of device becomes more established, we can add a new capability for it. Or we try extending an existing capability in a backwards-compatible way. We can then remove the custom-device handling from the input-driver and instead extend/write a generic driver for the new capability. So I cannot follow how you think this will have the same problems as evdev? Or, let's ask the inverse question: How does this differ from the X11 model where we move the custom device handling into the drivers? first of all - I do agree with all of the
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Thu, May 16, 2013 at 1:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: why are gamepads and joysticks different? buttons, a few axes that may or may not map to x/y and the rest is device-specific. this may be in the thread, but I still haven't gone through all msgs here. Joysticks are designed for a different purpose (flight sims), and so have a different set of controls. For example, on a lot of joysticks there is a throttle, which is a constrained axis you can set to any position and it will stay there until you move it again. Button placement on joysticks tends to be more arbitrary as well. In terms of raw functionality they're similar, but the differences are large enough (especially in the way they're used) that they are better treated separately. Todd. -- Todd Showalter, President, Electron Jump Games, Inc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [..] So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it doesn't work. if you want a mapping table, you need a per-client table because sooner or later you have a client that needs BTN_FOO when the kernel gives you BTN_BAR and you can't change the client to fix it. i.e. the same issue evdev has now, having a global remapping table just moves the problem down by 2 years. a mapping table is good, but you probably want two stages of mapping: one that's used in the compositor for truly broken devices that for some reason can't be fixed in the kernel, and one that's used on a per-client basis. and you'll likely want to be able to overide the client-specific from outside the client too. IMHO, the problem with evdev is, that it doesn't provide device classes. The only class we have is this is an input device. All other event-flags can be combined in whatever way we want. So like 10 years ago when the first gamepad driver was introduced, we added some mapping that was unique to this device (the device was probably unique, too). Some time later, we added some other gamepad-like driver with a different mapping (as it was probably a very different device-type, back then, and we didn't see it coming that this will become a wide-spread device-type). However, today we notice that a GamePad is an established type of device (like a touchpad), but we have tons of different mappings in the kernel for backwards-compatibility reasons. I can see that this kind of development can happen again (and very likely it _will_ happen again) and it will happen for all kinds of devices. But that's why I designed the proposal from a compositor's view instead of from a kernel's view. A touchpad driver of the compositor needs to know exactly what kind of events it gets from the kernel. If it gets wrong events, it will misbehave. As we cannot guarantee that all kernel drivers behave the same way, the compositor's touchpad driver needs to work around all these little details on a per-device basis. To avoid this, I tried to abstract the touchpad-protocol and moved per-device handling into a separate library. It detects all devices that can serve as a touchpad and fixes trivial (1-to-1 mapping) incompatibilities. This removes all per-device handling from the touchpad driver and it can expect all input it gets to be conform with a touchpad protocol. And in fact, it removes this from all the compositor's input drivers. So I think of it more like a lib-detect-and-make-compat. All devices that do not fall into one of the categories (I called it capability), will be handled as custom devices. So if we want an input driver for a new fancy device, then we need a custom driver, anyway (or adjust a generic driver to handle both). If at some point it turns out, that this kind of device becomes more established, we can add a new capability for it. Or we try extending an existing capability in a backwards-compatible way. We can then remove the custom-device handling from the input-driver and instead extend/write a generic driver for the new capability. So I cannot follow how you think this will have the same problems as evdev? Or, let's ask the inverse question: How does this differ from the X11 model where we move the custom device handling into the drivers? libinputmapper would use some static heuristics for all this, but additionally parse user-configuration. A configuration file contains [match] entries, which specify device-configurations to load
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
David Herrmann wrote: /** * @INMAP_CAP_ACCELEROMETER * Accelerometer interface * * Accelerometer devices report linear acceleration data as ABS_X/Y/Z * and rotational acceleration as ABS_RX/Y/Z. * * @TODO this collides with ABS_X/Y of absolute pointing devices * introduce ABS_ACCELX/Y/Z */ If actual position is called ABS_X and the first derivative is called REL_X, then it does not make sense for the second derivative to be called ABS again. The events should be called ACCEL_X or REL_REL_X or REL2_X. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: [bcc to gnome-shell-list and kwin, to keep discussion on wayland-devel] Without a generic graphics-server like xserver, compositors need to handle input devices themselves if run as wayland compositors. To avoid having several different conflicting implementations, I wrote up a small proposal and library API to have a common configuration. How is it currently handled? A compositor uses udev to listen for input devices. For each input-device, they use some heuristics (test for KEY_*, ABS_*, .. event-bits) to figure out what kind of input is provided by the device. Unknown devices and events are ignored, devices that look useful are passed to the correct input-driver. For keyboard input, libxkbcommon is used. For mouse/touchpad/touchscreen input, every compositor has it's own simple driver (I am not aware of an attempt to put xf86-input-synaptics into an independent library). fwiw, I tried this once, but the amount of legacy junk in the X driver is large enough that it would be better writing synaptics from scratch as a library and hook that up instead. For other device types, applications handle input themselves (gamepads, joysticks, and so on). And then there are devices that have x11 drivers, but I am not aware of external drivers for wayland-compositors (like wacom digitizers). I am not interested in the device-drivers itself (for now in this project). I think it would be nice to write a libsynapticscommon, ftr, please don't name such an effort synaptics. the name in the X driver is historical and should be changed, so libtouchpad is a better name. libmousecommon, .. which provide a libxkbcommon'ish interface for other device types independent of the compositor implementation, but that's another independent issue. Instead, I am more interested in the device-detection and enumeration. If I plug in a gamepad device, I don't want _any_ compositor to handle it as a mouse, just because it provides REL_X/Y values. I don't want compositors to erroneously handle accelerometers as mice because they provide ABS_X/Y values. But on the other hand, I want users to be able to tell compositors to handle ABS_X/Y input from their custom hardware as mouse input, _iff_ they want to. Furthermore, if a device has a buggy kernel driver and reports BTN_X instead of BTN_A, I want all compositors to detect that and apply a simple fixup button-mapping. Or allow users to remap buttons/axis/LEDs/EV_WHATEVER arbitrarily. udev provides some very basic heuristics with device-tags, but talking to Kay Sievers, he'd like to avoid having huge detection-tables and heuristics in udev (which is understandable). Dmitry Torokhov is not averse to providing device-type properties in the kernel input-subsystem, but on the other hand, it doesn't help us much. Generic HID devices might still provide any arbitrary input that we would have to write custom drivers/quirks for, if they don't match. So if no-one steps up to do all that work, I recommend providing these fixups in user-space. This also has the advantage, that users can arbitrarily modify these rules if they want crazy setups (which users normally want..). And we can ship fixup-rules for new devices, while in the meantime writing kernel drivers for them and waiting for the next kernel release. And don't forget the kernel drivers with broken mappings, which we cannot fix due to backwards-compatibility, but still want them to be correctly mapped in new compositors/applications. So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. libinputmapper provides an inmap_evdev object which reads device information from an evdev-fd or sysfs /sys/class/input/inputnum path, performs some heuristics to classify it and searches it's global database for known fixups for broken devices. It then provides capabilities to the caller, which allow them to see what drivers to load on the device. And it provides a very simple mapping table that allows to apply fixup mappings for broken devices. These mappings are simple 1-to-1 mappings that are supposed to be applied before drivers handle the input. This is to avoid device-specific fixup in the drivers and move all this to the inputmapper. An example would be a remapping for gamepads that report BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for backwards-compatibility reasons. The gamepad-driver can then assume that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and doesn't need to special case xbox360/etc. controllers, because they're broken. I think evdev is exactly that interface and apparently it
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Sun, May 12, 2013 at 10:20 AM, David Herrmann dh.herrm...@gmail.com wrote: So what is the proposed solution? My recommendation is, that compositors still search for devices via udev and use device drivers like libxkbcommon. So linux evdev handling is still controlled by the compositor. However, I'd like to see something like my libinputmapper proposal being used for device detection and classification. [8] I could work with this. Right now I'm somewhat tackling the whole problem head-on; I've got a server with an inotify watch on /dev/input that binds a udp port. Connect to the udp port, get a stream of events for all devices the server cares about (which in my case is gamepads), with suitable remapping. The idea isn't necessarily to do things precisely that way, it's more a proof of concept tool; it's easy enough to replace the udp socket with a fifo or just jack it in to something as a back-end. Likewise, it could just be processing data streams rather than dealing directly with /dev/input. The remapping could also be sourced out to your library. I haven't had as much time to devote to it as I'd like, but I'm hoping I can get the code up soon. Todd. -- Todd Showalter, President, Electron Jump Games, Inc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
