[systemd-devel] [PATCH] hwdb: add a new db for the DPI/frequency settings of mice

[Peter Hutterer]

On Wed, Nov 26, 2014 at 01:10:10AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 26, 2014 at 01:01:30AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Nov 26, 2014 at 07:30:51AM +1000, Peter Hutterer wrote:
> > > On Tue, Nov 25, 2014 at 02:56:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Tue, Nov 25, 2014 at 09:35:16PM +1000, Peter Hutterer wrote:
> > > > > Pointer acceleration for relative input devices (mice, trackballs, etc.)
> > > > > applies to the deltas of the device. Alas, those deltas have no physical
> > > > > reference point - a delta of 10 may be caused by a large movement of a low-dpi
> > > > > mouse or by a minute movement of a high-dpi mouse.
> > > > > Which makes pointer acceleration a bit useless and high-dpi devices
> > > > > essentially unusable.
> > > > > 
> > > > > In an ideal world, we could read the DPI from the device directly and work
> > > > > with that. In the world we actually live in, we need to compile this list
> > > > > manually. This patch introduces the database, with the usual match formats and
> > > > > a single property to be set on a device: MOUSE_DPI
> > > > > 
> > > > > That is either a single value for most mice, or a list of values for mice that
> > > > > can change resolution at runtime. The exact format is detailed in the hwdb
> > > > > file.
> > > > > 
> > > > > Note that we're explicitly overshooting the requirements we have for libinput
> > > > > atm. Frequency could be detected in software and we don't actually use the
> > > > > list of multiple resolutions (because we can't detect when they change
> > > > > anyway). However, we might as well collect those values from the get-go,
> > > > > adding/modifying what will eventually amount to hundreds of entries is a
> > > > > bit cumbersome.
> > > > > 
> > > > > Note: we rely on the input_id builtin to tag us as mouse first, ordering of
> > > > > the rules is important.
> > > > > ---
> > > > >  Makefile.am          |  4 ++-
> > > > >  rules/70-mouse.hwdb  | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  rules/70-mouse.rules | 15 +++++++++
> > > > >  3 files changed, 110 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 rules/70-mouse.hwdb
> > > > >  create mode 100644 rules/70-mouse.rules
> > > > > 
> > > > > diff --git a/Makefile.am b/Makefile.am
> > > > > index 3f9f3fa..d2b0d02 100644
> > > > > --- a/Makefile.am
> > > > > +++ b/Makefile.am
> > > > > @@ -3285,6 +3285,7 @@ dist_udevrules_DATA += \
> > > > >  	rules/50-udev-default.rules \
> > > > >  	rules/60-drm.rules \
> > > > >  	rules/60-keyboard.rules \
> > > > > +	rules/70-mouse.rules \
> > > > >  	rules/60-persistent-storage-tape.rules \
> > > > >  	rules/60-persistent-serial.rules \
> > > > >  	rules/60-persistent-input.rules \
> > > > > @@ -3311,7 +3312,8 @@ dist_udevhwdb_DATA = \
> > > > >  	hwdb/20-acpi-vendor.hwdb \
> > > > >  	hwdb/20-OUI.hwdb \
> > > > >  	hwdb/20-net-ifname.hwdb \
> > > > > -	hwdb/60-keyboard.hwdb
> > > > > +	hwdb/60-keyboard.hwdb \
> > > > > +	hwdb/70-mouse.hwdb
> > > > Wouldn't 60-mouse be more appropriate? It is very similar to 60-keyboard.
> > > 
> > > I had that at first but 60-mouse sorts before 60-persistent-input.rules and
> > > we partially rely on that, specifically the line
> > > SUBSYSTEMS=="usb", ENV{ID_BUS}=="", IMPORT{builtin}="usb_id"
> > > 
> > > Want me to add that line to this ruleset here, or should we leave the
> > > sorting as-is?
> > I think you should *move* it to 60-mouse.rules.
> > It seems better for something specific like persistent-input to depend
> > on something generic like mouse.
> > 
> > 60-persistent-input.rules has SUBSYSTEMS=="bluetooth", GOTO="persistent_input_end".
> > That'd skip bluetooth which you need.
> Scratch that. I don't think you need to move anything, because you
> don't rely on anything from 60-persistent-input.rules. ID_INPUT_MOUSE
> is provided by IMPORT{builtin}="input_id" which is run in
> 50-udev-default.rules.

yeah, what we need is the usb_id builtin though. That is run by the defaults
but only for devtype usb_device. The event nodes don't have that devtype
set. And moving the above line from 60-persistent-input would break things
since over there they get run for SUBSYSTEM=input, not the event nodes.

Cheers,
   Peter