On 11/08/2016 01:31 PM, Hans de Goede wrote:
> Hi,
>
> On 08-11-16 12:52, Jacek Anaszewski wrote:
>> Hi Hans,
>>
>> I've tested it with userspace test application and it seems to work
>> well both with hardware leds-aat1290 driver and drivers/leds/uleds.c.
&
Hi Hans,
I've tested it with userspace test application and it seems to work
well both with hardware leds-aat1290 driver and drivers/leds/uleds.c.
Applied to the for-next branch of linux-leds.git.
Thanks,
Jacek Anaszewski
On 11/01/2016 02:37 PM, Hans de Goede wrote:
> Add support for u
lution every call
to __led_set_brightness{_blocking} triggered the POLLPRI.
In the discussed approach it will not be the case.
> As wrote in some previous emails, consider "actual_brightness" sysfs
> name which is already used for this purpose by backlight subsystem --
> because fo
the file purpose. I bet that we would
see many questions once the file appeared in the mainline.
Also, I'm afraid that I wouldn't be able to explain this name in
few simple words, without daunting the listener, or even triggering
the discussion on brightness shortcomings we've already
Hi Pali, Glenn,
Thanks for your feedback.
On 11/22/2016 03:58 PM, Pali Rohár wrote:
> On Monday 21 November 2016 14:29:00 Jacek Anaszewski wrote:
>> Let's wait until every involved part agrees (Pavel, Pali).
>
> Ok, I read that discussion on linux-leds ML and finally underst
On 11/24/2016 03:26 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 15:21:36 Jacek Anaszewski wrote:
>> On 11/24/2016 10:15 AM, Pali Rohár wrote:
>>> On Wednesday 23 November 2016 12:01:02 Jacek Anaszewski wrote:
>>>> I would also appreciate your opinio
reading brightness
set in the meantime either by trigger or by userspace. Knowing that
value can be useful in case hardware tries to lower the brightness
level set by the user for some reason (e.g. low battery voltage).
However, I'd tweak the file name a bit, to make it clear
what property t
On 11/24/2016 10:15 AM, Pali Rohár wrote:
> On Wednesday 23 November 2016 12:01:02 Jacek Anaszewski wrote:
>> I would also appreciate your opinion on the other solution to the
>> problem of notifying brightness changes originating from hardware,
>> i.e. hw_brightness_change{
Hi,
On 11/18/2016 07:47 PM, Hans de Goede wrote:
> HI,
>
> On 18-11-16 17:03, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/18/2016 10:07 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 18-11-16 09:55, Jacek Anaszewski wrote:
>>>> Hi Ha
On 11/20/2016 04:05 PM, Pali Rohár wrote:
> On Saturday 19 November 2016 16:44:09 Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/18/2016 07:47 PM, Hans de Goede wrote:
>>> HI,
>>>
>>> On 18-11-16 17:03, Jacek Anaszewski wrote:
>>>> Hi,
>
d its only task is
to generate brightness change notification.
I'd add a file hw_brightness_change or async_brightness or something
similar and make it only readable/pollable. current_brightness is
ambiguous and questionable.
This is quite specific hardware feature so it needs specific hand
Hi,
On 11/21/2016 12:56 PM, Hans de Goede wrote:
> Hi,
>
> On 21-11-16 12:24, Jacek Anaszewski wrote:
>> On 11/21/2016 11:42 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 21-11-16 11:24, Jacek Anaszewski wrote:
>>>> Hi,
>>
perspective. It will be valid until next hw brightness change
occurs.
Current state does not mean current brightness in this case.
--
Best regards,
Jacek Anaszewski
--
Check out the vibr
Hi,
On 11/18/2016 10:07 AM, Hans de Goede wrote:
> Hi,
>
> On 18-11-16 09:55, Jacek Anaszewski wrote:
>> Hi Hans,
>>
>> Thanks for the patch.
>>
>> I think we need less generic trigger name.
>> With present name we pretend that all kbd-backl
Hi Hans,
Thanks for the patch.
I think we need less generic trigger name.
With present name we pretend that all kbd-backlight controllers
can change LED brightness autonomously.
How about kbd-backlight-pollable ?
Best regards,
Jacek Anaszewski
On 11/17/2016 11:24 PM, Hans de Goede wrote
ate from
>> this perspective. It will be valid until next hw brightness change
>> occurs.
>>
>> Current state does not mean current brightness in this case.
>
> Well.. actually... I think this is a little bit over complex and
> probably unneccessary. I'd let
On 11/21/2016 11:42 AM, Hans de Goede wrote:
> Hi,
>
> On 21-11-16 11:24, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/20/2016 05:21 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>>>>>> Thanks for the patch.
>>>>>&
Hi,
On 11/18/2016 10:04 AM, Hans de Goede wrote:
> Hi,
>
> On 18-11-16 09:52, Jacek Anaszewski wrote:
>> Hi Hans,
>>
>> Thanks for the new patch set.
>>
>> On 11/17/2016 11:24 PM, Hans de Goede wrote:
>>> In some cases an LED is controlled th
I'd do the trigger here. It is same way we can handle LEDs on
> thinkpad. Yes, it means you won't be able to do oneshot trigger on
> backlight. I don't think that's a huge problem.
There have been voices in this discussion claiming the opposite. :-)
--
Best regards,
Jacek A
> #define LED_DEV_CAP_FLASH(1 << 18)
> #define LED_HW_PLUGGABLE (1 << 19)
> #define LED_PANIC_INDICATOR (1 << 20)
> +#define LED_TRIGGER_READ_ONLY (1 << 21)
>
> /* set_brightness_work / blink_timer flags, atomic, private. */
> unsig
On 11/24/2016 04:36 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 16:32:06 Jacek Anaszewski wrote:
>> Since it has been reported that POLLPRI notifications on brightness
>> file can lead to increased power consumption, and having my above
>> statement I don't think
rol the LED from userspace, but then there's no way to put
> the LED back to firmware control. That's just broken.
>
> Do you have a proposal how to handle that?
Isn't it under firmware control all the time?
>
>>> So I'd do the tr
On 11/24/2016 05:51 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 17:21:19 Jacek Anaszewski wrote:
>> On 11/24/2016 04:36 PM, Pali Rohár wrote:
>>> On Thursday 24 November 2016 16:32:06 Jacek Anaszewski wrote:
>>>> Since it has been reported that POLLPRI no
On 11/24/2016 10:45 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 22:35:52 Jacek Anaszewski wrote:
>>> I understood that we cannot notify about changes done by CPU
>>> trigger due to high power usage... Or not?
>>
>> Exactly.
>
> So in this case
nism. The other possibility is to allow
for having more than one active trigger for a LED.
We could think of defining a special type of persistent trigger that
would be always enabled.
Best regards,
Jacek Anaszewski
>>> I just tried with leds on thinkpad
>>>
>>> ro
t;
> So... for #1 and #2 something like
>
> led/hardware_changes_brightness
>
> and for #2
>
> led/poll_for_hardware_brightness_change
>
> where poll() wakes the userspace up when the brightness changes, and
> read() can get new brightness...?
Well, it is almost the same as h
/* mic mute LED */
> + NUM_AUDIO_LEDS
> +};
> +
> +#if IS_ENABLED(CONFIG_LEDS_TRIGGER_AUDIO)
> +enum led_brightness ledtrig_audio_get(enum led_audio type);
> +void ledtrig_audio_set(enum led_audio type, enum led_brightness state);
> +#else
&
to decide if it
> should be input6::mute -- because it is on keyboard, or if it is
> sys::mute -- because the key is expected to mute whole system.
drivers/input/input-leds.c seems to already support mute LED.
It will be exposed as inputN::mute.
Documentation/leds/leds-class.txt defines LED naming pattern
to and "sys" does not look as
something resembling device name.
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
problem by appending number after
> "input" word.
>
> I think that driver name or subsystem name would be usable together with
> number.
>
> Userspace application would be probably interested to distinguish
> between "mute led which is part of laptop" and "mute led which is
> available on external USB keyboard".
>
> If external USB keyboard is identified as "input7" device, then
> "input7::mute" is a good name for mute key. But "sys::mute" does not say
> anything to which device or hardware it belongs nor does not solve
> problem that which device/driver/subsystem should have privilege to take
> this "sys" name.
How about just "platform" for the LEDs being part of the device
on which the system is running?
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
eth/adsl/wlan/camera LEDs.
Regarding sound devices - how would we name micmute LED for USB
microphone? I suppose that it is possible to discover some unique
identifier in runtime - this is a question to ALSA people.
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
t is muted.
+
+* System notification
+
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
Two problems here:
- "status-led" is in place of "devicename" instead of "function"
- "-led" is obvious and non-generic - we will have "status"
in the "functions.h"
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+
+Phones usually have multi-color status LED.
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
ng none fixes it.
Kernel 5.1.0-rc1 + some unrelated bits.
Maybe this is manifestation of the possible problem we still
have in the LED core.
I once proposed a patch [0]. You could try if it changes
something in your case.
[0] https://marc.info/?l=linux-kernel&m=151622365715313&w=2
nking on second run. Strange.
Did it work for previous releases? If yes, then bisect should help here.
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/
On 4/27/19 9:34 PM, Pavel Machek wrote:
On Sat 2019-04-27 18:55:37, Jacek Anaszewski wrote:
On 4/26/19 11:42 PM, Pavel Machek wrote:
Hi!
Kernel 5.1.0-rc1 + some unrelated bits.
I tried adding
https://marc.info/?l=linux-kernel&m=151622365715313&q=raw as Jacek
suggested, and it
blink_set &&
+ /* This can sleep */
!led_cdev->blink_set(led_cdev, delay_on, delay_off))
return;
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
ue, we don't
+* want that to be reordered after blink_set()
+*/
+ flush_work(&led_cdev->set_brightness_work);
if (!test_bit(LED_BLINK_ONESHOT, &led_cdev->work_flags) &&
led_cdev->blink_set &&
!led_cdev-&g
me, but it would be good to fix
the bug.
Currently not, so I applied the patch in this shape.
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
ing op")
?
--
Best regards,
Jacek Anaszewski
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
On 5/2/19 10:06 PM, Pavel Machek wrote:
On Thu 2019-05-02 21:28:06, Jacek Anaszewski wrote:
On 5/2/19 9:13 PM, Pavel Machek wrote:
Hi!
+++ b/drivers/leds/led-class.c
@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF
39 matches
Mail list logo
