On Tue, Sep 02, 2014 at 04:50:53PM +0200, David Herrmann wrote: > Hi > > On Tue, Sep 2, 2014 at 4:40 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > On 09/02/2014 02:55 PM, David Herrmann wrote: > >> Hi > >> > >> On Tue, Sep 2, 2014 at 2:43 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >>> Hi, > >>> > >>> It is useful for userspace to know that they're not dealing with a regular > >>> mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace > >>> can e.g. automatically enable middle button scrollwheel emulation. > >>> > >>> It is impossible to tell the difference from the evdev info without resorting > >>> to putting a list of device / driver names in userspace, this is undesirable. > >> > >> ..so it is better to put that table into the kernel? > > > > No not a table, at the kernel level we actually have different drivers > > for pointer sticks and for other mouse (and mouse like devices), so this is > > a simple matter of adding a single line of code to all of 4 drivers. > > > > We could have a table in userspace matching the driver/model strings used > > by those 4 drivers, but what if a 5th pops up ? > > Ok, for now it's pretty easy as all "pointing stick" drivers are > already separate in the kernel. But imagine a new generation of > "pointing stick" devices is an HID device handled by hid-input.c. What > do you do? To set the INPUT_PROPERTY bit, you need to add a driver for > this vid/did combination. Seems overkill, so we'd probably not set > this property bit for this device and let user-space deal with it. Now > we end up with two places to store such information. right now, there's no ioctl to set a property on a device. that'd be a requirement for a udev hwdb-like thing, unless you want clients to rely on pulling the information from two places and merging it in some strategy that's not well defined yet. I'm all for a userspace hwdb, but this is some bigger project that afaik hasn't been worked on beyond the libinputmapper discussions we had a year or so ago. Cheers, Peter > We already fix scancode/keycode mappings via hwdb as it would be > excessive to write kernel drivers for all devices just to fix those. > Imo, device properties are very similar to this. We have to draw a > line between properties the kernel should detect and expose, and > properties we detect in user-space. We already gave up defining ABS_ > axes for everything (I mean, we report all kinds of data via ABS_X, > ranging from trackpad, to pressure and accelerometer data). User-space > needs to detect what devices it deals with, to know what the different > axes event-bits mean. > > Yeah, the POINTING_STICK property turns out to be trivial, so please > go ahead. I just want to remind you, that we need a user-space > database, anyway. And hwdb entries can be added via simple distro > updates (even users can regenerate it themselves). Kernel driver > changes are way more heavy.. and slow. > > Thanks > David > -- -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
