From: Eduard Hasenleithner <eduard@hasenleithner.at>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH] Wacom Intuos4 LED and OLED control
Date: Fri, 06 May 2011 18:28:47 +0200 [thread overview]
Message-ID: <4DC421BF.9020204@hasenleithner.at> (raw)
In-Reply-To: <20110506155204.GA4754@core.coreip.homeip.net>
Hi Dmitry.
On 2011-05-06 17:52, Dmitry Torokhov wrote:
>> This "led" group only shows up when the correct device (M, L,
>> or XL) is detected. Four write-only attributes are created:
>> * "luminance":
>> array of three integers specfying
>> * status led brightness when no button is pressed (0..127)
>> * status led brightness when a button is pressed (0..127)
>> * brightness of the OLED display (0..15)
>
> This violates "one value per attribute" sysfs principle. I think these
> should be split into brightness on, brightness off, and display brightness.
The intention behind grouping these three together is that on the
USB-protocol level they are always set at the same time. Furthermore, on
the logical level they are very closely related. I have seen some other
driver doing it like that: Writing individual settings into different
properties, and then activating them at the same time by means of some
"tigger" property. Would you be fine with that?
> I also wonder if status LED should be wired into LED subsystem... Not
> sure though... The tablet does not allow controlling when LEDs are
> activated, does it?
I'm not sure what you mean with "controlling". You can set the status
LED at any time, other functions are not affected (at least as far I
know.) But I would perfer of not putting the LED into the LED subsystem
for several reasons:
1. It is harder from user-space to get the connection
between LED-Device and Tablet-device
2. yet another interface to support in Kernel and User-Space, and
3. the four status LEDs are exclusive, only one of them can be
"on" at a time.
>> * "status_select":
>> specifies the id (0..3) of the status led, -1 = none
>
> I think we should create 4 separate groups led0 .. led3 each containing
> the attributes above instead of implementing the selector which is
> inherently racy.
It selects the led which is "on", the others are implicitly off. So for
the status led, there are five different settings, either 0..3, or -1
for all LEDs to be off. Maybe "selector" is not the best naming?
>> * "button_select":
>> specifies the button id (0..7) of the image
>> * "button_rawimg":
>> sets the raw image data of the button (binary, 1024 octets)
>
> Same here, create as many binary attributes as needed (probably putting
> into separate group).
Well "button_select" is different from "status_select". While
status_select actually does something (change which led is on),
button_select just pre-sets which button image will be overwritten at
the next write.
I will change the interface to have "buttonN_rawimg" parameters, where N
is the button number.
> Also please document these attributes in
> Documentation/ABI/testing/sysfs-wacom
I was already planning to add this to this patch, but hesitated to do it
because the "README" tells to add the documentation when "interfaces are
felt to be stable as the main development of this interface has been
completed". Since we are still discussing the interface, I got the
feeling it is not yet "stable".
Thanks for your comments,
Eduard
next prev parent reply other threads:[~2011-05-06 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 22:54 [PATCH] Wacom Intuos4 LED and OLED control Eduard Hasenleithner
2011-04-13 9:08 ` Eduard Hasenleithner
2011-05-06 15:52 ` Dmitry Torokhov
2011-05-06 16:28 ` Eduard Hasenleithner [this message]
2011-05-06 16:43 ` Dmitry Torokhov
2011-05-06 17:32 ` Eduard Hasenleithner
2011-05-06 17:42 ` Dmitry Torokhov
2011-05-06 17:57 ` Eduard Hasenleithner
2011-06-02 9:51 ` San Vu Ngoc
[not found] ` <BANLkTi=E4BEpF0G90q4zNHtVLvpTDhWtvA@mail.gmail.com>
[not found] ` <20110817071724.GF29361@core.coreip.homeip.net>
2011-09-02 21:48 ` Eduard Hasenleithner
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=4DC421BF.9020204@hasenleithner.at \
--to=eduard@hasenleithner.at \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
/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).