Bug 102461 - psmouse doesn't create attributes when it should
Summary: psmouse doesn't create attributes when it should
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-07 20:28 UTC by sophusmeidell
Modified: 2017-08-31 18:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.1.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description sophusmeidell 2015-08-07 20:28:12 UTC
The psmouse driver does not create the attributes before userspace is notified of a (all or some?) device's presence. For instance, this causes a udev rule to adjust the speed and sensitivity of a trackpoint not to trigger.

Reference: https://github.com/systemd/systemd/commit/f2b8052fb648b788936dd3e85be6a9aca90fbb2f#commitcomment-12251878
Comment 1 Dmitry Torokhov 2015-08-07 20:38:53 UTC
We can wish as much as we want for all attributes to be created upfront, but it is not going to happen. Quite often attributes are added to the device by the driver that is bound to it (because without the driver nobody knows how to control hardware behavior). I think the only workable solution is to add an additional uevent (or piggy-back on KOBJ_CHNAGE) that we'd emit once driver is bound to the device, and have udev allow triggering on it.
Comment 2 Dmitry Torokhov 2017-08-31 18:41:07 UTC
We have BIND/UNBIND uevents now, for driver-specific attributes userspace should listen to them:

commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Jul 19 17:24:30 2017 -0700

    driver core: emit uevents when device is bound to a driver
    
    There are certain touch controllers that may come up in either normal
    (application) or boot mode, depending on whether firmware/configuration is
    corrupted when they are powered on. In boot mode the kernel does not create
    input device instance (because it does not necessarily know the
    characteristics of the input device in question).
    
    Another number of controllers does not store firmware in a non-volatile
    memory, and they similarly need to have firmware loaded before input device
    instance is created. There are also other types of devices with similar
    behavior.
    
    There is a desire to be able to trigger firmware loading via udev, but it
    has to happen only when driver is bound to a physical device (i2c or spi).
    These udev actions can not use ADD events, as those happen too early, so we
    are introducing BIND and UNBIND events that are emitted at the right
    moment.
    
    Also, many drivers create additional driver-specific device attributes
    when binding to the device, to provide userspace with additional controls.
    The new events allow userspace to adjust these driver-specific attributes
    without worrying that they are not there yet.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Note You need to log in before you can comment on or make changes to this bug.