From: Frank Praznik <frank.praznik@gmail.com>
To: bri <bri@abrij.org>
Cc: Antonio Ospite <ao2@ao2.it>, Jiri Kosina <jkosina@suse.cz>,
Henrik Rydberg <rydberg@euromail.se>,
open@abrij.org, HID CORE LAYER <linux-input@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning
Date: Mon, 17 Nov 2014 22:21:53 -0500 [thread overview]
Message-ID: <546ABB51.4010905@gmail.com> (raw)
In-Reply-To: <20141118000005.GA32256@abrij.org>
Hi Brian,
On 11/17/2014 19:00, bri wrote:
>
>> Yeah, the device ID in the driver is only for tracking devices internally
>> and setting sane default LED values. It has no meaning outside of the
>> module. Like Antonio said, if you want the system number for a controller
>> you are better off just getting it from the joystick device.
> Would you be amenable to a patch that removes the IDA entirely and just sets
> the LEDs to all solid-on? Since the LEDs are available through sysfs,
> udev rule could probably be made to set the LEDs in the absence of bluez
> or a higher level controller manager, and then it becomes the distro's
> responsibility.
>
What would be the benefit of doing this? Nothing is stopping higher
level services from setting the LEDs right now. The driver just sets
sane defaults for systems that don't have anything else to set the
'real' values. Other controllers like Wiimotes and Xbox gamepads do the
same thing. It doesn't get in the way of services like BlueZ setting
them once initialization is complete.
Leaving it completely up to the distro just means that there will be
situations where there is nothing to set the default values which makes
for a bad user experience.
next prev parent reply other threads:[~2014-11-18 3:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 18:18 [PATCH 001/001] hid-sony.c: add sysfs provisioning bri
2014-11-17 12:35 ` Antonio Ospite
2014-11-18 2:01 ` bri
2014-11-18 22:43 ` Antonio Ospite
2014-11-19 0:13 ` bri
[not found] ` <546A4EF7.903@gmail.com>
[not found] ` <20141118000005.GA32256@abrij.org>
2014-11-18 3:21 ` Frank Praznik [this message]
2014-11-18 14:26 ` bri
2014-11-18 22:30 ` Antonio Ospite
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546ABB51.4010905@gmail.com \
--to=frank.praznik@gmail.com \
--cc=ao2@ao2.it \
--cc=bri@abrij.org \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=open@abrij.org \
--cc=rydberg@euromail.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).