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

[David Herrmann]

Hi

On Thu, Nov 27, 2014 at 7:06 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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:
[snip]
>> > > 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.

I went ahead and applied the original patch. I amended few fixes:

1) move rules/70-mouse.hwdb into hwdb/ (no idea why you placed it in
rules/, I guess a typo?)

2) fix "60-mouse.hwdb/rule" to "70-mouse.hwdb/rule" in your comments

3) fix "/etc/udev/hwdb.d/60-mouse.hwdb" to
"/etc/udev/hwdb.d/71-mouse-local.hwdb"

4) dropped that extra whitespace in hwdb

I hope no-one minds that I applied it. We can easily move things
around afterwards. It's much easier for someone with -git access to
rename files than for Peter to send patches to fix trivial renames.
And the externally visible stuff is all fine, it's just internal
ordering we don't agree on.

Now, to address the remaining issues: I dislike depending on previous
rule-files to run built-ins, however, we also want to avoid running
built-ins multiple times. We could make builtins no-ops if they're run
more than once, but that will break if they are explicitly run
multiple times. And it adds state that we want to avoid..
So my idea is to add 10-input.rule which runs common builtins for
input devices, which later rules can rely on. persistent-input.rule,
keyboard.rule and mouse.rule can then safely rely on 10-input.rule. Or
we just accept the fact that 70-mouse.rule depends on
60-persistent-input.rule.

Adding Kay to the discussion, maybe he has better ideas..

Thanks
David