linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).